[Openmcl-devel] errors with the 1.9 rc
Faheem Mitha
faheem at faheem.info
Sat Feb 9 12:08:07 PST 2013
On Sat, 9 Feb 2013, Gary Byers wrote:
> What happens when you try to debug this ?
> On Sat, 9 Feb 2013, Faheem Mitha wrote:
>> Hi,
>> I'm getting errors with the 1.9 rc, both with upstream binaries and
>> also with a Debian package compiled from source; both give
>> identical errors. This is on Debian squeeze.
>> Notes: I don't currently have a .ccl-init.lisp, and in any case I'm
>> running CCL with the -n flag. Also, in Debian at least, the system
>> caches in .cache/common-lisp, but there is no CCL related entry
>> there currently. I haven't tried nuking everything.
>> faheem at orwell:~/.cache/common-lisp$ ls
>> ecl-11.1.1-linux-x86 sbcl-1.0.57.0.debian-linux-x86
>> sbcl-1.1.1.0.debian-linux-x86 sbcl-1.1.3.debian-linux-x86
>> sbcl-1.0.56.0.debian-linux-x86 sbcl-1.0.58.0.debian-linux-x86
>> sbcl-1.1.2.debian-linux-x86 sbcl-1.1.4.debian-linux-x86
>
> Ah, there's your problem right there ...
>> There is an cl-asdf Debian package also installed, version 2.22,
>> but it doesn't seem this would cause any problems.
> Nah. How could loading multiple incompatible versions of ASDF cause
> problems ?
Yes, in fact that is the problem. See transcript below.
? (setf *load-verbose* t)
T
? *load-verbose*
T
? (truename "ccl:")
#P"/usr/local/src/ccl/ccl/"
? (require 'asdf)
;Loading #P"/usr/local/src/ccl/ccl/tools/asdf.lisp"...
ASDF
("ASDF")
? (require 'cl-rmath)
;Loading #P"/usr/local/share/common-lisp/source/cl-rmath/cl-rmath.asd"...
;Loading #P"/usr/share/common-lisp/source/cl-asdf/asdf.asd"...
;Loading #P"/usr/share/common-lisp/source/cl-asdf/asdf.lisp"...ASDF could not load cl-rmath because Too many arguments in call to #<Compiled-function ASDF/PACKAGE:FIND-SYMBOL* #x187500D6>:
3 arguments provided, at most 2 accepted. .
> Error: Too many arguments in call to #<Compiled-function ASDF/PACKAGE:FIND-SYMBOL* #x187500D6>:
> 3 arguments provided, at most 2 accepted.
> While executing: ASDF/PACKAGE:FIND-SYMBOL*, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
So, (require 'cl-rmath) makes the debian ASDF load, even though ASDF
is already loaded. At that point wackiness ensues.
I'm not sure what the best solution is. I don't want to remove the
Debian ASDF because a) CL Debian packages depend on it, so they would
be removed too and b) other CL implementations don't necessarily
bundle ASDF, so I'd need to keep another ASDF implementation around
for them.
Stas on #lisp diagnosed the reason that the Debian ASDF gets loaded is
because ASDF is trying to auto-upgrade itself. I would have expected
loading ASDF to be a no-op if ASDF is already loaded, but I guess that
explains why that doesn't happen.
14:27 < faheem> stassats`: so, just to be clear (i'm writing to the ccl list)
the reason the Debian ASDF gets loaded is because of the auto
upgrade feature?
14:27 < stassats`> right
Here is the relevant transcript.
#####################################################################
faheem at orwell:/usr/local/src/ccl/ccl$ rlwrap ./lx86cl
Welcome to Clozure Common Lisp Version 1.9-rc1-r15685 (LinuxX8632)!
? (require 'asdf)
ASDF
("ASDF")
? (trace asdf:upgrade-asdf)
NIL
? (require 'cl-rmath)
0> Calling (ASDF/UPGRADE:UPGRADE-ASDF)
ASDF could not load cl-rmath because Too many arguments in call to #<Compiled-function ASDF/PACKAGE:FIND-SYMBOL* #x187601F6>:
3 arguments provided, at most 2 accepted. .
> Error: Too many arguments in call to #<Compiled-function ASDF/PACKAGE:FIND-SYMBOL* #x187601F6>:
> 3 arguments provided, at most 2 accepted.
> While executing: ASDF/PACKAGE:FIND-SYMBOL*, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
#####################################################################
I think it would be good if CCL users could either use the internal
copy or the external copy of ASDF, but not both. I'd appreciate
suggestions for doing it either way, I don't care which.
I notice that if the Debian ASDF is loaded first, none of this
happens. According to Stas again
14:59 < stassats`> the internal can only be loaded through REQUIRE
15:00 < faheem> so the external one doesn't try using require to find a more recent copy?
15:01 < stassats`> require isn't used by asdf
15:01 < faheem> so the external one doesn't "know" about the internal one.
###################################################
faheem at orwell:/usr/local/src/ccl/ccl$ rlwrap ./lx86cl
Welcome to Clozure Common Lisp Version 1.9-rc1-r15685 (LinuxX8632)!
? (load #P"/usr/share/common-lisp/source/cl-asdf/asdf.lisp")
#P"/usr/share/common-lisp/source/cl-asdf/asdf.lisp"
? (trace asdf:upgrade-asdf)
NIL
? (require 'asdf)
ASDF
NIL
? (asdf:asdf-version)
"2.22"
? (require 'cl-rmath)
CL-RMATH
NIL
##################################################
> I don't know whether that version of ASDF is in any way implicated; I don't
> know what version(s) of ASDF are being loaded in your debian-packaged version
> and I can't turn on *LOAD-VERBOSE* for you.
The debian package is not being tested here. This CCL version 1.9 rc1 was
downloaded direct from the CCL subversion repos.
> All that I do know is that:
>
> - the version of ASDF bundled with the CCL 1.9-rc1 (2.28) defines
>
> (defun find-symbol* (name package-designator &optional (error t))
>
> and code in that version calls FIND-SYMBOL* with 3 arguments
>
> - the version of ASDF that was bundled with CCL-1.8 defines
>
> (defun find-symbol* (s p)
>
> and something (I don't know what because I can't type :b for you)
> is calling a version of ASDF/PACKAGE:FIND-SYMBOL* with 3 args and
> that version only accepts 2 arguments.
>> Transcript with upstream binary follows. Note that the same error
>> occurs when I try to load any CL package, whether Debian package or
>> locally installed. This all worked fine with 1.8.
> Nope. When CCL 1.8 wasn't installed correctly (hint), it couldn't find
> the right CCL directory (hint) and often loaded the wrong version of ASDF.
Not the issue.
> Let's summarize:
>
> 1) Make sure that your debian-packaged CCL is able to find its installation
> directory ("the CCL directory").
>
> ? (truename "ccl:")
>
> will show the physical pathname of that directory. If it isn't correct,
> check your scripts and fix it.
>
> 2) If the problem persists, set *load-verbose* to true before doing anything
> else. Pay attention to the full names of files being loaded and try to
> note anomalies.
>
> 3) If you get the error, type :b at the break loop prompt. Note the call
> history and see if this sheds light on the problem.
>
> 4) If you still don't understand what's going on and have to ask someone else
> for help, include that backtrace output in any request for help.
More information about the Openmcl-devel
mailing list