Dear Nikodemus,

Using quicklisp-installed libraries -- (ql:quickload "linedit"): [...] 4. (asdf:load-system :linedit)

Observe that Alexandria is compiled and loaded twice. Once as a dependency of CFFI-GROVEL, once as a dependency of Linedit.

TL;DR: (1) *If* you're going to have an asdf.asd in your source-registry, make sure it's at least 2.0.18.14. (2) Then, use (asdf:upgrade-asdf) *after* you load quicklisp, but *before* you (asdf:load-system "linedit").

(When quicklisp's asdf is upgraded to 2.018.14 or later, step (2) will hopefully not be necessary anymore, at least in this case.)

Full version:

I cannot reproduce your issue when I (ql:use-only-quicklisp-systems). However, I am did find and fix problems when I am upgrading quicklisp's asdf to a local asdf checkout.

Issues when upgrading asdf:

1- asdf:*system-definition-search-functions* is a defparameter, because a defvar would not have been backwards-compatible, but which cancels the changes done by quicklisp. Fixed in 2.018.14, where I use a defvar followed by an ad-hoc fixup form.

2- upgrading asdf loses the methods on e.g. perform. This is alright when you upgrade asdf on its own, with e.g. (asdf:upgrade-asdf) or (asdf:load-system :asdf) at the REPL, because upgrade-asdf invalidates existing systems with clear-systems, which will cause these systems to be reloaded and their methods re-defined. However, when asdf is upgraded as part of a chain of find-system's and load-system's (which is the case when osicat uses load-system to load cffi-grovel), things break down badly, as the systems that caused asdf to be upgraded are invalidated, but not reloaded before they are next used. Oops. 2.018.14 tries to be better in this case, and has a more forward-compatible protocol for upgrading, by trying to reload the systems being currently defined (which are being remembered to fix the previous infinite recursion bug you found in asdf using quicklisp back in may and fixed in 2.015.2), so that this problem will disappear in the future, but this protocol isn't active yet when you're upgrading *to* 2.018.14 from an earlier asdf. Therefore, the only safe way from quicklisp's asdf 2.017 is to use (asdf:upgrade-asdf) *after* you load quicklisp and *before* you try to load linedit.

3- 2.017.12 introduced a backwards incompatibility by modifying the signature of do-dep and do-one-dep without shadowing (with unintern) the previous versions, which causes further damage that prevents from seeing the effects described in 2. I assume you were ugprading ASDF from quicklisp's 2.017 to a local checkout of 2.017.12 or earlier. If this was not the case, then you may or may not be experiencing a different problem, one that I cannot reproduce with my current setup.

My, hot upgrade of the software doing the upgrade itself is hard to get right.

If problem persists, please contact me again on this list.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org ``why'' is always relative to a model of possible explanations. It is never an "absolute" question. Which is precisely what makes it meaningful.