[asdf-devel] ABCL and UIOP

[Faré]

Well, in this case, it looks like it's a bug in ABCL:

[1] UIOP/BACKWARD-DRIVER(14): (find-symbol "LOAD-ASDF-DEBUG-UTILITY"
:uiop/utility)
UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY
:INTERNAL
[1] UIOP/BACKWARD-DRIVER(15): (find-symbol "LOAD-ASDF-DEBUG-UTILITY"
:uiop/driver)
UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY
:EXTERNAL
[1] UIOP/BACKWARD-DRIVER(17): [1] UIOP/BACKWARD-DRIVER(17): (unexport
(find-symbol "LOAD-ASDF-DEBUG-UTILITY" :uiop/driver) :uiop/driver)
Error loading /home/tunes/cl/asdf/build/asdf.lisp at line 5302 (offset 252109)
#<THREAD "interpreter" {7E6AB533}>: Debugger invoked on condition of
type PACKAGE-ERROR
  The symbol UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY is not accessible
in package UIOP/DRIVER
Restarts:
  0: ABORT Return to debug level 1.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it
        — Richard Feynman


On Mon, Mar 25, 2013 at 11:18 AM, Faré <fahree at gmail.com> wrote:
> That's an interesting situation.
>
> You're using ASDF and UIOP as intended,
> so a failure is a bug in UIOP and/or ABCL.
>
> I have renamed a symbol from LOAD-ASDF-DEBUG-UTILITY to
> LOAD-UIOP-DEBUG-UTILITY, which causes the UNEXPORT to happen when
> you load the new UIOP, at which point no one should be using the old symbol.
> But it looks like the unexport itself is failing,
> because it recurses to packages that :use the current one;
> yet somehow it looks like it's confused as to whether the symbol
> is accessible or not in UIOP/DRIVER:
> if it weren't, we shouldn't try the unexport,
> and if it is, then the unexport should succeed.
> That it tries to unexport and fails is a bad sign.
>
> Interestingly, it works on SBCL and other implementations,
> so ABCL is possibly doing something wrong.
>
> I can reproduce locally on ABCL 1.1.0 — I'll look into it.
>
> Sorry for the failure.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> I'd give my right arm to be ambidextrous.
>
>
> On Mon, Mar 25, 2013 at 10:04 AM, Mark Evenson <evenson at panix.com> wrote:
>> abcl-1.2.0-dev currently uses asdf-2.32 which includes a perfectly fine (as
>> far as we know) UIOP.
>>
>> But one can't load UIOP 2.32.5 from Quicklisp 2013-03-12 in abcl-1.2.0-dev,
>> getting the following error:
>>
>>     The symbol UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY is not accessible in
>> package UIOP/DRIVER
>>
>> which is triggered by the following UNEXPORT:
>>
>>      (UNEXPORT UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY #<PACKAGE UIOP/DRIVER>)
>>
>> Is it to be expected that ASDF cannot, in general, "host" later versions of
>> UIOP without first upgrading ASDF?
>>
>> It might be nice to consider some sort of warning in this situation, as
>> until ASDF3 gets more widespread, people may be tempted to get Quicklisp to
>> locate and load UIOP for them.
>>
>> Or maybe I have misunderstood the packaging of ASDF with ABCL?  I have been
>> simply using the results of "make build/asdf.lisp" in the path of our
>> CL:REQUIRE implementation.  I am supposed to somehow make the asdf.asd and
>> uiop.asd files accessible as well?
>>