ASDF debugging on Hangouts?

Faré fahree at gmail.com
Thu Dec 21 01:48:17 UTC 2017


It looks like there is a bug in ASDF 3.3 worth definitely worth fixing
before I leave:
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.
(NB: there are a few hundred misnamed secondary systems in quicklisp.)

That's a good opportunity for another live debugging session some time
next week.
One that works this time.
Please contact me via private email message if you want to be present.
A public that asks useful questions would be useful.

I expect the total session to last about two to three hours
from unwrapping the (reproducible) test case to filing the merge request.
You don't have to attend all of it, and are welcome to leave or join part way.

This time, I will record locally so even a remote fiasco like last
time won't prevent recording;
however the session will probably be more didactic if there are attendees
to ask relevant questions about what I'm doing.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Multiple instances of a same hacker with different context in his mental
cache count as multiple hackers wrt documentation and testing needs.


On Mon, Dec 4, 2017 at 10:56 PM, Faré <fahree at gmail.com> wrote:
> My second attempt at a live session was also ultimately a failure:
> there were interruptions, the rhythm was slow with lots of side issues,
> the microphone was unplugged at one point, etc.,
> and it all lasted way too many hours with lots of down time.
> Happily, none of the two anonymous spectators stayed long anyway, so
> no one missed much.
>
> That said, I battled and vanquished an interesting conundrum of bugs,
> all of them
> directly or indirectly related to code upgrade:
>
> * Simplest and most obvious issue: ASDF 3.3.1 renamed STAMP< to
> TIMESTAMP< because the API changed; this caused a naming conflict with
> LOCAL-TIME:TIMESTAMP<. Solution: in WORKOUT-TIMER's
> UIOP:DEFINE-PACKAGE, use the :MIX clause with LOCAL-TIME ahead of
> UIOP, instead of :USE. The backtrace pointed to the correct issue, the
> ASDF changelog and/or commit messages explained what it was about,
> this was obvious to find out and fix.
> https://gitlab.common-lisp.net/frideau/workout-timer/commit/0e3f0104ddb26524f8445ddcf5e34dafe43aa8dd
>
> * I had somehow compiled my SBCL with an old script that hadn't set
> the SB-LINKABLE-RUNTIME feature; but CFFI-TOOLCHAIN failed to tell me,
> instead failing in a cryptic way. Solution: have CFFI proactively
> check for feature presence and issue a useful error message if absent.
> (This is loosely related to SBCL, because CFFI failed to detect that
> SBCL hadn't been upgraded to be compiled with this recent feature I
> added.) This issue was compounded by the fact that, while believing
> that it was an ASDF bug and trying to check at what point the bug
> appeared, other issues kept cropping up because of the bug below, and
> the fact that downgrading ASDF is itself quite tricky, unlike
> upgrading which is trivial.
> https://github.com/cffi/cffi/pull/127
>
> * ASDF stored metadata in the :initform of operation class slots, but
> then changes due to code upgrade were not visible because the slot was
> already initialized (yet upgrade previously worked, once, due to
> change of :allocation to :class). Solution: use defmethod, not slots.
> This is a deep issue. At root was my failing to take measure of how
> :initform would ultimately interact with software upgrade, when I
> originally wrote this code. And yet it worked well enough so far.
> 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. This
> will impact backward compatibility and will require yet another round
> of going through Quicklisp fixing everything (not that many systems
> define new operations, but some do), and making big announcements. ---
> Good task for a candidate future maintainer: well defined and
> predictable, and yet will get you around the core code of ASDF.
> https://gitlab.common-lisp.net/asdf/asdf/merge_requests/89
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> If you don't like yourself, you *can't* like other people.
>         — Robert Heinlein, "Time Enough For Love"
>
>
> On Mon, Dec 4, 2017 at 11:29 AM, Faré <fahree at gmail.com> wrote:
>> Well, after realizing one hour into the debugging session that I
>> needed to click on a button "Start Broadcast" to go live, I'm going to
>> reschedule the event, starting at 14:00 EST (19:00 UTC). Sorry.
>>
>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
>> How small of all that human hearts endure
>> That part which laws or kings can cause or cure! — Samuel Johnson
>>
>>
>> On Wed, Nov 29, 2017 at 7:24 PM, Faré <fahree at gmail.com> wrote:
>>> After a kernel downgrade, I have painfully managed to get streaming to
>>> Youtube Live Events working.
>>> https://www.youtube.com/my_live_events
>>>
>>> I'm tentatively scheduled an event at 10:00 EST (15:00 UTC) on next
>>> Monday December 4th 2017.
>>> https://www.youtube.com/watch?v=1kq-73Cjn08
>>>
>>> I'll be using Hangouts on Air, and will send a message to these lists
>>> with the link before I go live,
>>> and also posting the link on my twitter https://twitter.com/Ngnghm
>>>
>>> If you have requests for an alternate time slot, I'm open to moving the session.
>>>
>>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
>>> What one person receives without working for, another person must work for
>>> without receiving. — Adrian Rogers



More information about the asdf-devel mailing list