[E] Re: new compiler error re: SET-DISPATCH-MACRO-CHARACTER
fahree at gmail.com
Thu Oct 12 04:41:29 UTC 2017
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
> No one is ever persuaded by the "it works for me"
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.
> 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?
> 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
More information about the asdf-devel