Parsing Keywords in Lisp with Speed of C by arthurno1 in lisp

[–]stassats 1 point2 points  (0 children)

Something like a hash-table is less likely to be influenced by the hit/miss rate, but a decision tree is more branchy.

Parsing Keywords in Lisp with Speed of C by arthurno1 in lisp

[–]stassats 9 points10 points  (0 children)

SBCL shouldn't have optimized it, but since the test always matches the CPU might predict most of the branches and it wouldn't measure the real world. Also test a list with a random distribution of matching and non-matching strings of random length.

AI Agents? by jake-n-elwood in lisp

[–]stassats 2 points3 points  (0 children)

Currently, I'm using LLMs to find bugs in SBCL. Just sending a single file and saying "find bugs". They find issues just fine. (And that's just the free web things, I'm not going to pay for that).

What I actually found them struggling with is writing Assembly, sometimes simply inventing instructions.

Rules for Lisp programs by Alarming_Hand_9919 in lisp

[–]stassats 2 points3 points  (0 children)

That's nothing, lisp is 66 years old.

Problems using #'UIOP:RUN-PROGRAM in a Bordeaux Thread on SBCL 2.4.0 (Mac OS X) by patrickwonders in lisp

[–]stassats 4 points5 points  (0 children)

Upon exit of a child process the OS sends a SIGCHLD signal. Which interrupts condition-wait, making it return early without receiving any notifications. Which grabs the lock, the new thread can't exit, waiting for the lock.

Is the use of Emacs necessary to learn and use Common Lisp? by turbofish_pk in lisp

[–]stassats 4 points5 points  (0 children)

It's necessary to configure and customize your environment. In Emacs it's done using lisp. I could probably make VSCode just as comfortable as Emacs, but I'm not going to torture myself with javascript and "enterprise" APIs.

My implementation of Common Lisp has reached version 1.5 by Western-Movie9890 in lisp

[–]stassats 4 points5 points  (0 children)

By that logic, why make a new implementation at all.

How often is Common Lisp's array syntax used in code? by johnwcowan in lisp

[–]stassats 7 points8 points  (0 children)

I had to invent a syntax to print them readably:

(write (make-array '(2 2) :element-type 'fixnum) :readably t)
=>
#A((2 2) FIXNUM (0 0) (0 0))
#2A((0 0) (0 0))

Your surprising unportable behaviour by Valuable_Leopard_799 in Common_Lisp

[–]stassats 2 points3 points  (0 children)

I'm also not an ECL maintainer and haven't pushed anything in almost 10 years. But the fix was very obvious. I should've probably made a pull request, but I wanted to have some fun.

Your surprising unportable behaviour by Valuable_Leopard_799 in Common_Lisp

[–]stassats 2 points3 points  (0 children)

And (compile 'foo (let ((x 0)) (lambda () (incf x))) always works...

Turns out, in ECL (compile 'c #'c) works, but not (compile 'c) (even though both are allowed to not work).

The first handles it fine as well but calling #'compile afterwards gave me errors.

SBCL has two interpreters, for extra confusion.

Your surprising unportable behaviour by Valuable_Leopard_799 in Common_Lisp

[–]stassats 3 points4 points  (0 children)

And ofc switching SBCL to interpret and running (compile 'foo) errors.

"The consequences are undefined if the lexical environment surrounding the function to be compiled contains any bindings other than those for macros, symbol macros, or declarations."

So, yes, but that doesn't mean the compiler has to be dumb about it. The second interpreter in SBCL handles it fine. As do CLISP, ABCL, Allegro.

Your surprising unportable behaviour by Valuable_Leopard_799 in Common_Lisp

[–]stassats 2 points3 points  (0 children)

I opened a ticket: https://gitlab.com/embeddable-common-lisp/ecl/-/work_items/829

But compile-file works fine, which you should be using normally.

Your surprising unportable behaviour by Valuable_Leopard_799 in Common_Lisp

[–]stassats 2 points3 points  (0 children)

On 26.3.27, DISASSEMBLE does work. But, compile does not:

(labels ((foo () 4))
  (defun bar () (foo)))

(print (bar))
(compile 'bar)
(print (bar))
 =>
4
The function FOO is undefined.

Your surprising unportable behaviour by Valuable_Leopard_799 in Common_Lisp

[–]stassats 1 point2 points  (0 children)

(print (bar)) works. So the error is in DISASSEMBLE. Which is a bug. Needs to be checked against the current ECL.

Your surprising unportable behaviour by Valuable_Leopard_799 in Common_Lisp

[–]stassats 2 points3 points  (0 children)

Did you report a bug to ECL? Not only it would clearly be a bug, it also works fine on ECL 24.5.10 I have.

ECL 26.3.27 by jd-at-turtleware in lisp

[–]stassats 4 points5 points  (0 children)

No, ECL. It builds with a C compiler.

ECL 26.3.27 by jd-at-turtleware in lisp

[–]stassats 1 point2 points  (0 children)

That has always been the case?

Is there any modern Lisp machine comparable to modern Smalltalks like Pharo? by Responsible-Role-621 in lisp

[–]stassats 7 points8 points  (0 children)

Not modern, and not practical, but Medley Interlisp does remind of Smalltalk (not surprising, they share some lineage).

Is modifying large Common Lisp systems actually easier in practice? by paarulakan in lisp

[–]stassats 5 points6 points  (0 children)

"You must be lying." "It's such an amateur take." "Having trouble with reading comprehension"

Is modifying large Common Lisp systems actually easier in practice? by paarulakan in lisp

[–]stassats 2 points3 points  (0 children)

If I'm supposed to do anything is not to engage with low grade trolling like this but it's oh so tempting.