[cl-debian] Bug#357238: cl-asdf: Package errors on system reload
Package: cl-asdf Version: 1.89-1 Severity: normal I am having some problems with ASDF, that hits both CMUCL and SBCL. The symptom is that the first I load and compiles a system, for instance with `clc-require', it works as expected. However, on subsequent starts of lisp, the load of the (now compiled) system fails. The full error log is below, but the error encountered is: The name "ASDF1073" does not designate any package. The system being loaded in this example is the :regex system of the "cl-regex" package (in version 1-1). The cause of the problem is not entirely clear to me, but I suspect the code for `find-system' in /usr/share/common-lisp/source/asdf/asdf.lisp. It contains the following: (let ((*package* (make-package (gensym #.(package-name *package*)) :use '(:cl :asdf)))) which will generate a new unique package at each run. However, that package is not likely to exist in another run of lisp. Even if a new package is generated in the new session, in all probability it will have a different name. How that interferes with reloading of systems is unclear, but I am guessing that systems that contains files without an explicit `in-package' will get a fasl file that contains a reference to this temporary package, but without code to make sure that it exists. At least the packages.lisp file of the cl-regex package is an example of such an file. Trace of the error encountered: The name "ASDF1073" does not designate any package. [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] Restarts: 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A922DE9}> on #<ASDF:CL-SOURCE-FILE "packages" {A8B3781}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A922DE9}> on #<ASDF:CL-SOURCE-FILE "packages" {A8B3781}> as having been successful. 2: [ABORT] Abort SLIME compilation. 3: [ABORT-REQUEST] Abort handling SLIME request. 4: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {AFC2571}>) Backtrace: 0: (SB-INT:%FIND-PACKAGE-OR-LOSE "ASDF1073") 1: (SB-INT:FIND-UNDELETED-PACKAGE-OR-LOSE "ASDF1073") 2: (SB-FASL::FOP-PACKAGE) 3: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file /var/cache/common-lisp-controller/usr/local/home/tedchly/sbcl/regex/packages.fasl" {A940189}>) 4: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file /var/cache/common-lisp-controller/usr/local/home/tedchly/sbcl/regex/packages.fasl" {A940189}> NIL #<unavailable argument>) 5: (SB-FASL::INTERNAL-LOAD #P"/var/cache/common-lisp-controller/usr/local/home/tedchly/sbcl/regex/packages.fasl" #P"/var/cache/common-lisp-controller/usr/local/home/tedchly/sbcl/regex/packages.fasl" :ERROR NIL NIL :BINARY NIL) 6: (SB-FASL::INTERNAL-LOAD #P"/var/cache/common-lisp-controller/usr/local/home/tedchly/sbcl/regex/packages.fasl" #P"/var/cache/common-lisp-controller/usr/local/home/tedchly/sbcl/regex/packages.fasl" :ERROR NIL NIL NIL :DEFAULT) 7: (LOAD #P"/var/cache/common-lisp-controller/usr/local/home/tedchly/sbcl/regex/packages.fasl") 8: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {A922DE9}> #<ASDF:CL-SOURCE-FILE "packages" {A8B3781}>) 9: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {A922DE9}> #<ASDF:CL-SOURCE-FILE "packages" {A8B3781}>) 10: ((LAMBDA NIL)) 11: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA NIL) {A939D65}>) 12: (ASDF:OPERATE ASDF:LOAD-OP :LEXER) 13: (COMMON-LISP-CONTROLLER::REQUIRE-ASDF :LEXER) 14: (SB-INT:EVAL-IN-LEXENV (COMMON-LISP-CONTROLLER:CLC-REQUIRE :LEXER) #<NULL-LEXENV>) 15: (SB-FASL::LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file /usr/local/home/tedchly/Tools/cl-ted/etoc/etoc.asd" {B1AAE21}> NIL NIL) 16: (SB-FASL::INTERNAL-LOAD #P"/usr/local/home/tedchly/.sbcl/systems/etoc.asd" #P"/usr/local/home/tedchly/Tools/cl-ted/etoc/etoc.asd" :ERROR NIL NIL :SOURCE :DEFAULT) 17: (SB-FASL::INTERNAL-LOAD #P"/usr/local/home/tedchly/.sbcl/systems/etoc.asd" #P"/usr/local/home/tedchly/Tools/cl-ted/etoc/etoc.asd" :ERROR NIL NIL NIL :DEFAULT) 18: (LOAD #P"/usr/local/home/tedchly/.sbcl/systems/etoc.asd") 19: (ASDF:FIND-SYSTEM "etoc" T) --more-- -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=da_DK (charmap=ISO-8859-1) cl-asdf depends on no packages. Versions of packages cl-asdf recommends: ii cmucl [lisp-compi 19c-release-20051115-1 The CMUCL lisp compiler and develo ii common-lisp-contr 4.27 This is a Common Lisp source and c ii sbcl [lisp-compil 1:0.9.9.0-2 A Common Lisp compiler and develop -- no debconf information
Hello, On Thursday 16 March 2006 11:29, Christian Lynbech wrote:
The symptom is that the first I load and compiles a system, for instance with `clc-require', it works as expected. However, on subsequent starts of lisp, the load of the (now compiled) system fails. The full error log is below, but the error encountered is:
The name "ASDF1073" does not designate any package.
I've been thinking about this for a while now and I think this is a feature, not a bug. All files should declare a package to load into, if not the results will be unpredictable. So this is IMHO just a gentle reminder to do an (in-package :something) at the start of the file.
The system being loaded in this example is the :regex system of the "cl-regex" package (in version 1-1).
regex/packages.lisp does not start with "(in-package :common-lisp-user)" when you add that line the problem should go away.
The cause of the problem is not entirely clear to me, but I suspect the code for `find-system' in /usr/share/common-lisp/source/asdf/asdf.lisp. It contains the following:
(let ((*package* (make-package (gensym #.(package-name *package*)) :use '(:cl :asdf))))
which will generate a new unique package at each run. However, that package is not likely to exist in another run of lisp. Even if a new package is generated in the new session, in all probability it will have a different name.
This is good, it protects lazy libraries against other lazy libraries symbols. Does anyone disagree that this is a feature? Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
"Peter" == Peter Van Eynde <pvaneynd@debian.org> writes:
The system being loaded in this example is the :regex system of the "cl-regex" package (in version 1-1).
Peter> regex/packages.lisp does not start with "(in-package :common-lisp-user)" Peter> when you add that line the problem should go away. So I should file a bug against cl-regex instead? I have some sympathy for the sentiment that adding `in-package' forms when you kind of don't care is silly. This is after all lisp, not Java or Erlang. The "packages.lisp" file just want to create packages for cl-regex and thus is rather safe, it is just that ASDF goes out of its way to break it. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
Christian Lynbech <christian.lynbech@ericsson.com> writes:
I have some sympathy for the sentiment that adding `in-package' forms when you kind of don't care is silly. This is after all lisp, not Java or Erlang. The "packages.lisp" file just want to create packages for cl-regex and thus is rather safe, it is just that ASDF goes out of its way to break it.
load makes no guarantees about the value of *package* (only that it is rebound). i have had situations in my code were (in-package :bar) failed because *package* didn't use :common-lisp, i was doing some really weird stuff, but still. technically you should always start any file with: (cl:in-package ...) or at least use cl:defpackage in packages.lisp. i (for what it's worth) don't have much sympathy for files which don't specify what package they want, they didn't get what they didn't ask for. and technical issuse aside, we're only talking about one line anyway. -- -Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
participants (3)
-
Christian Lynbech -
Marco Baringer -
Peter Van Eynde