As usual, I must apologize because I *did* introduce a bug, albeit a subtle one. Looking at the diff between uiop 3.2.1 and uiop 3.3.0, I found that the one relevant change was... the swap of encoding between nil and t in stamp< I swapped it after checking that no one in quicklisp uses that function anyway... but it does matter to older versions of asdf, that use it, at which point it can cause confusion in corner cases where the encoding of nil and t matter -- which I suppose somehow includes the cases uncovered by Xach, in which a previously existing but invisible bug was exacerbated into becoming a larger issue. The problem is related to upgrading uiop without asdf, which is something that only Quicklisp does, at Xach's insistence (I would prefer if it included a recent ASDF, as with all other systems), and that I had failed to take into consideration. I suppose the right thing to do is to rename the stamp< function and its siblings into timestamp< or some such, so it doesn't clash with the previous semantics under the previous name. I'll work on that. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Corollaries to the Law of Bitur-Camember: The political process destroys the value of all known resources that are up for grabs. The socialist process of systematically denying legitimacy to property rights applies the political process universally and destroys the value of all available resources. On Fri, Oct 20, 2017 at 10:01 AM, Robert Goldman <rpgoldman@sift.info> wrote:

This is a better summary than I gave. To summarize, loading UIOP exposes an error that was always in the version of ASDF in QL/SBCL. It's not a new problem with UIOP or ASDF. I think the issue is exposed because UIOP is so high up in the dependency chain.

Best, r

On 20 Oct 2017, at 0:25, Faré wrote:

Dear Xach,

I saw your blog post: http://lispblog.xach.com/post/166534341423/uiop-330-problems

There are no comments on your blog, so I'll just clarify things on the asdf-devel list: * The situation you describe is not at all a problem specific to uiop 3.3.0, or any other version of uiop. uiop.asd hasn't changed since 3.2.0, and the "issue" already existed before, and exists when there is no uiop.asd available but only the builtin uiop. * The situation you describe, where some libraries are loaded multiple times, is a bug in ASDF, that was fixed in 3.3.0 --- actually, fixing this situation and other related situations was the very reason why I had to teach ASDF about build phases, which lead to the big refactoring done in 3.3.0. * All build systems have to either face the issue of build system extension, or put their head in the sand and do the wrong thing. At least ASDF 3.3.0 does the right thing now, whereas earlier versions put their head in the sand as far as that issue was concerned. (I also know that Bazel has a proper solution, though it involves using a non-extensible DSL for extensions). * At least in that case, the issue is not too bad: just some system recompiled, that will also cause more recompilation the next time, but don't cause an infinite loop, just a waste of CPU time.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In Italia i fascisti si dividono in due categorie: i fascisti e gli antifascisti. — Ennio Flaiano

On Fri, Oct 20, 2017 at 6:09 PM, Anton Vodonosov <avodonosov@yandex.ru> wrote:

Fare, what do you mean by "encoding" of nil and t?

In ASDF 3, the function stamp< compared to timestamps that are either real numbers or booleans, where booleans represent the infinities on the real line. In ASDF 2.27 to 3.2.1, NIL represents -infinity and T represents +infinity. In ASDF 3.3.0, NIL represents +infinity and T represents -infinity, which allows ASDF to directly use safe-file-write-date / get-file-stamp results without inversion of convention all over the place. Problem is: since stamp< is defined in UIOP and used in ASDF, a discrepancy between the two breaks ASDF. But one of the avowed purposes of UIOP is to be used outside (or without) ASDF, and it therefore is very important for UIOP to be backward compatible and not make such changes, *even* if no one but ASDF uses the function. A version of UIOP ahead of ASDF *is* a valid supported use case, that Quicklisp exercises for us. It was thus a bug for me to do that, and it was my big mistake to fail to think about the consequences properly. The solution I have in !87 (which is included in the candidate test branch I'd like you to test) is for ASDF 3.3.1 to rename stamp< to timestamp< (and so on for related functions) in uiop/utility, so that the new convention comes with new names. Thus, when an old ASDF 3.[012] loads a new and the new functions don't overwrite the old ones (as they do with UIOP 3.3.0), but go into new symbols, while the old symbols get uninterned but keep their bindings and the old ASDF keeps using that. https://gitlab.common-lisp.net/asdf/asdf/merge_requests/87 NB: this is still not as backward compatible as can be. Here is a contrived scenario where the solution requires to keep defining the old functions as well as the new ones: when you upgrade ASDF from 3.1.5 to 3.2.1, but upgrade UIOP to 3.3.1 instead of 3.2.1. I don't think this is a likely scenario or one we should support, and it won't normally happen with Quicklisp, since whatever asdf source directory you use, outside of Quicklisp, will include its own UIOP, that will take precedence over the one in Quicklisp. To upgrade ASDF to a relatively old version yet UIOP to a newer one, you would really have to do it on purpose, and then you would deserve to lose. I don't believe we ought to support this scenario, at which point we don't have to keep defining the old functions. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Gauss, when asked how soon he expected to reach certain mathematical conclusions, replied that he had reached them long ago, all he was worrying about was how to reach them! [Karl F. Gauss (1777-1855), German mathematician]