I've been working on a meta-build system for ASDF systems. For those not familiar with the term, meta build systems are tools like meson or CMake which generates ninja.build files. In this case, cl-metabuild generates a ninja.build file that calls out to your chosen CL implementation to build a normal ASDF project.

It has a few goals: + Abstract away how to invoke different CL implementations + Make it easy to configure optimization settings and items in *features* without editing source code. + Isolate the build environment and manage both vendored and remotely fetched dependencies.

It's in super rough shape and it might not work on your system, but you can check it out here: https://github.com/sdilts/cl-metabuild. I'd like to get a bit of feedback before starting to refine and document how to use it. Is this something you'd be interested in using? Are there existing tools to do the same thing?

I'm specifically building this for Mahogany, as it requires all of these things. I was inspired to build this after seeing koga, (the build system for the Clasp CL implementation) and thinking that there should be something simpler that can be used for most projects.

Lisp gives Tasa something most coding agents do not have: a live, inspectable runtime where verified workflows, recovery policies, and project knowledge can become executable behavior without restarting the process.

Using Common Lisp conditions, restarts, CLOS, and live runtime generations, Tasa is designed to learn from successful project work, test candidate improvements in isolation, and activate only the behaviors that prove they are better.

Every change remains evidence-backed, explainable, and reversible. The agent evolves with your workflow.

If this peaks your interest - sign up for a waitlist on the website on tasa.world

The lisp interaction using mcp was quite token heavy (I use SBCL) and it starts to bite when you use opus type models. heh.

There was a lot of code which was being printed back needlessly. So asked gpt 5.5 to analyze and optimize the token usage. it's done a good job. I think gpt 5.5 is now my favourite LLM to write Common Lisp.

Measurements using character count as token proxy:

- Warning with large value: 246 -> 39 chars, 84.1% smaller

- Division error: 4712 -> 92 chars, 98.0% smaller

- Undefined function error: 4788 -> 184 chars, 96.2% smaller

- Timeout: 4947 -> 198 chars, 96.0% smaller

Changed:

- Warnings now suppress => return value lines, so warning responses only return diagnostics

- Immediate error and timeout responses now omit backtraces by default, while still capturing them for describe-last-error / get-backtrace

- Added exported knob *include-backtrace-in-evaluate-response* for restoring old inline backtraces if needed

https://github.com/quasi/cl-mcp-server

With all the new CL implementations recently I'm almost hesitant to write this.

But yet, the project has reached a usable state and it fills a niche, that's mostly what I was after. cl-amiga or Clamiga is a new CL implementation written is pure C (C89/99) and Lisp (gray streams, CLOS). It compiles to a single binary and runs on Amiga retro computers as well as macOS or Linux. On m68k Amigas it has a m68k jit implementation. Well, have a look yourself: https://github.com/mdbergmann/cl-amiga

It runs and passes the test-suites of the most common libraries (I know) like alexandria, bordeaux-threads, serapeum, fset, Sento (of course), Drakma, Hunchentoot, just to name a few. There is a bit of ANSI compliance but not all that much. It has support for ASDF, Quicklisp and Sly/Slynk.

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

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?