[Openmcl-devel] errors with the 1.9 rc

[Gary Byers]

See ?  Trying to debug is much better than ... whatever the alternative is.

If you remove or rename the version of ASDF in "ccl:tools;", is REQUIRE
able to find the Debian version ?  If so ...

If you rename the version of ASDF in "ccl:tools" to something like
"ccl:tools;upstream-asdf.lisp", then anyone who wanted to use that
version (and understood that it didn't interoperate correctly with
the Debian-provided version) could do:

? (require "ASDF" "ccl:tools;upstream-asdf")

I'm not really qualified to have an opinion.  We package ASDF with CCL
as a convenience to users (and in the belief that it's indeed convenient
for ... people who want to use ASDF.)  We were asked to try to get the
latest version of ASDF into the CCL trunk and 1.9 release and to encourage
people to use and test it.


On Sun, 10 Feb 2013, Faheem Mitha wrote:

>
> 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.
>
>