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