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