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@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/0e3f0104ddb26524...
- 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@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@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