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!