<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 12 Oct 2017, at 12:53, Konstanski, Carlos wrote:</p>

</div>
<div style="white-space:normal"></div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="1DEE4E82-6078-4D23-BF79-7ABA3775F259"><div dir="ltr">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.<div><br></div><div>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?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-12 11:45 GMT-06:00 Robert Goldman <span dir="ltr"><<a href="mailto:rpgoldman@sift.info" target="_blank">rpgoldman@sift.info</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Forwarded message:<br>
<br>
> From: 73budden . <<a href="mailto:budden73@gmail.com">budden73@gmail.com</a>><br>
> To: Robert Goldman <<a href="mailto:rpgoldman@sift.info">rpgoldman@sift.info</a>><br>
> Cc: Faré <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>>, ASDF-devel <<a href="mailto:asdf-devel@common-lisp.net">asdf-devel@common-lisp.net</a>><br>
> Subject: Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER<br>
> Date: Thu, 12 Oct 2017 20:09:44 +0300<br>
><br>
> Warning about modifying standard readtable is issued by SBCL (at least<br>
> in my SBCL 1.3.18), please grep for the message in SBCL sources, and<br>
> it seem to be introduced in 1.0.24. I took a look at puri's definition<br>
>  (maybe old, in my local copy of quicklisp) and it looks like it<br>
> actually tries to modify standard readtable. But here it does not<br>
> happen when it is being loaded via my patched asdf 3.1.6 and my own<br>
> IDE with forked SLIME with many systems pre-loaded. I don't know why<br>
> and have no time to investigate further. Obviously, my insights would<br>
> be of limited use because my environment is very different from that<br>
> of OP.<br>
><br>
>> So we might be able to help you debug this<br>
> It'd be very nice to have instructions on how to trace what happens<br>
> while system is being built:that is, which files are compiled, which<br>
> are loaded and what is a readtable in the beginning of each load<br>
> operation.<br>
><br>
> Running builds in old and new asdf versions and comparing logs it<br>
> would be relatively easy to figure out what is wrong.<br>
><br>
> I guess that in OP's setup something had changed readtable before, but<br>
> this does not happen anymore. And obviously many people would face<br>
> similar problems.<br>
><br>
> This tracing tool should help a lot.<br>
><br>
> I believe this tool should be supplied by asdf team. Even I begin to<br>
> be more positive towards efforts of ASDF team to clean up all the mess<br>
> that was in ASDF initially, but obviously society is not quite happy<br>
> with breaking changes, so some small tool with a good manual would<br>
> make life easier.<br>
><br>
> Printing readtable before loading, I think, requires just a line or<br>
> two. Dumping log of operations might be one (trace) call, so that's<br>
> trivial for the person who knows how ASDF is organized. Writing a<br>
> small two-paragraph addition to manual would relief a lot of pain and<br>
> stress for all.<br>
><br>
> WBR, Budden<br>
><br>
> 2017-10-12 18:46 GMT+03:00, Robert Goldman <<a href="mailto:rpgoldman@sift.info">rpgoldman@sift.info</a>>:<br>
>> I'm with Faré on this one.  I don't see evidence that this change is<br>
>> because ASDF is doing something bad.  I believe it's consistent with the<br>
>> hypothesis that there was some imperfectly-controlled aspect of building<br>
>> that is done differently now (e.g., files loaded in a different order<br>
>> where both orders are compatible with the constraints in the system<br>
>> definitions).<br>
>><br>
>> This doesn't even look like an ASDF error to me -- it looks like an<br>
>> error that occurred while loading a system that ASDF has re-packaged.<br>
>><br>
>> So we might be able to help you debug this, but without more evidence,<br>
>> there's no reason to believe that ASDF has done anything to you: it<br>
>> looks like the change in ASDF just reveals a pre-existing bug.<br>
>><br>
>><br>
>><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Carlos Konstanski<div><span style="color:rgb(60,60,60);font-family:Arial,sans-serif;font-size:12px">MTS IV Cslt</span><br></div><div><span style="color:rgb(60,60,60);font-family:Arial,sans-serif;font-size:12px">Verizon Cloud Platform</span></div><div><span style="color:rgb(60,60,60);font-family:Arial,sans-serif;font-size:12px"><a href="mailto:carlos.konstanski@verizonwireless.com" target="_blank">carlos.konstanski@verizonwireless.com</a></span></div><div><span style="color:rgb(60,60,60);font-family:Arial,sans-serif;font-size:12px">Cell: 15126218301</span></div><div><span style="color:rgb(60,60,60);font-family:Arial,sans-serif;font-size:12px">Slack: </span><font color="#3c3c3c" face="Arial, sans-serif"><span style="font-size:12px"><a href="http://vzw-vsi.slack.com" target="_blank">vzw-vsi.slack.com</a> username: @ckonstanski</span></font></div></div></div>
</div></div></blockquote>
<div style="white-space:normal">
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">That may be, but it was unfair to get angry at the ASDF maintainers about this.  This is just a pre-existing error that was <em>manifested</em> because of a change in ASDF.  It's not our fault that this error appeared, it's not our fault that the puri library is no longer maintained, and we can't be expected to avoid releasing improved versions of ASDF because there exists buggy, unmaintained code in Quicklisp.</p>

<p dir="auto">An apology from you would be appropriate at this point.</p>
</div>
</div>
</body>
</html>