Hi,
I would like to remove some old workaround code from a couple of systems, wrt to ASDF 3.1.4 bugs (see below). Is it safe to do so now, or are these "bugs" still lurking around?
The relevant parts are as follows:
:defsystem-depends-on (:net.didierverna.clon.setup/termio #+sbcl ;; BUG in ASDF 3.1.4: d-d-o can't deal dependency expanding to NIL (:feature :sbcl (:require :sb-grovel)) #+(or allegro clisp lispworks) (:feature (:or :allegro :clisp :lispworks) :cffi-grovel))
and
:components (;; bug in ASDF 3.1.4: cannot deal with conditionally defined ;; component class! #+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) #+(or allegro clisp lispworks) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks))
Thank you!
On 18 Mar 2021, at 11:59, Didier Verna wrote:
Hi,
I would like to remove some old workaround code from a couple of systems, wrt to ASDF 3.1.4 bugs (see below). Is it safe to do so now, or are these "bugs" still lurking around?
The relevant parts are as follows:
:defsystem-depends-on (:net.didierverna.clon.setup/termio #+sbcl ;; BUG in ASDF 3.1.4: d-d-o can't deal dependency expanding to NIL (:feature :sbcl (:require :sb-grovel)) #+(or allegro clisp lispworks) (:feature (:or :allegro :clisp :lispworks) :cffi-grovel))
Looking at the test suite, I see this test specifically aimed to check this:
``` (eval `(def-test-system test-defsystem-depends-on-4 :defsystem-depends-on ((:feature ,*newsym* "test-defsystem-depends-on-3"))))
(assert (find-system "test-defsystem-depends-on-4")) ```
and
:components (;; bug in ASDF 3.1.4: cannot deal with conditionally defined ;; component class! #+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) #+(or allegro clisp lispworks) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks))
I don't understand this well enough to know whether it's fixed or not. What's a minimum working example? Is `sb-grovel:grovel-constants-file` a component class? Is this issue with conditionally defined component class, or is this a package issue? Can't tell. Can you offer an alternative that wouldn't involve having to pull over a lot of systems?
This one seems complex enough -- and so much trouble to make a MWE -- that maybe you want to just change it and see if it breaks.
Thank you!
-- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now!
Lisp, Jazz, Aïkido: http://www.didierverna.info
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Voice: (612) 326-3934 Email: rpgoldman@SIFT.net
"Robert Goldman" rpgoldman@sift.info wrote:
This one seems complex enough -- and so much trouble to make a MWE -- that maybe you want to just change it and see if it breaks.
Yup, that's what I did locally, with recent versions of all compilers I have. Those shipping with ASDF seem to all have 3.2.0 at least now, but I was a bit curious as to when exactly the issues were fixed, and too lazy to investigate the change logs by myself ;-)
Looking at the test suite, I see this test specifically aimed to check this:
(eval `(def-test-system test-defsystem-depends-on-4
Using git log test/test-defsystem-depends-on.script it looks like this is https://bugs.launchpad.net/asdf/+bug/1445638 Looking for that bug in git log, it was fixed in 3.1.4.5 on 2015-04-23.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Work harder! Millions on welfare depend on you.
François-René ÐVB Rideau écrivait:
Using git log test/test-defsystem-depends-on.script it looks like this is https://bugs.launchpad.net/asdf/+bug/1445638 Looking for that bug in git log, it was fixed in 3.1.4.5 on 2015-04-23.
I'm proceeding with the second issue in my system, and it seems that the problem is still here (ASDF 3.3.4.10). With this inside:
:components (#+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks)) ...)
SBCL complains (as well as all but ACL, CLISP, and LW):
debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #<THREAD "main thread" RUNNING {1001888243}>: Error while trying to load definition for system net.didierverna.clon.termio from pathname /Users/didier/Documents/Science/Software/Common Lisp/clon/termio/net.didierverna.clon.termio.asd: don't recognize component type :CFFI-GROVEL-FILE
If I understand :if-feature correctly, the whole component form should be ignored, right?
I'm proceeding with the second issue in my system, and it seems that the problem is still here (ASDF 3.3.4.10). With this inside:
:components (#+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks)) ...)SBCL complains (as well as all but ACL, CLISP, and LW):
debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #<THREAD "main thread" RUNNING {1001888243}>: Error while trying to load definition for system net.didierverna.clon.termio from pathname /Users/didier/Documents/Science/Software/Common Lisp/clon/termio/net.didierverna.clon.termio.asd: don't recognize component type :CFFI-GROVEL-FILE
If I understand :if-feature correctly, the whole component form should be ignored, right?
Before it can be ignored, it must be defined. And so as to define it, its class must be defined. I suppose we could have some error class that it used when the class it not defined, that would only trigger an error at runtime if the feature is true. I'm sure the current / next sucker^W maintainer will accept patches.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org ...so that IBM Java envangelist tells me "nothing spread as fast as Java", to which I answer: "crack!"...
François-René ÐVB Rideau écrivait:
Before it can be ignored, it must be defined. And so as to define it, its class must be defined. I suppose we could have some error class that it used when the class it not defined, that would only trigger an error at runtime if the feature is true. I'm sure the current / next sucker^W maintainer will accept patches.
Not a big deal. I just thought that since everything in that form are keywords (so no read-time problem, as opposed to parsing sb-grovel:grovel-constants-file), perhaps the intended behavior was different.
So in the end, it seems that there's very little (if at all) to be gained by using :if-feature to conditionalize on implementation type.
Didier, would you mind posting a GitLab issue for this? It's feasible, but I'm so overloaded right now that there's no chance I will get to it before I forget.
Thanks
On 19 Mar 2021, at 8:34, Didier Verna wrote:
François-René ÐVB Rideau écrivait:
Before it can be ignored, it must be defined. And so as to define it, its class must be defined. I suppose we could have some error class that it used when the class it not defined, that would only trigger an error at runtime if the feature is true. I'm sure the current / next sucker^W maintainer will accept patches.
Not a big deal. I just thought that since everything in that form are keywords (so no read-time problem, as opposed to parsing sb-grovel:grovel-constants-file), perhaps the intended behavior was different.
So in the end, it seems that there's very little (if at all) to be gained by using :if-feature to conditionalize on implementation type.
-- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now!
Lisp, Jazz, Aïkido: http://www.didierverna.info
"Robert Goldman" rpgoldman@sift.info écrivait:
Didier, would you mind posting a GitLab issue for this? It's feasible, but I'm so overloaded right now that there's no chance I will get to it before I forget.
Sure!
Considering that SBCL upgraded to 3.1.5 in July 2015, I think you should be pretty safe assuming that your users' ASDF is more recent than 3.1.4.
What more, even Xach seems to have miraculously seen the light: one months and one week ago, he updated the fallback ASDF in Quicklisp from 2.26 to 3.2.1! That was the first update of ASDF in Quicklisp since 2012, to a version then-current, to a version 4 years old. By linear extrapolation, we should expect the next update to happen in 2030, to a version from 2022. I admit that I was thinking his next move would be to downgrade ASDF to 1.369 (the last version before I took over).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To avoid criticism, do nothing, say nothing, and be nothing. – Elbert Hubbard
On Thu, Mar 18, 2021 at 1:00 PM Didier Verna didier@lrde.epita.fr wrote:
Hi,
I would like to remove some old workaround code from a couple of systems, wrt to ASDF 3.1.4 bugs (see below). Is it safe to do so now, or are these "bugs" still lurking around?
The relevant parts are as follows:
:defsystem-depends-on (:net.didierverna.clon.setup/termio #+sbcl ;; BUG in ASDF 3.1.4: d-d-o can't deal dependency expanding to NIL (:feature :sbcl (:require :sb-grovel)) #+(or allegro clisp lispworks) (:feature (:or :allegro :clisp :lispworks) :cffi-grovel))
and
:components (;; bug in ASDF 3.1.4: cannot deal with conditionally defined ;; component class! #+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) #+(or allegro clisp lispworks) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks))
Thank you!
On Thu, 18 Mar 2021, Faré wrote:
Considering that SBCL upgraded to 3.1.5 in July 2015, I think you should be pretty safe assuming that your users' ASDF is more recent than 3.1.4.
What more, even Xach seems to have miraculously seen the light: one months and one week ago, he updated the fallback ASDF in Quicklisp from 2.26 to 3.2.1! That was the first update of ASDF in Quicklisp since 2012, to a version then-current, to a version 4 years old. By linear extrapolation, we should expect the next update to happen in 2030, to a version from 2022. I admit that I was thinking his next move would be to downgrade ASDF to 1.369 (the last version before I took over).
Didn't he revert that change after something broke?
/andreas
On Fri, Mar 19, 2021 at 3:10 AM Andreas Davour ante@update.uu.se wrote:
What more, even Xach […] updated the fallback ASDF in Quicklisp from 2.26 to 3.2.1!
Didn't he revert that change after something broke?
Not according to the git repository of quicklisp-client.
Also, we did a lot of testing of ASDF on Quicklisp thanks to Anton Vodonosov, and most implementations already have a more recent ASDF than that.
But yeah, of course, if something breaks, the rational thing to do is to revert, and not to either report or fix a bug in any of the software at stake. Or is it?
—♯ƒ • François-René Rideau • Co-Founder and CEO, MuKn.io MuKn.io is hiring. Looking for a senior language implementer for glow-lang.org. Our meta-language is Gerbil Scheme. We love macros, prototype objects and dependent types.
On Fri, 19 Mar 2021, Faré wrote:
On Fri, Mar 19, 2021 at 3:10 AM Andreas Davour ante@update.uu.se wrote:
What more, even Xach […] updated the fallback ASDF in Quicklisp from 2.26 to 3.2.1!
Didn't he revert that change after something broke?
Not according to the git repository of quicklisp-client.
Also, we did a lot of testing of ASDF on Quicklisp thanks to Anton Vodonosov, and most implementations already have a more recent ASDF than that.
But yeah, of course, if something breaks, the rational thing to do is to revert, and not to either report or fix a bug in any of the software at stake. Or is it?
So much the better. I just saw a note by Zach that something broke, but clearly it was something else, and me reading sloppily. Thanks for setting it straight, Faré. Please ignore me.
/andreas
-
Andreas Davour -
Didier Verna -
Faré -
Robert Goldman