slime-devel:
I'm just learning how to work with lisp and slime and I would like to know if I can ask questions on this list regarding the setup and operation of slime?
Thanks,
pbowyer
On 03/30/2011 12:37 PM, Paul Bowyer wrote:
slime-devel:
I'm just learning how to work with lisp and slime and I would like to know if I can ask questions on this list regarding the setup and operation of slime?
Thanks,
pbowyer
Of course! Where else can you go for help? Nowhere I can think of.
Welcome to the rarefied contingent of Lisp programmers! Makes my day.
Carlos
On 03/30/2011 11:56 AM, Carlos Konstanski wrote:
On 03/30/2011 12:37 PM, Paul Bowyer wrote:
slime-devel:
I'm just learning how to work with lisp and slime and I would like to know if I can ask questions on this list regarding the setup and operation of slime?
Thanks,
pbowyer
Of course! Where else can you go for help? Nowhere I can think of.
Welcome to the rarefied contingent of Lisp programmers! Makes my day.
Carlos
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
OK then:
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")
;;;more code containing functions follows ... ----------------------------------------------------------------------------- at the beginning of my lisp source files to try to handle problems I was having with error messages when I tried to compile or compile/load my source. It took me a while to discern how to get this far, but now with the code above (after the initial compile/load) I need to compile twice or compile then compile/load because the first compile produces error messages similar to the following. ------------------------------------------ Unable to display error condition: *PACKAGE* can't be a deleted package: *PACKAGE* has been reset to #<PACKAGE "COMMON-LISP-USER">. [Condition of type SIMPLE-TYPE-ERROR] ------------------------------------------ If I abort to slime's top level and then immediately compile or compile/load, it works correctly until the next time I try to compile when I have to repeat the process. Is there a way to avoid having to repeat the compile process twice? I've tried various gyrations of the above code without success.
Before I discerned that I needed to compile twice before getting a successful compilation, after aborting to slime's top level I tried (find-package "CH16") in the REPL and got NIL. After the second compilation, the 'find-package' command succeeded with #<PACKAGE "CH16">.
I'm using: sbcl-1.0.29 emacs-23.1.1 slime version uncertain, but downloaded recently All running under PCLinuxOS-2010 using KDE-4.6.1
Thanks for any light you can shed on this,
pbowyer
On 03/30/2011 02:53 PM, Paul Bowyer wrote:
On 03/30/2011 11:56 AM, Carlos Konstanski wrote:
On 03/30/2011 12:37 PM, Paul Bowyer wrote:
slime-devel:
I'm just learning how to work with lisp and slime and I would like to know if I can ask questions on this list regarding the setup and operation of slime?
Thanks,
pbowyer
Of course! Where else can you go for help? Nowhere I can think of.
Welcome to the rarefied contingent of Lisp programmers! Makes my day.
Carlos
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
OK then:
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")
;;;more code containing functions follows ...
at the beginning of my lisp source files to try to handle problems I was having with error messages when I tried to compile or compile/load my source. It took me a while to discern how to get this far, but now with the code above (after the initial compile/load) I need to compile twice or compile then compile/load because the first compile produces error messages similar to the following.
Unable to display error condition: *PACKAGE* can't be a deleted package: *PACKAGE* has been reset to #<PACKAGE "COMMON-LISP-USER">. [Condition of type SIMPLE-TYPE-ERROR]
If I abort to slime's top level and then immediately compile or compile/load, it works correctly until the next time I try to compile when I have to repeat the process. Is there a way to avoid having to repeat the compile process twice? I've tried various gyrations of the above code without success.
Before I discerned that I needed to compile twice before getting a successful compilation, after aborting to slime's top level I tried (find-package "CH16") in the REPL and got NIL. After the second compilation, the 'find-package' command succeeded with #<PACKAGE "CH16">.
I'm using: sbcl-1.0.29 emacs-23.1.1 slime version uncertain, but downloaded recently All running under PCLinuxOS-2010 using KDE-4.6.1
Thanks for any light you can shed on this,
pbowyer
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Carlos:
I have a little more information on the problem. It only occurs when I use the 'Compile' or 'Compile/Load' from the 'Slime' menu. If I do (compile-file "pathname.lisp") and (load "pathname.fasl") from the REPL (within Slime or directly from within SBCL), the problem does not occur. Either I have something set up incorrectly in my '.emacs' file or there is a problem with Slime. I'll attach my '.emacs. file (renamed to emacs) for your inspection, but please remember that I'm very much a newbie concerning all of this.
pbowyer
* 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....
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