On Wed, Oct 11, 2017 at 11:19 PM, Konstanski, Carlos <carlos.konstan...@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
