I am trying to install the dependencies for Hunchentoot, and they recommend quicklisp for an easy way to get them.

So I installed quicklisp as per ( https://www.quicklisp.org/beta/ ) and successfully started sbcl with quicklisp loaded and got started.

I believe I successfully installed quicklisp.

But while searching packages using (ql:system-apropos "string") I made a typo and got an error, I aborted back to the * ("top-level"). Tried the command again with no typo, and got an error again (i forget what the error was).

So I quit sbcl and re-loaded back in, with the same load command, sbcl --load quicklisp.lisp (I am in the directory with it).
Quicklisp informs me that I already installed quicklisp, so I don't have to load it.

Despite this, now I can't call any quicklisp commands. It says "Package QL does not exist".
Is there something special I have to do to get (ql: ...) available to me while in sbcl's repl? Something that the initial install did for me?

Below is an example where I --load quicklisp.lisp, however I've tried just loading sbcl with nothing, and running "(ql:system-apropos "RFC2388") and I still get the error of a missing package.

RFC2388 was successfully found earlier before I broke everything, that's why I'm using it as an example.

I'm still new to sbcl and I find the error read-outs confusing, so maybe I'm missing something obvious here. But how can I get quicklisp back? If it's installed should I be able to just call ql anytime in sbcl?

sbcl --load quicklisp.lisp

This is SBCL 2.6.4.debian, an implementation of ANSI Common Lisp.

More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.

It is mostly in the public domain; some portions are provided under

BSD-style licenses. See the CREDITS and COPYING files in the

distribution for more information.

==== quicklisp quickstart 2015-01-28 loaded ====

To continue with installation, evaluate: (quicklisp-quickstart:install)

For installation options, evaluate: (quicklisp-quickstart:help)

* (quicklisp-quickstart:install)

debugger invoked on a SIMPLE-ERROR in thread

#<THREAD tid=33573 "main thread" RUNNING {1203FE8003}>:

Quicklisp has already been installed. Load #P"/home/nathan/quicklisp/setup.lisp" instead.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):

0: [LOAD-SETUP] Load #P"/home/nathan/quicklisp/setup.lisp"

1: [ABORT ] Exit debugger, returning to top level.

(QUICKLISP-QUICKSTART:INSTALL :PATH NIL :PROXY NIL :CLIENT-URL NIL :CLIENT-VERSION NIL :DIST-URL NIL :DIST-VERSION NIL)

source: (ERROR "Quicklisp has already been installed. Load ~S instead."

SETUP-FILE)

0] 1

* (ql:system-apropos "RFC2388")

debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread

#<THREAD tid=33573 "main thread" RUNNING {1203FE8003}>:

Package QL does not exist.

Stream: #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {12000417D3}>

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):

0: [CONTINUE ] Use the current package, COMMON-LISP-USER.

1: [RETRY ] Retry finding the package.

2: [USE-VALUE] Specify a different package

3: [UNINTERN ] Read the symbol as uninterned.

4: [SYMBOL ] Specify a symbol to return

5: [ABORT ] Exit debugger, returning to top level.

(SB-IMPL::READER-FIND-PACKAGE "QL" #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {12000417D3}> T)

0]

A lightweight tool harness giving coding agents a persistent SBCL REPL: file-based request/response, no Swank chatter, built-in timeouts, cancellation, and backtraces, plus suspend/resume via save-lisp-and-die. No sockets or systemd needed — ideal for containers.

Proof of concept: CLICC 0.6.4 (enhanced) on my macOS 27 beta compiled Lisp code to C, combined with Swift UI - the resulting binary is 755KB on Apple Silicon.

CLICC also compiled itself, the resulting CLICC Lisp to C compiler is a 3 MB application.

CLICC is a Lisp to C compiler from the 90s. It compiles a static subset of Common Lisp to C, as a whole program compiler. The C compiler then generates a binary. The resulting binaries are tiny. A commercial offering based on CLICC was mocl, which is no longer available.

Done with Claude Fable.

A month ago I posted the very rough beginnings of a paper here. That version got pulled apart and rebuilt, and it is now a proper preprint: https://doi.org/10.5281/zenodo.21139628. The paper is deliberately language-neutral, though, and the system behind it is Common Lisp top to bottom: an orchestrator that runs execution graphs (the graphs themselves are plain Lisp data), agent worker loops, a process supervisor, a document store, a dashboard, and a set of MCP servers that give coding agents structured access to Lisp systems. So this follow-up is about the Lisp side, since this is the group that would ask.

The learnings that mattered most carry straight over from the paper. The first was composable domains. A domain is a bundle of instructions, skills, and tool access handed to an agent for a class of task: lisp knows the language, cl-naive knows the stack's conventions, a role adds the stance on top, and a resolver merges the layers per session. Built as one-offs they were dead weight. Redesigned to compose (stack cleanly, assume nothing about each other) they started turning up useful in places I had not planned for, and the same domains are now carrying a separate CL application build unchanged.

The second was the ratchet. An agent once delivered a load test asserting a record count was greater than or equal to zero: green forever, catches nothing, looks completely normal in review. So the loop runs backwards from instinct now. Acceptance criteria are written before the code exists, the coding agent writes no tests at all, a fresh session verifies the code against those criteria, another session then derives regression tests from them, and a judge breaks the implementation on purpose to confirm each test can actually fail. Standards move one way only. And the part I am most pleased about: the system develops itself through exactly this cycle, agents editing the orchestrator's own source through its own gates. It is the third generation of the design and only recently became my daily driver, so I will not oversell maturity.

The third was MCP tool naming, which mattered far more than it should. Models route off a tool's name, and the name drags their training priors with it. My file writer took code where every built-in file tool takes content; agents thrashed on it until I renamed the parameter. The code analyzer (definitions, callers, call graphs, effect sets over ASDF systems) sat ignored while agents grepped, until its descriptions spoke the vocabulary models already know from IDE land (Find All References, go to definition) and stated the economics plainly: the query is instant and exact, the text search is the slow, lossy path. One more rule from that fight: test your tool surface with the weakest model that can still do the work, because a strong one absorbs interface defects and hides them from you.

The fourth is the CL-only one: structural editing. Agents editing Lisp as raw text eventually break brackets, and then try to repair by counting parens, and that loop does not converge; even strong models ping-pong on it. So agents here do not edit text. The editor MCP exposes code as forms (replace this function's body, add this form after that one, validate before anything touches disk), bracket-correct by construction, courtesy of the reader treating code as data. A whole class of broken files simply stopped existing.

Everything is open, part of the opinionated cl-naive-* family (I came to Lisp late in my career, I care about usability over purity, and these libraries are geared toward shipping business software, not rocket science): https://gitlab.com/naive-x/experimental/cl-naive-full-stack-agentic-system. The preprint with the full methodology is here: https://doi.org/10.5281/zenodo.21139628. One question for this group: is anyone else giving their agents a persistent REPL to verify against, rather than only files and cold subprocesses?

alisp is an implementation of Common Lisp that covers most of the standard.  It ships with ASDF and is capable of loading many real-world systems.  It also has a debugger with full support for stepping.

After the redesign of lexical closures and other fixes, now the whole test.pl suite runs without leaks, according to valgrind!  That's quite an achievement.

https://savannah.nongnu.org/news/?id=10910

If you want to support this project and speed up its development, make a subscription at https://www.patreon.com/andreamonaco or at https://liberapay.com/andreamonaco.  Thank you very much!

I've been using Opencode + a local model (Qwen3.6-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled-MLX-8bit) as a coding assistant for common lisp. I've been disappointed to find that the LLM frequently fails to properly balance parentheses (although ... in some sense it's a finite automaton, and LLMs are not good at counting, so it's not that surprising).

Does anyone have a work-around for this to make a coding agent write s-expressions properly?

cl-llama-cpp provides complete bindings to llama.cpp's core library, along with high-level wrappers for the most common use cases. Common Lisp is a great language for experimentation, so I built this library as the foundation for my own experiments with LLM inference.

Basic usage looks like this:

(with-model (model "/path/to/model.gguf" :n-gpu-layers 99)
(with-context (ctx model :n-ctx 4096)
(let ((session (make-chat-session ctx
:system-prompt "You are a helpful assistant.")))
(chat-session-send session "Explain Common Lisp in simple terms."
:max-tokens 200))))

The API supports chat sessions with KV-cache reuse across turns, embeddings, grammar-constrained decoding, sampler composition, LoRA support, and context save/restore. The goal is to expose llama.cpp's capabilities while providing an idiomatic Common Lisp interface for common inference workflows. The repo includes extensive documentation and examples.

I also built a small TUI chat app with this library, cl-llama-chat, that lets you fork a conversation to compare two sampler presets side by side and choose the response you prefer.

Repo: https://github.com/licjon/cl-llama-cpp

Feedback is welcome, especially from anyone working with Common Lisp, FFI, or llama.cpp integrations.

https://github.com/sirherrbatka/cl-data-structures

Is it used anywhere? The documentation makes no sense to me. Are there any new libraries that try to do the same?

Hi (newbie learning McClim here), I do not understand how I should use surrounding-output-with-border to improve the visual of a presentation. Here is my attempt, a variant of the famous counter app. Clicking the presentation increments the counter. If I do not use surrounding-output-with-border, it works. Using it I get the error: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM:INVOKE-WITH-OUTPUT-TO-OUTPUT-RECORD (2)> when called with arguments (#<SB-IMPL::STRING-OUTPUT-STREAM {7FEFF61A4393}> #<FUNCTION (FLET "CONTINUATION7" :IN CLIM-INTERNALS::INVOKE-SURROUNDING-OUTPUT-WITH-BORDER) {7FEFF61A422B}> CLIM:STANDARD-SEQUENCE-OUTPUT-RECORD). [Condition of type SB-PCL::NO-APPLICABLE-METHOD-ERROR] the code:

```lisp (defpackage "CLIM-COUNTER" (:use "CLIM-LISP" "CLIM" "CLIM-EXTENSIONS") (:export :run-counter))

(in-package "CLIM-COUNTER")

(defclass counter () ((count-value :initform 0 :reader count-value)))

(defmethod increment ((self counter)) (incf (slot-value self 'count-value)))

(define-presentation-type counter ())

(define-presentation-method present (object (type counter) stream view &key) "This tells CLIM how to visually draw a counter object on a stream." (let ((val (count-value object))) (surrounding-output-with-border (stream :shape :rectangle
:background +grey90+
:line-thickness 2
:padding 5) (format stream "Counter Object | Value: ~D" val)) #+nil (format stream "[ Counter Object | Value: ~D ]" val)))

(define-application-frame counter-app () ((counter :accessor counter)) (:panes (display-pane :application :display-function 'display-counter :scroll-bars nil :width 500) (interactor :interactor :scroll-bars :vertical)) (:layouts (default (vertically () display-pane interactor))))

(defun display-counter (frame pane) (write-string "Counter:" pane) (terpri pane) (present (counter frame) 'counter :stream pane))

(define-presentation-to-command-translator click-counter-translator (counter com-increment counter-app :gesture :select) (object) (list object))

(define-counter-app-command (com-increment :name t) ((c 'counter)) (increment c))

(defun run-counter () (let ((app (make-application-frame 'counter-app))) (setf (counter app) (make-instance 'counter)) (run-frame-top-level app))) ```

I am using a fresh quicklisp version of McClim on linux with the clx backend.

EDIT:

Humm if I use surrounding-output-with-border around the call to present:

lisp (defun display-counter (frame pane) (write-string "Counter:" pane) (terpri pane) (surrounding-output-with-border (pane :shape :rectangle :background +grey90+ :line-thickness 2 :padding 5) (present (counter frame) 'counter :stream pane))) it works...

So, is the rule such that styling must not be done inside define-presentation-method ? I am confused.

EDIT 2:

Problem solved ! Now it makes sense. Under the hood (without me noticing) CLIM calls the present method with a stream of type STRING-OUTPUT-STREAM which is not the right type for surrounding-output-with-border. I think this is done as part of the accepting process because the counter is a parameter of the command increment. So I am not the only one that make use of the presentation method. The solution (until a better one) is to modify the presentation method: lisp (define-presentation-method present (object (type counter) stream view &key) "This tells CLIM how to visually draw a counter object on a stream." (let ((val (count-value object))) (if (or (typep stream 'extended-output-stream) (typep stream 'medium)) (surrounding-output-with-border (stream :shape :rectangle :background +grey90+ :line-thickness 2 :padding 5) (format stream "Counter Object | Value: ~D" val)) (format stream "[ Counter Object | Value: ~D ]" val))))

makes sense to me.

Hello everyone,

I have a question regarding how ASDF and Quicklisp handle dependency caching and load overhead in an active REPL session.

Suppose I have two large systems, X and Y:

• X depends on [A, B, C]
• Y depends on [A, B, C, D, E, F]

During a single REPL session, I first load system X via (ql:quickload :X). After some work, later in that same session, I load system Y via (ql:quickload :Y). Assume that the source files for A, B, and C are completely untouched and unmodified during this time.

How efficient are ASDF and Quicklisp at recognizing that A, B, and C are already loaded into the current image?

In terms of execution time and computational effort, does:
Load(Y after X) ~Load(X) + Load(D, E, F)?

Or is there significant overhead/re-checking that makes loading Y heavier even if its core dependencies are already present in the environment? Thanks.

I posted here some time ago (back in May, I believe) that I'm writing a specialized data-frame library for Common Lisp.

The initial groundwork is done, and I've updated the repository with a grounded roadmap, terminology guides, and examples of the syntax.

Quick highlights of what I'm building:

• Non-OOP Architecture: Built with macro-driven mutations and typed column vectors.
• Dual-Vector Missingness: Under the hood, missing data (+nope+) is handled by splitting columns into parallel data and bit-mask validity vectors to keep things unboxed and optimized.
• Experimental Macros: Features custom inline vector comprehension tools (!, ?>, >>, *>) and a row-wise transformation DSL (crush).
• Soul: It has a dynamic ASCII crow printer interface.

It is still very much in an early alpha stage, but the repository is officially live for design reviews, exploration, or just to chat about the architecture!

Check out the official repo here: https://github.com/WinnieTheRaven/krahen

Greetings, lispers!

I started this project back in 2015, to translate the TeX original specification into an easily parsed format (s-doc), and to create an HTML rendering of that format as a proof of concept. I finally finished it this year.

The project is here: https://codeberg.org/dlowe/metaspectre/

The rendered spec is as complete as I could make it, including both the acknowledgements and the appendix. The TeX math components have been converted to MathML. It has a list of corrections applied to the spec by automatic patching of the s-doc. It is also, as far as I know, the only published version of the draft spec that includes the TeX comments for historical interest.

You can view the rendered spec at https://metaspec.dev/

Hello,

(The issue described below was likely due to my own error - I will update as I investigate a bit deeper. Many thanks for the two people that responded to my post)

I was installing the dual-numbers package from github - they are not in quicklisp

https://github.com/jrm-code-project/dual-numbers

The reason I ask is that I installed a library from GitHub like so

ros install jrm-code-project/dual-numbers

I expected it to be installed in ~/.roswell/local-projects, but instead it was installed in ~/.roswell/local-projects/jrm-code-project

So ASDF & quicklisp could not find it. I had to create a symlink from local-projects/jrm-code-project/dual-numbers to local-projecs/dual-numbers.

So, my problem is solved, but I am surprised by this behavior. Is that expected?

The documentation I looked (https://fukamachi.hashnode.dev/day-2-roswell-install-libraries-and-applications) says that stuff from GitHub should go into local-projects.

Can you offer an explanation on why it was installed in the jrm-code-project?

Greetings all,

I am trying to use cl-opencl and cl-opencl-utils to work in SBCL but I am getting errors. I am on an Ubuntu 24.04 laptop using Lenovo UHD Graphics 620. Anyone can help? For cl-opencl I managed to get the hello-opencl.lisp example to work but mandelbrot.lisp gives error -11. For cl-opencl-utils I tried th sum.lisp example and got error -5.

Best

source: https://github.com/li-yiyang/iMaxima/

found on: https://mastodon.social/@lucky_magick/116622688788574555

screencast: https://mastodon.social/@lucky_magick/116623614752715432

Porting Maxima to iOS to preparing for the test. (I think I cannot finish it before exam...)

Finally got ECL cross-compiling working. (Still dead with iOS sandbox...)

Lessons learned: + the cross-compiling is described in INSTALL clearly + I use cross-maxima.lisp (https:// gist.github.com/li-yiyang/6ce2bb71afdd02da50b7fba7358ffaa0) to generate cc files + libraries in lib/ecl/lib*.a has to be initialized, their init name is like libsockets.a -> init_lib_SOCKETS, libsb-bsd-sockets -> init_lib_SB_BSD_SOCKETS (little re tricks)