One essential feature of ASDF is being able to upgrade from a previously loaded ASDF. This feature broke recently on CMUCL.
When trying to upgrade CMUCL's provided ASDF to the latest, some weird CLOS errors happen.
From 3.1.7 (using 21d), class MODULE isn't subtypep of its superclass COMPONENT. From 3.2.1 (using the april 2017 snapshot), I fail to set a newly
defined slot inside INITIALIZE-INSTANCE: Error in function "DEFMETHOD SLOT-MISSING (T T T T)": When attempting to set the slot's value to NIL (setf of slot-value), the slot ASDF/FORCING:FORCED is missing from the object #<ASDF/PLAN:SEQUENTIAL-PLAN {5A38C46D}>.
There's probably something wrong in some method caching mechanism, that prevents invalidation in presence of redefinition, or that breaks the class graph, etc.
I know that ASDF upgrade stresses the CLOS implementation a lot, but CMUCL is unique in being stumped by ASDF, and has been for years. I'm not going to spend too many cycles figuring out what's happening, or going to block an ASDF release. My understanding is that the policy with respect to CMUCL is that CMUCL is always very prompt to update its ASDF, and that live ASDF upgrades are therefore not as essential as it is on other implementations that linger for years without an update.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To distinguish the real from the unreal, one must experience both. — Saul Gorn
On Sun, Apr 9, 2017 at 1:11 AM, Raymond Toy toy.raymond@gmail.com wrote:
While looking at the logs, I came across this that occurred on Jan 18, 20 years ago:
Author: ram <ram> Date: Sat Jan 18 14:32:04 1997 +0000
Werkowskis source kit 1.03.7I guess this is the birth of cmucl in the new era.
Seems so long ago, and yet not really that long ago either.
-- Ray _______________________________________________ cmucl-imp mailing list cmucl-imp@cmucl.cons.org https://lists.zs64.net/mailman/listinfo/cmucl-imp