[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
with-standard-io-syntax.
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
checkout).
> 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:
https://gitlab.common-lisp.net/asdf/asdf/merge_requests/85
—♯ƒ • 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