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

[Faré]

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


> 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• 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

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

[Konstanski, Carlos]

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. No one is ever persuaded by the "it works for me"
argument. The issue is real. 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.

Let's say you are right in saying that puri is doing something naughty by
polluting a readtable. I'll go along with that. I have no reason to doubt
it. I'm on your side on this issue. Nevertheless we have a problem: 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 than
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.

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.

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.

Carlos

2017-10-11 20:31 GMT-06:00 Faré :

> I just tried compiling puri with asdf 3.3.0, using either quicklisp or
> the latest commit (b537e93 from August 29 2015) on sbcl 1.3.20, and
> had no issue whatsoever.
>
> Odds are the problem is on your side, probably with your using
> with-standard-io-syntax or some such. Note that it is very rude to use
> set-dispatch-macro-character on a readtable you didn't specifically
> setup, especially since it might be a read-only readtable, or worse, a
> writable one used by people who assume it won't be modified.
>
> I've had a branch of ASDF, called "syntax-control", supposed to bring
> *some* sanity in readtables used while building with ASDF. It has
> bitrotten in the last 4 years and is nowhere near being merged at this
> point.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection•
> https://urldefense.proofpoint.com/v2/url?u=http-3A__fare.
> tunes.org=DwIFaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LR
> xpb6__0PomBTQ=UXttlWX_R8MsWhBAnFwO2t5aPuH2x7HGk4gZpT
> TCo-UE-RFLppFABNHDw29AmFnQ=sNgypPrTU-ocowWcZQAmsxdniF2mxBwl_
> 6BmfJxiyjY=8O9az24Gmg12t9C9jp5bOiJSXjwPqkIvmeFuYqIUCnw=
> Opportunity is missed by most people because it comes dressed in overalls
> and looks like work.— T. A. Edison
>
>
> On Wed, Oct 11, 2017 at 8:41 PM, Konstanski, Carlos
>  wrote:
> > This is a bug report. I'm using puri as an example, but it's not a puri
> > bug.
> >
> > With the latest version of asdf (3.3.0) puri no longer compiles. The
> > following compiler error is thrown:
> >
> >SET-DISPATCH-MACRO-CHARACTER would modify the standard readtable.
> >[Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]
> >
> > In:
> >
> >   0: (SET-DISPATCH-MACRO-CHARACTER #\# #\u #
> > #)
> >
> > The code:
> >
> > (defun sharp-u (stream chr arg)
> >   (declare (ignore chr arg))
> >   (let ((arg (read stream nil nil t)))
> > (if *read-suppress*
> > nil
> >   (if* (stringp arg)
> >  then (parse-uri arg)
> >  else
> >  (internal-reader-error
> >   stream
> >   "#u takes a string or list argument: ~s" arg)
> >
> > (set-dispatch-macro-character #\# #\u #'puri::sharp-u)
> >
> > What puri is doing re: SET-DISPATCH-MACRO-CHARACTER is totally by the
> > book. Why is this suddenly an error? Is there a workaround?
> >
> > Backing up to the next most recent release of asdf makes the problem go
> > away:
> >
> > dev-lisp/asdf-3.2.1-r1:0/3.2.1-r1
> > dev-lisp/uiop-3.2.1:0
> >
> > I tried to find the asdf changelog to see if this is a documented
> > change. But the link is broken.
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__common-
> 2Dlisp.net_project_asdf_Changelog=DwIFaQ=
> udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=UXttlWX_
> R8MsWhBAnFwO2t5aPuH2x7HGk4gZpTTCo-UE-RFLppFABNHDw29AmFnQ=sNgypPrTU-
> ocowWcZQAmsxdniF2mxBwl_6BmfJxiyjY=-Ety3cawXfSBOqWK_
> Ms5Hi2TwB62089buk66HVbLu-s=
> >
> > uiop seems to be closely tied to asdf. Not sure which package is
> > actually at fault.
> > --
> > Carlos Konstanski
> >
>



-- 
Carlos Konstanski
MTS IV Cslt
Verizon Cloud Platform
carlos.konstan...@verizonwireless.com
Cell: 15126218301
Slack: vzw-vsi.slack.com 

Re: WARNING: System definition file ...

[Faré]

On Wed, Oct 11, 2017 at 9:14 PM, Stas Boukarev  wrote:
> 3.3.0 issues a barrage of new warnings about something it has decided is
> uncouth now.
>
On what systems is it issuing warnings? Any free software that we can patch?

Without specific warnings coming from specific libraries, it's hard to
tell what can be fixed, what cannot, what is an actual problem with
the code you're using, what is possibly a problem about ASDF itself,
etc.

Odds are, the something had been decided as uncouth long ago, and ASDF
just lacked the means to warn you about it.

> I really have no wish to stare at these warnings coming from third party
> libraries, especially since they're never going to be fixed.
> Is the old behavior posing problems? Is the old behavior going away soon?
>
Yes, some old behavior is posing problem and has for years. Sometimes
the old behavior has already gone away and/or is precariously emulated
in slightly incompatible ways using the newer better interface.
Sometimes we really want to get away from a really bad interface that
has been deprecated for years (e.g. run-shell-command, which is a
security liability in addition to been challenged with usability).
Sometimes a recent refactoring made some operation non-sensical (e.g.
operation-on-warnings) and/or not so useful (e.g. require-system), or
a really bad interface to the system (system-registered-p).

Depending on the interfaces, the old behavior may go away within two
year, especially where supporting it is problematic and/or the
interface is bogus and misleading and not properly doing what it was
once advertised to be used for. Well, whoever is maintainer then will
probably do something conservative that preserves compatibility (with
some kind of warning) wherever it isn't an encouragement to writing
nonsensical code.

> This is why I don't update ASDF, I don't want to change anything in my code
> because of a new version.

Last I heard, janderson was using his own slightly forked ASDF 1, and
some russians had forked ASDF 2.

On the other hand, some programs depend on a recent ASDF, such as
IOlib or CFFI, or scripts that depend on a fixes run-program or on its
younger sibling launch-program, especially so on SBCL/Windows.

There is no pleasing everyone, but there's going forward. SBCL also
sometimes deprecates some old interfaces, and issues warnings to those
who use them.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
Every four seconds a woman has a baby.
Our problem is to find this woman and stop her.

WARNING: System definition file ...

[Stas Boukarev]

3.3.0 issues a barrage of new warnings about something it has decided is
uncouth now.
I really have no wish to stare at these warnings coming from third party
libraries, especially since they're never going to be fixed.
Is the old behavior posing problems? Is the old behavior going away soon?

This is why I don't update ASDF, I don't want to change anything in my code
because of a new version.

new compiler error re: SET-DISPATCH-MACRO-CHARACTER

[Konstanski, Carlos]

This is a bug report. I'm using puri as an example, but it's not a puri
bug.

With the latest version of asdf (3.3.0) puri no longer compiles. The
following compiler error is thrown:

   SET-DISPATCH-MACRO-CHARACTER would modify the standard readtable.
   [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]

In:

  0: (SET-DISPATCH-MACRO-CHARACTER #\# #\u #
#)

The code:

(defun sharp-u (stream chr arg)
  (declare (ignore chr arg))
  (let ((arg (read stream nil nil t)))
(if *read-suppress*
nil
  (if* (stringp arg)
 then (parse-uri arg)
 else
 (internal-reader-error
  stream
  "#u takes a string or list argument: ~s" arg)

(set-dispatch-macro-character #\# #\u #'puri::sharp-u)

What puri is doing re: SET-DISPATCH-MACRO-CHARACTER is totally by the
book. Why is this suddenly an error? Is there a workaround?

Backing up to the next most recent release of asdf makes the problem go
away:

dev-lisp/asdf-3.2.1-r1:0/3.2.1-r1
dev-lisp/uiop-3.2.1:0

I tried to find the asdf changelog to see if this is a documented
change. But the link is broken.
https://common-lisp.net/project/asdf/Changelog

uiop seems to be closely tied to asdf. Not sure which package is
actually at fault.
--
Carlos Konstanski