I updated my post "Do I need a Lisp Machine comeback?". I have added the new information I've found with chatting with folks on lisp IRC channels.

https://far.chickenkiller.com/computing/do-i-need-a-lisp-machine-comeback/

Seems like I was looking for was "residential style development" or something. Dunno yet what does it mean. But for sure I am digging something out of grave!

#programming #workflow #GUI #mcclim #commonLisp #emacs #ecl #clisp #slime #leonardoCalculus #eepitch

https://screwlisp.small-web.org/lispgames/LCKR-object-oriented-simulation-simulation/

I have to say, I am really, really happy with how the flow into the thirty second GIF reflects my ideal computer useage.

Basically, I write a clim command that steers my leonardo system "like a person does" via emacs-server, visible in the background of the straightforward clim interactor GUI I generated in a couple lines.

@sigue @scream

Oh-kay. I have been foollowing the code down the rabbit hole, and I am a bit out of my depth here, but what I see are two things:

1) (ext:default-directory) calls another function CD, which can change the directory. If without an argument, the argument is created by merging (the non-argument) with defaults and doing logical path translation, then it actually changes the directory and returns the pathname calculated before (the new path to which it changed the working directory).

So querying the default directory comes about as a side effect, sort of.

2) I am not sure about what actually happens in this default thing, but what seems certain, we're doing a call to chdir(2) every time (which has no effect when the argument is the working directory already except when the dir is unlinked (**)). We would have to call 1 system call anywhere here, but this ... and then I don't know if it doesn't call getcwd anyway in this default/normalizing stuff.

And the version comes in from the place where the "empty argument" is expanded into a pathname.

I think I'll really be circumventing this all. Instead of UIOP:GETCWD (which calls EXT:DEFAULT-DIRECTORY) I'll just redirect my GETCWD wrappe to (osicat:current-directory). Which, BTW, does the right thing.

But really, I am not sure if I shouldn't try to raise a bug here (not for the implementation, I am understanding it not good enough to judge it, but rather for the spurious :VERSION which also cannot be deleted). Any advise?

On CLISP:

(ext:default-directory) => #P"/tmp/"

(equal (ext:default-directory) #P"/tmp/") => NIL

But

(equal (pathname (namestring (ext:default-directory))) #P"/tmp/") => T

And this now is not a typo. Gonna ask again: Anybody has any idea what is going on?

64 core monster, half a TB of RAM, NVME disks…. And #sbcl takes 20 minutes to compile (#GNU #clisp — I like you but you’re slow!)

CL packages are the wrong way to implement packages in Lisp. As I explained in a discussion two years ago, packages implemented using obarrays (or equivalent) don’t work reliably.

We have a much better basis for Lisp packages in the shorthands mechanism. It only needs to be completed.

Richard Stallman on CL packages landed
#clisp #emacs
https://andreyor.st/posts/2022-11-01-emacs-lisp-shorthands-as-namespacing-system/

> The reason namespaces systems do not fit well into #Lisp is that they have to operate in ‘read’, in the choice of which symbol object you get.

Richard Stallman on Emacs Lisp's future

TIL: every run of #SBCL has the same initial `*random-state*`, so sequences of pseudo-random numbers are not so random. The solution is super simple: `(setf *random-state* (make-random-state t))`.
It makes sense considering what a #Lisp image is... but it's still pretty surprising compared to other programming languages. (And doesn't happen in #ECL or #clisp )