ASDF debugging on Hangouts?

Wed Dec 27 15:37:44 UTC 2017

In the future, when debugging something like this, where the environment 
into which you are loading code is of critical importance, and an ASDF 
issue is suspected, I suggest the following:

On the various implementations, do whatever you need to do to prepare to 
load the system that exhibits the error.  Then try to load the system.  
After the system either loads successfully, or encounters an error, 
collect the value of `(ASDF:ASDF-VERSION)`.

That will be better than trying to guess what's being loaded, and will 
zero in on issues.

Best,
r

On 26 Dec 2017, at 12:39, Ken Tilton wrote:

> Speaking of ASDF, quicklisp loaded :ceramic OK into SBCL on Mac OS X 
> but on
> Windows under AllegroCL Ansi I get:
>
> 
>>
> Error: OPERATION instances must only be created through 
> MAKE-OPERATION.
>
> [condition type: FORMATTED-SYSTEM-DEFINITION-ERROR]
>
>
> Is that an ASDF issue? Ceramic? ACL? cffi-grovel (the system being 
> built
> when the error is thrown)?
>
> Does quicklisp use its own copy of ASDF for stability?
>
> I will try Clozure on Windows, but I would love to stick to 
> AllegroCL's
> windows IDE.
>
> -kt
> 
>
>> 
>>
>>
> On Wed, Dec 20, 2017 at 8:48 PM, Faré <fahree at gmail.com> wrote:
>
>> 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
>>
>>
>
>
> -- 
> Kenneth Tilton
> http://tiltontec.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20171227/cd47c78f/attachment-0001.html>