On 04/02/2011 12:58 AM, Helmut Eller wrote:
- Paul Bowyer [2011-04-01 16:23] writes:
In my learning exercises, I have been using something like:
(eval-when (:compile-toplevel :load-toplevel :execute) (if (find-package "CH16") (delete-package "CH16")) ) (defpackage "CH16" (:use "COMMON-LISP" "UTIL") (:shadow "LENGTH" "MEMBER" "COUNT") (:export "LENGTH" "MEMBER" "BEFORE" "NUMBER-LISTP" "SAME-LENGTH1" "SAME-LENGTH2" "COUNT") )
(in-package "CH16")
I think the problem is that the code tries to delete the current package, i.e. the package stored in the variable *package*. You can also produce the error in a normal SBCL session without Slime:
cl-user> (load (compile-file "x.lisp")) [...] t cl-user> (in-package ch16) #<package "CH16"> ch16> (load (compile-file "x.lisp")) [...] debugger invoked on a SIMPLE-TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {AA43859}>: *PACKAGE* can't be a deleted package: *PACKAGE* has been reset to #<PACKAGE "COMMON-LISP-USER">. [...]
COMPILE-FILE does something like (let ((*package* *package*)) <code-that-does-the-rest>) so that *package* is automatically reset to the original value at the end. But if *package* is the CH16 package before you call COMPILE-FILE and that CH16 package is deleted at compile-time, we end up with a deleted package in *package*.
Now, you may ask why *package* is CH16 when using Slime. That's because there is a (in-package ch16) form in the file and Slime tries to be friendly and automatically switches to that package.
Yes, this is really confusing.
CLTL2[*] has some good rules to avoid many of those situations:
In order to guarantee that compiled files can be loaded correctly, the user must ensure that the packages referenced in the file are defined consistently at compile and load time. Conforming Common Lisp programs must satisfy the following requirements.
- The value of *package* when a top-level form in the file is processed by compile-file must be the same as the value of *package* when the code corresponding to that top-level form in the compiled file is executed by the loader. In particular, any top-level form in a file that alters the value of *package* must change it to a package of the same name at both compile and load time; moreover, if the first non-atomic top-level form in the file is not a call to in-package, then the value of *package* at the time load is called must be a package with the same name as the package that was the value of *package* at the time compile-file was called. - For every symbol appearing lexically within a top-level form that was accessible in the package that was the value of *package* during processing of that top-level form at compile time, but whose home package was another package, at load time there must be a symbol with the same name that is accessible in both the load-time *package* and in the package with the same name as the compile-time home package. - For every symbol in the compiled file that was an external symbol in its home package at compile time, there must be a symbol with the same name that is an external symbol in the package with the same name at load time.Some of the package related functions like delete-package, unintern, rename-package etc. can lead to those confusing situations. If possible, create the package structure once and don't modify it later. Obviously that's not always possible but now you know that you need to be careful when messing around with packages.
Helmut
[*] http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/html/cltl/clm/node224....
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Thank you for the explanation. I had tried:
cl-user> (compile-file "x.lisp") cl-user> (load "x.fasl")
which worked. I didn't think to try:
cl-user> (load (compile-file "x.lisp"))
so I will be better educated (maybe) for future problems. Now that I understand the problem, I think I have a working solution, but I'll need to test all of my lesson files to be certain.
I'm pleased that I have a place to bring my problems when I run into things I don't understand about lisp and slime, but I'll try not to be continual pest so as not to be a burden on the mailing list.
Paul