An innocuous-looking change suggested by rpgoldman, of not providing a default initform for the selfward-operation slot, led after testing to fixing a few innocuous bugs in asdf, but also to a better understanding of the issues with CMUCL and upgrade.
After the innocuous change, tests failed on CMUCL that didn't; some of it was bugs in ASDF that had been papered over by that initform: things that shouldn't have been selfward-operation were, and now had no initform — that was easily fixed. Then, there was a CMUCL bug, whereby sometimes, for reasons not understood yet deterministic and easy but not simple to trigger, some operations would be created without an initialized selfward-operation slot. This was worked around by noticing that selfward-operation was meant to be an :allocation :class slot, but that option wasn't inherited by slot specializations, and needed to be explicitly specified every time the slot was specialized (no doubt because trying to inherit the option would require a non-trivial decision procedure in case of conflict between multiple super-slots); fixing ASDF to do the right thing papered over that CMUCL bug. (to reproduce, checkout 3.1.0.37 and make t l=cmucl t=test-encodings.script)
While we were experimenting with CLOS and CMUCL, we tried to remove the #+cmu declaim optimize (not sure why it was ever there), and/or add a #+cmu (setf c::top-level-lambda-max 0). That didn't help (yet I removed the declaim at rtoy's suggestion), but along the way, we noticed that upgrade works from 3.0.1, 3.0.2, 3.0.3, and fails from 2.32 and earlier. The issue is that defclass component has a renamed a slot, and its subclass system is invalidated, but CMUCL somehow fails to finalize it again before it's next used.
The good news is that not only have we identified two CMUCL bugs, we have established to upgrade works from 3.0.1 to 3.0.3, which is all that matters, really, since CMUCL updates its ASDF frequently. And we know what to do to avoid more upgrade woes on CMUCL: avoid incompatible slot definitions in classes and/or superclasses.
I changed our tests to upgrade versions in reverse chronological order, which is more relevant, and disabled older versions when using CMUCL. I also bumped *oldest-forward-compatible-asdf-version* to 2.33, since we don't have a method on update-instance-for-redefined-class to account for the renamed slot.
That leaves the upgrade issue found by cl-grid-test on CCL with cl-l10n and some other systems.
wow. such procrastination. much bugfix. very robustified. wow. All because rpgoldman read the source and wanted a tiny cleanup.
In other news, still no date set for the walkthrough of ASDF sources on Google hangout; since rpgoldman is the primary audience, we're waiting for his schedule to open up.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I believe that sex is one of the most beautiful, natural, wholesome things that money can buy." — Steve Martin
Unfortunately the upgrade still fails for my CMUCL snapshot (cmucl-2013-04) I have tried the very recent ASDF:
commit 28a5c936421cdb72b218002c9b207c29bbf592d4 Author: Francois-Rene Rideau tunes@google.com Date: Thu Jan 9 16:58:01 2014 -0500
Bump version to 3.1.0.46
On Sun, Jan 12, 2014 at 6:24 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Unfortunately the upgrade still fails for my CMUCL snapshot (cmucl-2013-04) I have tried the very recent ASDF:
Weird. What version of ASDF are you upgrading from? It should work with ASDF 2.33 and later (3.0.1, 3.0.2, 3.0.3). What error are you getting? Quicklisp is working for me on the latest CMUCL snapshot, except for lots of low-level errors in some systems that seem wholly unrelated to ASDF itself.
Happy new year!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Constitution may not be perfect, but it's a lot better than what we've got!
13.01.2014, 05:04, "Faré" fahree@gmail.com:
On Sun, Jan 12, 2014 at 6:24 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Unfortunately the upgrade still fails for my CMUCL snapshot (cmucl-2013-04) I have tried the very recent ASDF:
Weird. What version of ASDF are you upgrading from? It should work with ASDF 2.33 and later (3.0.1, 3.0.2, 3.0.3). What error are you getting?
Yes, my CMUCL comes with previous ASDF - 2.32. The error is
Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: #<KERNEL::STANDARD-CLASS ASDF/SYSTEM:SYSTEM {585CCEF5}>
So you think this upgrate error is not important?
Happy new year!
And to you :)
On Mon, Jan 13, 2014 at 12:07 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Unfortunately the upgrade still fails for my CMUCL snapshot (cmucl-2013-04) I have tried the very recent ASDF:
Weird. What version of ASDF are you upgrading from? It should work with ASDF 2.33 and later (3.0.1, 3.0.2, 3.0.3). What error are you getting?
Yes, my CMUCL comes with previous ASDF - 2.32. The error is
Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: #<KERNEL::STANDARD-CLASS ASDF/SYSTEM:SYSTEM {585CCEF5}>So you think this upgrate error is not important?
This upgrade error *is* important, but unhappily in the "known issues" category, and a bug in CMUCL, not ASDF.
I suggest you skip tests that require an upgrade of ASDF 2.32 or earlier on CMUCL.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The only way for a reporter to look at a politician is down. — H.L. Mencken
14.01.2014, 02:18, "Faré" fahree@gmail.com:
I suggest you skip tests that require an upgrade of ASDF 2.32 or earlier on CMUCL.
OK. I am now running tests on the latest ASDF with ASDF upgrade on lisps where it works (including the very recent CMUCL). Then I will re-run tests without upgrate.
On Wed, 2014-01-08 at 01:10 -0500, Faré wrote:
An innocuous-looking change suggested by rpgoldman, of not providing a default initform for the selfward-operation slot, led after testing to fixing a few innocuous bugs in asdf, but also to a better understanding of the issues with CMUCL and upgrade.
It also broke Clozure, but it works now.
-
Anton Vodonosov -
Faré -
Stelian Ionescu