All signs point at puri being the culprit. I am absolutely not disagreeing with that. I provided the offending code in the bug report myself. The question is: what to do about it? The project is dead. The home page is gone. Here is what I will do: I'll see if I can get drakma to steer clear of it. They will undoubtedly be interested in not having their fine code dragged down by a dead library.

The only other option is to fix puri. I don't even know how to begin doing that with a dead project. Where did Kevin Rosenberg disappear off to?

2017-10-12 11:45 GMT-06:00 Robert Goldman <rpgoldman@sift.info>:

Forwarded message:

> From: 73budden . <budden73@gmail.com>
> To: Robert Goldman <rpgoldman@sift.info>
> Cc: Faré <fahree@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 <rpgoldman@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.
>>
>>
>>

--

Carlos Konstanski

MTS IV Cslt

Verizon Cloud Platform

carlos.konstanski@verizonwireless.com

Cell: 15126218301

Slack: vzw-vsi.slack.com username: @ckonstanski