[E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER

Faré fahree at gmail.com
Thu Oct 12 18:04:58 UTC 2017

On Thu, Oct 12, 2017 at 5:09 PM, 73budden . <budden73 at gmail.com> wrote:
> Warning about modifying standard readtable is issued by SBCL (at least
> in my SBCL 1.3.18), please grep for the message in SBCL sources, and
> it seem to be introduced in 1.0.24. I took a look at puri's definition
>  (maybe old, in my local copy of quicklisp) and it looks like it
> actually tries to modify standard readtable.
More precisely, puri modifies the _current_ *readtable*, which is very rude.
If anyone maintains puri (fat luck), he should remove this bug
and instead offer an interface using named-readtables.

The error happens when the current readtable happens to be the
standard readtable, which will happen if someone uses

Looking at ASDF sources, there is one place that uses it, and indeed,
a bug was introduced during the refactoring of ASDF 3.3.0: whereas
earlier variants of ASDF
saved the *readtable* from outside the with-standard-io-syntax to
restore it inside,
the new ASDF fails to do it. Reduced test case: try to
(asdf:load-system "ddop") with the following ddop.asd.

(defsystem "ddop" :defsystem-depends-on ("puri"))

I believe this justifies a 3.3.1 bugfix release indeed.

It also justifies spending more time on the syntax-control branch
supposed to cleanup the readtable issues, and/or getting all software
fixed so it never modifies the current readtable unless it explicitly
makes and sets a new readtable.

> It'd be very nice to have instructions on how to trace what happens
> while system is being built:that is, which files are compiled, which
> are loaded and what is a readtable in the beginning of each load
> operation.
You can pass a :verbose t flag to load-system and its friends.

As for tracing what readtable are used, there does not exist
infrastructure for even identifying readtables. You're welcome to
write one and seek assistance in writing
a hook in ASDF (e.g. as a :before method on perform compile-op or load-op,
which would not have helped you much in this case, or as a local
modification to uiop:compile-file*, if you have a local ASDF source

> Running builds in old and new asdf versions and comparing logs it
> would be relatively easy to figure out what is wrong.
Only if given enough information to reproduce, which the complainer
failed to provide. Luckily, I investigated nevertheless.

For those in a hurry for a fix, here is the merge request:

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The two most common things in the Universe are hydrogen and stupidity.
                — Harlan Ellison

More information about the asdf-devel mailing list