<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>