From: 73budden . <budde...@gmail.com>
To: Robert Goldman <rpgold...@sift.info>
Cc: Faré <fah...@gmail.com>, ASDF-devel
<asdf-devel@common-lisp.net>
Subject: Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER
Date: Thu, 12 Oct 2017 20:09:44 +0300
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. But here it does not
happen when it is being loaded via my patched asdf 3.1.6 and my own
IDE with forked SLIME with many systems pre-loaded. I don't know why
and have no time to investigate further. Obviously, my insights
would
be of limited use because my environment is very different from that
of OP.
So we might be able to help you debug this
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.
Running builds in old and new asdf versions and comparing logs it
would be relatively easy to figure out what is wrong.
I guess that in OP's setup something had changed readtable before,
but
this does not happen anymore. And obviously many people would face
similar problems.
This tracing tool should help a lot.
I believe this tool should be supplied by asdf team. Even I begin to
be more positive towards efforts of ASDF team to clean up all the
mess
that was in ASDF initially, but obviously society is not quite happy
with breaking changes, so some small tool with a good manual would
make life easier.
Printing readtable before loading, I think, requires just a line or
two. Dumping log of operations might be one (trace) call, so that's
trivial for the person who knows how ASDF is organized. Writing a
small two-paragraph addition to manual would relief a lot of pain
and
stress for all.
WBR, Budden
2017-10-12 18:46 GMT+03:00, Robert Goldman <rpgold...@sift.info>:
I'm with Faré on this one. I don't see evidence that this change
is
because ASDF is doing something bad. I believe it's consistent
with the
hypothesis that there was some imperfectly-controlled aspect of
building
that is done differently now (e.g., files loaded in a different
order
where both orders are compatible with the constraints in the system
definitions).
This doesn't even look like an ASDF error to me -- it looks like an
error that occurred while loading a system that ASDF has
re-packaged.
So we might be able to help you debug this, but without more
evidence,
there's no reason to believe that ASDF has done anything to you: it
looks like the change in ASDF just reveals a pre-existing bug.
