sbcl-devel Mailing List for Steel Bank Common Lisp

Not checking for the 8th bit is a question. A custom SIMD routine
would provide ascii-checking basically for free (and even for :utf8),
although it's harder to keep up with well optimized memcpy (but
they're all in assembly anyway, not impossible to copy the same
approaches).
The buffering external formats do have SB-VM::SIMD-COPY-UTF8-TO-BASE-STRING.

On Wed, Jun 10, 2026 at 6:09 AM snuglas via Sbcl-commits
<sbc...@li...> wrote:
>
> The branch "master" has been updated in SBCL:
>        via  007463a97af9e11b4ea2c41917bf2838b371e9c0 (commit)
>       from  2df3f8071bfcf85721104e58efad6d38e9c2b912 (commit)
>
> - Log -----------------------------------------------------------------
> commit 007463a97af9e11b4ea2c41917bf2838b371e9c0
> Author: Douglas Katzman <do...@go...>
> Date:   Tue Jun 9 22:57:57 2026 -0400
>
>     Improve receiving some C strings from foreign function on 64-bit Unicode
>
>     If the string's EF is :ASCII and the desired element-type is BASE-CHAR then just memcpy.
> ---
>  src/code/c-call.lisp           | 33 ++++++++++++++++++++++++---------
>  src/code/misc-aliens.lisp      |  8 --------
>  src/code/target-alieneval.lisp |  9 +++++++++
>  src/code/target-c-call.lisp    |  8 ++++++++
>  src/cold/exports.lisp          |  2 +-
>  src/compiler/fndb.lisp         |  2 ++
>  tests/aliencall.pure.lisp      | 16 ++++++++++++++++
>  7 files changed, 60 insertions(+), 18 deletions(-)
>
> diff --git a/src/code/c-call.lisp b/src/code/c-call.lisp
> index 2d343d1ac..67c130576 100644
> --- a/src/code/c-call.lisp
> +++ b/src/code/c-call.lisp
> @@ -83,6 +83,8 @@
>           :datum nil))
>
>  (define-alien-type-method (c-string :naturalize-gen) (type alien)
> +  ;; Potentially the SAFETY policy could influence whether to elide
> +  ;; the null check on strings whose alien type says non-nullable.
>    `(if (zerop (sap-int ,alien))
>         ,(if (alien-c-string-type-not-null type)
>              `(null-error ',type)
> @@ -91,19 +93,32 @@
>         ;; conversion, or whether we can just do a cheap byte-by-byte
>         ;; copy of the c-string data.
>         ;;
> -       ;; On SB-UNICODE we can never do the cheap copy, even if the
> -       ;; external format and element-type are suitable, since
> +       ;; On SB-UNICODE the cheap copy is possible for external-format :ASCII
> +       ;; and copying to a base-string. Otherwise it isn't since
>         ;; simple-base-strings may not contain ISO-8859-1 characters.
>         ;; If we need to check for non-ascii data in the input, we
>         ;; might as well go through the usual external-format machinery
>         ;; instead of rewriting another version of it.
> -       ,(if #+sb-unicode t
> -            #-sb-unicode (c-string-needs-conversion-p type)
> -            `(c-string-to-string ,alien
> -                                 (c-string-external-format ,type)
> -                                 (alien-c-string-type-element-type
> -                                  ,type))
> -            `(%naturalize-c-string ,alien))))
> +       ,(let ((conv `(c-string-to-string
> +                      ,alien
> +                      (c-string-external-format ,type)
> +                      ',(alien-c-string-type-element-type type))))
> +          #-sb-unicode
> +          (if (c-string-needs-conversion-p type) conv `(%naturalize-c-string ,alien))
> +          #+sb-unicode
> +          (if (or (neq (alien-c-string-type-external-format type) :ascii)
> +                  (neq (alien-c-string-type-element-type type) 'base-char)
> +                   ;; this test might be unnecessary but if you're asking for maximum
> +                   ;; safety then we should check for non-ASCII characters
> +                   (sb-c::policy sb-c::*policy* (= safety 3)))
> +              conv
> +              ;; else "cheap byte-by-byte copy"
> +              #-64-bit `(%naturalize-c-string ,alien)
> +              ;; even better: avoid SAP consing. The CPU and OS assure that us that
> +              ;; userspace can't have bit 63 on for two popular architectures.
> +              #+64-bit
> +              `(%naturalize-base-string/word #+(or arm64 x86-64) (the fixnum (sap-int ,alien))
> +                                             #-(or arm64 x86-64) (sap-int ,alien))))))
>
>  (define-alien-type-method (c-string :deport-gen) (type value)
>    ;; This SAP taking is safe as DEPORT callers pin the VALUE when
> diff --git a/src/code/misc-aliens.lisp b/src/code/misc-aliens.lisp
> index 49620026e..6c8d73139 100644
> --- a/src/code/misc-aliens.lisp
> +++ b/src/code/misc-aliens.lisp
> @@ -69,14 +69,6 @@
>    (dest system-area-pointer)
>    (src system-area-pointer)
>    (n sb-unix::size-t))
> -;;; The overhead of Lisp may make the distinction between memmove() and memcpy()
> -;;; irrelevant, but we may as well promise that the ranges don't overlap when one
> -;;; of them is a freshly consed string, for example.
> -(declaim (inline memcpy))
> -(define-alien-routine ("memcpy" memcpy) system-area-pointer
> -  (dest system-area-pointer)
> -  (src system-area-pointer)
> -  (n sb-unix::size-t))
>
>  (defun copy-ub8-to-system-area (src src-offset dst dst-offset length)
>    (with-pinned-objects (src)
> diff --git a/src/code/target-alieneval.lisp b/src/code/target-alieneval.lisp
> index dce96d26b..b2fa2593e 100644
> --- a/src/code/target-alieneval.lisp
> +++ b/src/code/target-alieneval.lisp
> @@ -963,3 +963,12 @@ specifies the way that the argument is passed.
>                 (error "(STRUCT ~S) has unexpected size" tag)))))
>      (check-size 'sb-unix::timespec)
>      (check-size 'sb-unix::timeval)))
> +
> +;;; The overhead of Lisp may make the distinction between memmove() and memcpy()
> +;;; irrelevant, but we may as well promise that the ranges don't overlap when one
> +;;; of them is a freshly consed string, for example.
> +(declaim (inline sb-impl::memcpy))
> +(define-alien-routine ("memcpy" sb-impl::memcpy) system-area-pointer
> +  (dest system-area-pointer)
> +  (src system-area-pointer)
> +  (n sb-unix::size-t))
> diff --git a/src/code/target-c-call.lisp b/src/code/target-c-call.lisp
> index c24355191..c517663ed 100644
> --- a/src/code/target-c-call.lisp
> +++ b/src/code/target-c-call.lisp
> @@ -70,3 +70,11 @@
>      ;; COPY-UB8 pins the lisp string, no need to do it here
>      (sb-kernel:copy-ub8-from-system-area sap 0 result 0 length)
>      result))
> +
> +(defun %naturalize-base-string/word (word)
> +  (declare (type sb-vm:word word))
> +  (let* ((length (alien-funcall (extern-alien "strlen" (function size-t unsigned)) word))
> +         (result (make-string length :element-type 'base-char)))
> +    (with-pinned-objects (result)
> +      (sb-impl::memcpy (vector-sap result) (int-sap word) length))
> +    result))
> diff --git a/src/cold/exports.lisp b/src/cold/exports.lisp
> index cf0f8b564..34770006b 100644
> --- a/src/cold/exports.lisp
> +++ b/src/cold/exports.lisp
> @@ -1012,7 +1012,7 @@ Lisp extension proposal by David N. Gray")
>             "%CAST"
>             "%DEREF-ADDR" "%HEAP-ALIEN" "%HEAP-ALIEN-ADDR"
>             "%LOCAL-ALIEN-ADDR" "%LOCAL-ALIEN-FORCED-TO-MEMORY-P" "%SAP-ALIEN"
> -           "%NATURALIZE-C-STRING"
> +           "%NATURALIZE-C-STRING" "%NATURALIZE-BASE-STRING/WORD"
>             "%SET-DEREF" "%SET-HEAP-ALIEN" "%SET-LOCAL-ALIEN" "%SET-SLOT"
>             "%SLOT-ADDR" "*SAVED-FP*" "*VALUES-TYPE-OKAY*"
>             "*ALIEN-TYPE-HASHSETS*"
> diff --git a/src/compiler/fndb.lisp b/src/compiler/fndb.lisp
> index 69a7f4be3..622d27a08 100644
> --- a/src/compiler/fndb.lisp
> +++ b/src/compiler/fndb.lisp
> @@ -2397,6 +2397,8 @@
>  ;;;; ALIEN and call-out-to-C stuff
>
>  (defknown %alien-funcall ((or string system-area-pointer) alien-type &rest t) *)
> +#+64-bit
> +(defknown sb-alien-internals:%naturalize-base-string/word (sb-vm:word) simple-base-string)
>
>  ;; Used by WITH-PINNED-OBJECTS
>  (defknown sb-vm::touch-object (t) (values)
> diff --git a/tests/aliencall.pure.lisp b/tests/aliencall.pure.lisp
> index 68d651671..84d3bf19f 100644
> --- a/tests/aliencall.pure.lisp
> +++ b/tests/aliencall.pure.lisp
> @@ -39,3 +39,19 @@
>      ;;    53F9FF58         LDR R9, #x1001A10048     ; printf
>      ;; 2) 60023FD6         BLR R9
>      #+arm64 (assert (= (loop for line in lines count (search "BLR" line)) 2))))
> +
> +(locally
> +(declare (optimize (sb-c::alien-funcall-saves-fp-and-pc 0)))
> +(define-alien-routine strerror (c-string :external-format :ascii :element-type base-char)
> +  (e int)))
> +
> +(with-test (:name :return-c-string-optimizer :skipped-on (:not :x86-64))
> +  ;; check that the thing actually works
> +  (assert (plusp (length (strerror sb-unix:ebadf))))
> +  (let ((lines (ctu:disassembly-lines #'strerror)))
> +    ;; should tail-call the naturalize function
> +    (assert (loop for line in lines
> +                  thereis (and (search "JMP" line) (search "%NATURALIZE-BASE-STRING/WORD" line))))
> +    ;; no alloc-tramp (no SAP consing), nor BIGNUM consing
> +    (assert (loop for line in lines
> +                  never (or (search "ALLOC" line) (search "BIGNUM" line))))))
>
> -----------------------------------------------------------------------
>
>
> hooks/post-receive
> --
> SBCL
>
>
> _______________________________________________
> Sbcl-commits mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-commits

I improved a couple of things and updated the samples.

- sb-manual: fix CONVERT-DOCSTRING-PACKAGE-OVERRIDES-TO-PAX

- sb-manual: add support for [label](uri) and [label][id]

- sb-manual: automatically USE-PAX
    
    Put a magic marker on the value of the variable holding the dummy
    section. Variables with these markers are recognized by PAX (from
    v0.4.12) as lazy sections. So, (DREF @FAKE 'SECTION) works. Then,
    whenever such a reference is RESOLVEd, the function following the
    magic marker is called. That function is USE-PAX in this case.
    
    The net effect of this hack is that PAX:DOCUMENTing a fake section
    will unfake it.
    
    Export USE-PAX for the remaining cases.

- sb-manual: USE-PAX automatically if PAX is already loaded
    
    ... when sb-manual is loaded.
    
    SWITCH-TO-PAX was renamed to USE-PAX.

- doc: fix overlapping section numbers and title in the PDF toc

- sb-manual: make GENERATE-TEXINFO unaffected by SWITCH-TO-PAX

- Add support for (DOCUMENTATION ... 'declaration)
    
    - Add docstrings for user-facing declaration.
    
    - Fix the hacks for declarations in the manual.
    
    - Add documentation of DOCUMENTATION extensions to the manual.
    
    - Add a "Declaration Index" appendix to the manual.

Gábor Melis <me...@re...> writes:

> Alright.
>
> The latest code and documentation are at
> https://github.com/melisgl/sbcl/commits/pax-doc/.
>
> The interesting commit is "PAXlike docs". The rest are bug fixes, and
> three large commits with docstring updates, lisp files with manual
> sections, and generated texinfo files.
>
> The following files were generated using the new Markdown-to-Texinfo
> converter, and subsequently compiled with Texinfo.
>
> https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.html
> https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info
> https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info-1
> https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info-2
> https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info-3
> https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.pdf
>
> The above are quite close to the current documentation (e.g.
> https://www.sbcl.org/manual/), but lots of small fixes have been made to
> the docstrings as well.
>
> The following alternatives were generated with PAX, with the command line
>
>     ./contrib/sb-manual/make-pax-docs.sh https://github.com/melisgl/sbcl
>
> https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.txt
> https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.md
> https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.pdf
> https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html
>
> The main feature in these files (well, except the txt one) is linking:
> - cross-linking within the document,
> - linking to the CLHS, and
> - linking the locative (e.g. "[function]") to the sources on GitHub.
>
> SBCL, PAX, DRef, 3BMD and Slime required a couple of fixes. They are all
> available on GitHub (except https://github.com/3b/3bmd/pull/74), and
> hopefully in Ultralisp by now.
>
> For more information, see
>
> - the SB-MANUAL documentation
>
>     https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html#x-28SB-MANUAL-3A-40SB-MANUAL-20MGL-PAX-3ASECTION-29
>
> - the docstring style guide:
>
>     https://github.com/melisgl/sbcl/blob/pax-doc/contrib/sb-manual/README.md
>
> - and the TODO list:
>
>    https://github.com/melisgl/sbcl/blob/pax-doc/contrib/sb-manual/TODO.md
>
> To avoid merge conflicts, I'll probably commit this soon if there are no
> objections, and then take my time with the TODO list.
>
> Cheers,
> Gábor

Hi everybody,

here's the current version of my user-defined immediates
contrib.
As the changes in the SBCL core are really minimal now
I'd like to ask for a review resp. inclusion in upstream SBCL.


Summary:

    This patch series provides a column-oriented structure variant
    that's type-safe at compile- and runtime; such objects
    are addressed via immediates with an 8-bit SBCL tag and
    another 8-bit tag to provide multiple such types.

    This reduces memory usage, GC time, and therefore time required
    for safe-lisp-and-die.

The intended use-case is a in-memory database that allocates
lots (>10M) of small structures of a few different types.

The full documentation is available at [1].



This works fine in a production setup,
tested with up to 12 cores parallel allocation.
RAM usage is much better than plain instances,
also because the "pointers" are now mostly (unsigned-byte 32)
or even just (unsigned-byte 8) where possible.

   Class instances:
   - Path 56M instances, deduplicated as 8M fragments using 210MB
   - SHA256 34M instances
   - Version 530k instances, points to Repo, Arch, Dist instances
   In-memory indizes:
   - Versions pointing to 124M (Path, SHA256) tuples
   - SHA256 pointing to 92M (Version, SHA256) tuples

In 2024 the software couldn't import (fewer) data with a 64GB heap;
now, with UDEFs, the heap doesn't grow above ~16GB
and the uncompressed executable is ~7GB.


The contrib directory contains a Makefile
for running a small benchmark script. With
   # make comparison
only allocation is tested, adding an argument
   # make comparison dumpfile=/tmp/text.heap
writes a heap dump as well.
User/System/Wall clock times and max. RAM usage are printed;
while allocation alone is slower (6.3 vs. 5.3 seconds),
the GC on save-lisp-and-die makes the UDEF version faster
(8 instead of 17 seconds); and heap usage is also only half as much.


Known points that could be fixed/enhanced:
- udef subtypes for TYPE-OF
- defmethod with (EQL x)
- accessor performance
- There's no GC (yet); not needed for my usecases,
   full GC could build a freelist for each tag.
- I add a few transforms "by hand", as the specifiers
   collide with built-in DEFTRANSFORMS.
   Having a separate value to differentiate would be great,
   eg. "optimize" for the built-ins vs. "udef" for these here.


Any feedback is welcome, of course.



Ad 1: 
https://github.com/phmarek/sbcl/blob/udef-direct-expansion/contrib/sb-udef-immediate/README.md

Alright.

The latest code and documentation are at
https://github.com/melisgl/sbcl/commits/pax-doc/.

The interesting commit is "PAXlike docs". The rest are bug fixes, and
three large commits with docstring updates, lisp files with manual
sections, and generated texinfo files.

The following files were generated using the new Markdown-to-Texinfo
converter, and subsequently compiled with Texinfo.

https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.html
https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info
https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info-1
https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info-2
https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.info-3
https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.pdf

The above are quite close to the current documentation (e.g.
https://www.sbcl.org/manual/), but lots of small fixes have been made to
the docstrings as well.

The following alternatives were generated with PAX, with the command line

    ./contrib/sb-manual/make-pax-docs.sh https://github.com/melisgl/sbcl

https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.txt
https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.md
https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.pdf
https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html

The main feature in these files (well, except the txt one) is linking:
- cross-linking within the document,
- linking to the CLHS, and
- linking the locative (e.g. "[function]") to the sources on GitHub.

SBCL, PAX, DRef, 3BMD and Slime required a couple of fixes. They are all
available on GitHub (except https://github.com/3b/3bmd/pull/74), and
hopefully in Ultralisp by now.

For more information, see

- the SB-MANUAL documentation

    https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html#x-28SB-MANUAL-3A-40SB-MANUAL-20MGL-PAX-3ASECTION-29

- the docstring style guide:

    https://github.com/melisgl/sbcl/blob/pax-doc/contrib/sb-manual/README.md

- and the TODO list:

   https://github.com/melisgl/sbcl/blob/pax-doc/contrib/sb-manual/TODO.md

To avoid merge conflicts, I'll probably commit this soon if there are no
objections, and then take my time with the TODO list.

Cheers,
Gábor

>> I read manual all the time, so I do care about it :).
>
> We are at least 3 by now.

A  highly popular  choice than 🙂

>> I do it in Emacs info mode though. There I can just 's' or 'm' (search
>> or menu) and use completing read on menus or links so it is a bit
>> better than reading in a web-browser. Especially with Helm and some
>> extras to complete menus and search.
>>
>> Yes, that should be more tolerable. I took note that there is a
>> sbcl.info consumer, too.
>>
>> It would be nice if the ansi draft was included and the standard
>> functions or parts of the standard were linked to the draft, but I
>> guess it would be a lot of work.
>
> I do not immediately see the point of including the entire ANSI draft,

Mostly to skip the web, and have it in Info-mode directly in Emacs. Just
a convenience.

I do have my own emacs package to include the draft into info, but I would
prefer if it was included with some other package so I don't have to
manage my own package. I did use for a while slime-star by Montone,
I like his extensions, so perhaps it could be included there. I'll ask him.

> but autolinks are already made to CLHS (most visible in the PDF, where
> external links are red). Also, I'm adding links to the relevant sections
> of the CLHS (e.g. "CLHS `1.4.4.5`") while I'm converting the manual.

I agree, it would be perhaps too much to have all functions linked.
Relevant sections sound like much better choice.

I did send in patch. It was a year or couple of years ago perhaps, I don't remember to be honest.

Yes, I am aware they prefer patches here. I have no problem with that :).

But thanks for the advice anyway.


-------- Originalmeddelande --------
Från: Jesse Bouwman <jes...@pr...>
Datum: 2026-06-04 18:07 (GMT+01:00)
Till: arthur miller <art...@li...>
Kopia: Christoph Breitkopf <chb...@gm...>, Gábor Melis <me...@re...>, sbc...@li...
Ämne: Re: [Sbcl-devel] SB-MANUAL contrib prototype

Though the officially sanctioned submission route is still mailed patches, you could consider opening PRs on the github mirror for incremental beneficial patches like this, as I believe it's very easy for maintainers to review and apply them:

https://github.com/sbcl/sbcl

Cheers
Jesse

On Jun 4, 2026, at 8:25 AM, arthur miller <art...@li...> wrote:

I read manual all the time, so I do care about it :).  I do it in Emacs info mode though. There I can just 's' or 'm' (search or menu) and use completing read on menus or links so it is a bit better than reading in a web-browser. Especially with Helm and some extras to complete menus and search.

But I would appreciate a more detailed and up to date manual. I have once sent in a patch to update the link to C. Rhodes paper about sequences. The link was broken in the manual, but since the patch was ignored I never bothered to send anything more related to the manual.

It would be nice if the ansi draft was included and the standard functions or parts of the standard were linked to the draft, but I guess it would be a lot of work.


-------- Originalmeddelande --------
Från: Christoph Breitkopf <chb...@gm...>
Datum: 2026-06-04 13:15 (GMT+01:00)
Till: Gábor Melis <me...@re...>
Kopia: sbc...@li...
Ämne: Re: [Sbcl-devel] SB-MANUAL contrib prototype

Hi folks,

can't help much, but I wanted to give feedback on this:

"... This is especially so because no one
seems to care about the user manual, which may be because it's a dead,
neglected, offline thing ..."

I look into the user manual about once a week, usually the online version I find from a search for "sbcl manual". With some luck, it's the current one.
And I would appreciate more information in there. E.g. the parts of the cmucl manual that are linked could be updated to reflect the sbcl state and integrated.

So there's at least one person who _does_ care about the manual. Any improvements and better find-ability would be greatly appreciated.

- Chris




On Thu, Jun 4, 2026 at 12:35 AM Gábor Melis <me...@re...<mailto:me...@re...>> wrote:
Hello

The SBCL user manual is not in great shape. I reckon it's because it is
slow and cumbersome both to read and to write.

For the reader
--------------

- Finding the user manual in whatever form, opening it, finding the
  chapter or definition of interest is pure friction. It's not often
  worth it.

- In the manual, there are very few links. If I see SB-EXT:EXIT
  mentioned in the text, I need to do text search and find the
  definition among the 8 hits.

- The indices in the appendix do not help in a meaningful way (unless
  printed).

- From the narrative part (coming from the doc/manual/*.texinfo chapter
  files), the vast majority of links go to sections.

- The manual is incomplete and sometimes not up-to-date.

- Going from documentation to the code it documents is also a manual
  process.

This friction and low-usability combine to make the user manual
decidedly unfun to read.

I prefer staying in Slime because the docstrings are a M-. away. That's
where most of the of the useful information is anyway. That said, I'd
read the high-level discussions in the manual more often if I could more
easily go to it.

For the writer
--------------

- Change a docstring, recompile SBCL, do make-doc.sh, check the result
  in a browser. Argh.

- Docstrings are in a Markdown subset, but chapters are in Texinfo files
  with different capabilities. At least, changing a chapter file does
  not require recompiling SBCL.

- It is demotivating that no one reads the user manual.

Thus, working on the manual is quite painful.

Addressing these issues
-----------------------

For both the reader and writer, my main goal is to reduce the friction:
opening, navigating, updating the documentation should be as interactive
as working with code.

It is unsurprising, of course, that I think this way considering that I
wrote PAX for pretty much the same reasons
(https://github.com/melisgl/mgl-pax/).

SBCL is different from CL libraries though: it has no lisp library
dependencies. So, using PAX is seemingly out of the question. This is a
pity because PAX provides

- live browsing (to greatly speed up the edit-compile-view cycle)

- a way to switch between code and its documentation easily

- auto- and explicit linking

It's also a fairly mature system.

So, PAX supports really nice, live and offline, cross-linked
documentation in plain text, Markdown, HTML and PDF formats with better
infrastructure than even in Emacs. But PAX is large with a few
dependencies of its own, and I don't think people would appreciate if
SBCL acquired a hard dependency even if only for building documentation
instead of the very stable Texinfo. This is especially so because no one
seems to care about the user manual, which may be because it's a dead,
neglected, offline thing ...

This prototype
--------------

Since a full dependency on PAX is out of question, I implemented in a
couple of hundred lines as much as was absolutely necessary to fake a
PAX-like DEFSECTION macro and generate Texinfo from it:
https://github.com/melisgl/sbcl/commit/f7f8251242696ed7a5d00f359bcb544af6023e73

(Eventually, when all chapter files are converted to lisp,
doc/manual/*.lisp can be removed.)

The generated Texinfo is somewhat close to the original:
https://github.com/melisgl/sbcl/commit/0057f3ae2e49d40e927f2c4502848e57616c191e

Here is the actual manual generated from this Texinfo (of which the
first 6 chapters were generated from Lisp):

- https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.html
- https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.pdf

The implementation is in the new SB-MANUAL contrib. When it's loaded,
one can already M-. around, which provides a quick and dirty
documentation browser.

To actually view the documentation without recompiling the entire SBCL,
we need the live documentation browser from the real PAX (w3m in Slime,
or any browser via Hunchentoot):
https://melisgl.github.io/mgl-pax-world/mgl-pax-manual.html#MGL-PAX:@BROWSING-LIVE-DOCUMENTATION%20MGL-PAX:SECTION

To make switching from documentation to code faster, clicking on the
locative (e.g. "[function]" in "- [function] sb-ext:exit") tells Slime
to visit the definition.

In this prototype, calling SB-MANUAL::SWITCH-TO-PAX will load PAX and
patch up the data in the SB-MANUAL to make it as if PAX had been used
all along. In addition, PAX can generate autolinked dead documentation:

- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.txt
- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.md
- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl.pdf
- https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html

Note the autolinking in all formats but plain text.

In dead documentation, clicking on the locative goes to definition in
the sources on GitHub.

Summary
-------

In this setup, like SLIME, PAX is merely an optional development tool to
make documentation truly interactive. It can also generate dead
documentation with much better internal and external linking.

Even without PAX, the lispification of chapter files provides minor M-.
pleasures and makes linking to sections from definition docstrings
possible.

This is the best I could come up with to make the user manual a part of
the live image within the constraints of SBCL. There is more to be done,
but this should be a good time to give feedback.

Cheers,
Gábor

PS: To play with SB-MANUAL::SWITCH-TO-PAX, you'll need the latest DRef,
PAX and Autoload. Probably best to go with Ultralisp.


_______________________________________________
Sbcl-devel mailing list
Sbc...@li...<mailto:Sbc...@li...>
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

arthur miller <art...@li...> writes:

> I read manual all the time, so I do care about it :). 

We are at least 3 by now.

> I do it in Emacs info mode though. There I can just 's' or 'm' (search
> or menu) and use completing read on menus or links so it is a bit
> better than reading in a web-browser. Especially with Helm and some
> extras to complete menus and search.

Yes, that should be more tolerable. I took note that there is a
sbcl.info consumer, too.

> It would be nice if the ansi draft was included and the standard
> functions or parts of the standard were linked to the draft, but I
> guess it would be a lot of work.

I do not immediately see the point of including the entire ANSI draft,
but autolinks are already made to CLHS (most visible in the PDF, where
external links are red). Also, I'm adding links to the relevant sections
of the CLHS (e.g. "CLHS `1.4.4.5`") while I'm converting the manual.

Though the officially sanctioned submission route is still mailed patches, you could consider opening PRs on the github mirror for incremental beneficial patches like this, as I believe it's very easy for maintainers to review and apply them:
https://github.com/sbcl/sbcl

Cheers
Jesse

> On Jun 4, 2026, at 8:25 AM, arthur miller <art...@li...> wrote:
>
> I read manual all the time, so I do care about it :). I do it in Emacs info mode though. There I can just 's' or 'm' (search or menu) and use completing read on menus or links so it is a bit better than reading in a web-browser. Especially with Helm and some extras to complete menus and search.
>
> But I would appreciate a more detailed and up to date manual. I have once sent in a patch to update the link to C. Rhodes paper about sequences. The link was broken in the manual, but since the patch was ignored I never bothered to send anything more related to the manual.
>
> It would be nice if the ansi draft was included and the standard functions or parts of the standard were linked to the draft, but I guess it would be a lot of work.
>
> -------- Originalmeddelande --------
> Från: Christoph Breitkopf <chb...@gm...>
> Datum: 2026-06-04 13:15 (GMT+01:00)
> Till: Gábor Melis <me...@re...>
> Kopia: sbc...@li...
> Ämne: Re: [Sbcl-devel] SB-MANUAL contrib prototype
>
> Hi folks,
>
> can't help much, but I wanted to give feedback on this:
>
> "... This is especially so because no one
> seems to care about the user manual, which may be because it's a dead,
> neglected, offline thing ..."
>
> I look into the user manual about once a week, usually the online version I find from a search for "sbcl manual". With some luck, it's the current one.
> And I would appreciate more information in there. E.g. the parts of the cmucl manual that are linked could be updated to reflect the sbcl state and integrated.
>
> So there's at least one person who _does_ care about the manual. Any improvements and better find-ability would be greatly appreciated.
>
> - Chris
>
> On Thu, Jun 4, 2026 at 12:35 AM Gábor Melis <me...@re...> wrote:
>
>> Hello
>>
>> The SBCL user manual is not in great shape. I reckon it's because it is
>> slow and cumbersome both to read and to write.
>>
>> For the reader
>> --------------
>>
>> - Finding the user manual in whatever form, opening it, finding the
>> chapter or definition of interest is pure friction. It's not often
>> worth it.
>>
>> - In the manual, there are very few links. If I see SB-EXT:EXIT
>> mentioned in the text, I need to do text search and find the
>> definition among the 8 hits.
>>
>> - The indices in the appendix do not help in a meaningful way (unless
>> printed).
>>
>> - From the narrative part (coming from the doc/manual/*.texinfo chapter
>> files), the vast majority of links go to sections.
>>
>> - The manual is incomplete and sometimes not up-to-date.
>>
>> - Going from documentation to the code it documents is also a manual
>> process.
>>
>> This friction and low-usability combine to make the user manual
>> decidedly unfun to read.
>>
>> I prefer staying in Slime because the docstrings are a M-. away. That's
>> where most of the of the useful information is anyway. That said, I'd
>> read the high-level discussions in the manual more often if I could more
>> easily go to it.
>>
>> For the writer
>> --------------
>>
>> - Change a docstring, recompile SBCL, do make-doc.sh, check the result
>> in a browser. Argh.
>>
>> - Docstrings are in a Markdown subset, but chapters are in Texinfo files
>> with different capabilities. At least, changing a chapter file does
>> not require recompiling SBCL.
>>
>> - It is demotivating that no one reads the user manual.
>>
>> Thus, working on the manual is quite painful.
>>
>> Addressing these issues
>> -----------------------
>>
>> For both the reader and writer, my main goal is to reduce the friction:
>> opening, navigating, updating the documentation should be as interactive
>> as working with code.
>>
>> It is unsurprising, of course, that I think this way considering that I
>> wrote PAX for pretty much the same reasons
>> (https://github.com/melisgl/mgl-pax/).
>>
>> SBCL is different from CL libraries though: it has no lisp library
>> dependencies. So, using PAX is seemingly out of the question. This is a
>> pity because PAX provides
>>
>> - live browsing (to greatly speed up the edit-compile-view cycle)
>>
>> - a way to switch between code and its documentation easily
>>
>> - auto- and explicit linking
>>
>> It's also a fairly mature system.
>>
>> So, PAX supports really nice, live and offline, cross-linked
>> documentation in plain text, Markdown, HTML and PDF formats with better
>> infrastructure than even in Emacs. But PAX is large with a few
>> dependencies of its own, and I don't think people would appreciate if
>> SBCL acquired a hard dependency even if only for building documentation
>> instead of the very stable Texinfo. This is especially so because no one
>> seems to care about the user manual, which may be because it's a dead,
>> neglected, offline thing ...
>>
>> This prototype
>> --------------
>>
>> Since a full dependency on PAX is out of question, I implemented in a
>> couple of hundred lines as much as was absolutely necessary to fake a
>> PAX-like DEFSECTION macro and generate Texinfo from it:
>> https://github.com/melisgl/sbcl/commit/f7f8251242696ed7a5d00f359bcb544af6023e73
>>
>> (Eventually, when all chapter files are converted to lisp,
>> doc/manual/*.lisp can be removed.)
>>
>> The generated Texinfo is somewhat close to the original:
>> https://github.com/melisgl/sbcl/commit/0057f3ae2e49d40e927f2c4502848e57616c191e
>>
>> Here is the actual manual generated from this Texinfo (of which the
>> first 6 chapters were generated from Lisp):
>>
>> - https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.html
>> - https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.pdf
>>
>> The implementation is in the new SB-MANUAL contrib. When it's loaded,
>> one can already M-. around, which provides a quick and dirty
>> documentation browser.
>>
>> To actually view the documentation without recompiling the entire SBCL,
>> we need the live documentation browser from the real PAX (w3m in Slime,
>> or any browser via Hunchentoot):
>> https://melisgl.github.io/mgl-pax-world/mgl-pax-manual.html#MGL-PAX:@BROWSING-LIVE-DOCUMENTATION%20MGL-PAX:SECTION
>>
>> To make switching from documentation to code faster, clicking on the
>> locative (e.g. "[function]" in "- [function] sb-ext:exit") tells Slime
>> to visit the definition.
>>
>> In this prototype, calling SB-MANUAL::SWITCH-TO-PAX will load PAX and
>> patch up the data in the SB-MANUAL to make it as if PAX had been used
>> all along. In addition, PAX can generate autolinked dead documentation:
>>
>> - https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.txt
>> - https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.md
>> - https://quotenil.com/blog-files/sbcl-pax-doc/sbcl.pdf
>> - https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html
>>
>> Note the autolinking in all formats but plain text.
>>
>> In dead documentation, clicking on the locative goes to definition in
>> the sources on GitHub.
>>
>> Summary
>> -------
>>
>> In this setup, like SLIME, PAX is merely an optional development tool to
>> make documentation truly interactive. It can also generate dead
>> documentation with much better internal and external linking.
>>
>> Even without PAX, the lispification of chapter files provides minor M-.
>> pleasures and makes linking to sections from definition docstrings
>> possible.
>>
>> This is the best I could come up with to make the user manual a part of
>> the live image within the constraints of SBCL. There is more to be done,
>> but this should be a good time to give feedback.
>>
>> Cheers,
>> Gábor
>>
>> PS: To play with SB-MANUAL::SWITCH-TO-PAX, you'll need the latest DRef,
>> PAX and Autoload. Probably best to go with Ultralisp.
>>
>> _______________________________________________
>> Sbcl-devel mailing list
>> Sbc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

I read manual all the time, so I do care about it :).  I do it in Emacs info mode though. There I can just 's' or 'm' (search or menu) and use completing read on menus or links so it is a bit better than reading in a web-browser. Especially with Helm and some extras to complete menus and search.

But I would appreciate a more detailed and up to date manual. I have once sent in a patch to update the link to C. Rhodes paper about sequences. The link was broken in the manual, but since the patch was ignored I never bothered to send anything more related to the manual.

It would be nice if the ansi draft was included and the standard functions or parts of the standard were linked to the draft, but I guess it would be a lot of work.


-------- Originalmeddelande --------
Från: Christoph Breitkopf <chb...@gm...>
Datum: 2026-06-04 13:15 (GMT+01:00)
Till: Gábor Melis <me...@re...>
Kopia: sbc...@li...
Ämne: Re: [Sbcl-devel] SB-MANUAL contrib prototype

Hi folks,

can't help much, but I wanted to give feedback on this:

"... This is especially so because no one
seems to care about the user manual, which may be because it's a dead,
neglected, offline thing ..."

I look into the user manual about once a week, usually the online version I find from a search for "sbcl manual". With some luck, it's the current one.
And I would appreciate more information in there. E.g. the parts of the cmucl manual that are linked could be updated to reflect the sbcl state and integrated.

So there's at least one person who _does_ care about the manual. Any improvements and better find-ability would be greatly appreciated.

- Chris




On Thu, Jun 4, 2026 at 12:35 AM Gábor Melis <me...@re...<mailto:me...@re...>> wrote:
Hello

The SBCL user manual is not in great shape. I reckon it's because it is
slow and cumbersome both to read and to write.

For the reader
--------------

- Finding the user manual in whatever form, opening it, finding the
  chapter or definition of interest is pure friction. It's not often
  worth it.

- In the manual, there are very few links. If I see SB-EXT:EXIT
  mentioned in the text, I need to do text search and find the
  definition among the 8 hits.

- The indices in the appendix do not help in a meaningful way (unless
  printed).

- From the narrative part (coming from the doc/manual/*.texinfo chapter
  files), the vast majority of links go to sections.

- The manual is incomplete and sometimes not up-to-date.

- Going from documentation to the code it documents is also a manual
  process.

This friction and low-usability combine to make the user manual
decidedly unfun to read.

I prefer staying in Slime because the docstrings are a M-. away. That's
where most of the of the useful information is anyway. That said, I'd
read the high-level discussions in the manual more often if I could more
easily go to it.

For the writer
--------------

- Change a docstring, recompile SBCL, do make-doc.sh, check the result
  in a browser. Argh.

- Docstrings are in a Markdown subset, but chapters are in Texinfo files
  with different capabilities. At least, changing a chapter file does
  not require recompiling SBCL.

- It is demotivating that no one reads the user manual.

Thus, working on the manual is quite painful.

Addressing these issues
-----------------------

For both the reader and writer, my main goal is to reduce the friction:
opening, navigating, updating the documentation should be as interactive
as working with code.

It is unsurprising, of course, that I think this way considering that I
wrote PAX for pretty much the same reasons
(https://github.com/melisgl/mgl-pax/).

SBCL is different from CL libraries though: it has no lisp library
dependencies. So, using PAX is seemingly out of the question. This is a
pity because PAX provides

- live browsing (to greatly speed up the edit-compile-view cycle)

- a way to switch between code and its documentation easily

- auto- and explicit linking

It's also a fairly mature system.

So, PAX supports really nice, live and offline, cross-linked
documentation in plain text, Markdown, HTML and PDF formats with better
infrastructure than even in Emacs. But PAX is large with a few
dependencies of its own, and I don't think people would appreciate if
SBCL acquired a hard dependency even if only for building documentation
instead of the very stable Texinfo. This is especially so because no one
seems to care about the user manual, which may be because it's a dead,
neglected, offline thing ...

This prototype
--------------

Since a full dependency on PAX is out of question, I implemented in a
couple of hundred lines as much as was absolutely necessary to fake a
PAX-like DEFSECTION macro and generate Texinfo from it:
https://github.com/melisgl/sbcl/commit/f7f8251242696ed7a5d00f359bcb544af6023e73

(Eventually, when all chapter files are converted to lisp,
doc/manual/*.lisp can be removed.)

The generated Texinfo is somewhat close to the original:
https://github.com/melisgl/sbcl/commit/0057f3ae2e49d40e927f2c4502848e57616c191e

Here is the actual manual generated from this Texinfo (of which the
first 6 chapters were generated from Lisp):

- https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.html
- https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.pdf

The implementation is in the new SB-MANUAL contrib. When it's loaded,
one can already M-. around, which provides a quick and dirty
documentation browser.

To actually view the documentation without recompiling the entire SBCL,
we need the live documentation browser from the real PAX (w3m in Slime,
or any browser via Hunchentoot):
https://melisgl.github.io/mgl-pax-world/mgl-pax-manual.html#MGL-PAX:@BROWSING-LIVE-DOCUMENTATION%20MGL-PAX:SECTION

To make switching from documentation to code faster, clicking on the
locative (e.g. "[function]" in "- [function] sb-ext:exit") tells Slime
to visit the definition.

In this prototype, calling SB-MANUAL::SWITCH-TO-PAX will load PAX and
patch up the data in the SB-MANUAL to make it as if PAX had been used
all along. In addition, PAX can generate autolinked dead documentation:

- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.txt
- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.md
- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl.pdf
- https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html

Note the autolinking in all formats but plain text.

In dead documentation, clicking on the locative goes to definition in
the sources on GitHub.

Summary
-------

In this setup, like SLIME, PAX is merely an optional development tool to
make documentation truly interactive. It can also generate dead
documentation with much better internal and external linking.

Even without PAX, the lispification of chapter files provides minor M-.
pleasures and makes linking to sections from definition docstrings
possible.

This is the best I could come up with to make the user manual a part of
the live image within the constraints of SBCL. There is more to be done,
but this should be a good time to give feedback.

Cheers,
Gábor

PS: To play with SB-MANUAL::SWITCH-TO-PAX, you'll need the latest DRef,
PAX and Autoload. Probably best to go with Ultralisp.


_______________________________________________
Sbcl-devel mailing list
Sbc...@li...<mailto:Sbc...@li...>
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Hi folks,

can't help much, but I wanted to give feedback on this:

"... This is especially so because no one
seems to care about the user manual, which may be because it's a dead,
neglected, offline thing ..."

I look into the user manual about once a week, usually the online version I
find from a search for "sbcl manual". With some luck, it's the current one.
And I would appreciate more information in there. E.g. the parts of the
cmucl manual that are linked could be updated to reflect the sbcl state and
integrated.

So there's at least one person who _does_ care about the manual. Any
improvements and better find-ability would be greatly appreciated.

- Chris




On Thu, Jun 4, 2026 at 12:35 AM Gábor Melis <me...@re...> wrote:

> Hello
>
> The SBCL user manual is not in great shape. I reckon it's because it is
> slow and cumbersome both to read and to write.
>
> For the reader
> --------------
>
> - Finding the user manual in whatever form, opening it, finding the
>   chapter or definition of interest is pure friction. It's not often
>   worth it.
>
> - In the manual, there are very few links. If I see SB-EXT:EXIT
>   mentioned in the text, I need to do text search and find the
>   definition among the 8 hits.
>
> - The indices in the appendix do not help in a meaningful way (unless
>   printed).
>
> - From the narrative part (coming from the doc/manual/*.texinfo chapter
>   files), the vast majority of links go to sections.
>
> - The manual is incomplete and sometimes not up-to-date.
>
> - Going from documentation to the code it documents is also a manual
>   process.
>
> This friction and low-usability combine to make the user manual
> decidedly unfun to read.
>
> I prefer staying in Slime because the docstrings are a M-. away. That's
> where most of the of the useful information is anyway. That said, I'd
> read the high-level discussions in the manual more often if I could more
> easily go to it.
>
> For the writer
> --------------
>
> - Change a docstring, recompile SBCL, do make-doc.sh, check the result
>   in a browser. Argh.
>
> - Docstrings are in a Markdown subset, but chapters are in Texinfo files
>   with different capabilities. At least, changing a chapter file does
>   not require recompiling SBCL.
>
> - It is demotivating that no one reads the user manual.
>
> Thus, working on the manual is quite painful.
>
> Addressing these issues
> -----------------------
>
> For both the reader and writer, my main goal is to reduce the friction:
> opening, navigating, updating the documentation should be as interactive
> as working with code.
>
> It is unsurprising, of course, that I think this way considering that I
> wrote PAX for pretty much the same reasons
> (https://github.com/melisgl/mgl-pax/).
>
> SBCL is different from CL libraries though: it has no lisp library
> dependencies. So, using PAX is seemingly out of the question. This is a
> pity because PAX provides
>
> - live browsing (to greatly speed up the edit-compile-view cycle)
>
> - a way to switch between code and its documentation easily
>
> - auto- and explicit linking
>
> It's also a fairly mature system.
>
> So, PAX supports really nice, live and offline, cross-linked
> documentation in plain text, Markdown, HTML and PDF formats with better
> infrastructure than even in Emacs. But PAX is large with a few
> dependencies of its own, and I don't think people would appreciate if
> SBCL acquired a hard dependency even if only for building documentation
> instead of the very stable Texinfo. This is especially so because no one
> seems to care about the user manual, which may be because it's a dead,
> neglected, offline thing ...
>
> This prototype
> --------------
>
> Since a full dependency on PAX is out of question, I implemented in a
> couple of hundred lines as much as was absolutely necessary to fake a
> PAX-like DEFSECTION macro and generate Texinfo from it:
>
> https://github.com/melisgl/sbcl/commit/f7f8251242696ed7a5d00f359bcb544af6023e73
>
> (Eventually, when all chapter files are converted to lisp,
> doc/manual/*.lisp can be removed.)
>
> The generated Texinfo is somewhat close to the original:
>
> https://github.com/melisgl/sbcl/commit/0057f3ae2e49d40e927f2c4502848e57616c191e
>
> Here is the actual manual generated from this Texinfo (of which the
> first 6 chapters were generated from Lisp):
>
> - https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.html
> - https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.pdf
>
> The implementation is in the new SB-MANUAL contrib. When it's loaded,
> one can already M-. around, which provides a quick and dirty
> documentation browser.
>
> To actually view the documentation without recompiling the entire SBCL,
> we need the live documentation browser from the real PAX (w3m in Slime,
> or any browser via Hunchentoot):
>
> https://melisgl.github.io/mgl-pax-world/mgl-pax-manual.html#MGL-PAX:@BROWSING-LIVE-DOCUMENTATION%20MGL-PAX:SECTION
>
> To make switching from documentation to code faster, clicking on the
> locative (e.g. "[function]" in "- [function] sb-ext:exit") tells Slime
> to visit the definition.
>
> In this prototype, calling SB-MANUAL::SWITCH-TO-PAX will load PAX and
> patch up the data in the SB-MANUAL to make it as if PAX had been used
> all along. In addition, PAX can generate autolinked dead documentation:
>
> - https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.txt
> - https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.md
> - https://quotenil.com/blog-files/sbcl-pax-doc/sbcl.pdf
> - https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html
>
> Note the autolinking in all formats but plain text.
>
> In dead documentation, clicking on the locative goes to definition in
> the sources on GitHub.
>
> Summary
> -------
>
> In this setup, like SLIME, PAX is merely an optional development tool to
> make documentation truly interactive. It can also generate dead
> documentation with much better internal and external linking.
>
> Even without PAX, the lispification of chapter files provides minor M-.
> pleasures and makes linking to sections from definition docstrings
> possible.
>
> This is the best I could come up with to make the user manual a part of
> the live image within the constraints of SBCL. There is more to be done,
> but this should be a good time to give feedback.
>
> Cheers,
> Gábor
>
> PS: To play with SB-MANUAL::SWITCH-TO-PAX, you'll need the latest DRef,
> PAX and Autoload. Probably best to go with Ultralisp.
>
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>

Hello

The SBCL user manual is not in great shape. I reckon it's because it is
slow and cumbersome both to read and to write.

For the reader
--------------

- Finding the user manual in whatever form, opening it, finding the
  chapter or definition of interest is pure friction. It's not often
  worth it.

- In the manual, there are very few links. If I see SB-EXT:EXIT
  mentioned in the text, I need to do text search and find the
  definition among the 8 hits.

- The indices in the appendix do not help in a meaningful way (unless
  printed).

- From the narrative part (coming from the doc/manual/*.texinfo chapter
  files), the vast majority of links go to sections.

- The manual is incomplete and sometimes not up-to-date.

- Going from documentation to the code it documents is also a manual
  process.

This friction and low-usability combine to make the user manual
decidedly unfun to read.

I prefer staying in Slime because the docstrings are a M-. away. That's
where most of the of the useful information is anyway. That said, I'd
read the high-level discussions in the manual more often if I could more
easily go to it.

For the writer
--------------

- Change a docstring, recompile SBCL, do make-doc.sh, check the result
  in a browser. Argh.

- Docstrings are in a Markdown subset, but chapters are in Texinfo files
  with different capabilities. At least, changing a chapter file does
  not require recompiling SBCL.

- It is demotivating that no one reads the user manual.

Thus, working on the manual is quite painful.

Addressing these issues
-----------------------

For both the reader and writer, my main goal is to reduce the friction:
opening, navigating, updating the documentation should be as interactive
as working with code.

It is unsurprising, of course, that I think this way considering that I
wrote PAX for pretty much the same reasons
(https://github.com/melisgl/mgl-pax/).

SBCL is different from CL libraries though: it has no lisp library
dependencies. So, using PAX is seemingly out of the question. This is a
pity because PAX provides

- live browsing (to greatly speed up the edit-compile-view cycle)

- a way to switch between code and its documentation easily

- auto- and explicit linking

It's also a fairly mature system.

So, PAX supports really nice, live and offline, cross-linked
documentation in plain text, Markdown, HTML and PDF formats with better
infrastructure than even in Emacs. But PAX is large with a few
dependencies of its own, and I don't think people would appreciate if
SBCL acquired a hard dependency even if only for building documentation
instead of the very stable Texinfo. This is especially so because no one
seems to care about the user manual, which may be because it's a dead,
neglected, offline thing ...

This prototype
--------------

Since a full dependency on PAX is out of question, I implemented in a
couple of hundred lines as much as was absolutely necessary to fake a
PAX-like DEFSECTION macro and generate Texinfo from it:
https://github.com/melisgl/sbcl/commit/f7f8251242696ed7a5d00f359bcb544af6023e73

(Eventually, when all chapter files are converted to lisp,
doc/manual/*.lisp can be removed.)

The generated Texinfo is somewhat close to the original:
https://github.com/melisgl/sbcl/commit/0057f3ae2e49d40e927f2c4502848e57616c191e

Here is the actual manual generated from this Texinfo (of which the
first 6 chapters were generated from Lisp):

- https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.html
- https://quotenil.com/blog-files/sbcl-pax-doc/texinfo/sbcl.pdf

The implementation is in the new SB-MANUAL contrib. When it's loaded,
one can already M-. around, which provides a quick and dirty
documentation browser.

To actually view the documentation without recompiling the entire SBCL,
we need the live documentation browser from the real PAX (w3m in Slime,
or any browser via Hunchentoot):
https://melisgl.github.io/mgl-pax-world/mgl-pax-manual.html#MGL-PAX:@BROWSING-LIVE-DOCUMENTATION%20MGL-PAX:SECTION

To make switching from documentation to code faster, clicking on the
locative (e.g. "[function]" in "- [function] sb-ext:exit") tells Slime
to visit the definition.

In this prototype, calling SB-MANUAL::SWITCH-TO-PAX will load PAX and
patch up the data in the SB-MANUAL to make it as if PAX had been used
all along. In addition, PAX can generate autolinked dead documentation:

- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.txt
- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl-manual.md
- https://quotenil.com/blog-files/sbcl-pax-doc/sbcl.pdf
- https://quotenil.com/blog-files/sbcl-pax-doc/html/sbcl-manual.html

Note the autolinking in all formats but plain text.

In dead documentation, clicking on the locative goes to definition in
the sources on GitHub.

Summary
-------

In this setup, like SLIME, PAX is merely an optional development tool to
make documentation truly interactive. It can also generate dead
documentation with much better internal and external linking.

Even without PAX, the lispification of chapter files provides minor M-.
pleasures and makes linking to sections from definition docstrings
possible.

This is the best I could come up with to make the user manual a part of
the live image within the constraints of SBCL. There is more to be done,
but this should be a good time to give feedback.

Cheers,
Gábor

PS: To play with SB-MANUAL::SWITCH-TO-PAX, you'll need the latest DRef,
PAX and Autoload. Probably best to go with Ultralisp.

Howdy sbcl-devel,

Here is a revised patch to introduce fibers/coroutines via a sb-fiber contrib and what I believe to be idiomatic x86-64/arm64 runtime support. Subsequent to providing invaluable guidance on implementation, Charles Zhang was kind enough to review a version a few weeks ago and suggested that it was in good enough shape that I share it here to solicit feedback on interface shape, completeness and fitness to purpose.

There's been further work over the past few weeks, mainly an outcome of exposing a fiber-based HTTP proxy in a DMZ, where it was promptly incinerated by scanners, php probes, etc. The package has gained more consistent interrupt and condition support, and notably the ability to migrate fibers between threads, which should allow users good flexibility in scheduler design. Further to that, I'll say again that the main goal here has been to introduce the minimal operation set to support user applications: concrete scheduler and generator implementations are not provided. I'll share gists of what I'm using for those, if there is interest.

Some measurements on arm64, Apple M2, Mac14,2 are:

pingpong (resume, yield)         ~62 ns/op   (2 switches/iter -> ~31 ns/switch)
switch, 32 live bindings      ~97 ns/op   (binding-stack swap = ~2 ns/binding)
make-fiber, release           ~4.6 us/op   (stack mmap, struct alloc)

(Creation is mmap-bound; pooling is the obvious mitigation.)

A patch is attached, corresponding to https://github.com/jbouwman/sbcl/commit/1c5ba1fc4ee3246e4455e2af998b9e7eb004cbf2

  — Jesse

I think this somehow breaks non-threaded platforms, and single-threaded
builds on usually-threaded platforms: the use of pthread_self() without
a pthread.h include in scope.  (Of course nothing is simple because we
probably don't want to include pthread.h on Windows).

In file included from interrupt.c:71:
interrupt.c: In function 'can_handle_now':
genesis/events.h:66:30: error: implicit declaration of function 'pthread_self'; did you mean 'pthread_kill'? [-Wimplicit-function-declaration]
   66 |    eventdata[i_] = ((uword_t)pthread_self() << 2) | id;   eventdata[i_+1] = (uword_t)arg1; \
      |                              ^~~~~~~~~~~~
genesis/events.h:91:55: note: in expansion of macro 'EVENT3'
   91 | #define event_SigDeferred_IntDisabled(arg1,arg2,arg3) EVENT3(EventSigDeferred_IntDisabled,arg1,arg2,arg3)
      |                                                       ^~~~~~
interrupt.c:1262:9: note: in expansion of macro 'event_SigDeferred_IntDisabled'
 1262 |         event_SigDeferred_IntDisabled(handler, signal, in_leaving_without_gcing_race_p(thread));
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

is where it breaks for me on arm and x86-64.

It is not broken in github CI for non-threaded x86 / x86-64, which is
interesting: I guess something was making pthread_self() visible there
despite the missing explicit include?  My build breakage is with Debian
trixie in both cases, and locally adding <pthread.h> to the bit in
genesis/events.h allows the build to complete.

Christophe

snuglas via Sbcl-commits <sbc...@li...> writes:

> +(defun write-events (output &aux (defs sb-impl::*c-runtime-events*))
> +  ;; Only 5 bits are allocated to the ID in an event record
> +  (aver (<= (length defs) 32))
> +  (format output "enum vmevent {~%  Event~A=0~{,~%  Event~A~}~%};~2%"
> +          (caar defs) (mapcar 'car (cdr defs)))
> +  (format output "#include <stdint.h>
> +#define EVENTBUFMAX 400000
> +extern uintptr_t *eventdata;
> +extern int n_logevents;
> +#ifndef should_record_event
> +#define should_record_event(x) 0
> +#endif~%")
> +  ;; eventN = record event with N parameters
> +  ;; NOTE 1: The buffer is oversized by enough to ensure that i_+N does not
> +  ;; overrun, so we need not adjust the comparison of 'i_ <' by the number
> +  ;; of format arguments. A more sophisticated approach would have the log
> +  ;; be a ring buffer, which would work fine in most cases since the focus
> +  ;; of a crash is generally on the most recent events.
> +  ;; NOTE 2: Assume that pthread_self() can be cast to 'uword_t' - which is
> +  ;; true for or supported platforms - and that the low 3 bits are 0 (which
> +  ;; may not hold for 32-bit, but surely does for 64-bit). Hence the low 3 can
> +  ;; can be used for the ID. But in fact we would like 5 bits for that, so
> +  ;; left-shift an additional 2 bits. This is OK as long as the upper 2 bits
> +  ;; of pthread_t are 0, which they are if it's a virtual address.
> +  (flet ((count-printf-args (str &aux (count 0) (start 0))
> +           (loop (let ((p (position #\% str :start start)))
> +                   (setq start (cond ((not p) (return count))
> +                                     ((char= (char str (1+ p)) #\%) (+ p 2))
> +                                     (t (incf count) (1+ p)))))))
> +         (formals (arity)
> +           (if (> arity 0)
> +               (format nil "~{,arg~D~}" (loop for i from 1 repeat arity collect i))
> +               "")))
> +    (format output "#ifdef WANT_EVENTLOG_FORMAT_STRINGS
> +static char event_printf_nargs[32] = {~{~D~^,~}};
> +static char *event_printf_format[] = {~{~%  ~S~^,~}~%};~%#endif~2%"
> +            (mapcar (lambda (x) (count-printf-args (cadr x))) defs)
> +            (mapcar 'cadr defs))
> +    (dotimes (argc 7)
> +      (format output "#define EVENT~D(id~A) { if(should_record_event(id)) \\
> + { int i_ = __sync_fetch_and_add(&n_logevents, ~A); if (i_ < EVENTBUFMAX) { \\
> +   eventdata[i_] = ((uword_t)pthread_self() << 2) | id;~
> +~{   eventdata[i_+~D] = (uword_t)arg~:*~D;~^ \\~%~} }}}~%"
> +              argc (formals argc) (1+ argc) (loop for n from 1 to argc collect n)))
> +    (dolist (x defs)
> +      (let* ((event (car x))
> +             (arity (count-printf-args (cadr x)))
> +             (formals (formals arity)))
> +        (format output "#define event_~A(~A) EVENT~D(Event~A~A)~%"
> +                event (subseq formals (min 1 (length formals)))
> +                arity event formals)))))

Fixed. Thanks.

On Fri, May 22, 2026 at 11:08 PM J Klein <je...@gm...> wrote:
>
>
>
> Unless I'm messing up, it seems that repeatedly using listen  on a run-program output stream in what appears to be a non-recursive situation results in control stack exhaustion.
>
> The (read-yes)  function below gives an error when using LISTEN but not when using READ-CHAR-NO-HANG for same purpose.
>
> This is a stripped down version of a function that runs an external program that performs a web connection and processes it, and outputs it.  This one just calls /usr/bin/yes as the external process.
>
> Apologies in advance is this is some error on my part.
>
>
> cl-user> (lisp-implementation-version)  ;; found no reference to listen in last few months of sbcl bug list
> "2.6.0"
>
> cl-user> (read-yes :listen nil)  ;; using read-char-no-hang
> 8388608
>
>
>
> cl-user> (read-yes :listen t)
>
> Control stack exhausted (no more space for function call frames).
> This is probably due to heavily nested or infinitely recursive function
> calls, or a tail call that SBCL cannot or has not optimized away.
>
> PROCEED WITH CAUTION.
>    [Condition of type sb-kernel::control-stack-exhausted]
>
> Restarts:
>  0: [retry] Retry SLIME REPL evaluation request.
>  1: [*abort] Return to SLIME's top level.
>  2: [abort] abort thread (#<thread tid=10499 "repl-thread" running {70051604A3}>)
>
> Backtrace:
>   0: (sb-kernel::control-stack-exhausted-error)
>   1: (sb-impl::fd-stream-misc-routine #<sb-sys:fd-stream for "descriptor 31" {70087B8853}> 0 0)
>   2: (listen #<sb-sys:fd-stream for "descriptor 31" {70087B8853}>)
>
> ------
>
> cl-user> *features*
> (:osicat-fd-streams :chunga :cl-fad :cl-ppcre :cl+ssl-homebrew-arm64-found
>  :cl+ssl-macports-found :split-sequence :flexi-streams :xmls-nodes-are-structs
>  :have-nr-wavelets chipz-system:gray-streams :swank :lparallel
>  :lparallel.with-cltl2 :lparallel.with-cas :lparallel.with-stealing-scheduler
>  :bordeaux-threads :global-vars :thread-support cffi-features:flat-namespace
>  cffi-features:unix cffi-features:darwin :cffi cffi-sys::flat-namespace
>  alexandria::sequence-emptyp :quicklisp :infix :asdf3.3 :asdf3.2 :asdf3.1
>  :asdf3 :asdf2 :asdf :os-macosx :os-unix :non-base-chars-exist-p :asdf-unicode
>  :arena-allocator :arm64 :gencgc :64-bit :ansi-cl :bsd :common-lisp :darwin
>  :ieee-floating-point :little-endian :mach-o :package-local-nicknames
>  :sb-core-compression :sb-ldb :sb-package-locks :sb-thread :sb-unicode :sbcl
>  :unix)
>
>
>
>
>
>  (defun read-yes (&key
>    (listen t) ;; use LISTEN instead of READ-CHAR-NO-HANG
>    (nwanted #.(expt 2 23))  ;; try to read this many butes
>    (max-output-length #.(expt 2 24)))  ;; safety read max
>   (let ((proc (sb-ext:run-program "/usr/bin/yes" nil :input :stream :output :stream :error :stream :wait nil)))
>     (let
> ((output-string
>    (with-output-to-string (sout)
>      (loop
> with in-stream = (sb-ext:process-output proc)
> with nbytes of-type fixnum = 0
> do
>   ;; LISTEN causes stack exhaustion on arm64 darwin
>   (if listen
>       (loop until (not (listen in-stream))
>     for c = (read-char in-stream nil nil)
>     while c
>     do (write-char c sout)
> (incf nbytes 1)
> (when (= nbytes nwanted) (return nil)))
>       (loop for c = (read-char-no-hang in-stream nil nil)
>     while c
>     do (write-char c sout)
> (incf nbytes 1)
> (when (= nbytes nwanted) (return nil))))
>   ;; when done, return
>   (when (not (process-alive-p proc))
>     (return nil))
>   (when (= nbytes nwanted) ;; done
>     (return nil))
>   (when (> nbytes max-output-length)
>     (error "External process output too long."))))))
>
>       (length output-string))))
> _______________________________________________
> Sbcl-bugs mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

On 5/18/26 10:58 AM, Stas Boukarev wrote:
> (let () (compile nil `(lambda (x)
>                                    (declare (optimize speed))
>                                    (1+ x))))
> stopped producing optimization notes.


have you tried the code starting with locally instead of let?



CL-USER> (locally (declare (optimize (speed 3) (debug 2)))
   (compile nil `(lambda (x)
                   (declare (optimize speed))
                   (1+ x))))
; in: LAMBDA (X)
;     (1+ X)
;
; note: unable to associate +/(+ -) of constants due to type 
uncertainty: The first argument is a NUMBER, not a RATIONAL.
;
; note: forced to do GENERIC-+ (cost 10)
;       unable to do #1=inline fixnum arithmetic (cost 1) because:
;       The first argument is a T, not a FIXNUM.
;       The result is a (VALUES NUMBER . #2=(&OPTIONAL)), not a (VALUES 
FIXNUM . #2#).
;       unable to do #1# (cost 2) because:
;       The first argument is a T, not a FIXNUM.
;       The result is a (VALUES NUMBER . #2#), not a (VALUES FIXNUM . #2#).
;       etc.
;
; compilation unit finished
;   printed 2 notes
#<FUNCTION (LAMBDA (X)) {B800C1C84B}>
NIL
NIL
CL-USER>

On Thu, May 21, 2026 at 11:09 AM Charles Zhang <cha...@ya...> wrote:
>
> Oh, right. Thanks for tracking these issues down.

I just fed the function to an llm.

> I look forward to any masochist’s x86-64 software implementation to make breakpoint tracing thread safe. :)
>
> On Thursday, May 21, 2026, 12:30 AM, Stas Boukarev <sta...@gm...> wrote:
>
> It's a safepoint.
>
> On Thu, May 21, 2026 at 12:22 AM Charles Zhang <cha...@ya...> wrote:
> >
> > Thanks. Not a proper fix because I don't have a Windows machine. I'm thoroughly confused about why this is Windows only.
> >
> >
> >
> >
> >
> > On Wednesday, May 20, 2026 at 08:29:14 PM GMT+2, Stas Boukarev <sta...@gm...> wrote:
> >
> >
> > ::: Running (TRACE :ENCAPSULATE NIL)
> > fatal error encountered in SBCL pid 5521255184:
> > Unsupported LDR (literal) variant.
> > 0: 00000291caaa1938 pc=0000001000181ed0 {0000001000181dc0+0110}
> > SB-DI::BREAKPOINT-DO-DISPLACED-INST
> > 1: 00000291caaa1928 pc=00007ff7531059e0
> > 2: 00000291caaa1900 pc=00000010019d75e0 {00000010019d7580+0060}
> > CL-USER::TRACE-THIS
> >
> > On Wed, May 20, 2026 at 1:14 PM apache--- via Sbcl-commits
> > <sbc...@li...> wrote:
> > >
> > > The branch "master" has been updated in SBCL:
> > >        via  f982475b0bcb6d691cf172630fad9c14087378b2 (commit)
> > >      from  07f82d35917900fe1222891579c2fe9d3d8df3c4 (commit)
> > >
> > > - Log -----------------------------------------------------------------
> > > commit f982475b0bcb6d691cf172630fad9c14087378b2
> > > Author: Charles Zhang <cha...@ya...>
> > > Date:  Tue Mar 17 15:18:20 2026 +0100
> > >
> > >    arm64-arch.c: Fix soft-simulation of some instructions.
> > >
> > >    For breakpoint support.
> > > ---
> > >  src/runtime/arm64-arch.c | 63 ++++++++++++++++++++++++++++++------------------
> > >  1 file changed, 39 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/src/runtime/arm64-arch.c b/src/runtime/arm64-arch.c
> > > index 9183013fe..e9e8d3af1 100644
> > > --- a/src/runtime/arm64-arch.c
> > > +++ b/src/runtime/arm64-arch.c
> > > @@ -88,20 +88,35 @@ condition_holds(os_context_t *context, unsigned int cond)
> > >  {
> > >      int flags = *os_context_flags_addr(context);
> > >      bool result;
> > > -    // Evaluate base condition.
> > > -    switch (cond) {
> > > -    case 0b000: result = ((flags >> Z_BIT) & 1);
> > > -    case 0b001: result = ((flags >> C_BIT) & 1);
> > > -    case 0b010: result = ((flags >> N_BIT) & 1);
> > > -    case 0b011: result = ((flags >> V_BIT) & 1);
> > > -    case 0b100: result = ((flags >> V_BIT) & 1) && ~((flags >> Z_BIT) & 1);
> > > -    case 0b101: result = ((flags >> N_BIT) == (flags >> V_BIT));
> > > -    case 0b110: result = ((flags >> N_BIT) == (flags >> V_BIT)) && !((flags >> Z_BIT) & 1);
> > > -    case 0b111: result = 1;
> > > +    // Evaluate base condition (ignoring the inversion bit).
> > > +    switch (cond >> 1) {
> > > +    case 0b000:
> > > +      result = (flags >> Z_BIT) & 1;
> > > +      break;
> > > +    case 0b001:
> > > +      result = (flags >> C_BIT) & 1;
> > > +      break;
> > > +    case 0b010:
> > > +      result = (flags >> N_BIT) & 1;
> > > +      break;
> > > +    case 0b011: result = (flags >> V_BIT) & 1;
> > > +      break;
> > > +    case 0b100:
> > > +      result = ((flags >> C_BIT) & 1) && !((flags >> Z_BIT) & 1);
> > > +      break;
> > > +    case 0b101:
> > > +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1);
> > > +      break;
> > > +    case 0b110:
> > > +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1) && !((flags >> Z_BIT) & 1);
> > > +      break;
> > > +    default:
> > > +      result = 1;
> > > +      break;
> > >      }
> > >
> > > -    // Condition flag values in the set '111x' indicate always true
> > > -    // Otherwise, invert condition if necessary.
> > > +    // Condition flag values in the set '111x' indicate always true.
> > > +    // Otherwise, invert condition if the low bit is set.
> > >      if ((cond & 0b1) && (cond != 0b1111))
> > >          result = !result;
> > >
> > > @@ -158,12 +173,10 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
> > >      }
> > >      else if (((orig_inst >> 25) & 0b111111) == 0b011010) {
> > >          // Compare branch imm
> > > -        bool size_is_64 = (orig_inst >> 31) & 0b1;
> > >          bool op = (orig_inst >> 24) & 0b1;
> > >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> > >          int rt = orig_inst & 0b11111;
> > > -        if (!size_is_64) lose("Size must be 64 bits.");
> > > -        if (*os_context_register_addr(context, rt) ^ op)
> > > +        if ((!*os_context_register_addr(context, rt)) ^ op)
> > >              next_pc += offset;
> > >          else
> > >              next_pc += 1;
> > > @@ -173,32 +186,34 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
> > >          bool b5 = (orig_inst >> 31) & 0b1;
> > >          bool op = (orig_inst >> 24) & 0b1;
> > >          bool b40 = (orig_inst >> 19) & 0b11111;
> > > -        int bit_pos = (b5 << 6) | b40;
> > > +        int bit_pos = (b5 << 5) | b40;
> > >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 14), 14);
> > >          int rt = orig_inst & 0b11111;
> > > -        if (!b5) lose("b5 must be 64 bits.");
> > >          if (((*os_context_register_addr(context, rt) >> bit_pos) & 0b1) ^ op)
> > >              next_pc += offset;
> > >          else
> > >              next_pc += 1;
> > >      }
> > > -    else if (((orig_inst >> 31) & 0b1) == 0b0) {
> > > +    else if (((orig_inst >> 24) & 0b11111) == 0b11000) {
> > >          // LDR (literal)
> > > -        bool size_is_64 = (orig_inst >> 30) & 0b1;
> > > +        int opc = (orig_inst >> 30) & 0b11;
> > >          int rt = orig_inst & 0b11111;
> > >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> > > -        if (!size_is_64) lose("Size must be 64 bits.");
> > > -        *os_context_register_addr(context, rt) = *((lispobj*)(pc + offset));
> > > +        if (opc == 0b01)
> > > +          *os_context_register_addr(context, rt) = *((uint64_t *)(pc + offset));
> > > +        else if (opc == 0b00)
> > > +          *os_context_register_addr(context, rt) = *((uint32_t *)(pc + offset));
> > > +        else
> > > +          lose("Unsupported LDR (literal) variant.");
> > >          next_pc += 1;
> > >      }
> > >      else if (((orig_inst >> 24) & 0b11111) == 0b10000) {
> > >          // ADR(P)
> > >          bool op = (orig_inst >> 31) & 0b1;
> > >          int rd = orig_inst & 0b11111;
> > > -        int imm = sign_extend(((orig_inst >> 5) & ~(1 << 19)) |
> > > -                              ((orig_inst >> 29) & ~(1 << 2)), 21);
> > > +        int imm = sign_extend(((orig_inst >> 3) & 0x1FFFFC) | ((orig_inst >> 29) & 3), 21);
> > >          if (op) // ADRP
> > > -            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(1 << 12)) + (imm << 12);
> > > +            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(uword_t)0xFFF) + ((sword_t)imm << 12);
> > >          else // ADR
> > >              *os_context_register_addr(context, rd) = (uword_t)pc + imm;
> > >          next_pc += 1;
> > >
> > > -----------------------------------------------------------------------
> > >
> > >
> > > hooks/post-receive
> > > --
> > > SBCL
> > >
> > >
> > > _______________________________________________
> > > Sbcl-commits mailing list
> > > Sbc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/sbcl-commits

There's more breakage from removed symbols.
Some code (slime) grabbed sb-c::tl-xep, some code used
SB-IMPL::MAKE-EVAL-LAMBDA.
Some referenced SB-PCL::CHECK-APPLICABLE-KEYWORDS.
Neither of these uses is defensible, but they should be updated
(naturally, slime already is).

On Thu, May 21, 2026 at 11:52 AM Christophe Rhodes via Sbcl-devel
<sbc...@li...> wrote:
>
> Hi all,
>
> Let's press pause on all the exciting changes for now, while we gear up
> for sbcl-2.6.5, probably in the latter half of next week.  Testing would
> be much appreciated, particularly of Real World Code, because although
> we are completely within our rights to change the implementation of
> INTERSECTION and UNION, history (and a current system which rhymes a bit
> with Boogle Plights) suggests that it's possible to end up embedding
> dependencies on the order of elements in the return values of those
> notional set functions.  Reports and bug fixes to other software that
> embeds those assumptions, as well as to SBCL itself, are even more
> welcome in the next week than they would be in general.
>
> Thanks,
>
> Christophe
>
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Hi all,

Let's press pause on all the exciting changes for now, while we gear up
for sbcl-2.6.5, probably in the latter half of next week.  Testing would
be much appreciated, particularly of Real World Code, because although
we are completely within our rights to change the implementation of
INTERSECTION and UNION, history (and a current system which rhymes a bit
with Boogle Plights) suggests that it's possible to end up embedding
dependencies on the order of elements in the return values of those
notional set functions.  Reports and bug fixes to other software that
embeds those assumptions, as well as to SBCL itself, are even more
welcome in the next week than they would be in general.

Thanks,

Christophe

Oh, right. Thanks for tracking these issues down.

I look forward to any masochist’s x86-64 software implementation to make breakpoint tracing thread safe. :)

On Thursday, May 21, 2026, 12:30 AM, Stas Boukarev <sta...@gm...> wrote:

It's a safepoint.

On Thu, May 21, 2026 at 12:22 AM Charles Zhang <cha...@ya...> wrote:
>
> Thanks. Not a proper fix because I don't have a Windows machine. I'm thoroughly confused about why this is Windows only.
>
>
>
>
>
> On Wednesday, May 20, 2026 at 08:29:14 PM GMT+2, Stas Boukarev <sta...@gm...> wrote:
>
>
> ::: Running (TRACE :ENCAPSULATE NIL)
> fatal error encountered in SBCL pid 5521255184:
> Unsupported LDR (literal) variant.
> 0: 00000291caaa1938 pc=0000001000181ed0 {0000001000181dc0+0110}
> SB-DI::BREAKPOINT-DO-DISPLACED-INST
> 1: 00000291caaa1928 pc=00007ff7531059e0
> 2: 00000291caaa1900 pc=00000010019d75e0 {00000010019d7580+0060}
> CL-USER::TRACE-THIS
>
> On Wed, May 20, 2026 at 1:14 PM apache--- via Sbcl-commits
> <sbc...@li...> wrote:
> >
> > The branch "master" has been updated in SBCL:
> >        via  f982475b0bcb6d691cf172630fad9c14087378b2 (commit)
> >      from  07f82d35917900fe1222891579c2fe9d3d8df3c4 (commit)
> >
> > - Log -----------------------------------------------------------------
> > commit f982475b0bcb6d691cf172630fad9c14087378b2
> > Author: Charles Zhang <cha...@ya...>
> > Date:  Tue Mar 17 15:18:20 2026 +0100
> >
> >    arm64-arch.c: Fix soft-simulation of some instructions.
> >
> >    For breakpoint support.
> > ---
> >  src/runtime/arm64-arch.c | 63 ++++++++++++++++++++++++++++++------------------
> >  1 file changed, 39 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/runtime/arm64-arch.c b/src/runtime/arm64-arch.c
> > index 9183013fe..e9e8d3af1 100644
> > --- a/src/runtime/arm64-arch.c
> > +++ b/src/runtime/arm64-arch.c
> > @@ -88,20 +88,35 @@ condition_holds(os_context_t *context, unsigned int cond)
> >  {
> >      int flags = *os_context_flags_addr(context);
> >      bool result;
> > -    // Evaluate base condition.
> > -    switch (cond) {
> > -    case 0b000: result = ((flags >> Z_BIT) & 1);
> > -    case 0b001: result = ((flags >> C_BIT) & 1);
> > -    case 0b010: result = ((flags >> N_BIT) & 1);
> > -    case 0b011: result = ((flags >> V_BIT) & 1);
> > -    case 0b100: result = ((flags >> V_BIT) & 1) && ~((flags >> Z_BIT) & 1);
> > -    case 0b101: result = ((flags >> N_BIT) == (flags >> V_BIT));
> > -    case 0b110: result = ((flags >> N_BIT) == (flags >> V_BIT)) && !((flags >> Z_BIT) & 1);
> > -    case 0b111: result = 1;
> > +    // Evaluate base condition (ignoring the inversion bit).
> > +    switch (cond >> 1) {
> > +    case 0b000:
> > +      result = (flags >> Z_BIT) & 1;
> > +      break;
> > +    case 0b001:
> > +      result = (flags >> C_BIT) & 1;
> > +      break;
> > +    case 0b010:
> > +      result = (flags >> N_BIT) & 1;
> > +      break;
> > +    case 0b011: result = (flags >> V_BIT) & 1;
> > +      break;
> > +    case 0b100:
> > +      result = ((flags >> C_BIT) & 1) && !((flags >> Z_BIT) & 1);
> > +      break;
> > +    case 0b101:
> > +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1);
> > +      break;
> > +    case 0b110:
> > +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1) && !((flags >> Z_BIT) & 1);
> > +      break;
> > +    default:
> > +      result = 1;
> > +      break;
> >      }
> >
> > -    // Condition flag values in the set '111x' indicate always true
> > -    // Otherwise, invert condition if necessary.
> > +    // Condition flag values in the set '111x' indicate always true.
> > +    // Otherwise, invert condition if the low bit is set.
> >      if ((cond & 0b1) && (cond != 0b1111))
> >          result = !result;
> >
> > @@ -158,12 +173,10 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
> >      }
> >      else if (((orig_inst >> 25) & 0b111111) == 0b011010) {
> >          // Compare branch imm
> > -        bool size_is_64 = (orig_inst >> 31) & 0b1;
> >          bool op = (orig_inst >> 24) & 0b1;
> >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> >          int rt = orig_inst & 0b11111;
> > -        if (!size_is_64) lose("Size must be 64 bits.");
> > -        if (*os_context_register_addr(context, rt) ^ op)
> > +        if ((!*os_context_register_addr(context, rt)) ^ op)
> >              next_pc += offset;
> >          else
> >              next_pc += 1;
> > @@ -173,32 +186,34 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
> >          bool b5 = (orig_inst >> 31) & 0b1;
> >          bool op = (orig_inst >> 24) & 0b1;
> >          bool b40 = (orig_inst >> 19) & 0b11111;
> > -        int bit_pos = (b5 << 6) | b40;
> > +        int bit_pos = (b5 << 5) | b40;
> >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 14), 14);
> >          int rt = orig_inst & 0b11111;
> > -        if (!b5) lose("b5 must be 64 bits.");
> >          if (((*os_context_register_addr(context, rt) >> bit_pos) & 0b1) ^ op)
> >              next_pc += offset;
> >          else
> >              next_pc += 1;
> >      }
> > -    else if (((orig_inst >> 31) & 0b1) == 0b0) {
> > +    else if (((orig_inst >> 24) & 0b11111) == 0b11000) {
> >          // LDR (literal)
> > -        bool size_is_64 = (orig_inst >> 30) & 0b1;
> > +        int opc = (orig_inst >> 30) & 0b11;
> >          int rt = orig_inst & 0b11111;
> >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> > -        if (!size_is_64) lose("Size must be 64 bits.");
> > -        *os_context_register_addr(context, rt) = *((lispobj*)(pc + offset));
> > +        if (opc == 0b01)
> > +          *os_context_register_addr(context, rt) = *((uint64_t *)(pc + offset));
> > +        else if (opc == 0b00)
> > +          *os_context_register_addr(context, rt) = *((uint32_t *)(pc + offset));
> > +        else
> > +          lose("Unsupported LDR (literal) variant.");
> >          next_pc += 1;
> >      }
> >      else if (((orig_inst >> 24) & 0b11111) == 0b10000) {
> >          // ADR(P)
> >          bool op = (orig_inst >> 31) & 0b1;
> >          int rd = orig_inst & 0b11111;
> > -        int imm = sign_extend(((orig_inst >> 5) & ~(1 << 19)) |
> > -                              ((orig_inst >> 29) & ~(1 << 2)), 21);
> > +        int imm = sign_extend(((orig_inst >> 3) & 0x1FFFFC) | ((orig_inst >> 29) & 3), 21);
> >          if (op) // ADRP
> > -            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(1 << 12)) + (imm << 12);
> > +            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(uword_t)0xFFF) + ((sword_t)imm << 12);
> >          else // ADR
> >              *os_context_register_addr(context, rd) = (uword_t)pc + imm;
> >          next_pc += 1;
> >
> > -----------------------------------------------------------------------
> >
> >
> > hooks/post-receive
> > --
> > SBCL
> >
> >
> > _______________________________________________
> > Sbcl-commits mailing list
> > Sbc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbcl-commits

It's a safepoint.

On Thu, May 21, 2026 at 12:22 AM Charles Zhang <cha...@ya...> wrote:
>
> Thanks. Not a proper fix because I don't have a Windows machine. I'm thoroughly confused about why this is Windows only.
>
>
>
>
>
> On Wednesday, May 20, 2026 at 08:29:14 PM GMT+2, Stas Boukarev <sta...@gm...> wrote:
>
>
> ::: Running (TRACE :ENCAPSULATE NIL)
> fatal error encountered in SBCL pid 5521255184:
> Unsupported LDR (literal) variant.
> 0: 00000291caaa1938 pc=0000001000181ed0 {0000001000181dc0+0110}
> SB-DI::BREAKPOINT-DO-DISPLACED-INST
> 1: 00000291caaa1928 pc=00007ff7531059e0
> 2: 00000291caaa1900 pc=00000010019d75e0 {00000010019d7580+0060}
> CL-USER::TRACE-THIS
>
> On Wed, May 20, 2026 at 1:14 PM apache--- via Sbcl-commits
> <sbc...@li...> wrote:
> >
> > The branch "master" has been updated in SBCL:
> >        via  f982475b0bcb6d691cf172630fad9c14087378b2 (commit)
> >      from  07f82d35917900fe1222891579c2fe9d3d8df3c4 (commit)
> >
> > - Log -----------------------------------------------------------------
> > commit f982475b0bcb6d691cf172630fad9c14087378b2
> > Author: Charles Zhang <cha...@ya...>
> > Date:  Tue Mar 17 15:18:20 2026 +0100
> >
> >    arm64-arch.c: Fix soft-simulation of some instructions.
> >
> >    For breakpoint support.
> > ---
> >  src/runtime/arm64-arch.c | 63 ++++++++++++++++++++++++++++++------------------
> >  1 file changed, 39 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/runtime/arm64-arch.c b/src/runtime/arm64-arch.c
> > index 9183013fe..e9e8d3af1 100644
> > --- a/src/runtime/arm64-arch.c
> > +++ b/src/runtime/arm64-arch.c
> > @@ -88,20 +88,35 @@ condition_holds(os_context_t *context, unsigned int cond)
> >  {
> >      int flags = *os_context_flags_addr(context);
> >      bool result;
> > -    // Evaluate base condition.
> > -    switch (cond) {
> > -    case 0b000: result = ((flags >> Z_BIT) & 1);
> > -    case 0b001: result = ((flags >> C_BIT) & 1);
> > -    case 0b010: result = ((flags >> N_BIT) & 1);
> > -    case 0b011: result = ((flags >> V_BIT) & 1);
> > -    case 0b100: result = ((flags >> V_BIT) & 1) && ~((flags >> Z_BIT) & 1);
> > -    case 0b101: result = ((flags >> N_BIT) == (flags >> V_BIT));
> > -    case 0b110: result = ((flags >> N_BIT) == (flags >> V_BIT)) && !((flags >> Z_BIT) & 1);
> > -    case 0b111: result = 1;
> > +    // Evaluate base condition (ignoring the inversion bit).
> > +    switch (cond >> 1) {
> > +    case 0b000:
> > +      result = (flags >> Z_BIT) & 1;
> > +      break;
> > +    case 0b001:
> > +      result = (flags >> C_BIT) & 1;
> > +      break;
> > +    case 0b010:
> > +      result = (flags >> N_BIT) & 1;
> > +      break;
> > +    case 0b011: result = (flags >> V_BIT) & 1;
> > +      break;
> > +    case 0b100:
> > +      result = ((flags >> C_BIT) & 1) && !((flags >> Z_BIT) & 1);
> > +      break;
> > +    case 0b101:
> > +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1);
> > +      break;
> > +    case 0b110:
> > +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1) && !((flags >> Z_BIT) & 1);
> > +      break;
> > +    default:
> > +      result = 1;
> > +      break;
> >      }
> >
> > -    // Condition flag values in the set '111x' indicate always true
> > -    // Otherwise, invert condition if necessary.
> > +    // Condition flag values in the set '111x' indicate always true.
> > +    // Otherwise, invert condition if the low bit is set.
> >      if ((cond & 0b1) && (cond != 0b1111))
> >          result = !result;
> >
> > @@ -158,12 +173,10 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
> >      }
> >      else if (((orig_inst >> 25) & 0b111111) == 0b011010) {
> >          // Compare branch imm
> > -        bool size_is_64 = (orig_inst >> 31) & 0b1;
> >          bool op = (orig_inst >> 24) & 0b1;
> >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> >          int rt = orig_inst & 0b11111;
> > -        if (!size_is_64) lose("Size must be 64 bits.");
> > -        if (*os_context_register_addr(context, rt) ^ op)
> > +        if ((!*os_context_register_addr(context, rt)) ^ op)
> >              next_pc += offset;
> >          else
> >              next_pc += 1;
> > @@ -173,32 +186,34 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
> >          bool b5 = (orig_inst >> 31) & 0b1;
> >          bool op = (orig_inst >> 24) & 0b1;
> >          bool b40 = (orig_inst >> 19) & 0b11111;
> > -        int bit_pos = (b5 << 6) | b40;
> > +        int bit_pos = (b5 << 5) | b40;
> >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 14), 14);
> >          int rt = orig_inst & 0b11111;
> > -        if (!b5) lose("b5 must be 64 bits.");
> >          if (((*os_context_register_addr(context, rt) >> bit_pos) & 0b1) ^ op)
> >              next_pc += offset;
> >          else
> >              next_pc += 1;
> >      }
> > -    else if (((orig_inst >> 31) & 0b1) == 0b0) {
> > +    else if (((orig_inst >> 24) & 0b11111) == 0b11000) {
> >          // LDR (literal)
> > -        bool size_is_64 = (orig_inst >> 30) & 0b1;
> > +        int opc = (orig_inst >> 30) & 0b11;
> >          int rt = orig_inst & 0b11111;
> >          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> > -        if (!size_is_64) lose("Size must be 64 bits.");
> > -        *os_context_register_addr(context, rt) = *((lispobj*)(pc + offset));
> > +        if (opc == 0b01)
> > +          *os_context_register_addr(context, rt) = *((uint64_t *)(pc + offset));
> > +        else if (opc == 0b00)
> > +          *os_context_register_addr(context, rt) = *((uint32_t *)(pc + offset));
> > +        else
> > +          lose("Unsupported LDR (literal) variant.");
> >          next_pc += 1;
> >      }
> >      else if (((orig_inst >> 24) & 0b11111) == 0b10000) {
> >          // ADR(P)
> >          bool op = (orig_inst >> 31) & 0b1;
> >          int rd = orig_inst & 0b11111;
> > -        int imm = sign_extend(((orig_inst >> 5) & ~(1 << 19)) |
> > -                              ((orig_inst >> 29) & ~(1 << 2)), 21);
> > +        int imm = sign_extend(((orig_inst >> 3) & 0x1FFFFC) | ((orig_inst >> 29) & 3), 21);
> >          if (op) // ADRP
> > -            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(1 << 12)) + (imm << 12);
> > +            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(uword_t)0xFFF) + ((sword_t)imm << 12);
> >          else // ADR
> >              *os_context_register_addr(context, rd) = (uword_t)pc + imm;
> >          next_pc += 1;
> >
> > -----------------------------------------------------------------------
> >
> >
> > hooks/post-receive
> > --
> > SBCL
> >
> >
> > _______________________________________________
> > Sbcl-commits mailing list
> > Sbc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbcl-commits

Thanks. Not a proper fix because I don't have a Windows machine. I'm thoroughly confused about why this is Windows only.


 

    On Wednesday, May 20, 2026 at 08:29:14 PM GMT+2, Stas Boukarev <sta...@gm...> wrote:  
 
 ::: Running (TRACE :ENCAPSULATE NIL)
fatal error encountered in SBCL pid 5521255184:
Unsupported LDR (literal) variant.
0: 00000291caaa1938 pc=0000001000181ed0 {0000001000181dc0+0110}
SB-DI::BREAKPOINT-DO-DISPLACED-INST
1: 00000291caaa1928 pc=00007ff7531059e0
2: 00000291caaa1900 pc=00000010019d75e0 {00000010019d7580+0060}
CL-USER::TRACE-THIS

On Wed, May 20, 2026 at 1:14 PM apache--- via Sbcl-commits
<sbc...@li...> wrote:
>
> The branch "master" has been updated in SBCL:
>        via  f982475b0bcb6d691cf172630fad9c14087378b2 (commit)
>      from  07f82d35917900fe1222891579c2fe9d3d8df3c4 (commit)
>
> - Log -----------------------------------------------------------------
> commit f982475b0bcb6d691cf172630fad9c14087378b2
> Author: Charles Zhang <cha...@ya...>
> Date:  Tue Mar 17 15:18:20 2026 +0100
>
>    arm64-arch.c: Fix soft-simulation of some instructions.
>
>    For breakpoint support.
> ---
>  src/runtime/arm64-arch.c | 63 ++++++++++++++++++++++++++++++------------------
>  1 file changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/src/runtime/arm64-arch.c b/src/runtime/arm64-arch.c
> index 9183013fe..e9e8d3af1 100644
> --- a/src/runtime/arm64-arch.c
> +++ b/src/runtime/arm64-arch.c
> @@ -88,20 +88,35 @@ condition_holds(os_context_t *context, unsigned int cond)
>  {
>      int flags = *os_context_flags_addr(context);
>      bool result;
> -    // Evaluate base condition.
> -    switch (cond) {
> -    case 0b000: result = ((flags >> Z_BIT) & 1);
> -    case 0b001: result = ((flags >> C_BIT) & 1);
> -    case 0b010: result = ((flags >> N_BIT) & 1);
> -    case 0b011: result = ((flags >> V_BIT) & 1);
> -    case 0b100: result = ((flags >> V_BIT) & 1) && ~((flags >> Z_BIT) & 1);
> -    case 0b101: result = ((flags >> N_BIT) == (flags >> V_BIT));
> -    case 0b110: result = ((flags >> N_BIT) == (flags >> V_BIT)) && !((flags >> Z_BIT) & 1);
> -    case 0b111: result = 1;
> +    // Evaluate base condition (ignoring the inversion bit).
> +    switch (cond >> 1) {
> +    case 0b000:
> +      result = (flags >> Z_BIT) & 1;
> +      break;
> +    case 0b001:
> +      result = (flags >> C_BIT) & 1;
> +      break;
> +    case 0b010:
> +      result = (flags >> N_BIT) & 1;
> +      break;
> +    case 0b011: result = (flags >> V_BIT) & 1;
> +      break;
> +    case 0b100:
> +      result = ((flags >> C_BIT) & 1) && !((flags >> Z_BIT) & 1);
> +      break;
> +    case 0b101:
> +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1);
> +      break;
> +    case 0b110:
> +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1) && !((flags >> Z_BIT) & 1);
> +      break;
> +    default:
> +      result = 1;
> +      break;
>      }
>
> -    // Condition flag values in the set '111x' indicate always true
> -    // Otherwise, invert condition if necessary.
> +    // Condition flag values in the set '111x' indicate always true.
> +    // Otherwise, invert condition if the low bit is set.
>      if ((cond & 0b1) && (cond != 0b1111))
>          result = !result;
>
> @@ -158,12 +173,10 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
>      }
>      else if (((orig_inst >> 25) & 0b111111) == 0b011010) {
>          // Compare branch imm
> -        bool size_is_64 = (orig_inst >> 31) & 0b1;
>          bool op = (orig_inst >> 24) & 0b1;
>          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
>          int rt = orig_inst & 0b11111;
> -        if (!size_is_64) lose("Size must be 64 bits.");
> -        if (*os_context_register_addr(context, rt) ^ op)
> +        if ((!*os_context_register_addr(context, rt)) ^ op)
>              next_pc += offset;
>          else
>              next_pc += 1;
> @@ -173,32 +186,34 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
>          bool b5 = (orig_inst >> 31) & 0b1;
>          bool op = (orig_inst >> 24) & 0b1;
>          bool b40 = (orig_inst >> 19) & 0b11111;
> -        int bit_pos = (b5 << 6) | b40;
> +        int bit_pos = (b5 << 5) | b40;
>          int offset = sign_extend((orig_inst >> 5) & ~(1 << 14), 14);
>          int rt = orig_inst & 0b11111;
> -        if (!b5) lose("b5 must be 64 bits.");
>          if (((*os_context_register_addr(context, rt) >> bit_pos) & 0b1) ^ op)
>              next_pc += offset;
>          else
>              next_pc += 1;
>      }
> -    else if (((orig_inst >> 31) & 0b1) == 0b0) {
> +    else if (((orig_inst >> 24) & 0b11111) == 0b11000) {
>          // LDR (literal)
> -        bool size_is_64 = (orig_inst >> 30) & 0b1;
> +        int opc = (orig_inst >> 30) & 0b11;
>          int rt = orig_inst & 0b11111;
>          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> -        if (!size_is_64) lose("Size must be 64 bits.");
> -        *os_context_register_addr(context, rt) = *((lispobj*)(pc + offset));
> +        if (opc == 0b01)
> +          *os_context_register_addr(context, rt) = *((uint64_t *)(pc + offset));
> +        else if (opc == 0b00)
> +          *os_context_register_addr(context, rt) = *((uint32_t *)(pc + offset));
> +        else
> +          lose("Unsupported LDR (literal) variant.");
>          next_pc += 1;
>      }
>      else if (((orig_inst >> 24) & 0b11111) == 0b10000) {
>          // ADR(P)
>          bool op = (orig_inst >> 31) & 0b1;
>          int rd = orig_inst & 0b11111;
> -        int imm = sign_extend(((orig_inst >> 5) & ~(1 << 19)) |
> -                              ((orig_inst >> 29) & ~(1 << 2)), 21);
> +        int imm = sign_extend(((orig_inst >> 3) & 0x1FFFFC) | ((orig_inst >> 29) & 3), 21);
>          if (op) // ADRP
> -            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(1 << 12)) + (imm << 12);
> +            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(uword_t)0xFFF) + ((sword_t)imm << 12);
>          else // ADR
>              *os_context_register_addr(context, rd) = (uword_t)pc + imm;
>          next_pc += 1;
>
> -----------------------------------------------------------------------
>
>
> hooks/post-receive
> --
> SBCL
>
>
> _______________________________________________
> Sbcl-commits mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-commits
  

::: Running (TRACE :ENCAPSULATE NIL)
fatal error encountered in SBCL pid 5521255184:
Unsupported LDR (literal) variant.
0: 00000291caaa1938 pc=0000001000181ed0 {0000001000181dc0+0110}
SB-DI::BREAKPOINT-DO-DISPLACED-INST
1: 00000291caaa1928 pc=00007ff7531059e0
2: 00000291caaa1900 pc=00000010019d75e0 {00000010019d7580+0060}
CL-USER::TRACE-THIS

On Wed, May 20, 2026 at 1:14 PM apache--- via Sbcl-commits
<sbc...@li...> wrote:
>
> The branch "master" has been updated in SBCL:
>        via  f982475b0bcb6d691cf172630fad9c14087378b2 (commit)
>       from  07f82d35917900fe1222891579c2fe9d3d8df3c4 (commit)
>
> - Log -----------------------------------------------------------------
> commit f982475b0bcb6d691cf172630fad9c14087378b2
> Author: Charles Zhang <cha...@ya...>
> Date:   Tue Mar 17 15:18:20 2026 +0100
>
>     arm64-arch.c: Fix soft-simulation of some instructions.
>
>     For breakpoint support.
> ---
>  src/runtime/arm64-arch.c | 63 ++++++++++++++++++++++++++++++------------------
>  1 file changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/src/runtime/arm64-arch.c b/src/runtime/arm64-arch.c
> index 9183013fe..e9e8d3af1 100644
> --- a/src/runtime/arm64-arch.c
> +++ b/src/runtime/arm64-arch.c
> @@ -88,20 +88,35 @@ condition_holds(os_context_t *context, unsigned int cond)
>  {
>      int flags = *os_context_flags_addr(context);
>      bool result;
> -    // Evaluate base condition.
> -    switch (cond) {
> -    case 0b000: result = ((flags >> Z_BIT) & 1);
> -    case 0b001: result = ((flags >> C_BIT) & 1);
> -    case 0b010: result = ((flags >> N_BIT) & 1);
> -    case 0b011: result = ((flags >> V_BIT) & 1);
> -    case 0b100: result = ((flags >> V_BIT) & 1) && ~((flags >> Z_BIT) & 1);
> -    case 0b101: result = ((flags >> N_BIT) == (flags >> V_BIT));
> -    case 0b110: result = ((flags >> N_BIT) == (flags >> V_BIT)) && !((flags >> Z_BIT) & 1);
> -    case 0b111: result = 1;
> +    // Evaluate base condition (ignoring the inversion bit).
> +    switch (cond >> 1) {
> +    case 0b000:
> +      result = (flags >> Z_BIT) & 1;
> +      break;
> +    case 0b001:
> +      result = (flags >> C_BIT) & 1;
> +      break;
> +    case 0b010:
> +      result = (flags >> N_BIT) & 1;
> +      break;
> +    case 0b011: result = (flags >> V_BIT) & 1;
> +      break;
> +    case 0b100:
> +      result = ((flags >> C_BIT) & 1) && !((flags >> Z_BIT) & 1);
> +      break;
> +    case 0b101:
> +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1);
> +      break;
> +    case 0b110:
> +      result = ((flags >> N_BIT) & 1) == ((flags >> V_BIT) & 1) && !((flags >> Z_BIT) & 1);
> +      break;
> +    default:
> +      result = 1;
> +      break;
>      }
>
> -    // Condition flag values in the set '111x' indicate always true
> -    // Otherwise, invert condition if necessary.
> +    // Condition flag values in the set '111x' indicate always true.
> +    // Otherwise, invert condition if the low bit is set.
>      if ((cond & 0b1) && (cond != 0b1111))
>          result = !result;
>
> @@ -158,12 +173,10 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
>      }
>      else if (((orig_inst >> 25) & 0b111111) == 0b011010) {
>          // Compare branch imm
> -        bool size_is_64 = (orig_inst >> 31) & 0b1;
>          bool op = (orig_inst >> 24) & 0b1;
>          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
>          int rt = orig_inst & 0b11111;
> -        if (!size_is_64) lose("Size must be 64 bits.");
> -        if (*os_context_register_addr(context, rt) ^ op)
> +        if ((!*os_context_register_addr(context, rt)) ^ op)
>              next_pc += offset;
>          else
>              next_pc += 1;
> @@ -173,32 +186,34 @@ void arch_do_displaced_inst(os_context_t *context, unsigned int orig_inst)
>          bool b5 = (orig_inst >> 31) & 0b1;
>          bool op = (orig_inst >> 24) & 0b1;
>          bool b40 = (orig_inst >> 19) & 0b11111;
> -        int bit_pos = (b5 << 6) | b40;
> +        int bit_pos = (b5 << 5) | b40;
>          int offset = sign_extend((orig_inst >> 5) & ~(1 << 14), 14);
>          int rt = orig_inst & 0b11111;
> -        if (!b5) lose("b5 must be 64 bits.");
>          if (((*os_context_register_addr(context, rt) >> bit_pos) & 0b1) ^ op)
>              next_pc += offset;
>          else
>              next_pc += 1;
>      }
> -    else if (((orig_inst >> 31) & 0b1) == 0b0) {
> +    else if (((orig_inst >> 24) & 0b11111) == 0b11000) {
>          // LDR (literal)
> -        bool size_is_64 = (orig_inst >> 30) & 0b1;
> +        int opc = (orig_inst >> 30) & 0b11;
>          int rt = orig_inst & 0b11111;
>          int offset = sign_extend((orig_inst >> 5) & ~(1 << 19), 19);
> -        if (!size_is_64) lose("Size must be 64 bits.");
> -        *os_context_register_addr(context, rt) = *((lispobj*)(pc + offset));
> +        if (opc == 0b01)
> +          *os_context_register_addr(context, rt) = *((uint64_t *)(pc + offset));
> +        else if (opc == 0b00)
> +          *os_context_register_addr(context, rt) = *((uint32_t *)(pc + offset));
> +        else
> +          lose("Unsupported LDR (literal) variant.");
>          next_pc += 1;
>      }
>      else if (((orig_inst >> 24) & 0b11111) == 0b10000) {
>          // ADR(P)
>          bool op = (orig_inst >> 31) & 0b1;
>          int rd = orig_inst & 0b11111;
> -        int imm = sign_extend(((orig_inst >> 5) & ~(1 << 19)) |
> -                              ((orig_inst >> 29) & ~(1 << 2)), 21);
> +        int imm = sign_extend(((orig_inst >> 3) & 0x1FFFFC) | ((orig_inst >> 29) & 3), 21);
>          if (op) // ADRP
> -            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(1 << 12)) + (imm << 12);
> +            *os_context_register_addr(context, rd) = ((uword_t)pc & ~(uword_t)0xFFF) + ((sword_t)imm << 12);
>          else // ADR
>              *os_context_register_addr(context, rd) = (uword_t)pc + imm;
>          next_pc += 1;
>
> -----------------------------------------------------------------------
>
>
> hooks/post-receive
> --
> SBCL
>
>
> _______________________________________________
> Sbcl-commits mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-commits

(let () (compile nil `(lambda (x)
                                  (declare (optimize speed))
                                  (1+ x))))
stopped producing optimization notes.


On Mon, May 18, 2026 at 2:31 PM apache--- via Sbcl-commits
<sbc...@li...> wrote:
>
> The branch "master" has been updated in SBCL:
>        via  1f5238fe0b578e2a0ef201e851809c9ac9d3d862 (commit)
>       from  2720527dfadc6ab004d9e6778ed35743aaa59a76 (commit)
>
> - Log -----------------------------------------------------------------
> commit 1f5238fe0b578e2a0ef201e851809c9ac9d3d862
> Author: Charles Zhang <cha...@ya...>
> Date:   Thu Dec 15 12:09:51 2022 +0100
>
>     Allow the compile-evaluator to evaluate forms directly.
>
>     This change has the overall effect of having the evaluator properly
>     separate out top level code from any defined functions. See the new
>     test :EVAL-TOP-LEVEL-CODE-SEPARATE-COMPONENT and the existing tests
>     :STRUCTURE-SLOT-VALUE-IN-METHOD-NO-CALLEES and
>     :STRUCTURE-MISSING-SLOT-VALUE-IN-METHOD-SINGLE-CALLEE. As a bonus,
>     self call recognition works for COMPILE now. As a side effect,
>     we (correctly) get more redefinition warnings as well (for example for
>     WARN during bootstrap), which were missing before for some reason.
>
>     In order to achieve this, the following needs to be done:
>
>     * COMPILE does not have its own special way of doing ir1 conversion
>     for lambdas anymore, instead relying on the top level lambda machinery
>     to separate out the actual compiled code. This gives the correct
>     semantics for policy and compilation etc. for free without special or
>     duplicate logic, and removes all the stuff around
>     HAS-EXTERNAL-REFERENCES-P, which was an idea that was never really
>     finished. This allows us to extend COMPILE-IN-LEXENV to evaluate forms
>     directly and hence allow %SIMPLE-EVAL to not have to manually wrap the
>     lambdas either, so evaluation-via-compilation behaves like top-level
>     evaluation by the file compiler (of course without file compilation
>     semantics). LTV processing and fasteval also can just evaluate forms
>     directly with EVAL-WITH-COMPILE-IN-LEXENV.
>     * Storing source forms should always be off for PCL generated
>     functions, revealed by the clos-arena test. This was probably not
>     detected before because the policy inheritance was subtly wrong.
>     * Fix some tests to not rely on questionable behavior of how named
>     COMPILE interacts with global type information. Such behavior should
>     only work in compile file mode.
>     * The TL-XEP debug name had nothing to do with the actual TL-XEP
>     functional kind, which was confusing.
>     * TIME now counts all lambda conversions. Just ignoring the entry
>     points produced by COMPILE for the top level lambda didn't make much
>     sense since all other kinds of entry points get counted. It's there
>     purely to give a hint to the user how much work the compiler is doing,
>     not to count anything in the source being compiled.
>     * Core components need to have patch tables again. The fact that they
>     are exercised in warm bootstrap now means that we are likely actually
>     using the load time code stripping functionality not just in theory,
>     vut in practice as well.
>     * Add post ir1-toplevel processing smashing of names onto compiled
>     functions again to get names right. As an added bonus, this allows us
>     to get recognize self calls working for COMPILE functions.
>     * core debug source infos never actually used the function slot, and
>     it's not clear what function to give it when evaluating top level
>     forms, so delete it.
>     * Also fix > 3 decade old bug in MAKE-LISP-SOURCE-INFO in which a
>     plain vector was used when one with a fill pointer was expected. I
>     guess this code path hadn't been exercised in a long time.
> ---

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     19th European Lisp Symposium

			Call for Participation

			    May 11-12 2026
		     Skład Długa, Kraków, Poland

	     https://www.european-lisp-symposium.org/2026
		    Sponsored by Keepit and SISCOG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Important News
~~~~~~~~~~~~~~~

- Programme and remote attendance instructions now available
- Keynotes announced
  Lambda: the Ultimate Paradigm -- François-René Rideau, Gerbil Scheme
  McCLIM and ECL -- Daniel Kochmański


Important Dates
~~~~~~~~~~~~~~~
- Symposium: May 11-12 2026


Scope
~~~~~

The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and
application of any of the Lisp dialects, including Common Lisp,
Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan,
SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so
on. We encourage everyone interested in Lisp to participate.

The European Lisp Symposium invites high quality papers about novel
research results, insights and lessons learned from practical
applications, and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- context-, aspect-, domain-oriented and generative programming
- macro-, reflective-, meta- and/or rule-based development approaches
- language design and implementation
- language integration, inter-operation, and deployment
- development methodologies, support, and environments
- educational approaches and perspectives
- experience reports and case studies


Programme Chair
~~~~~~~~~~~~~~~
Mark Evenson, ABCL.org, Austria


Organizing Chair
~~~~~~~~~~~~~~~~
Didier Verna, EPITA / LRE, France


Programme Committee
~~~~~~~~~~~~~~~~~~~
Alan Ruttenberg, USA
Dave Cooper, Genworks, USA
Dimitris Vyzovitis, Mighty Gerbils
Eitaro Fukamachi, Japan
Jason Hemann, Seton Hall University, USA
Kristopher Micinski, Syracuse University, USA
Marc Battyani, Enfabrica, USA
Mark David, USA
Michael Raskin, LaBRI, France
Robert Goldman, SIFT, USA
Thomas de Grivel, France


Local Chairs
~~~~~~~~~~~~
Wojciech Gac, Keepit, Poland
Michał Herda, Keepit, Poland


Virtualization Team
~~~~~~~~~~~~~~~~~~~
Georgiy Tugai, Configura, Sweden
Yukari Hafner, Shirakumo.org, Switzerland

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

"It is not permitted to supply a keyword argument to a function using
a name that is not a symbol.

If this situation occurs in a safe call, an error of type
program-error must be signaled unless keyword argument checking is
suppressed as described in Section 3.4.1.4.1 (Suppressing Keyword
Argument Checking)"

On Sun, May 10, 2026 at 12:23 AM Charles Zhang via Sbcl-commits
<sbc...@li...> wrote:
>
> But what’s with the removed tests and the ansi test failure?
>
> On Saturday, May 9, 2026, 11:19 PM, stassats via Sbcl-commits <sbc...@li...> wrote:
>
> The branch "master" has been updated in SBCL:
>       via  c7921a02d8b8ff95914108b2395069bdc7f299aa (commit)
>       from  9ce4f6ccc4a20abe3161ab68ac60d0f654611f25 (commit)
>
> - Log -----------------------------------------------------------------
> commit c7921a02d8b8ff95914108b2395069bdc7f299aa
> Author: Stas Boukarev <sta...@gm...>
> Date:  Sat May 9 22:49:45 2026 +0300
>
>     Faster keyword argument checking in CLOS
>
>     Copy what convert-more-entry is doing and inline it.
> ---
> src/pcl/combin.lisp    | 68 +++++++++++++++++++++-----------------------------
> src/pcl/fngen.lisp    |  3 ++-
> tests/ansi-tests.sh    |  2 +-
> tests/clos.impure.lisp |  4 ---
> 4 files changed, 32 insertions(+), 45 deletions(-)
>
> diff --git a/src/pcl/combin.lisp b/src/pcl/combin.lisp
> index 6037c651a..7fd56f15e 100644
> --- a/src/pcl/combin.lisp
> +++ b/src/pcl/combin.lisp
> @@ -576,46 +576,36 @@
>         (aver any-keyp)
>         (values (if allowp t keys) nopt)))))
>
> -(defun check-applicable-keywords (start valid-keys more-context more-count)
> -  (let ((allow-other-keys-seen nil)
> -        (allow-other-keys nil)
> -        (i start))
> -    (declare (type index i more-count)
> -            (optimize speed))
> -    (flet ((current-value ()
> -            (sb-c::%more-arg more-context i)))
> -      (declare (inline current-value))
> -      (collect ((invalid))
> -        (loop
> -          (when (>= i more-count)
> -            (when (and (invalid) (not allow-other-keys))
> -              (%program-error "~@<invalid keyword argument~P: ~
> -                                ~{~S~^, ~} (valid keys are ~{~S~^, ~}).~@:>"
> -                              (length (invalid)) (invalid) valid-keys))
> -            (return))
> -          (let ((key (current-value)))
> -            (incf i)
> -            (cond
> -              ((not (symbolp key))
> -                (%program-error "~@<keyword argument not a symbol: ~S.~@:>"
> -                                key))
> -              ((= i more-count)
> -                (sb-c::%odd-key-args-error))
> -              ((eq key :allow-other-keys)
> -                ;; only the leftmost :ALLOW-OTHER-KEYS has any effect
> -                (unless allow-other-keys-seen
> -                  (setq allow-other-keys-seen t
> -                        allow-other-keys (current-value))))
> -              ((eq t valid-keys))
> -              ((not (memq key valid-keys)) (invalid key))))
> -          (incf i))))))
> -
> (defun wrap-with-applicable-keyword-check (effective valid-keys keyargs-start)
> -  `(let ((.valid-keys. ',valid-keys)
> -        (.keyargs-start. ',keyargs-start))
> -    (multiple-value-bind (.more-context. .more-count.) (sb-c::%rest-context .rest.)
> -      (check-applicable-keywords
> -      .keyargs-start. .valid-keys. .more-context. .more-count.))
> +  `(progn
> +    (multiple-value-bind (more-context more-count) (sb-c::%rest-context .rest.)
> +      (declare (ignorable more-context))
> +      ;; Similar to what SB-C::CONVERT-MORE-ENTRY does
> +      (let ((count (- more-count ,keyargs-start)))
> +        (when ,(if (zerop keyargs-start)
> +                    `(oddp count)
> +                    `(and (plusp count)
> +                          (oddp count)))
> +          (sb-c::%odd-key-args-error)))
> +      ,@(unless (eq valid-keys t)
> +          (let ((restart (sb-c:make-restart-location)))
> +            `((let (allowp
> +                    (lose (make-unbound-marker))
> +                    (index more-count))
> +                (declare (index index))
> +                (loop until (<= index ,keyargs-start)
> +                      do (decf (truly-the index index) 2)
> +                          (let ((key (sb-c::%more-arg more-context index)))
> +                            (case key
> +                              (,(remove :allow-other-keys valid-keys))
> +                              (:allow-other-keys
> +                              (setf allowp (sb-c::%more-arg more-context (1+ index))))
> +                              (t
> +                              (setf lose key)))))
> +                (if (or (unbound-marker-p lose)
> +                        allowp)
> +                    (sb-c::restart-point ,restart)
> +                    (sb-c::%unknown-key-arg-error lose ,restart)))))))
>       ,effective))
>
> ;;;; the STANDARD method combination type. This is coded by hand
> diff --git a/src/pcl/fngen.lisp b/src/pcl/fngen.lisp
> index 6eb140875..60d2b060a 100644
> --- a/src/pcl/fngen.lisp
> +++ b/src/pcl/fngen.lisp
> @@ -97,7 +97,8 @@
>
> (defun default-constantp (form)
>   (and (constantp form)
> -      (not (typep (constant-form-value form) '(or symbol fixnum cons layout)))))
> +      (not (typep (constant-form-value form) '(or symbol fixnum cons layout
> +                                                sb-c::restart-location)))))
>
> (defun default-test-converter (form)
>   (if (default-constantp form)
> diff --git a/tests/ansi-tests.sh b/tests/ansi-tests.sh
> index fb8dc92ce..6e807d0e3 100755
> --- a/tests/ansi-tests.sh
> +++ b/tests/ansi-tests.sh
> @@ -56,7 +56,7 @@ rm -fr sandbox/scratch
>   "SUBSTITUTE-IF.FOLD.3" "SUBSTITUTE-IF.FOLD.2" "SUBSTITUTE-IF.FOLD.1"
>   "SUBSTITUTE.FOLD.4" "SUBSTITUTE.FOLD.3" "SUBSTITUTE.FOLD.2"
>   "SUBSTITUTE.FOLD.1"  "SUBSTITUTE-IF-NOT.FOLD.3"
> - "MISC.598" "IMAGPART.4"
> + "MISC.598" "IMAGPART.4" "SHARED-INITIALIZE.ERROR.4"
>   (append #+x86 (list "CIS.4")
>           #+(or arm riscv (and arm64 (not darwin)))
>             (list "EXP.ERROR.4" "EXP.ERROR.5" "EXP.ERROR.6" "EXP.ERROR.7" "EXPT.ERROR.4"
> diff --git a/tests/clos.impure.lisp b/tests/clos.impure.lisp
> index af142e6e9..f8e25dd69 100644
> --- a/tests/clos.impure.lisp
> +++ b/tests/clos.impure.lisp
> @@ -1352,10 +1352,6 @@
>   (assert-error (shared-initialize (make-instance 'shared-initialize-keyword-check) nil :a)
>                 program-error))
>
> -(with-test (:name (:check-keyword-args shared-initialize :non-keyword :error))
> -  (assert-error (shared-initialize (make-instance 'shared-initialize-keyword-check) nil '(abc) 1)
> -                program-error))
> -
> ;;; verify that we can still detect no primary methods and invalid qualifiers
>
> (defmethod gf-with-keys-and-no-primary-method :around ((x integer) &key b)
>
> -----------------------------------------------------------------------
>
>
> hooks/post-receive
> --
> SBCL
>
>
> _______________________________________________
> Sbcl-commits mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-commits
>
> _______________________________________________
> Sbcl-commits mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-commits