On Thu, Oct 12, 2017 at 5:09 PM, 73budden . budden73@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