<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">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:</p>
<p dir="auto">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 <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">(ASDF:ASDF-VERSION)</code>.</p>
<p dir="auto">That will be better than trying to guess what's being loaded, and will zero in on issues.</p>
<p dir="auto">Best,<br>
r</p>
<p dir="auto">On 26 Dec 2017, at 12:39, Ken Tilton wrote:</p>
</div>
<div style="white-space:normal"></div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="537FFE34-10C6-4071-BB16-B6B522B2481F"><div dir="ltr"><div class="gmail_default" style="font-size:large">Speaking of ASDF, quicklisp loaded :ceramic OK into SBCL on Mac OS X but on Windows under AllegroCL Ansi I get:</div><div class="gmail_default" style="font-size:large"><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail_default" style="font-size:large;display:inline"></div></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><font size="4">Error: OPERATION instances must only be created through MAKE-OPERATION.</font></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><font size="4">[condition type: FORMATTED-SYSTEM-DEFINITION-ERROR]</font></blockquote><div><br></div><div class="gmail_default" style="font-size:large">Is that an ASDF issue? Ceramic? ACL? cffi-grovel (the system being built when the error is thrown)?</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Does quicklisp use its own copy of ASDF for stability?</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">I will try Clozure on Windows, but I would love to stick to AllegroCL's windows IDE.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">-kt</div><div class="gmail_default" style="font-size:large"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail_default" style="font-size:large;display:inline"></div><br></blockquote></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 20, 2017 at 8:48 PM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It looks like there is a bug in ASDF 3.3 worth definitely worth fixing<br>
before I leave:<br>
<a href="https://bugs.launchpad.net/asdf/+bug/1739514" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>asdf/+bug/1739514</a><br>
Basically, ASDF fails spuriously rebuilds misnamed secondary systems<br>
and/or things that depend on them, instead of just issuing a warning<br>
as intended.<br>
(NB: there are a few hundred misnamed secondary systems in quicklisp.)<br>
<br>
That's a good opportunity for another live debugging session some time<br>
next week.<br>
One that works this time.<br>
Please contact me via private email message if you want to be present.<br>
A public that asks useful questions would be useful.<br>
<br>
I expect the total session to last about two to three hours<br>
from unwrapping the (reproducible) test case to filing the merge request.<br>
You don't have to attend all of it, and are welcome to leave or join part way.<br>
<br>
This time, I will record locally so even a remote fiasco like last<br>
time won't prevent recording;<br>
however the session will probably be more didactic if there are attendees<br>
to ask relevant questions about what I'm doing.<br>
<br>
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
Multiple instances of a same hacker with different context in his mental<br>
cache count as multiple hackers wrt documentation and testing needs.<br>
<br>
<br>
On Mon, Dec 4, 2017 at 10:56 PM, Faré <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>> wrote:<br>
> My second attempt at a live session was also ultimately a failure:<br>
> there were interruptions, the rhythm was slow with lots of side issues,<br>
> the microphone was unplugged at one point, etc.,<br>
> and it all lasted way too many hours with lots of down time.<br>
> Happily, none of the two anonymous spectators stayed long anyway, so<br>
> no one missed much.<br>
><br>
> That said, I battled and vanquished an interesting conundrum of bugs,<br>
> all of them<br>
> directly or indirectly related to code upgrade:<br>
><br>
> * Simplest and most obvious issue: ASDF 3.3.1 renamed STAMP< to<br>
> TIMESTAMP< because the API changed; this caused a naming conflict with<br>
> LOCAL-TIME:TIMESTAMP<. Solution: in WORKOUT-TIMER's<br>
> UIOP:DEFINE-PACKAGE, use the :MIX clause with LOCAL-TIME ahead of<br>
> UIOP, instead of :USE. The backtrace pointed to the correct issue, the<br>
> ASDF changelog and/or commit messages explained what it was about,<br>
> this was obvious to find out and fix.<br>
> <a href="https://gitlab.common-lisp.net/frideau/workout-timer/commit/0e3f0104ddb26524f8445ddcf5e34dafe43aa8dd" rel="noreferrer" target="_blank">https://gitlab.common-lisp.<wbr>net/frideau/workout-timer/<wbr>commit/<wbr>0e3f0104ddb26524f8445ddcf5e34d<wbr>afe43aa8dd</a><br>
><br>
> * I had somehow compiled my SBCL with an old script that hadn't set<br>
> the SB-LINKABLE-RUNTIME feature; but CFFI-TOOLCHAIN failed to tell me,<br>
> instead failing in a cryptic way. Solution: have CFFI proactively<br>
> check for feature presence and issue a useful error message if absent.<br>
> (This is loosely related to SBCL, because CFFI failed to detect that<br>
> SBCL hadn't been upgraded to be compiled with this recent feature I<br>
> added.) This issue was compounded by the fact that, while believing<br>
> that it was an ASDF bug and trying to check at what point the bug<br>
> appeared, other issues kept cropping up because of the bug below, and<br>
> the fact that downgrading ASDF is itself quite tricky, unlike<br>
> upgrading which is trivial.<br>
> <a href="https://github.com/cffi/cffi/pull/127" rel="noreferrer" target="_blank">https://github.com/cffi/cffi/<wbr>pull/127</a><br>
><br>
> * ASDF stored metadata in the :initform of operation class slots, but<br>
> then changes due to code upgrade were not visible because the slot was<br>
> already initialized (yet upgrade previously worked, once, due to<br>
> change of :allocation to :class). Solution: use defmethod, not slots.<br>
> This is a deep issue. At root was my failing to take measure of how<br>
> :initform would ultimately interact with software upgrade, when I<br>
> originally wrote this code. And yet it worked well enough so far.<br>
> Fixing the same potential issue with the (more stable but still<br>
> evolvable) code in the core of ASDF will require applying the same<br>
> solution to action.lisp all files that define new operations. This<br>
> will impact backward compatibility and will require yet another round<br>
> of going through Quicklisp fixing everything (not that many systems<br>
> define new operations, but some do), and making big announcements. ---<br>
> Good task for a candidate future maintainer: well defined and<br>
> predictable, and yet will get you around the core code of ASDF.<br>
> <a href="https://gitlab.common-lisp.net/asdf/asdf/merge_requests/89" rel="noreferrer" target="_blank">https://gitlab.common-lisp.<wbr>net/asdf/asdf/merge_requests/<wbr>89</a><br>
><br>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
> If you don't like yourself, you *can't* like other people.<br>
> — Robert Heinlein, "Time Enough For Love"<br>
><br>
><br>
> On Mon, Dec 4, 2017 at 11:29 AM, Faré <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>> wrote:<br>
>> Well, after realizing one hour into the debugging session that I<br>
>> needed to click on a button "Start Broadcast" to go live, I'm going to<br>
>> reschedule the event, starting at 14:00 EST (19:00 UTC). Sorry.<br>
>><br>
>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
>> How small of all that human hearts endure<br>
>> That part which laws or kings can cause or cure! — Samuel Johnson<br>
>><br>
>><br>
>> On Wed, Nov 29, 2017 at 7:24 PM, Faré <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>> wrote:<br>
>>> After a kernel downgrade, I have painfully managed to get streaming to<br>
>>> Youtube Live Events working.<br>
>>> <a href="https://www.youtube.com/my_live_events" rel="noreferrer" target="_blank">https://www.youtube.com/my_<wbr>live_events</a><br>
>>><br>
>>> I'm tentatively scheduled an event at 10:00 EST (15:00 UTC) on next<br>
>>> Monday December 4th 2017.<br>
>>> <a href="https://www.youtube.com/watch?v=1kq-73Cjn08" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=1kq-73Cjn08</a><br>
>>><br>
>>> I'll be using Hangouts on Air, and will send a message to these lists<br>
>>> with the link before I go live,<br>
>>> and also posting the link on my twitter <a href="https://twitter.com/Ngnghm" rel="noreferrer" target="_blank">https://twitter.com/Ngnghm</a><br>
>>><br>
>>> If you have requests for an alternate time slot, I'm open to moving the session.<br>
>>><br>
>>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
>>> What one person receives without working for, another person must work for<br>
>>> without receiving. — Adrian Rogers<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Kenneth Tilton</div><div><a href="http://tiltontec.com/" target="_blank">http://tiltontec.com/</a><br></div></div></div>
</div></div></blockquote>
<div style="white-space:normal">
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>