Dear future maintainers of ASDF,

I have great news for you if you were looking for an opportunity to learn about the guts of ASDF: a new bug that will cover a lot of ground, yet is relatively well-understood, and isn't urgent at all. I wouldn't make it anyone's first bug, but once you have some experience, it might be great bug to get really into it.

Context: I did this interactive debugging session, but it went quite slow and after two hours we only narrowed down the root issue: we needed the primary-system-* functions to distinguish between "syntactic" and "semantic" primariness, since the two notions aren't identical in the existing codebase, and my just ignoring the issue caused these spurious rebuilds. I once again failed to properly record the 2.5 hour interaction, but one of the participants might have done so, though it's not as valuable as I'd have hoped. Then, It took me the next morning to slowly develop a bug fix. See explanation in the bug and code in the MR: https://bugs.launchpad.net/asdf/+bug/1739514 https://gitlab.common-lisp.net/asdf/asdf/merge_requests/91

Now now now, while thinking very hard about the correct fix to the above bug, and especially about the up-to-date-p condition in find-system, I realized that there was a lingering bug in it, of the kind order as the bug that broke ASDF 2, except in a much rarer situation: if you update the defsystem-depends-on of a loaded system a that could cause a change in how the a.asd file would be evaluated; then this should trigger a reload of a.asd when you next operate on a; but it won't because the timestamp is not propagated, because find-system fails to integrate well enough with the dependency graph usage and construction (which integration is new with 3.3). https://bugs.launchpad.net/asdf/+bug/1741083

This seems to be like it's "just" a variant at the meta-level of the famous bug that broke ASDF 2 (see my 25 page paper on the history of ASDF about that). Except that now the infrastructure to propagate timestamps, what more across evaluation phases, already exists; therefore fixing this bug should mostly "just" use the existing infrastructure. Then again, it could possibly break the universe again, though I bet it won't: I believe there should be "just" an update of find-system and the creation of a new operation class prepare-define-op.

In any case, not my problem anymore, because it's clearly not a regression. But a great opportunity for whoever steps up and fixes this bug and whatever else they find. You better step forward while I'm still here to answer questions: considering how hard it was for me to page back the crucial elements of the algorithm into memory after just one year, don't wait.

PS: Another exercise for a future ASDF maintainer would be to do the boring work and fix all the 300+ systems on Quicklisp that trigger the bad-system-name warning, one by one. This is also a great exercise for getting to know what kind of clients are around. And for fixing them according to my best_practices document.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every great truth begins as heresy and ends as superstition. — Thomas Henry Huxley