ASDF debugging on Hangouts?

[Faré]

OK, I'm setting the day and time for the next ASDF debugging session
to Tuesday January 2nd 2018 at 14:00 EST (19:00 UTC). Please send me a
private email if you can make it, I'll add you to a Google Calendar
event with a Hangout invitation.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
When it comes to giving, some men stop at nothing. — Saul Gorn


On Wed, Dec 27, 2017 at 6:06 PM, Faré <fahree at gmail.com> wrote:
> 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:
>>> 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).