[E] Re: new compiler error re: SET-DISPATCH-MACRO-CHARACTER

[Faré]

On Wed, Oct 11, 2017 at 11:19 PM, Konstanski, Carlos
<carlos.konstanski at verizonwireless.com> wrote:
> puri was pulled into my system by quicklisp as s dependency of drakma, and
> asdf was installed by portage. I have never written a line of lisp that
> called puri directly.
Good for you. Have you written a line of lisp that calls asdf? Because
asdf does not call itself magically after reading your thoughts. Would
perchance your build scripts be using with-standard-io-syntax or some
such?

> No one is ever persuaded by the "it works for me"
> argument.
No one is ever persuaded by the "it doesn't work for me" argument.
<insert copious expletives here>

> The issue is real.
(realp 'issue) => NIL
Not reproducible. Come back with a reproducible test case and a complete log.
http://www.catb.org/~esr/reposurgeon/reporting-bugs.html

> Are you using a clean install of asdf, uiop and
> puri? Or are you using your development branch of asdf? Developers can
> always get it to work on their workstations. Maybe it's the gentoo package
> for asdf or uiop. Maybe slime is providing some sort of wrapping environment
> that affects readtables. There are any number of things that could be at
> play that are beyond the user's control.
>
You're the one experiencing an issue. These questions are for you to
answer. No one is going to hack into your computer to extract the
configuration information necessary to produce a useful bug report.

> Let's say you are right in saying that puri is doing something naughty by
> polluting a readtable.
No. YOU say it. I'm just interpreting in English the precious little
information that you claim you extracted from a backtrace generated in
mysterious ways that you didn't tell anything about.

> I'll go along with that. I have no reason to doubt
> it. I'm on your side on this issue.
Frankly not only do you sound like you're not on my side, you sound
like you're not even on your own side.

> Nevertheless we have a problem:
No. YOU have a problem. No one else has a problem.
Before you blame others, what are YOU doing wrong?

> this
> code has been in the wild since 2015 or earlier. A very ubiquitous library
> (drakma) depends on it. Cleaning up poor behavior is a bigger job thant
> making a fundamental and core component like asdf no longer accept the
> behavior. The offending libraries have to be fixed in concert with this
> refactoring. Established libraries cannot simply have the rug pulled out
> from under them.
>
Not only puri but all of quicklisp builds fine for me with ASDF 3.3.0,
except a handful of well-identified systems that are unmaintained
(patch not merged and no answer from maintainers after repeated
prodding over 6 months).

> I'm with Stas. I cannot upgrade asdf if it makes it impossible for me to use
> libraries that I depend on. Whatever new things asdf does are less important
> to me than having a working drakma. I believe just about all users would
> agree with this sentiment.
>
Drakma works perfectly with ASDF 3.3.0, thank you. (asdf:test-system
:drakma)... Did 40 checks. Pass: 40 (100%).

> I'm perfectly willing to contribute to the fixing of these libraries. But
> let's not do it as a mad scramble. Let's issue deprecation warnings,
> identify broken quicklisp packages, get the bugs in those packages fixed and
> then implement the new asdf behavior. I'm here to help.
>
You're being extremely unhelpful --- including to yourself.

What ASDF 3.3.0 does change compared to ASDF 3.2.1 is the behavior
with respect to :defsystem-depends-on libraries (and more generally,
libraries loaded inside a .asd) and their transitive dependencies. No
more double-loading or missed loading. If you were depending on some
double-loading to counteract side-effects to the readtable by some
library, you lose.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If you make people think they're thinking, they'll love you;
but if you really make them think, they'll hate you. — Don Marquis