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@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 inpackage 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?