I haven't had a chance to look into this myself but on the off chance anyone else has seen this: it seems that from time to time when I use IN-PACKAGE at the REPL *PACKAGE* doesn't change even though the prompt does. Sometimes, however, it does work properly.
-Peter
On Wed, 14 Jul 2004, Peter Seibel wrote:
I haven't had a chance to look into this myself but on the off chance anyone else has seen this: it seems that from time to time when I use IN-PACKAGE at the REPL *PACKAGE* doesn't change even though the prompt does. Sometimes, however, it does work properly.
Not that, but the prompt and *package* can be desynched by deleting *package* (SBCL signals an error right after the delete-package, which I backed out of by aborting the slime request):
CL-USER> (defpackage :tmp (:use :cl)) #<PACKAGE "TMP"> CL-USER> (in-package :tmp) #<PACKAGE "TMP"> TMP> (delete-package :tmp) ; Evaluation aborted TMP> *package* #<PACKAGE "COMMON-LISP-USER">
[ I think this falls into the real of "don't do that, then", unless someone is desperately bored or thinks the cause may be linked to the issue Peter is seeing. ]
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time."
Nikodemus Siivola tsiivola@cc.hut.fi writes:
On Wed, 14 Jul 2004, Peter Seibel wrote:
I haven't had a chance to look into this myself but on the off chance anyone else has seen this: it seems that from time to time when I use IN-PACKAGE at the REPL *PACKAGE* doesn't change even though the prompt does. Sometimes, however, it does work properly.
Not that, but the prompt and *package* can be desynched by deleting *package* (SBCL signals an error right after the delete-package, which I backed out of by aborting the slime request):
CL-USER> (defpackage :tmp (:use :cl)) #<PACKAGE "TMP"> CL-USER> (in-package :tmp) #<PACKAGE "TMP"> TMP> (delete-package :tmp) ; Evaluation aborted TMP> *package* #<PACKAGE "COMMON-LISP-USER">
[ I think this falls into the real of "don't do that, then", unless someone is desperately bored or thinks the cause may be linked to the issue Peter is seeing. ]
Hmmm. I don't think I explicitly deleted any packages but I may have reevaluated various DEFPACKAGE forms. Mightn't that sometimes cause an implicit DELETE-PACKAGE? Or something that would confuse SLIME in the same way? I tried various permutations I couldn't manage to confuse SLIME so it's nothing obvious. Just thinking out loud on the off chance it will lead someone to an Aha! moment.
-Peter
On Wed, 14 Jul 2004, Peter Seibel wrote:
Hmmm. I don't think I explicitly deleted any packages but I may have reevaluated various DEFPACKAGE forms. Mightn't that sometimes cause an implicit DELETE-PACKAGE? Or something that would confuse SLIME in the
It _would_ be legal, since the consequences are undefined if a defpackage form that is at variance with the current state of the package is evaluated... but that sounds like a fairly inhospitable way to go about things, so I'd be a tad surprised if some implementation does that.
I think it's just Slime getting out of synch when eg. package nicknames change, as it seems to be holding on to the package name, not the object (which would preserve identity across renames):
CL-USER> (defpackage :temporary (:use :cl) (:nicknames :tmp)) #<PACKAGE "TEMPORARY"> CL-USER> (in-package :tmp) #<PACKAGE "TEMPORARY"> TMP> (rename-package :temporary :temporary) ; remove nickname #<PACKAGE "TEMPORARY"> TMP> (find-package :tmp) ; really gone NIL TMP> *package* ; so where are we really.... #<PACKAGE "COMMON-LISP-USER"> TMP> (in-package :cl-user) #<PACKAGE "COMMON-LISP-USER"> TMP>
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java. An elegant weapon for a more civilized time."
Nikodemus Siivola tsiivola@cc.hut.fi writes:
On Wed, 14 Jul 2004, Peter Seibel wrote:
Hmmm. I don't think I explicitly deleted any packages but I may have reevaluated various DEFPACKAGE forms. Mightn't that sometimes cause an implicit DELETE-PACKAGE? Or something that would confuse SLIME in the
It _would_ be legal, since the consequences are undefined if a defpackage form that is at variance with the current state of the package is evaluated... but that sounds like a fairly inhospitable way to go about things, so I'd be a tad surprised if some implementation does that.
I think it's just Slime getting out of synch when eg. package nicknames change, as it seems to be holding on to the package name, not the object (which would preserve identity across renames):
CL-USER> (defpackage :temporary (:use :cl) (:nicknames :tmp)) #<PACKAGE "TEMPORARY"> CL-USER> (in-package :tmp) #<PACKAGE "TEMPORARY"> TMP> (rename-package :temporary :temporary) ; remove nickname #<PACKAGE "TEMPORARY"> TMP> (find-package :tmp) ; really gone NIL TMP> *package* ; so where are we really.... #<PACKAGE "COMMON-LISP-USER"> TMP> (in-package :cl-user) #<PACKAGE "COMMON-LISP-USER"> TMP>
Okay, now I'm afraid I dorked something up with my change the other day to abbreviate the package name in the prompt. Namely I'm afraid that somewhere SLIME is using the abbreviated name, which is not necessarily a real package nickname, as the name of the package. Can someone explain the basic theory of how SLIME thinks about packages?
-Peter
Peter Seibel peter@javamonkey.com writes:
Nikodemus Siivola tsiivola@cc.hut.fi writes:
On Wed, 14 Jul 2004, Peter Seibel wrote:
Hmmm. I don't think I explicitly deleted any packages but I may have reevaluated various DEFPACKAGE forms. Mightn't that sometimes cause an implicit DELETE-PACKAGE? Or something that would confuse SLIME in the
It _would_ be legal, since the consequences are undefined if a defpackage form that is at variance with the current state of the package is evaluated... but that sounds like a fairly inhospitable way to go about things, so I'd be a tad surprised if some implementation does that.
I think it's just Slime getting out of synch when eg. package nicknames change, as it seems to be holding on to the package name, not the object (which would preserve identity across renames):
CL-USER> (defpackage :temporary (:use :cl) (:nicknames :tmp)) #<PACKAGE "TEMPORARY"> CL-USER> (in-package :tmp) #<PACKAGE "TEMPORARY"> TMP> (rename-package :temporary :temporary) ; remove nickname #<PACKAGE "TEMPORARY"> TMP> (find-package :tmp) ; really gone NIL TMP> *package* ; so where are we really.... #<PACKAGE "COMMON-LISP-USER"> TMP> (in-package :cl-user) #<PACKAGE "COMMON-LISP-USER"> TMP>
Okay, now I'm afraid I dorked something up with my change the other day to abbreviate the package name in the prompt. Namely I'm afraid that somewhere SLIME is using the abbreviated name, which is not necessarily a real package nickname, as the name of the package. Can someone explain the basic theory of how SLIME thinks about packages?
I just checked in a change that adds a new SLIME connection var slime-lisp-package-prompt-string which holds the name used by the prompt which may or may not be an actual package name or nickname. I don't know if this was the root of my earlier problems but it can't have been good before that slime-lisp-package was sometimes not a real package name.
-Peter
Peter Seibel peter@javamonkey.com writes:
Can someone explain the basic theory of how SLIME thinks about packages?
The main thing is that the "current package" is determined by Emacs state, not by *PACKAGE*. In a source buffer the current package is determined by searching backwards for the nearest IN-PACKAGE and in the REPL it's determined by looking at the local variable that you just defined. :-)
When Emacs makes an RPC it includes the package name in the request. The Lisp side finds the package and binds it to *BUFFER-PACKAGE* and then uses it in the appropriate ways, e.g. as *PACKAGE* when reading/eval'ing code from the user.
One issue is when you evaluate code in the REPL that reassigns *PACKAGE*, e.g. calling IN-PACKAGE, you want that to change the current REPL package. We detect these assignments specially with some code in SWANK::EVAL-REGION and send a (:new-package FOO) update message to Emacs.
Another complication is that code you enter in the REPL will be evaluated in an environment that has a dynamic binding of *PACKAGE* and various other things (e.g. standard streams), so you can't change their global bindings with SETQ.
That help any?
-
Luke Gorrie -
Nikodemus Siivola -
Peter Seibel