Would it work with the parallel GC feature?
I haven't really looked into it, but I'm hopeful it can be made to work.
Readit Newsatgreen commented on SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf] research.gold.ac.uk/id/ep... · Posted by u/pabs3
atgreen commented on SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf] research.gold.ac.uk/id/ep... · Posted by u/pabs3
Incredible! Is this ready for at scale production use?
No. I have yet to propose the patches formally. The SBCL maintainers are reviewing the high-level proposal (on my blog) first. You can try the implementation, however. There's a pointer to the repo/branch on my blog. I need to build a proper benchmarking framework and publish some real numbers that people can reproduce before I am confident enough to submit the patches for review.
Let me know if you try it out. I would love some feedback (via github)
atgreen commented on SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf] research.gold.ac.uk/id/ep... · Posted by u/pabs3
I am learning scheme(dr racket), which is i think derived from lisp, what is this actually used for and do people build anything with lisp???
This very website that you are using right now, Hacker News, runs on sbcl.
atgreen commented on SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf] research.gold.ac.uk/id/ep... · Posted by u/pabs3
Do you have a link to the proposal and the discussion? I am quite interested to see the implementation details. Thanks!
I'm the author. https://atgreen.github.io/repl-yell/posts/sbcl-fibers/
atgreen commented on Smalltalk's Browser: Unbeatable, yet Not Enough blog.lorenzano.eu/smallta... · Posted by u/mpweiher
I set out to create a better text repl experience for Common Lisp couple of months ago, but was inspired by the pharo interface and built something much larger: https://atgreen.github.io/icl/
I use it all the time.
atgreen commented on Cl-kawa: Scheme on Java on Common Lisp github.com/atgreen/cl-kaw... · Posted by u/varjag
Agreed, "Java" was an oversimplification. It's actually JVM bytecode. It's still strange in my book to use an object soup runtime for something (Lisp/Scheme) that feels closer to functional languages to me.
Clojure is a different case, because when you already are on the JVM anyway, then Clojure is still infinitely better than no Lisp at all. It's not the same as putting the JVM somewhere where it wasn't before and where it's not actually needed.
It's like Dr Ian Malcolm says.. "Your developers were so preoccupied with whether or not they could, they didn't stop to think if they should" - Jurrasic Park (almost)
atgreen commented on Cl-kawa: Scheme on Java on Common Lisp github.com/atgreen/cl-kaw... · Posted by u/varjag
Here's something I wrote about this work: https://atgreen.github.io/repl-yell/posts/cl-kawa/
atgreen commented on Cl-kawa: Scheme on Java on Common Lisp github.com/atgreen/cl-kaw... · Posted by u/varjag
If you are interested in this, you might also be interested to learn that I also got clojure running on SBCL via OpenLDK. See https://github.com/atgreen/cl-clojure.
Regarding LLM-usage, the bulk of OpenLDK was written without the use of LLMs. But recently I let Claude loose on the code to fix a few remaining problems blocking kawa. Claude also upleveled the Java support from Java 8 to Java 21.
I wrote a couple of blog entries related to this work that might be of interest. One was around how I had to use the MOP to optimize method dispatch in CLOS for clojure: https://atgreen.github.io/repl-yell/posts/clos-mop-dispatch/
atgreen commented on Bending the CLOS Mop for Java-Style Single Dispatch atgreen.github.io/repl-ye... · Posted by u/atgreen
I managed to get a clojure REPL running on Common Lisp (SBCL) via OpenLDK, my Java JIT compiler and runtime on Common Lisp. This blog post gives an overview on how I manipulated CLOS's method dispatch to improve performance for single-dispatch methods calls.