Starting with a bare lisp image (e.g --no-userinit --no-sysinit for SBCL), the following signals a "component not found" error:
(load "asdf-2.26.lisp") ;;; or whatever system you want (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/" asdf:*central-registry*) (load "asdf-3.2.1.lisp") (asdf:load-system "alexandria")
The first bad commit is https://github.com/fare/asdf/commit/3a9457a
I hope this wasn't intentional? Ideally an old asdf version would never get loaded, but practically speaking it sometimes does (e.g. on LispWorks PE and CLISP). And if that happens, thereafter one is unable to load a system that requires asdf-3. The above case is a whittled-down version of a quickloading problem.
Best, lmj
This is totally intentional and well-documented.
Do NOT use the central-registry if you don't know what you're doing. Use the source-registry as recommended. (Or, if you truly insist, reinitialize the central-registry after upgrade; upgrading from ASDF 2 will create a fresh ASDF package; see asdf/tools/load-asdf.lisp for how to load ASDF while supporting backward compatibility back to ASDF 1 the hard way).
Do NOT use ASDF 2.26 (from October 2012), ever. Help me convince Xach to stop distributing that bitrotting piece of maintenance nightmare. Seriously, it's a shame that Quicklisp isn't distributing ASDF 3.1.7 (from May 2016), which is the very stable culmination of the 3.1 series and works great with all its systems. And I totally understand that Quicklisp must be conservative and should not upgrade to the latest 3.2.1 (from April 2017) yet. Considering how badly ASDF 2.26 now behaves when trying to load systems from Quicklisp, I wonder if Xach even ever tests it; I bet not. Alternatively, to show how utterly ridiculous his attitude is, convince him to distribute ASDF 1.85 (from May 2004) instead, the perfect gem that Dan Barlow bequeathed us (). Or no more recent 1.366 (from September 2009), the last version wholly untainted by my code contributions.
-#f
On May 3, 2017 2:23 PM, "James M. Lawrence" llmjjmll@gmail.com wrote:
Starting with a bare lisp image (e.g --no-userinit --no-sysinit for SBCL), the following signals a "component not found" error:
(load "asdf-2.26.lisp") ;;; or whatever system you want (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/" asdf:*central-registry*) (load "asdf-3.2.1.lisp") (asdf:load-system "alexandria")
The first bad commit is https://github.com/fare/asdf/commit/3a9457a
I hope this wasn't intentional? Ideally an old asdf version would never get loaded, but practically speaking it sometimes does (e.g. on LispWorks PE and CLISP). And if that happens, thereafter one is unable to load a system that requires asdf-3. The above case is a whittled-down version of a quickloading problem.
Best, lmj
Is there any chance for specification of the "core ASDF protocol" - subset guaranteed to not change every few years, so one may write today systems which will be loadadable in the future?
Regards, Daniel
Faré writes:
This is totally intentional and well-documented.
Do NOT use the central-registry if you don't know what you're doing. Use the source-registry as recommended. (Or, if you truly insist, reinitialize the central-registry after upgrade; upgrading from ASDF 2 will create a fresh ASDF package; see asdf/tools/load-asdf.lisp for how to load ASDF while supporting backward compatibility back to ASDF 1 the hard way).
Do NOT use ASDF 2.26 (from October 2012), ever. Help me convince Xach to stop distributing that bitrotting piece of maintenance nightmare. Seriously, it's a shame that Quicklisp isn't distributing ASDF 3.1.7 (from May 2016), which is the very stable culmination of the 3.1 series and works great with all its systems. And I totally understand that Quicklisp must be conservative and should not upgrade to the latest 3.2.1 (from April 2017) yet. Considering how badly ASDF 2.26 now behaves when trying to load systems from Quicklisp, I wonder if Xach even ever tests it; I bet not. Alternatively, to show how utterly ridiculous his attitude is, convince him to distribute ASDF 1.85 (from May 2004) instead, the perfect gem that Dan Barlow bequeathed us (). Or no more recent 1.366 (from September 2009), the last version wholly untainted by my code contributions.
-#f
On May 3, 2017 2:23 PM, "James M. Lawrence" llmjjmll@gmail.com wrote:
Starting with a bare lisp image (e.g --no-userinit --no-sysinit for SBCL), the following signals a "component not found" error:
(load "asdf-2.26.lisp") ;;; or whatever system you want (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/" asdf:*central-registry*) (load "asdf-3.2.1.lisp") (asdf:load-system "alexandria")
The first bad commit is https://github.com/fare/asdf/commit/3a9457a
I hope this wasn't intentional? Ideally an old asdf version would never get loaded, but practically speaking it sometimes does (e.g. on LispWorks PE and CLISP). And if that happens, thereafter one is unable to load a system that requires asdf-3. The above case is a whittled-down version of a quickloading problem.
Best, lmj
-- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
On 5/3/17 May 3 -2:30 PM, Daniel Kochmański wrote:
Is there any chance for specification of the "core ASDF protocol" - subset guaranteed to not change every few years, so one may write today systems which will be loadadable in the future?
This question really isn't germane to the original post. The original post was a question about online upgrade, which is simply impossible in some cases.
If you would like to raise this issue again, I suggest doing it with a subject line that more correctly fits the topic.
That said, the core ASDF protocol really hasn't changed much at all. Most of the changes have been extensions. The few exceptions lie with deprecated lower-level interfaces. A first step to stabilizing this would be to document all of the interface functions, variables, and classes. But that's a lot of work. The documentation is getting better, but slowly.
Best, r
Regards, Daniel
Faré writes:
This is totally intentional and well-documented.
Do NOT use the central-registry if you don't know what you're doing. Use the source-registry as recommended. (Or, if you truly insist, reinitialize the central-registry after upgrade; upgrading from ASDF 2 will create a fresh ASDF package; see asdf/tools/load-asdf.lisp for how to load ASDF while supporting backward compatibility back to ASDF 1 the hard way).
Do NOT use ASDF 2.26 (from October 2012), ever. Help me convince Xach to stop distributing that bitrotting piece of maintenance nightmare. Seriously, it's a shame that Quicklisp isn't distributing ASDF 3.1.7 (from May 2016), which is the very stable culmination of the 3.1 series and works great with all its systems. And I totally understand that Quicklisp must be conservative and should not upgrade to the latest 3.2.1 (from April 2017) yet. Considering how badly ASDF 2.26 now behaves when trying to load systems from Quicklisp, I wonder if Xach even ever tests it; I bet not. Alternatively, to show how utterly ridiculous his attitude is, convince him to distribute ASDF 1.85 (from May 2004) instead, the perfect gem that Dan Barlow bequeathed us (). Or no more recent 1.366 (from September 2009), the last version wholly untainted by my code contributions.
-#f
On May 3, 2017 2:23 PM, "James M. Lawrence" llmjjmll@gmail.com wrote:
Starting with a bare lisp image (e.g --no-userinit --no-sysinit for SBCL), the following signals a "component not found" error:
(load "asdf-2.26.lisp") ;;; or whatever system you want (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/" asdf:*central-registry*) (load "asdf-3.2.1.lisp") (asdf:load-system "alexandria")
The first bad commit is https://github.com/fare/asdf/commit/3a9457a
I hope this wasn't intentional? Ideally an old asdf version would never get loaded, but practically speaking it sometimes does (e.g. on LispWorks PE and CLISP). And if that happens, thereafter one is unable to load a system that requires asdf-3. The above case is a whittled-down version of a quickloading problem.
Best, lmj
-- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken. I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable). Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
On Wed, May 3, 2017 at 3:19 PM, Faré fahree@gmail.com wrote:
This is totally intentional and well-documented.
Do NOT use the central-registry if you don't know what you're doing. Use the source-registry as recommended. (Or, if you truly insist, reinitialize the central-registry after upgrade; upgrading from ASDF 2 will create a fresh ASDF package; see asdf/tools/load-asdf.lisp for how to load ASDF while supporting backward compatibility back to ASDF 1 the hard way).
Do NOT use ASDF 2.26 (from October 2012), ever. Help me convince Xach to stop distributing that bitrotting piece of maintenance nightmare. Seriously, it's a shame that Quicklisp isn't distributing ASDF 3.1.7 (from May 2016), which is the very stable culmination of the 3.1 series and works great with all its systems. And I totally understand that Quicklisp must be conservative and should not upgrade to the latest 3.2.1 (from April 2017) yet. Considering how badly ASDF 2.26 now behaves when trying to load systems from Quicklisp, I wonder if Xach even ever tests it; I bet not. Alternatively, to show how utterly ridiculous his attitude is, convince him to distribute ASDF 1.85 (from May 2004) instead, the perfect gem that Dan Barlow bequeathed us (). Or no more recent 1.366 (from September 2009), the last version wholly untainted by my code contributions.
-#f
On May 3, 2017 2:23 PM, "James M. Lawrence" llmjjmll@gmail.com wrote:
Starting with a bare lisp image (e.g --no-userinit --no-sysinit for SBCL), the following signals a "component not found" error:
(load "asdf-2.26.lisp") ;;; or whatever system you want (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/" asdf:*central-registry*) (load "asdf-3.2.1.lisp") (asdf:load-system "alexandria")
The first bad commit is https://github.com/fare/asdf/commit/3a9457a
I hope this wasn't intentional? Ideally an old asdf version would never get loaded, but practically speaking it sometimes does (e.g. on LispWorks PE and CLISP). And if that happens, thereafter one is unable to load a system that requires asdf-3. The above case is a whittled-down version of a quickloading problem.
Best, lmj
On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence llmjjmll@gmail.com wrote:
The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken.
Upgrading works. Central-registry works. Central-registry is not preserved by upgrading. And doesn't need to be, because central-registry is something you insert into a special configuration file that needs to first load the proper asdf, anyway. Whoever writes that configuration file by hypothesis knows where all the software is located. It just doesn't make sense to load the wrong asdf then configure your central-registry only then to load yet another asdf. If you do things like that you deserve to lose.
I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
That doesn't make sense, and asdf cannot guess what ancient version of asdf was moved aside. Once again, it used to try much harder to upgrade from 2.26 on sbcl and several other implementations, but that got too unwieldy to support, for no good reason.
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable).
That part is totally reasonable indeed, and works perfectly.
Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Does not compute. Neither LispWorks PE nor CLISP release from 2010 provides ASDF. Quicklisp will then load its own ASDF, but that entails no upgrade. If you want a more recent ASDF on top of that provided by Quicklisp, you are going to lose anyway — instead overwrite Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make your implementation provide ASDF despite it not being provided out of the box.
If you insist on such a weird upgrade, many things may go wrong beside the *central-registry*. Yet even then you shouldn't be using the *central-registry* to begin with. Use the source-registry.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
Upgrading is not broken. Your use pattern is broken. Don't initialize the central registry after you load the wrong asdf then load the correct one then expect things to work.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
It's completely unnatural and backwards to load a wrong asdf, initialize it, then upgrade it. Please configure *after* you upgrade (and yes, *if* the configuration is for ASDF to find ASDF itself, you may have to configure that part twice; or just skip the part about loading the wrong asdf). And try using install-asdf.lisp where applicable.
Finally, please don't use the central-registry for cases like these. Use the source-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only a fool tests the depth of the water with both feet. — African proverb
LispWorks PE bundles an old asdf, which is loaded with (require "asdf").
CLISP optionally bundles asdf -- (require "asdf") -- and I would expect some Linux distributions to have that configuration in the CLISP they supply. (require "asdf") also looks in directories (including the user home directory!) for asdf.lisp, so an old version could be unintentionally loaded. My real concern is LispWorks, though.
Maybe this wasn't clear enough, but my communications here are on behalf of users, not me. Many -- perhaps most, perhaps nearly all -- people use asdf only indirectly through Quicklisp. I am trying to help the poor end-user who has a borked system and doesn't understand what is wrong. I would like to prevent the borkedness from happening in the first place.
Most people initialize Quicklisp in their startup file. After using the lisp image for a while, they may wish to load a system and discover that the system requires asdf3. So they load asdf3. And then everything is borked. It may be difficult even for an experienced user to discover what is wrong, much less a casual user, and next to impossible for a newcomer.
In the manual I didn't see any of the caveats you mention about the central registry. It says that asdf can be upgraded on the fly, and that's what people will expect. They don't expect that upgrading will bork the lisp image for some reason unknown to them.
The quick and dirty workaround I mentioned is not something that would be part of any real code, just something a user could do to get things unborked again, that is, to enable Quicklisp to load again.
I don't want to use *central-registry*. I'm not advocating using *central-registry*. I don't use *centry-registry* myself, except indirectly through Quicklisp. I am not insisting on weird upgrades. All I want to do is fix problems that end-users encounter.
On Wed, May 3, 2017 at 11:16 PM, Faré fahree@gmail.com wrote:
On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence llmjjmll@gmail.com wrote:
The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken.
Upgrading works. Central-registry works. Central-registry is not preserved by upgrading. And doesn't need to be, because central-registry is something you insert into a special configuration file that needs to first load the proper asdf, anyway. Whoever writes that configuration file by hypothesis knows where all the software is located. It just doesn't make sense to load the wrong asdf then configure your central-registry only then to load yet another asdf. If you do things like that you deserve to lose.
I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
That doesn't make sense, and asdf cannot guess what ancient version of asdf was moved aside. Once again, it used to try much harder to upgrade from 2.26 on sbcl and several other implementations, but that got too unwieldy to support, for no good reason.
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable).
That part is totally reasonable indeed, and works perfectly.
Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Does not compute. Neither LispWorks PE nor CLISP release from 2010 provides ASDF. Quicklisp will then load its own ASDF, but that entails no upgrade. If you want a more recent ASDF on top of that provided by Quicklisp, you are going to lose anyway — instead overwrite Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make your implementation provide ASDF despite it not being provided out of the box.
If you insist on such a weird upgrade, many things may go wrong beside the *central-registry*. Yet even then you shouldn't be using the *central-registry* to begin with. Use the source-registry.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
Upgrading is not broken. Your use pattern is broken. Don't initialize the central registry after you load the wrong asdf then load the correct one then expect things to work.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
It's completely unnatural and backwards to load a wrong asdf, initialize it, then upgrade it. Please configure *after* you upgrade (and yes, *if* the configuration is for ASDF to find ASDF itself, you may have to configure that part twice; or just skip the part about loading the wrong asdf). And try using install-asdf.lisp where applicable.
Finally, please don't use the central-registry for cases like these. Use the source-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only a fool tests the depth of the water with both feet. — African proverb
On 5/4/17 May 4 -8:54 AM, James M. Lawrence wrote:
LispWorks PE bundles an old asdf, which is loaded with (require "asdf").
Is this because LWPE is still LW 6 instead of 7?
CLISP optionally bundles asdf -- (require "asdf") -- and I would expect some Linux distributions to have that configuration in the CLISP they supply. (require "asdf") also looks in directories (including the user home directory!) for asdf.lisp, so an old version could be unintentionally loaded. My real concern is LispWorks, though.
We can't really handle clisp effectively, because as far as releases are concerned, it's dead. I realize that the code repo is active, but releases aren't being made, which means the de facto standard is now something going on 7 years old. That's not the ASDF project's fault.
Maybe this wasn't clear enough, but my communications here are on behalf of users, not me. Many -- perhaps most, perhaps nearly all -- people use asdf only indirectly through Quicklisp. I am trying to help the poor end-user who has a borked system and doesn't understand what is wrong. I would like to prevent the borkedness from happening in the first place.
Most people initialize Quicklisp in their startup file. After using the lisp image for a while, they may wish to load a system and discover that the system requires asdf3. So they load asdf3. And then everything is borked. It may be difficult even for an experienced user to discover what is wrong, much less a casual user, and next to impossible for a newcomer.
In the manual I didn't see any of the caveats you mention about the central registry. It says that asdf can be upgraded on the fly, and that's what people will expect. They don't expect that upgrading will bork the lisp image for some reason unknown to them.
I will see if I can put in a FAQ about this. Look for something soon.
The quick and dirty workaround I mentioned is not something that would be part of any real code, just something a user could do to get things unborked again, that is, to enable Quicklisp to load again.
I don't want to use *central-registry*. I'm not advocating using *central-registry*. I don't use *centry-registry* myself, except indirectly through Quicklisp. I am not insisting on weird upgrades. All I want to do is fix problems that end-users encounter.
I'm not familiar with the guts of QL, but I thought QL didn't use central registry. I thought it used its own extension to the loading process.
Best, R
On Wed, May 3, 2017 at 11:16 PM, Faré fahree@gmail.com wrote:
On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence llmjjmll@gmail.com wrote:
The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken.
Upgrading works. Central-registry works. Central-registry is not preserved by upgrading. And doesn't need to be, because central-registry is something you insert into a special configuration file that needs to first load the proper asdf, anyway. Whoever writes that configuration file by hypothesis knows where all the software is located. It just doesn't make sense to load the wrong asdf then configure your central-registry only then to load yet another asdf. If you do things like that you deserve to lose.
I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
That doesn't make sense, and asdf cannot guess what ancient version of asdf was moved aside. Once again, it used to try much harder to upgrade from 2.26 on sbcl and several other implementations, but that got too unwieldy to support, for no good reason.
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable).
That part is totally reasonable indeed, and works perfectly.
Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Does not compute. Neither LispWorks PE nor CLISP release from 2010 provides ASDF. Quicklisp will then load its own ASDF, but that entails no upgrade. If you want a more recent ASDF on top of that provided by Quicklisp, you are going to lose anyway — instead overwrite Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make your implementation provide ASDF despite it not being provided out of the box.
If you insist on such a weird upgrade, many things may go wrong beside the *central-registry*. Yet even then you shouldn't be using the *central-registry* to begin with. Use the source-registry.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
Upgrading is not broken. Your use pattern is broken. Don't initialize the central registry after you load the wrong asdf then load the correct one then expect things to work.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
It's completely unnatural and backwards to load a wrong asdf, initialize it, then upgrade it. Please configure *after* you upgrade (and yes, *if* the configuration is for ASDF to find ASDF itself, you may have to configure that part twice; or just skip the part about loading the wrong asdf). And try using install-asdf.lisp where applicable.
Finally, please don't use the central-registry for cases like these. Use the source-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only a fool tests the depth of the water with both feet. — African proverb
Actually, I find that there already WAS a discussion of just this issue in the ASDF manual. See the node "Pitfalls of the upgrade to ASDF 3." I have added another FAQ node to try to make this information easier to find, based on what went wrong. Review welcome.
Cheers, r
On 5/4/17 May 4 -9:59 AM, Robert Goldman wrote:
On 5/4/17 May 4 -8:54 AM, James M. Lawrence wrote:
LispWorks PE bundles an old asdf, which is loaded with (require "asdf").
Is this because LWPE is still LW 6 instead of 7?
CLISP optionally bundles asdf -- (require "asdf") -- and I would expect some Linux distributions to have that configuration in the CLISP they supply. (require "asdf") also looks in directories (including the user home directory!) for asdf.lisp, so an old version could be unintentionally loaded. My real concern is LispWorks, though.
We can't really handle clisp effectively, because as far as releases are concerned, it's dead. I realize that the code repo is active, but releases aren't being made, which means the de facto standard is now something going on 7 years old. That's not the ASDF project's fault.
Maybe this wasn't clear enough, but my communications here are on behalf of users, not me. Many -- perhaps most, perhaps nearly all -- people use asdf only indirectly through Quicklisp. I am trying to help the poor end-user who has a borked system and doesn't understand what is wrong. I would like to prevent the borkedness from happening in the first place.
Most people initialize Quicklisp in their startup file. After using the lisp image for a while, they may wish to load a system and discover that the system requires asdf3. So they load asdf3. And then everything is borked. It may be difficult even for an experienced user to discover what is wrong, much less a casual user, and next to impossible for a newcomer.
In the manual I didn't see any of the caveats you mention about the central registry. It says that asdf can be upgraded on the fly, and that's what people will expect. They don't expect that upgrading will bork the lisp image for some reason unknown to them.
I will see if I can put in a FAQ about this. Look for something soon.
The quick and dirty workaround I mentioned is not something that would be part of any real code, just something a user could do to get things unborked again, that is, to enable Quicklisp to load again.
I don't want to use *central-registry*. I'm not advocating using *central-registry*. I don't use *centry-registry* myself, except indirectly through Quicklisp. I am not insisting on weird upgrades. All I want to do is fix problems that end-users encounter.
I'm not familiar with the guts of QL, but I thought QL didn't use central registry. I thought it used its own extension to the loading process.
Best, R
On Wed, May 3, 2017 at 11:16 PM, Faré fahree@gmail.com wrote:
On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence llmjjmll@gmail.com wrote:
The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken.
Upgrading works. Central-registry works. Central-registry is not preserved by upgrading. And doesn't need to be, because central-registry is something you insert into a special configuration file that needs to first load the proper asdf, anyway. Whoever writes that configuration file by hypothesis knows where all the software is located. It just doesn't make sense to load the wrong asdf then configure your central-registry only then to load yet another asdf. If you do things like that you deserve to lose.
I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
That doesn't make sense, and asdf cannot guess what ancient version of asdf was moved aside. Once again, it used to try much harder to upgrade from 2.26 on sbcl and several other implementations, but that got too unwieldy to support, for no good reason.
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable).
That part is totally reasonable indeed, and works perfectly.
Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Does not compute. Neither LispWorks PE nor CLISP release from 2010 provides ASDF. Quicklisp will then load its own ASDF, but that entails no upgrade. If you want a more recent ASDF on top of that provided by Quicklisp, you are going to lose anyway — instead overwrite Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make your implementation provide ASDF despite it not being provided out of the box.
If you insist on such a weird upgrade, many things may go wrong beside the *central-registry*. Yet even then you shouldn't be using the *central-registry* to begin with. Use the source-registry.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
Upgrading is not broken. Your use pattern is broken. Don't initialize the central registry after you load the wrong asdf then load the correct one then expect things to work.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
It's completely unnatural and backwards to load a wrong asdf, initialize it, then upgrade it. Please configure *after* you upgrade (and yes, *if* the configuration is for ASDF to find ASDF itself, you may have to configure that part twice; or just skip the part about loading the wrong asdf). And try using install-asdf.lisp where applicable.
Finally, please don't use the central-registry for cases like these. Use the source-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only a fool tests the depth of the water with both feet. — African proverb
OK I now see the last bullet point in "Pitfalls...", thanks. I had searched the manual for "central-registry", which isn't mentioned there directly.
This part could be improved: "startup scripts should load, configure and upgrade ASDF among the very first things they do". Let's not tempt the user to configure before upgrading!
Another bullet says, "Now that all implementations provide ASDF 3.1 or later...", but that's not true. LispWorks PE does not. Yes, it's LW version 6.1.1. And CLISP does not, though I understand that situation is somewhat forlorn.
Here's the reason all this is immensely unexpected. If upgrading on the fly requires reconfiguration, then I wonder what the purpose of upgrading on the fly is supposed to be. Now that I understand that caveat, I don't know why the on-the-fly feature exists. If one already has such control over the configuration, then one wouldn't have loaded ASDF2 in the first place The whole purpose of on-the-fly upgrades, it seemed to me, was to handle the case where such control has passed. For example the situation I mentioned: the user has the bog standard Quicklisp setup in their init file and, after running an image for some time, needs to load an ASDF3-only library.
I suppose the root problem here is LispWorks PE. Perhaps it should be put into the same category as CLISP. On the other hand I place high value on having things just work, no matter where the user is coming from. If that's not possible or too difficult or too annoying then so be it. It seemed reasonable to try.
Best, lmj
On Thu, May 4, 2017 at 11:30 AM, Robert Goldman rpgoldman@sift.net wrote:
Actually, I find that there already WAS a discussion of just this issue in the ASDF manual. See the node "Pitfalls of the upgrade to ASDF 3." I have added another FAQ node to try to make this information easier to find, based on what went wrong. Review welcome.
Cheers, r
On 5/4/17 May 4 -9:59 AM, Robert Goldman wrote:
On 5/4/17 May 4 -8:54 AM, James M. Lawrence wrote:
LispWorks PE bundles an old asdf, which is loaded with (require "asdf").
Is this because LWPE is still LW 6 instead of 7?
CLISP optionally bundles asdf -- (require "asdf") -- and I would expect some Linux distributions to have that configuration in the CLISP they supply. (require "asdf") also looks in directories (including the user home directory!) for asdf.lisp, so an old version could be unintentionally loaded. My real concern is LispWorks, though.
We can't really handle clisp effectively, because as far as releases are concerned, it's dead. I realize that the code repo is active, but releases aren't being made, which means the de facto standard is now something going on 7 years old. That's not the ASDF project's fault.
Maybe this wasn't clear enough, but my communications here are on behalf of users, not me. Many -- perhaps most, perhaps nearly all -- people use asdf only indirectly through Quicklisp. I am trying to help the poor end-user who has a borked system and doesn't understand what is wrong. I would like to prevent the borkedness from happening in the first place.
Most people initialize Quicklisp in their startup file. After using the lisp image for a while, they may wish to load a system and discover that the system requires asdf3. So they load asdf3. And then everything is borked. It may be difficult even for an experienced user to discover what is wrong, much less a casual user, and next to impossible for a newcomer.
In the manual I didn't see any of the caveats you mention about the central registry. It says that asdf can be upgraded on the fly, and that's what people will expect. They don't expect that upgrading will bork the lisp image for some reason unknown to them.
I will see if I can put in a FAQ about this. Look for something soon.
The quick and dirty workaround I mentioned is not something that would be part of any real code, just something a user could do to get things unborked again, that is, to enable Quicklisp to load again.
I don't want to use *central-registry*. I'm not advocating using *central-registry*. I don't use *centry-registry* myself, except indirectly through Quicklisp. I am not insisting on weird upgrades. All I want to do is fix problems that end-users encounter.
I'm not familiar with the guts of QL, but I thought QL didn't use central registry. I thought it used its own extension to the loading process.
Best, R
On Wed, May 3, 2017 at 11:16 PM, Faré fahree@gmail.com wrote:
On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence llmjjmll@gmail.com wrote:
The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken.
Upgrading works. Central-registry works. Central-registry is not preserved by upgrading. And doesn't need to be, because central-registry is something you insert into a special configuration file that needs to first load the proper asdf, anyway. Whoever writes that configuration file by hypothesis knows where all the software is located. It just doesn't make sense to load the wrong asdf then configure your central-registry only then to load yet another asdf. If you do things like that you deserve to lose.
I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
That doesn't make sense, and asdf cannot guess what ancient version of asdf was moved aside. Once again, it used to try much harder to upgrade from 2.26 on sbcl and several other implementations, but that got too unwieldy to support, for no good reason.
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable).
That part is totally reasonable indeed, and works perfectly.
Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Does not compute. Neither LispWorks PE nor CLISP release from 2010 provides ASDF. Quicklisp will then load its own ASDF, but that entails no upgrade. If you want a more recent ASDF on top of that provided by Quicklisp, you are going to lose anyway — instead overwrite Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make your implementation provide ASDF despite it not being provided out of the box.
If you insist on such a weird upgrade, many things may go wrong beside the *central-registry*. Yet even then you shouldn't be using the *central-registry* to begin with. Use the source-registry.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
Upgrading is not broken. Your use pattern is broken. Don't initialize the central registry after you load the wrong asdf then load the correct one then expect things to work.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
It's completely unnatural and backwards to load a wrong asdf, initialize it, then upgrade it. Please configure *after* you upgrade (and yes, *if* the configuration is for ASDF to find ASDF itself, you may have to configure that part twice; or just skip the part about loading the wrong asdf). And try using install-asdf.lisp where applicable.
Finally, please don't use the central-registry for cases like these. Use the source-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only a fool tests the depth of the water with both feet. — African proverb
The main thing is: do NOT use ASDF 2. Please address your complaints to Xach for the disservice of providing it.
On Thu, May 4, 2017, 13:01 James M. Lawrence llmjjmll@gmail.com wrote:
OK I now see the last bullet point in "Pitfalls...", thanks. I had searched the manual for "central-registry", which isn't mentioned there directly.
This part could be improved: "startup scripts should load, configure and upgrade ASDF among the very first things they do". Let's not tempt the user to configure before upgrading!
Another bullet says, "Now that all implementations provide ASDF 3.1 or later...", but that's not true. LispWorks PE does not. Yes, it's LW version 6.1.1. And CLISP does not, though I understand that situation is somewhat forlorn.
Here's the reason all this is immensely unexpected. If upgrading on the fly requires reconfiguration, then I wonder what the purpose of upgrading on the fly is supposed to be. Now that I understand that caveat, I don't know why the on-the-fly feature exists. If one already has such control over the configuration, then one wouldn't have loaded ASDF2 in the first place The whole purpose of on-the-fly upgrades, it seemed to me, was to handle the case where such control has passed. For example the situation I mentioned: the user has the bog standard Quicklisp setup in their init file and, after running an image for some time, needs to load an ASDF3-only library.
I suppose the root problem here is LispWorks PE. Perhaps it should be put into the same category as CLISP. On the other hand I place high value on having things just work, no matter where the user is coming from. If that's not possible or too difficult or too annoying then so be it. It seemed reasonable to try.
Best, lmj
On Thu, May 4, 2017 at 11:30 AM, Robert Goldman rpgoldman@sift.net wrote:
Actually, I find that there already WAS a discussion of just this issue in the ASDF manual. See the node "Pitfalls of the upgrade to ASDF 3." I have added another FAQ node to try to make this information easier to find, based on what went wrong. Review welcome.
Cheers, r
On 5/4/17 May 4 -9:59 AM, Robert Goldman wrote:
On 5/4/17 May 4 -8:54 AM, James M. Lawrence wrote:
LispWorks PE bundles an old asdf, which is loaded with (require
"asdf").
Is this because LWPE is still LW 6 instead of 7?
CLISP optionally bundles asdf -- (require "asdf") -- and I would expect some Linux distributions to have that configuration in the CLISP they supply. (require "asdf") also looks in directories (including the user home directory!) for asdf.lisp, so an old version could be unintentionally loaded. My real concern is LispWorks, though.
We can't really handle clisp effectively, because as far as releases are concerned, it's dead. I realize that the code repo is active, but releases aren't being made, which means the de facto standard is now something going on 7 years old. That's not the ASDF project's fault.
Maybe this wasn't clear enough, but my communications here are on behalf of users, not me. Many -- perhaps most, perhaps nearly all -- people use asdf only indirectly through Quicklisp. I am trying to help the poor end-user who has a borked system and doesn't understand what is wrong. I would like to prevent the borkedness from happening in the first place.
Most people initialize Quicklisp in their startup file. After using the lisp image for a while, they may wish to load a system and discover that the system requires asdf3. So they load asdf3. And then everything is borked. It may be difficult even for an experienced user to discover what is wrong, much less a casual user, and next to impossible for a newcomer.
In the manual I didn't see any of the caveats you mention about the central registry. It says that asdf can be upgraded on the fly, and that's what people will expect. They don't expect that upgrading will bork the lisp image for some reason unknown to them.
I will see if I can put in a FAQ about this. Look for something soon.
The quick and dirty workaround I mentioned is not something that would be part of any real code, just something a user could do to get things unborked again, that is, to enable Quicklisp to load again.
I don't want to use *central-registry*. I'm not advocating using *central-registry*. I don't use *centry-registry* myself, except indirectly through Quicklisp. I am not insisting on weird upgrades. All I want to do is fix problems that end-users encounter.
I'm not familiar with the guts of QL, but I thought QL didn't use central registry. I thought it used its own extension to the loading process.
Best, R
On Wed, May 3, 2017 at 11:16 PM, Faré fahree@gmail.com wrote:
On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence llmjjmll@gmail.com
wrote:
The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or ASDF 3 on the fly", and "asdf:*central-registry* is not recommended anymore, though we will continue to support it". From the documentation it is not immediately clear that upgrading is purposefully broken.
Upgrading works. Central-registry works. Central-registry is not preserved by upgrading. And doesn't need to be, because central-registry is something you insert into a special configuration file that needs to first load the proper asdf, anyway. Whoever writes that configuration file by hypothesis knows where all the software is located. It just doesn't make sense to load the wrong asdf then configure your central-registry only then to load yet another asdf. If you do things like that you deserve to lose.
I suppose a quick and dirty workaround would be something like (setf asdf:*central-registry* asdf-2.26:*central-registry*).
That doesn't make sense, and asdf cannot guess what ancient version of asdf was moved aside. Once again, it used to try much harder to upgrade from 2.26 on sbcl and several other implementations, but that got too unwieldy to support, for no good reason.
Quicklisp's behavior of using the asdf version bundled with the implementation, if it exists, seems reasonable, at least at face value. After all, that's the version the vendors tested, and it may already be part of the image (or speedily loadable).
That part is totally reasonable indeed, and works perfectly.
Even if Quicklisp includes asdf-3.1.7, it would still try to load the bundled version first, so things would still be broken on LispWorks PE and CLISP.
Does not compute. Neither LispWorks PE nor CLISP release from 2010 provides ASDF. Quicklisp will then load its own ASDF, but that entails no upgrade. If you want a more recent ASDF on top of that provided by Quicklisp, you are going to lose anyway — instead overwrite Quicklisp's asdf.lisp with the recent one, or convince Xach to upgrade Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to make your implementation provide ASDF despite it not being provided out of the box.
If you insist on such a weird upgrade, many things may go wrong beside the *central-registry*. Yet even then you shouldn't be using the *central-registry* to begin with. Use the source-registry.
Therefore the real question is whether people should load the asdf bundled with the implementation, either on their own or through Quicklisp. If upgrading wasn't broken, things would just work and we wouldn't have to debate that question.
Upgrading is not broken. Your use pattern is broken. Don't initialize the central registry after you load the wrong asdf then load the correct one then expect things to work.
How about preserving *central-registry* when upgrading? That seems completely natural and expected to me, even apart from the fact that it happens to solve the problem at hand.
It's completely unnatural and backwards to load a wrong asdf, initialize it, then upgrade it. Please configure *after* you upgrade (and yes, *if* the configuration is for ASDF to find ASDF itself, you may have to configure that part twice; or just skip the part about loading the wrong asdf). And try using install-asdf.lisp where applicable.
Finally, please don't use the central-registry for cases like these. Use the source-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
Only a fool tests the depth of the water with both feet. — African
proverb
Also, do NOT use LispWorks PE for any serious development. It is only meant as a technology demonstration platform. Please complain to LispWorks if you want their personal edition to be more usable (including providing a recent asdf).
And if your clisp fails to include a recent asdf, complain to your software distribution so they grab a recent hg snapshot rather than a 2010 tarball.
-#f
On Thu, May 4, 2017, 13:13 Faré fahree@gmail.com wrote:
The main thing is: do NOT use ASDF 2. Please address your complaints to Xach for the disservice of providing it.
On Thu, May 4, 2017, 13:01 James M. Lawrence llmjjmll@gmail.com wrote:
OK I now see the last bullet point in "Pitfalls...", thanks. I had searched the manual for "central-registry", which isn't mentioned there directly.
This part could be improved: "startup scripts should load, configure and upgrade ASDF among the very first things they do". Let's not tempt the user to configure before upgrading!
Another bullet says, "Now that all implementations provide ASDF 3.1 or later...", but that's not true. LispWorks PE does not. Yes, it's LW version 6.1.1. And CLISP does not, though I understand that situation is somewhat forlorn.
Here's the reason all this is immensely unexpected. If upgrading on the fly requires reconfiguration, then I wonder what the purpose of upgrading on the fly is supposed to be. Now that I understand that caveat, I don't know why the on-the-fly feature exists. If one already has such control over the configuration, then one wouldn't have loaded ASDF2 in the first place The whole purpose of on-the-fly upgrades, it seemed to me, was to handle the case where such control has passed. For example the situation I mentioned: the user has the bog standard Quicklisp setup in their init file and, after running an image for some time, needs to load an ASDF3-only library.
I suppose the root problem here is LispWorks PE. Perhaps it should be put into the same category as CLISP. On the other hand I place high value on having things just work, no matter where the user is coming from. If that's not possible or too difficult or too annoying then so be it. It seemed reasonable to try.
Best, lmj
On Thu, May 4, 2017 at 11:30 AM, Robert Goldman rpgoldman@sift.net wrote:
Actually, I find that there already WAS a discussion of just this issue in the ASDF manual. See the node "Pitfalls of the upgrade to ASDF 3." I have added another FAQ node to try to make this information easier to find, based on what went wrong. Review welcome.
Cheers, r
On 5/4/17 May 4 -9:59 AM, Robert Goldman wrote:
On 5/4/17 May 4 -8:54 AM, James M. Lawrence wrote:
LispWorks PE bundles an old asdf, which is loaded with (require
"asdf").
Is this because LWPE is still LW 6 instead of 7?
CLISP optionally bundles asdf -- (require "asdf") -- and I would expect some Linux distributions to have that configuration in the CLISP they supply. (require "asdf") also looks in directories (including the user home directory!) for asdf.lisp, so an old version could be unintentionally loaded. My real concern is LispWorks, though.
We can't really handle clisp effectively, because as far as releases
are
concerned, it's dead. I realize that the code repo is active, but releases aren't being made, which means the de facto standard is now something going on 7 years old. That's not the ASDF project's fault.
Maybe this wasn't clear enough, but my communications here are on behalf of users, not me. Many -- perhaps most, perhaps nearly all -- people use asdf only indirectly through Quicklisp. I am trying to help the poor end-user who has a borked system and doesn't understand what is wrong. I would like to prevent the borkedness from happening in the first place.
Most people initialize Quicklisp in their startup file. After using the lisp image for a while, they may wish to load a system and discover that the system requires asdf3. So they load asdf3. And then everything is borked. It may be difficult even for an experienced user to discover what is wrong, much less a casual user, and next to impossible for a newcomer.
In the manual I didn't see any of the caveats you mention about the central registry. It says that asdf can be upgraded on the fly, and that's what people will expect. They don't expect that upgrading will bork the lisp image for some reason unknown to them.
I will see if I can put in a FAQ about this. Look for something soon.
The quick and dirty workaround I mentioned is not something that would be part of any real code, just something a user could do to get things unborked again, that is, to enable Quicklisp to load again.
I don't want to use *central-registry*. I'm not advocating using *central-registry*. I don't use *centry-registry* myself, except indirectly through Quicklisp. I am not insisting on weird upgrades. All I want to do is fix problems that end-users encounter.
I'm not familiar with the guts of QL, but I thought QL didn't use central registry. I thought it used its own extension to the loading process.
Best, R
On Wed, May 3, 2017 at 11:16 PM, Faré fahree@gmail.com wrote:
On Wed, May 3, 2017 at 7:10 PM, James M. Lawrence <
llmjjmll@gmail.com> wrote:
> The manual says "it is possible to upgrade from ASDF 1 to ASDF 2 or > ASDF 3 on the fly", and "asdf:*central-registry* is not recommended > anymore, though we will continue to support it". From the > documentation it is not immediately clear that upgrading is > purposefully broken. > Upgrading works. Central-registry works. Central-registry is not preserved by upgrading. And doesn't need to be, because central-registry is something you insert into a special configuration file that needs to first load the proper asdf, anyway. Whoever writes that configuration file by hypothesis knows where all the software is located. It just doesn't make sense to load the wrong asdf then configure your central-registry only then to load yet another asdf.
If
you do things like that you deserve to lose.
> I suppose a quick and dirty workaround would be > something like (setf asdf:*central-registry* > asdf-2.26:*central-registry*). That doesn't make sense, and asdf cannot guess what ancient version
of
asdf was moved aside. Once again, it used to try much harder to upgrade from 2.26 on sbcl and several other implementations, but that got too unwieldy to support, for no good reason.
> Quicklisp's behavior of using the asdf version bundled with the > implementation, if it exists, seems reasonable, at least at face > value. After all, that's the version the vendors tested, and it may > already be part of the image (or speedily loadable). That part is totally reasonable indeed, and works perfectly.
> Even if Quicklisp > includes asdf-3.1.7, it would still try to load the bundled version > first, so things would still be broken on LispWorks PE and CLISP. > Does not compute. Neither LispWorks PE nor CLISP release from 2010 provides ASDF. Quicklisp will then load its own ASDF, but that
entails
no upgrade. If you want a more recent ASDF on top of that provided by Quicklisp, you are going to lose anyway — instead overwrite Quicklisp's asdf.lisp with the recent one, or convince Xach to
upgrade
Quicklisp's ASDF to 3.1.7. Or use asdf/tools/install-asdf.lisp to
make
your implementation provide ASDF despite it not being provided out of the box.
If you insist on such a weird upgrade, many things may go wrong
beside
the *central-registry*. Yet even then you shouldn't be using the *central-registry* to begin with. Use the source-registry.
> Therefore the real question is whether people should load the asdf > bundled with the implementation, either on their own or through > Quicklisp. If upgrading wasn't broken, things would just work and we > wouldn't have to debate that question. > Upgrading is not broken. Your use pattern is broken. Don't initialize the central registry after you load the wrong asdf then load the correct one then expect things to work.
> How about preserving *central-registry* when upgrading? That seems > completely natural and expected to me, even apart from the fact that > it happens to solve the problem at hand. > It's completely unnatural and backwards to load a wrong asdf, initialize it, then upgrade it. Please configure *after* you upgrade (and yes, *if* the configuration is for ASDF to find ASDF itself, you may have to configure that part twice; or just skip the part about loading the wrong asdf). And try using install-asdf.lisp where applicable.
Finally, please don't use the central-registry for cases like these. Use the source-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
Only a fool tests the depth of the water with both feet. — African
proverb
The main thing is: do NOT use ASDF 2. Please address your complaints to Xach for the disservice of providing it.
Fare, do try to read more thoroughly what you're replying to. The old ASDF here is the one bundled with LispWorks PE, not the one in Quicklisp. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
My understanding is that LispWorks PE does NOT provide any version of ASDF whatsoever, that Quicklisp then provides the less-than-useful ASDF 2.26, and that the user tries to load an ASDF 3 on top of that. Which can't work.
On Thu, May 4, 2017, 13:20 Stelian Ionescu sionescu@cddr.org wrote:
The main thing is: do NOT use ASDF 2. Please address your complaints to Xach for the disservice of providing it.
Fare, do try to read more thoroughly what you're replying to. The old ASDF here is the one bundled with LispWorks PE, not the one in Quicklisp.
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
My apologies if the misunderstanding was mine. I think there's a great need for an implementation manager that forces its own ASDF, among other things.In my smalll CL implementation .rc framework I wrote, I always load a pinned ASDF, completely ignoring the host ASDF or the one in Quicklisp - and also eschewing the ASDF upgrade mechanism. I found that it worked much better and never broke in the last 4-5 years since.
My understanding is that LispWorks PE does NOT provide any version of ASDF whatsoever, that Quicklisp then provides the less-than-useful ASDF 2.26, and that the user tries to load an ASDF 3 on top of that. Which can't work.> On Thu, May 4, 2017, 13:20 Stelian Ionescu sionescu@cddr.org wrote:>>
The main thing is: do NOT use ASDF 2. Please address your complaints to Xach for the disservice of providing it.>>
Fare, do try to read more thoroughly what you're replying to. The old ASDF here is the one bundled with LispWorks PE, not the one in Quicklisp.>> -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
As I said, LispWorks PE provides an old ASDF. To verify this,
* download LispWorks Personal Edition * launch it * (require "asdf") * (asdf:asdf-version)
Again, I am writing on behalf of users, not myself personally. I don't use LispWorks PE or any LispWorks version for development. Others use LispWorks PE. Some do so to evaluate not only LispWorks but Common Lisp as a language. It seemed reasonable to prevent them from getting into a borked state, if possible (and not too difficult or annoying).
On Thu, May 4, 2017 at 1:35 PM, Faré fahree@gmail.com wrote:
My understanding is that LispWorks PE does NOT provide any version of ASDF whatsoever, that Quicklisp then provides the less-than-useful ASDF 2.26, and that the user tries to load an ASDF 3 on top of that. Which can't work.
On Thu, May 4, 2017, 13:20 Stelian Ionescu sionescu@cddr.org wrote:
The main thing is: do NOT use ASDF 2. Please address your complaints to Xach for the disservice of providing it.
Fare, do try to read more thoroughly what you're replying to. The old ASDF here is the one bundled with LispWorks PE, not the one in Quicklisp.
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
On 5/4/17 May 4 -1:17 PM, James M. Lawrence wrote:
As I said, LispWorks PE provides an old ASDF. To verify this,
- download LispWorks Personal Edition
- launch it
- (require "asdf")
- (asdf:asdf-version)
Again, I am writing on behalf of users, not myself personally. I don't use LispWorks PE or any LispWorks version for development. Others use LispWorks PE. Some do so to evaluate not only LispWorks but Common Lisp as a language. It seemed reasonable to prevent them from getting into a borked state, if possible (and not too difficult or annoying).
I'm not sure what is the proper solution. Should we detect this kind of condition and raise an error if ASDF is not reconfigured after an upgrade?
R
On Thu, May 4, 2017 at 1:35 PM, Faré fahree@gmail.com wrote:
My understanding is that LispWorks PE does NOT provide any version of ASDF whatsoever, that Quicklisp then provides the less-than-useful ASDF 2.26, and that the user tries to load an ASDF 3 on top of that. Which can't work.
On Thu, May 4, 2017, 13:20 Stelian Ionescu sionescu@cddr.org wrote:
The main thing is: do NOT use ASDF 2. Please address your complaints to Xach for the disservice of providing it.
Fare, do try to read more thoroughly what you're replying to. The old ASDF here is the one bundled with LispWorks PE, not the one in Quicklisp.
-- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
On Thu, May 4, 2017 at 2:35 PM, Robert Goldman rpgoldman@sift.net wrote:
On 5/4/17 May 4 -1:17 PM, James M. Lawrence wrote:
As I said, LispWorks PE provides an old ASDF. To verify this,
- download LispWorks Personal Edition
- launch it
- (require "asdf")
- (asdf:asdf-version)
Again, I am writing on behalf of users, not myself personally. I don't use LispWorks PE or any LispWorks version for development. Others use LispWorks PE. Some do so to evaluate not only LispWorks but Common Lisp as a language. It seemed reasonable to prevent them from getting into a borked state, if possible (and not too difficult or annoying).
I'm not sure what is the proper solution. Should we detect this kind of condition and raise an error if ASDF is not reconfigured after an upgrade?
Indeed it sports ASDF 2.019.
The proper solution is to tell the user to use the asdf/tools/install-asdf.lisp script to replace that ancient ASDF with a more recent one. See manual section "Replacing your implementation's ASDF".
Alternatively, tell Quicklisp to not use ASDF 2.26 but ASDF 3.1.7.
You can also lobby LispWorks so they make an update to their personal edition.
In any case, friends don't let novices use the central-registry.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What someone says often fails to inform us about the (rest of the) world, but always informs us about the utterer.
On 5/4/17 May 4 -2:34 PM, Faré wrote:
In any case, friends don't let novices use the central-registry.
The counter-argument to this is that *central-registry* is much more conceptually simple and easier to debug than the new configuration framework.
If I write code that populates my *central-registry*, I can trace that code and I can look at the *central-registry*. It's as easy as (PPRINT asdf:*central-registry*)
At least in the past, if you added a new asd file to a directory in the *central-registry*, then ASDF would find it. If you add it to somewhere covered by the new configuration framework, it won't, will it? because the new configuration framework eagerly searches for asd files.
(Admittedly, *central-registry* scales poorly for very large programs).
For the new configuration arrangements, things are much more difficult for a novice to understand. The actual configuration is held in tables that are opaque (yes, they can be dumped, but it's non-trivial and not discussed in the manual).
Much of the configuration code cannot be traced because key operations take place in side-effecting anonymous lambdas.
Finally, if you configure with configuration files in your XDG config directories, there's not even a chance to trace, because by the time you could set up a trace, the configuration's been loaded.
In short, while the new configuration structure is better in many ways, that's only if it works. If something odd happens, it leaves you pretty flat. If you have a small set of libraries in use, *central-registry* can be a lot easier to deal with.
I've been meaning to provide more debugging to the configuration process, but just keeping up with everyone else's mods to ASDF has eaten all the ASDF time I have for now.
On Thu, May 4, 2017 at 4:52 PM, Robert Goldman rpgoldman@sift.net wrote:
On 5/4/17 May 4 -2:34 PM, Faré wrote:
In any case, friends don't let novices use the central-registry.
The counter-argument to this is that *central-registry* is much more conceptually simple and easier to debug than the new configuration framework.
The problem with central-registry is a bootstrap problem. It requires everyone to be a system administrator and edit configuration files.
If I write code that populates my *central-registry*, I can trace that code and I can look at the *central-registry*. It's as easy as (PPRINT asdf:*central-registry*)
But to write that code, you must be an expert who can intercept CL configuration and be productive in that bootstrap environment.
But then you can just as well call (asdf:initialize-source-registry) and inspect the contents of asdf::*source-registry* or what is returned by (asdf/source-registry:flatten-source-registry), or trace functions in the source-registry. But mostly you don't need to, because it just works out of the box without configuration.
At least in the past, if you added a new asd file to a directory in the *central-registry*, then ASDF would find it. If you add it to somewhere covered by the new configuration framework, it won't, will it? because the new configuration framework eagerly searches for asd files.
(Admittedly, *central-registry* scales poorly for very large programs).
You may indeed need to re-run (asdf:initialize-source-registry) after you install or remove .asd files. That is documented, and a small price to pay for scaling the registry much beyond what the *central-registry* will crumble with.
For the new configuration arrangements, things are much more difficult for a novice to understand. The actual configuration is held in tables that are opaque (yes, they can be dumped, but it's non-trivial and not discussed in the manual).
A novice does not need to understand it. If you follow the instructions, such as "install your software under ~/common-lisp/", then it Just Works™.
Experts can dump tables. I hesitated about replicating alexandria:hash-table-alist in uiop, to make it easy to dump some tables. Decided against it in the end, but if you believe novices should be able to dump those tables, that's something to consider.
Much of the configuration code cannot be traced because key operations take place in side-effecting anonymous lambdas.
That code is not the most readable, but what it does it well documented, well debugged, and it's easy to look at the result, change something and look at the result again.
Finally, if you configure with configuration files in your XDG config directories, there's not even a chance to trace, because by the time you could set up a trace, the configuration's been loaded.
It doesn't actually make tracing harder than usual. Tracing asdf configuration is a normally hard bootstrap issue.
In short, while the new configuration structure is better in many ways, that's only if it works. If something odd happens, it leaves you pretty flat. If you have a small set of libraries in use, *central-registry* can be a lot easier to deal with.
On the other hand, the source-registry often "just works" out of the box, or requires a one-liner to configure. The *central-registry* is cognitively much heavier, especially so on novices.
I've been meaning to provide more debugging to the configuration process, but just keeping up with everyone else's mods to ASDF has eaten all the ASDF time I have for now.
That would be a good thing.
When you have time, a post hoc review of the changes from 3.2.0 to 3.2.1 would be nice. Also a review of the plan branch, and some opinions on what to do about syntax-control and when.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Conservative, n.: One who admires radicals centuries after they're dead. — Leo C. Rosten
On 5/4/17 May 4 -4:23 PM, Faré wrote:
On Thu, May 4, 2017 at 4:52 PM, Robert Goldman rpgoldman@sift.net wrote:
On 5/4/17 May 4 -2:34 PM, Faré wrote:
In any case, friends don't let novices use the central-registry.
The counter-argument to this is that *central-registry* is much more conceptually simple and easier to debug than the new configuration framework.
The problem with central-registry is a bootstrap problem. It requires everyone to be a system administrator and edit configuration files.
I don't follow this claim. All central registry requires is that you run some lisp code, generally in your lisp-init file.
If I write code that populates my *central-registry*, I can trace that code and I can look at the *central-registry*. It's as easy as (PPRINT asdf:*central-registry*)
But to write that code, you must be an expert who can intercept CL configuration and be productive in that bootstrap environment.
Again, I don't get this. We have one piece of lisp code that does a simple depth-first search and jams things into ASDF:*CENTRAL-REGISTRY*. People stuff that into their lisp-init files and that's it.
You are right, of course, that we can do that with INITIALIZE-SOURCE-REGISTRY, too, but I don't understand your claims about needing root privilege or needing to understand the bootstrap environment any more than just understanding how to write a lisp-init file.
But then you can just as well call (asdf:initialize-source-registry) and inspect the contents of asdf::*source-registry* or what is returned by (asdf/source-registry:flatten-source-registry), or trace functions in the source-registry. But mostly you don't need to, because it just works out of the box without configuration.
At least in the past, if you added a new asd file to a directory in the *central-registry*, then ASDF would find it. If you add it to somewhere covered by the new configuration framework, it won't, will it? because the new configuration framework eagerly searches for asd files.
(Admittedly, *central-registry* scales poorly for very large programs).
You may indeed need to re-run (asdf:initialize-source-registry) after you install or remove .asd files. That is documented, and a small price to pay for scaling the registry much beyond what the *central-registry* will crumble with.
It's a small price to pay IF YOU NEED TO SCALE THE REGISTRY BEYOND WHAT *CENTRAL-REGISTRY* WILL CRUMBLE WITH. Otherwise, it's an annoyance created by an optimization you don't need.
The largest project I'm working on now has 212 entries in ASDF:*CENTRAL-REGISTRY*. Could be zippier, but that certainly doesn't cause the list representation to crumble.
I get it that the new structure scales better, but it is a tradeoff, and some users will find that it's not a tradeoff that works for them.
For the new configuration arrangements, things are much more difficult for a novice to understand. The actual configuration is held in tables that are opaque (yes, they can be dumped, but it's non-trivial and not discussed in the manual).
A novice does not need to understand it. If you follow the instructions, such as "install your software under ~/common-lisp/", then it Just Works™.
That doesn't work if you work on multiple different systems that have different source repositories. I typically work on at least three different CL projects at once, which means a single configuration is a non-starter for me.
Experts can dump tables. I hesitated about replicating alexandria:hash-table-alist in uiop, to make it easy to dump some tables. Decided against it in the end, but if you believe novices should be able to dump those tables, that's something to consider.
Yes, I do believe that novices should be able to dump those tables, because I have seen novices make mistakes (e.g., having both lisp code configuration and a .conf file configuration -- the former being added after the latter was forgotten), and just be completely confused and lost.
But in addition to dumping the tables, everyone must be able to figure out where the table entries came from. That's why something like tracing is so important. Again, if anyone, including a novice, gets their configuration messed up -- and, indeed, novices are very likely to, because they often just cargo-cult configs from others -- they need to be able to see where that configuration comes from and how to fix it.
The current "there's more than one way to do it" configuration process means that this is especially important, because we can no longer simply look in our lisp initialization to figure out why things have gone up the spout. Instead, we have to check hidden configuration directories, environment variables, lisp code, etc.
Much of the configuration code cannot be traced because key operations take place in side-effecting anonymous lambdas.
That code is not the most readable, but what it does it well documented, well debugged, and it's easy to look at the result, change something and look at the result again.
Only if you know where the configuration was that needs to be changed. I have definitely seen people who have configurations slopped all over the place, some forgotten, and had to try to help them debug.
Finally, if you configure with configuration files in your XDG config directories, there's not even a chance to trace, because by the time you could set up a trace, the configuration's been loaded.
It doesn't actually make tracing harder than usual. Tracing asdf configuration is a normally hard bootstrap issue.
Not if the configuration is in your lisp code it isn't. Only when we added the configuration files.
In short, while the new configuration structure is better in many ways, that's only if it works. If something odd happens, it leaves you pretty flat. If you have a small set of libraries in use, *central-registry* can be a lot easier to deal with.
On the other hand, the source-registry often "just works" out of the box, or requires a one-liner to configure. The *central-registry* is cognitively much heavier, especially so on novices.
My philosophy is to assume that code will always break and then consider how people can recover from that. So yes, I agree, ASDF now typically just works, but we haven't left users with much support when it doesn't.
I've been meaning to provide more debugging to the configuration process, but just keeping up with everyone else's mods to ASDF has eaten all the ASDF time I have for now.
That would be a good thing.
When you have time, a post hoc review of the changes from 3.2.0 to 3.2.1 would be nice. Also a review of the plan branch, and some opinions on what to do about syntax-control and when.
Will do. I'm just nudging up from half time, though, so I'm moving slowly. And maybe I need to prioritize something I want to do (the debugging utils) over chores, or I'm just going to end up hating to work on ASDF....
Please note that I don't think what you did was bad, I just think that it can on occasion leave people flat, and I would like to work to help them when that happens.
best, r
The problem with central-registry is a bootstrap problem. It requires everyone to be a system administrator and edit configuration files.
I don't follow this claim. All central registry requires is that you run some lisp code, generally in your lisp-init file.
Yes, and that's what I mean by "system administrator": you need to write code in configuration files. Something that end-users shouldn't have to do.
With ASDF 3.1's source-registry, end-users don't have to edit anything, and it will just work: just put your code under ~/common-lisp/ — or they can add one line worth of configuration per non-default source location they want to use.
I wanted to make ASDF suitable for writing code deployed to end-users. Now it is.
We have one piece of lisp code that does a simple depth-first search and jams things into ASDF:*CENTRAL-REGISTRY*. People stuff that into their lisp-init files and that's it.
Writing that code is nothing for an expert like you, but a huge hurdle for novices. Copy/pasting it without understanding it is also full of dangers.
You are right, of course, that we can do that with INITIALIZE-SOURCE-REGISTRY, too, but I don't understand your claims about needing root privilege or needing to understand the bootstrap environment any more than just understanding how to write a lisp-init file.
It's not about root privilege, it's about being a power user who has deep understanding of configuration and your Lisp application's bootstrap process.
You may indeed need to re-run (asdf:initialize-source-registry) after you install or remove .asd files. That is documented, and a small price to pay for scaling the registry much beyond what the *central-registry* will crumble with.
It's a small price to pay IF YOU NEED TO SCALE THE REGISTRY BEYOND WHAT *CENTRAL-REGISTRY* WILL CRUMBLE WITH. Otherwise, it's an annoyance created by an optimization you don't need.
The largest project I'm working on now has 212 entries in ASDF:*CENTRAL-REGISTRY*. Could be zippier, but that certainly doesn't cause the list representation to crumble.
I get it that the new structure scales better, but it is a tradeoff, and some users will find that it's not a tradeoff that works for them.
Having 212 entries is one to two order of magnitude more than most people need.
I consider my home installation advanced, and it has all of 6 lines of configuration, counting lines for each of the :source-registry tag and the :inherit-configuration directive.
For QRes, I had the makefile export CL_SOURCE_REGISTRY with a single entry, and that was it.
A novice does not need to understand it. If you follow the instructions, such as "install your software under ~/common-lisp/", then it Just Works™.
That doesn't work if you work on multiple different systems that have different source repositories. I typically work on at least three different CL projects at once, which means a single configuration is a non-starter for me.
The easiest way is to export CL_SOURCE_REGISTRY from the shell, and/or equivalently have each project's Lisp init script use asdf:initialize-source-registry with a parameter. Unlike loading asdf from .sbclrc, that works without polluting a shared file for other environments.
Experts can dump tables. I hesitated about replicating alexandria:hash-table-alist in uiop, to make it easy to dump some tables. Decided against it in the end, but if you believe novices should be able to dump those tables, that's something to consider.
Yes, I do believe that novices should be able to dump those tables, because I have seen novices make mistakes (e.g., having both lisp code configuration and a .conf file configuration -- the former being added after the latter was forgotten), and just be completely confused and lost.
I recently helped Raymond Toy debug an issue he had with ASDF, and for diagnosing his problem, I asked him to tell me what that form returned:
(list asdf:*central-registry* (uiop:getenv "CL_SOURCE_REGISTRY") asdf::*source-registry-parameter* (mapcar (lambda (x) (list x (uiop:read-file-string x))) (mapcan 'uiop:directory-files (list (uiop:subpathname (user-homedir-pathname) ".config/common-lisp/source-registry.conf") (uiop:merge-pathnames* ".config/common-lisp/source-registry.conf.d/" (user-homedir-pathname))))) (loop :for a :in (asdf/source-registry::flatten-source-registry) :when (and (getf (cdr a) :recurse) (uiop:probe-file* (car a))) :append (uiop:while-collecting (c) (uiop:collect-sub*directories (car a) (lambda (d) (uiop:if-let ((f (uiop:probe-file* (uiop:subpathname d ".cl-source-registry.cache")))) (c f)) t) (constantly t) (constantly t)))))
[It turns out his problem was that he was trying to manually load .asd files that were not in any of his registries, and expecting it to work even though they themselves called other unregistered .asd files via :defsystem-depends-on. Don't do that.]
But in addition to dumping the tables, everyone must be able to figure out where the table entries came from. That's why something like tracing is so important. Again, if anyone, including a novice, gets their configuration messed up -- and, indeed, novices are very likely to, because they often just cargo-cult configs from others -- they need to be able to see where that configuration comes from and how to fix it.
I agree that the source-registry is less easy to debug than could be. Yet, I have never been contacted for misuse of it, but I have been contacted a lot for misuse of *central-registry* (though it has gotten much better since the missing trailing / became detected by asdf itself).
The current "there's more than one way to do it" configuration process means that this is especially important, because we can no longer simply look in our lisp initialization to figure out why things have gone up the spout. Instead, we have to check hidden configuration directories, environment variables, lisp code, etc.
That is true. And it gets only more complicated when Quicklisp introduces its own extensions. Yet in the end, that was the true power of ASDF's extensible system search design (thanks, Dan Barlow!): let people define their own system search facilities, and see which grows and survives.
That code is not the most readable, but what it does it well documented, well debugged, and it's easy to look at the result, change something and look at the result again.
Only if you know where the configuration was that needs to be changed. I have definitely seen people who have configurations slopped all over the place, some forgotten, and had to try to help them debug.
We probably can provide better diagnostic tools. At the same time, if you grow complex configurations, you're probably doing it wrong.
Finally, if you configure with configuration files in your XDG config directories, there's not even a chance to trace, because by the time you could set up a trace, the configuration's been loaded.
It doesn't actually make tracing harder than usual. Tracing asdf configuration is a normally hard bootstrap issue.
Not if the configuration is in your lisp code it isn't. Only when we added the configuration files.
OK, so it makes things slightly harder for the expert who uses SLIME, but much easier for the novice who doesn't use it yet. I believe this is a vast net win.
On the other hand, the source-registry often "just works" out of the box, or requires a one-liner to configure. The *central-registry* is cognitively much heavier, especially so on novices.
My philosophy is to assume that code will always break and then consider how people can recover from that. So yes, I agree, ASDF now typically just works, but we haven't left users with much support when it doesn't.
I agree we can offer better debugging support.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Truth comes as conqueror only to those who have lost the art of receiving it as friend. — Tagore
On Thu, May 4, 2017 at 2:35 PM, Robert Goldman rpgoldman@sift.net wrote:
On 5/4/17 May 4 -1:17 PM, James M. Lawrence wrote:
As I said, LispWorks PE provides an old ASDF. To verify this,
- download LispWorks Personal Edition
- launch it
- (require "asdf")
- (asdf:asdf-version)
Again, I am writing on behalf of users, not myself personally. I don't use LispWorks PE or any LispWorks version for development. Others use LispWorks PE. Some do so to evaluate not only LispWorks but Common Lisp as a language. It seemed reasonable to prevent them from getting into a borked state, if possible (and not too difficult or annoying).
I'm not sure what is the proper solution. Should we detect this kind of condition and raise an error if ASDF is not reconfigured after an upgrade?
R
If you have consideration for the end-user experience in mind, then you should emphasize, underline, asterisk, and caps-lock shout that install-asdf.lisp should be run before doing anything else. Given the circumstances, that seems like the best you can do.
Don't even suggest doing a live "upgrade", if you have consideration for end-users, since no user will expect an upgrade feature to purposefully bork things. That doesn't match what the word "upgrade" generally means. To the general end-user who adds the quicklisp init code to their init file and doesn't otherwise bother with asdf (I suspect this is the vast majority of users), it's just a way to break quickloading for some unknown reason. (And it's not clear that there is *any* practical use case for it -- see my previous message starting at "I don't know why the on-the-fly feature exists".)
Yes, I get that LispWorks shouldn't be bundling an old asdf. Yes, I get that Quicklisp shouldn't be bundling an old asdf. Yes, I get that Quicklisp shouldn't be using the central registry. Yes, I get that LispWorks PE is not for serious use. And so forth. I am addressing how the lisp ecosystem actually exists today, as opposed to how developers wish it to be. I am looking at the experience of end-users, not me personally.
On Thu, May 4, 2017 at 2:17 PM, James M. Lawrence llmjjmll@gmail.com wrote:
Again, I am writing on behalf of users, not myself personally. I don't use LispWorks PE or any LispWorks version for development. Others use LispWorks PE. Some do so to evaluate not only LispWorks but Common Lisp as a language. It seemed reasonable to prevent them from getting into a borked state, if possible (and not too difficult or annoying).
Using crippleware to evaluate Common Lisp as a language strikes me as a very bad idea. Do NOT let your friends, users, etc., do that.
Friends don't let friends use LispWorks PE.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You think minimum height restrictions make children taller? — Luke McCormick, regarding minimum wage restrictions
On Thu, May 4, 2017 at 1:01 PM, James M. Lawrence llmjjmll@gmail.com wrote:
This part could be improved: "startup scripts should load, configure and upgrade ASDF among the very first things they do". Let's not tempt the user to configure before upgrading!
This works perfectly with ASDF 3 or later.
The reason you have a problem is because you are using software well past its "best use before" date, that is thoroughly bitrotten.
Another bullet says, "Now that all implementations provide ASDF 3.1 or later...", but that's not true. LispWorks PE does not. Yes, it's LW version 6.1.1. And CLISP does not, though I understand that situation is somewhat forlorn.
I'll specify "all ***maintained*** implementations", i.e. having had a release since 2014. LispWorks PE is not a maintained implementation, it's a 5 years old demo from 2012. Don't expect much from it. If you are unhappy with it, please take irt to your friendly LispWorks representative, not to asdf-devel.
CLISP hasn't been released for 7 years. Still, the better software distributions (e.g. debian-based) use a recent hg checkout that does provide ASDF, or otherwise bundle a recent ASDF with it. (I see that NixOS uses the tarball; that's a mistake, I'll file a bug.) If that doesn't satisfy you, take it to the clisp mailing-list or file a bug against your favorite software distribution.
If you are hit by a bug in Quicklisp (that gives you an unusable ASDF 2.26), then complain to Zach, not to asdf-devel.
Your problem is not our problem. ASDF 2 is unsupported, except for upgrade, which itself is only supported if you follow the upgrade instructions in the manual. And even then, we recommend instead replacing your implementation-provided ASDF 2 with ASDF 3.
When you meet users who are experiencing known bugs with 5-year-old versions of your software, what do you tell them? Does your manual document a live upgrade procedure?
Here's the reason all this is immensely unexpected.
Any expectations founded on the premise of LispWorks PE are deeply flawed. Tell your users not to use 5-year old crippleware.
If upgrading on the fly requires reconfiguration, then I wonder what the purpose of upgrading on the fly is supposed to be. Now that I understand that caveat, I don't know why the on-the-fly feature exists. If one already has such control over the configuration, then one wouldn't have loaded ASDF2 in the first place The whole purpose of on-the-fly upgrades, it seemed to me, was to handle the case where such control has passed. For example the situation I mentioned: the user has the bog standard Quicklisp setup in their init file and, after running an image for some time, needs to load an ASDF3-only library.
Obviously, you have control over the configuration, since you are using the central-registry (which you shouldn't be using in the first place). It is logically impossible to use the central-registry without controlling the configuration. And since you do, then you can upgrade ASDF as recommended in the manual instead of whichever wrong way you're doing it. Live upgrade from ASDF 2 works, but only if you follow the instructions.
PS: Anton, would you have time to run cl-test-grid using ASDF 2.26, making sure that it is loaded before and instead of whatever the implementation provides, and not otherwise upgraded afterwards? That would be informative. At least CFFI and plenty systems that I have written or contributed to in the last two or three years depend on ASDF 3 (and more recently often 3.1), plus anything that depends on them.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Keynesians: see how much more Cuba has benefited from Sandy's desolation? How blessed is it with that great natural resource, Hurricanes!
-
Daniel Kochmański -
Faré -
James M. Lawrence -
Robert Goldman -
Stelian Ionescu