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(a)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.7
>
>
> I 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(a)cmucl.cons.org
> https://lists.zs64.net/mailman/listinfo/cmucl-imp
