ASDF debugging on Hangouts?

[Faré]

On Wed, Dec 27, 2017 at 10:33 AM, Robert Goldman <rpgoldman at sift.info> wrote:
> On 4 Dec 2017, at 21:56, Faré wrote:
>
>> Fixing the same potential issue with the (more stable but still
>> evolvable) code in the core of ASDF will require applying the same
>> solution to action.lisp all files that define new operations.
>
> Will you please clarify this sentence? It looks like some editing error cost
> us some key words.  Did you originally write "to action.lisp" and then
> decide it had to change to "to all files that define new operations"?
>
Oops, I meant to action.lisp AND all files that define new operations.
Fixing action.lisp is trivial: change all the operation slots to methods.
But *first* you need to change all clients to do the same, probably over a year
(doing it in the other order doesn't work).

Alternatively, demand that suitable
update-instance-for-redefined-class methods be written; but it's just
as much work, and much more fragile. It's also slightly more backward
compatible, especially if are aggressive bumping
*oldest-forward-compatible-asdf-version*, but the fragility means that
if someone makes an API call with an operation created before upgrade
then things might go wrong (the operate :around method will catch that
in the common case; but your uncommon case will be "interesting" to
debug).

>> https://bugs.launchpad.net/asdf/+bug/1739514
>> Basically, ASDF fails spuriously rebuilds misnamed secondary systems
>> and/or things that depend on them, instead of just issuing a warning
>> as intended.
>
> Another editing query here.  Looks like it might be either "ASDF fails to rebuild" or "ASDF spuriously rebuilds misnamed..."
>
Yes, it's "ASDF spuriously rebuilds misnamed...".

Note that if it were a simple circular dependency, it would have just
broken the build and be very visible and I'd have caught it last year.

Without having looked at the code or tried to debug it yet, my working
hypothesis is that having "foo" in "foo.asd" depend on "bar" also
defined in "foo.asd" causes dependency from (define-op "foo") to
(define-op . "bar"), which is always in need of build because there is
no "bar.asd" and the associated timestamp is therefore NIL. If that is
correct, the backward-compatible solution would be to make sure that
"bar" remembers that it was defined in "foo.asd", so that it gets the
timestamp from "foo.asd", and the next time around, if there is no
up-to-date "bar.asd", ASDF falls back on looking at the previously
loaded "foo.asd" or a more up-to-date version of it.

Note that if "bar" is defined in both "foo.asd" and "bar.asd" you'll
still have a mighty bug. Therefore people should still fix their code
to properly name secondary system, ASDF should still issue a warning
when they are misnamed, and this warning should still be upgraded to a
cerror then an error when all of Quicklisp is fixed (>300 systems).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Rocky's Lemma of Innovation Prevention
Unless the results are known in advance, funding agencies will
reject the proposal.