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?
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?
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@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@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?
On 3/26/13 0039 , Faré wrote:
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.
[…]
Thanks for the confirmation. We're tracking this as ticket [311][].
On 3/26/13 0039 , Faré wrote:
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.
Hmmm. How did you get into the state where UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY is :INTERNAL? asdf.lisp:1017 explicitly exports this symbol from what I see.
From ABCL trunk I only see it as an :EXTERNAL symbol:
CL-USER> (lisp-implementation-version) "1.2.0-dev" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_17-b02" "x86_64-Mac_OS_X-10.8.3" CL-USER> (asdf:asdf-version) "2.32" CL-USER> (find-symbol "LOAD-ASDF-DEBUG-UTILITY" :uiop/driver) UIOP/UTILITY:LOAD-ASDF-DEBUG-UTILITY :EXTERNAL CL-USER> (find-symbol "LOAD-ASDF-DEBUG-UTILITY" :uiop/utility) UIOP/UTILITY:LOAD-ASDF-DEBUG-UTILITY :EXTERNAL CL-USER>
I unexport the symbol from UIOP/UTILITY long before I unexport it from packages that use it. Actually, it's precisely because I unexported it from UIOP/UTILITY when I evaluated the updated DEFINE-PACKAGE for it that I unexport it from UIOP/DRIVER when I evaluate the updated DEFINE-PACKAGE for the latter.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org drug, n: A substance that, injected into a rat, produces a scientific paper.
On Tue, Mar 26, 2013 at 9:55 AM, Mark Evenson evenson@panix.com wrote:
On 3/26/13 0039 , Faré wrote:
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.
Hmmm. How did you get into the state where UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY is :INTERNAL? asdf.lisp:1017 explicitly exports this symbol from what I see.
From ABCL trunk I only see it as an :EXTERNAL symbol:
CL-USER> (lisp-implementation-version) "1.2.0-dev" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_17-b02" "x86_64-Mac_OS_X-10.8.3" CL-USER> (asdf:asdf-version) "2.32" CL-USER> (find-symbol "LOAD-ASDF-DEBUG-UTILITY" :uiop/driver) UIOP/UTILITY:LOAD-ASDF-DEBUG-UTILITY :EXTERNAL CL-USER> (find-symbol "LOAD-ASDF-DEBUG-UTILITY" :uiop/utility) UIOP/UTILITY:LOAD-ASDF-DEBUG-UTILITY :EXTERNAL CL-USER>
I meant that I couldn't figure out how to reproduce the state you get ABCL into, but it seems the answer is that one tries to QL:QUICKLOAD :UIOP from abcl-1.2.0-dev.
-- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad idea? A: Top-posting. Q: What is the most annoying thing in email?
On Mar 26, 2013, at 3:14 PM, Faré fahree@gmail.com wrote:
I unexport the symbol from UIOP/UTILITY long before I unexport it from packages that use it. Actually, it's precisely because I unexported it from UIOP/UTILITY when I evaluated the updated DEFINE-PACKAGE for it that I unexport it from UIOP/DRIVER when I evaluate the updated DEFINE-PACKAGE for the latter.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org drug, n: A substance that, injected into a rat, produces a scientific paper.
On Tue, Mar 26, 2013 at 9:55 AM, Mark Evenson evenson@panix.com wrote:
On 3/26/13 0039 , Faré wrote:
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.
Hmmm. How did you get into the state where UIOP/UTILITY::LOAD-ASDF-DEBUG-UTILITY is :INTERNAL? asdf.lisp:1017 explicitly exports this symbol from what I see.
From ABCL trunk I only see it as an :EXTERNAL symbol:
CL-USER> (lisp-implementation-version) "1.2.0-dev" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_17-b02" "x86_64-Mac_OS_X-10.8.3" CL-USER> (asdf:asdf-version) "2.32" CL-USER> (find-symbol "LOAD-ASDF-DEBUG-UTILITY" :uiop/driver) UIOP/UTILITY:LOAD-ASDF-DEBUG-UTILITY :EXTERNAL CL-USER> (find-symbol "LOAD-ASDF-DEBUG-UTILITY" :uiop/utility) UIOP/UTILITY:LOAD-ASDF-DEBUG-UTILITY :EXTERNAL CL-USER>
On 3/26/13 1733 , Mark Evenson wrote:
I meant that I couldn't figure out how to reproduce the state you get ABCL into, but it seems the answer is that one tries to QL:QUICKLOAD :UIOP from abcl-1.2.0-dev.
We managed to get this fixed in [ABCL][r14449].
[r14449]: http://trac.common-lisp.net/armedbear/changeset/14449
Now to contemplate ASDF-JAR as part of ASDF/BUNDLE…
-
Faré -
Mark Evenson