[asdf-devel] Buggy release
The last commit causes this: ; caught ERROR: ; READ error during COMPILE-FILE: ; ; The function ASDF::FIND-SYMBOL* is undefined. ; ; (in form starting at line: 3452, column: 53, file-position: 150201) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Uh? Is it a bad upgrade issue? From what version? How exactly are you loading ASDF? On what implementation? Or, did my tweak in file concatenation order somehow cause this failure? md5sum /project/asdf/public_html/archives/asdf.lisp 2ba7192774cffa501586376ab651928c Line 3452 is (parse-native-namestring "/tmp/"))) which is a function, not a macro call involving asdf::find-symbol*. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There is never a better measure of what a person is than what he does when he's absolutely free to choose." — William M. Bulger On Wed, May 15, 2013 at 5:35 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
The last commit causes this:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; The function ASDF::FIND-SYMBOL* is undefined. ; ; (in form starting at line: 3452, column: 53, file-position: 150201)
On Wed, 2013-05-15 at 21:25 -0400, Faré wrote:
Uh? Is it a bad upgrade issue? From what version? How exactly are you loading ASDF? On what implementation? Or, did my tweak in file concatenation order somehow cause this failure?
Calling compile-file on asdf.lisp tag 3.0.0 using latest sbcl and without upgrading(asdf isn't previously loaded). Code: https://github.com/sionescu/skel/blob/master/.cl-init/asdf-init.lisp -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Works for me on asdf 3.0.0 and the latest sbcl on linux/x64 Did you use make to build a new asdf.lisp? Is there an old asdf.fasl polluting the build? Which version is it from? You can load it manually then query (asdf:asdf-version). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Honor among thieves is the ancestor of all honor. — John McCarthy On Thu, May 16, 2013 at 12:21 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
On Wed, 2013-05-15 at 21:25 -0400, Faré wrote:
Uh? Is it a bad upgrade issue? From what version? How exactly are you loading ASDF? On what implementation? Or, did my tweak in file concatenation order somehow cause this failure?
Calling compile-file on asdf.lisp tag 3.0.0 using latest sbcl and without upgrading(asdf isn't previously loaded). Code: https://github.com/sionescu/skel/blob/master/.cl-init/asdf-init.lisp
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
On Thu, 2013-05-16 at 12:54 -0400, Faré wrote:
Works for me on asdf 3.0.0 and the latest sbcl on linux/x64 Did you use make to build a new asdf.lisp? Is there an old asdf.fasl polluting the build? Which version is it from? You can load it manually then query (asdf:asdf-version).
I figured out what's happening: I load ASDF before quicklisp, and quicklisp doesn't recognize "3.0.0" as being recent enough so it tries to load 2.26 which fails during upgrade. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Oh shit, that's right: it uses version-satisfies instead of version<= (which didn't exist at the time), and of course, 3.0.0 doesn't satisfy 2.26 because of the major version mismatch. Ouch. One solution would be that quicklisp be patched to accept asdf if #+asdf3 or (member :asdf3 *features*). Another solution that quicklisp itself be updated to use asdf3 and possibly version<= rather than version-satisfies, or not: I've added a minor version number that allows to have version "branches" that don't involve a new major version number. The last solution would be that ASDF be stuck forever in using 2 as its major version number. Maybe I should have done just that, because that's the only 100% backward compatible way. Then I should promptly rename ASDF 3.0.0 into ASDF 2.34.0 or some such. I don't like any of these solutions, and I feel stupid for not thinking about it earlier. Xach, any comment? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Most people think they need a ruler. Perhaps we should give them a fake one that doesn't actually do anything, and then they won't think about it. It is sort of like giving an infant a pacifier. — Perry Metzger On Thu, May 16, 2013 at 1:19 PM, Stelian Ionescu <sionescu@cddr.org> wrote:
On Thu, 2013-05-16 at 12:54 -0400, Faré wrote:
Works for me on asdf 3.0.0 and the latest sbcl on linux/x64 Did you use make to build a new asdf.lisp? Is there an old asdf.fasl polluting the build? Which version is it from? You can load it manually then query (asdf:asdf-version).
I figured out what's happening: I load ASDF before quicklisp, and quicklisp doesn't recognize "3.0.0" as being recent enough so it tries to load 2.26 which fails during upgrade.
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
Faré <fahree@gmail.com> writes:
Oh shit, that's right: it uses version-satisfies instead of version<= (which didn't exist at the time), and of course, 3.0.0 doesn't satisfy 2.26 because of the major version mismatch. Ouch.
One solution would be that quicklisp be patched to accept asdf if #+asdf3 or (member :asdf3 *features*). Another solution that quicklisp itself be updated to use asdf3 and possibly version<= rather than version-satisfies, or not: I've added a minor version number that allows to have version "branches" that don't involve a new major version number.
The last solution would be that ASDF be stuck forever in using 2 as its major version number. Maybe I should have done just that, because that's the only 100% backward compatible way. Then I should promptly rename ASDF 3.0.0 into ASDF 2.34.0 or some such.
I don't like any of these solutions, and I feel stupid for not thinking about it earlier.
Xach, any comment?
What about making version-satisfies return t? Zach
What about making version-satisfies return t?
I could do (and implemented that as version<=), but that would violate the previous contract. Not that I am aware of anyone relying on the previous contract. What do people here think is the right thing? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do. — Henry Ford
Looking at packages in quicklisp, it appears that no one explicitly calls version-satisfies and really relies on the fact that it isn't the same as version<= (actually, several packages, all written by me, go through some pains to emulate version<= in spite of only version-satisfies being available in asdf 2). On the other hand, 41 different .asd files rely on (:version ...) constrained dependencies, and may or may not expect a different major version to be considered as incompatible. So, is anyone going to complain if I do as Xach suggests and have version-satisfies be an alias for version<= ? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If this country is worth saving, it's worth saving at a profit. — H. L. Hunt This country can only be saved if it can be saved at a profit. — Patri Friedman On Thu, May 16, 2013 at 2:03 PM, Faré <fahree@gmail.com> wrote:
What about making version-satisfies return t?
I could do (and implemented that as version<=), but that would violate the previous contract. Not that I am aware of anyone relying on the previous contract.
What do people here think is the right thing?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do. — Henry Ford
I would suggest if you do this, we might want to offer some syntactic means to get the old behavior. Certainly there are cases where a library supplier may change the API in ways that mean "any version from 2 on" will be the wrong thing and what is wanted really is "version 2, not version 1, and not version 3." There have definitely been cases where upgrading a library will break dependent systems: I don't think we should have a build system that can't deal with that case. Best, R "Faré" <fahree@gmail.com> wrote:
Looking at packages in quicklisp, it appears that no one explicitly calls version-satisfies and really relies on the fact that it isn't the same as version<= (actually, several packages, all written by me, go through some pains to emulate version<= in spite of only version-satisfies being available in asdf 2).
On the other hand, 41 different .asd files rely on (:version ...) constrained dependencies, and may or may not expect a different major version to be considered as incompatible.
So, is anyone going to complain if I do as Xach suggests and have version-satisfies be an alias for version<= ?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If this country is worth saving, it's worth saving at a profit. — H. L. Hunt This country can only be saved if it can be saved at a profit. — Patri Friedman
On Thu, May 16, 2013 at 2:03 PM, Faré <fahree@gmail.com> wrote:
What about making version-satisfies return t?
I could do (and implemented that as version<=), but that would violate the previous contract. Not that I am aware of anyone relying on the previous contract.
What do people here think is the right thing?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do. — Henry Ford
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Thu, 2013-05-16 at 13:57 -0400, Faré wrote:
Oh shit, that's right: it uses version-satisfies instead of version<= (which didn't exist at the time), and of course, 3.0.0 doesn't satisfy 2.26 because of the major version mismatch. Ouch.
One solution would be that quicklisp be patched to accept asdf if #+asdf3 or (member :asdf3 *features*). Another solution that quicklisp itself be updated to use asdf3 and possibly version<= rather than version-satisfies, or not: I've added a minor version number that allows to have version "branches" that don't involve a new major version number.
The last solution would be that ASDF be stuck forever in using 2 as its major version number. Maybe I should have done just that, because that's the only 100% backward compatible way. Then I should promptly rename ASDF 3.0.0 into ASDF 2.34.0 or some such.
The latter is what I did, changed the version to 2.33.11 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
participants (4)
-
Faré -
rpgoldman＠sift.info -
Stelian Ionescu -
Zach Beane