uiop non-problems

[Faré]

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 at 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