First of, thanks to everyone working on this -- slime seems great.
Simple question: when the sldb window pops up -- and I type e -- or other evaluation related functions, the interactions occur in the minibuffer -- which doesn't work well for me for forms/results that extend over multiple lines. What's the accepted wisdom wrt. what one could do here?
Second, when I type 't' -- sometimes the top frame disappears in sldb -- and my cursor is left at the next frame.. is this a bug? (I'm using cmucl on FC2 via xemacs).
Thanks.
Sundar Narasimhan sundar@itasoftware.com writes:
First of, thanks to everyone working on this -- slime seems great.
Thanks!
Simple question: when the sldb window pops up -- and I type e -- or other evaluation related functions, the interactions occur in the minibuffer -- which doesn't work well for me for forms/results that extend over multiple lines. What's the accepted wisdom wrt. what one could do here?
I can think of a few related points, I don't know if any is what you're after -
You can use `C-u :' and (now) `C-u e' to have the evaluation result printed into the REPL buffer instead of displayed in a message.
You can use `M-x slime-ensure-typeout-frame' to create a new small frame for displaying the messages with instead of the echo area. (When you close the frame it'll go back to using the echo area.)
You can actually use the REPL even while debugging an error from an REPL evaluation. This useful but seedy feature is because the REPL is really based on RPCs rather than streams.
We've had requests for a feature to open a new REPL from the SLDB buffer but we're currently resisting creeping features.
Second, when I type 't' -- sometimes the top frame disappears in sldb -- and my cursor is left at the next frame.. is this a bug? (I'm using cmucl on FC2 via xemacs).
Thanks for the report. It looks like Helmut's fixed this now.
-Luke
You can actually use the REPL even while debugging an error from an REPL evaluation. This useful but seedy feature is because the REPL is really based on RPCs rather than streams.
Thanks Luke. This is what I've been doing.
Luke Gorrie wrote:
Simple question: when the sldb window pops up -- and I type e -- or other evaluation related functions, the interactions occur in the minibuffer -- which doesn't work well for me for forms/results that extend over multiple lines. What's the accepted wisdom wrt. what one could do here?
I can think of a few related points, I don't know if any is what you're after -
You can use `C-u :' and (now) `C-u e' to have the evaluation result printed into the REPL buffer instead of displayed in a message.
You can use `M-x slime-ensure-typeout-frame' to create a new small frame for displaying the messages with instead of the echo area. (When you close the frame it'll go back to using the echo area.)
You can actually use the REPL even while debugging an error from an REPL evaluation. This useful but seedy feature is because the REPL is really based on RPCs rather than streams.
BTW -- following up on this. I may not have my mental model quite right yet -- if I type several 'n' or 'p' in SLDB -- and then type in the REPL loop -- should I expect to (or not) get eval-in-frame semantics right -- i.e. the scope is as indicated by the cursor in the sldb buffer? (I'm a bit mystified wrt. what scope my evaluations are taking place in this case).
A couple of other newbie questions: 1. I notice that c-c c-m (macroexpand) does not seem to work correctly wrt. packages.. for example in cmu lisp -- it inserts common-lisp-user: rather than the package the form appears in. Is there an equivalent of reparse-attribute-list?
2. When I type 'r' within sldb I get the foll.. how do I get to restart a frame.. w/ the same arguments as originally invoked..?
No matching method for the generic function #<STANDARD-GENERIC-FUNCTION SWANK-BACKEND:RESTART-FRAME (0) {5717D391}>, when called with arguments (0). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
Restarts: 0: [CONTINUE] Retry call to :FUNCTION. 1: [ABORT] Return to sldb level 1. 2: [ABORT] Abort handling SLIME request. 3: [DESTROY] Destroy the process
Sundar Narasimhan sundar@itasoftware.com writes:
BTW -- following up on this. I may not have my mental model quite right yet -- if I type several 'n' or 'p' in SLDB -- and then type in the REPL loop -- should I expect to (or not) get eval-in-frame semantics right
No. Only the commands named `in-frame' will actually evaluate in the specific frame. Everything else, including REPL input, will just be EVAL'd in the null lexical environment from deep in the debugger loop.
I have a feeling that people are expecting different behaviour, but I'm not sure exactly what. Please feel free to spell it out.
- I notice that c-c c-m (macroexpand) does not seem to work
correctly wrt. packages.. for example in cmu lisp -- it inserts common-lisp-user: rather than the package the form appears in.
It does the right thing in the examples I've tried. More details?
Is there an equivalent of reparse-attribute-list?
I'm not familiar with that, what's it do?
- When I type 'r' within sldb I get the foll.. how do I get to
restart a frame.. w/ the same arguments as originally invoked..?
No matching method for the generic function #<STANDARD-GENERIC-FUNCTION SWANK-BACKEND:RESTART-FRAME (0)
This ugly message really means that the RESTART-FRAME feature is not implemented for CMUCL. I would like to improve such messages but it's at least slightly tricky, as I believe is supporting that feature.
-Luke
Luke Gorrie wrote:
Sundar Narasimhan sundar@itasoftware.com writes:
BTW -- following up on this. I may not have my mental model quite right yet -- if I type several 'n' or 'p' in SLDB -- and then type in the REPL loop -- should I expect to (or not) get eval-in-frame semantics right
No. Only the commands named `in-frame' will actually evaluate in the specific frame. Everything else, including REPL input, will just be EVAL'd in the null lexical environment from deep in the debugger loop.
I have a feeling that people are expecting different behaviour, but I'm not sure exactly what. Please feel free to spell it out.
Hi, Luke -- I wonder if there should be a "set-frame-in-repl" command.. which when invoked.. will make these evaluations occur in the specific frame. I know you mentioned C-u : and C-u e, but the former seems not to eval in frame, and the latter goes to the minibuffer. What I think I would like is to do a 'set-frame' and then just c-x o to the other window and continue to interact there.. which will avoid a lot of the limitations associated with having limited screen real estate in the minibuffer area. Does that make sense?
- I notice that c-c c-m (macroexpand) does not seem to work
correctly wrt. packages.. for example in cmu lisp -- it inserts common-lisp-user: rather than the package the form appears in.
It does the right thing in the examples I've tried. More details?
Ok.. We have code that essentially does a (in-package :xyz) at the top of the file. Unfortunately I have a habit of moving to a particular form, and then macro expanding it to see the code. When I do this in slime mode.. I get global variables and other things prefixed with common-lisp-user::. But when I actually cut-paste (macroexpand 'myform) or (macroexpand1 'myform) in the repl .. I don't get this .. any idea on what could be happening?
<>Is there an equivalent of reparse-attribute-list? I'm not familiar with that, what's it do?
On certain machines.. :) emacs would, if you had a line like so at the top of your file.. ;;;-*- Mode: Lisp; Package: foo; -*-
M-x reparse-attribute-list setup the evaluation context to do the appropriate thing. In ilisp -- this is similar to set-buffer-package-lisp?
<>
- When I type 'r' within sldb I get the foll.. how do I get to
restart a frame.. w/ the same arguments as originally invoked..?
No matching method for the generic function #<STANDARD-GENERIC-FUNCTION SWANK-BACKEND:RESTART-FRAME (0)
This ugly message really means that the RESTART-FRAME feature is not implemented for CMUCL. I would like to improve such messages but it's at least slightly tricky, as I believe is supporting that feature.
Yes.. I just realized cmucl doesn't have this -- thanks :)
-Luke
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Sundar Narasimhan sundar@itasoftware.com writes:
Hi, Luke -- I wonder if there should be a "set-frame-in-repl" command..
This sounds like something that other people have wanted too, more or less. We can look at it in the future, but it's a bit big to slip into slime 1.0, which should go out in a week or two warts and all :-)
Ok.. We have code that essentially does a (in-package :xyz) at the top of the file.
The modeline shows what SLIME thinks is the current package. You should see "Slime:xyz", do you?
This is based on a text search for an in-package form, first backwards then forwards. The modeline is updated on an idle timer just for display purposes. Any evaluation/macroexpansion/etc will lookup the package by search afresh each time.
An exception is popup buffers like apropos results. These inherit the package that was current when they popped up (stored in a buffer-local variable.)
Less-than-intuitively, if the current buffer's declared package doesn't exist then the CL-USER package is used as a default. This "may be difficult to construe as a feature."
Unfortunately I have a habit of moving to a particular form, and then macro expanding it to see the code. When I do this in slime mode.. I get global variables and other things prefixed with common-lisp-user::. But when I actually cut-paste (macroexpand 'myform) or (macroexpand1 'myform) in the repl .. I don't get this .. any idea on what could be happening?
Can you reproduce this with a really simple/explicit example?
One possible explanation is:
The macro was accidentally defined in the CL-USER package. It refers to the wrong symbols.
You macroexpand it in a Lisp buffer belonging to a different package and the result is formatted with that package being *package*. The result thus includes common-lisp-user:: qualifiers.
You then paste the form into (macroexpand '...) in the REPL. The REPL happens to be in the CL-USER package so it prints with that as *package* and the result has no package qualifiers.
I can't be sure without more information.
On certain machines.. :) emacs would, if you had a line like so at the top of your file.. ;;;-*- Mode: Lisp; Package: foo; -*-
SLIME currently works solely on text-search for an in-package form.
Note that those magic "file cookies" are meaningful in Emacs too, and they can have awful side-effects. If the variable was in lowercase:
-*- package: foo -*-
Then Emacs would create a buffer-local variable called `package'. Unfortunately, that local variable could clobber dynamic bindings of `package' when switching buffers, and thus accidentally rebind a local variable some function was using!
Really disgusting, and this has happened somewhere in SLIME, and it still can. Be careful of your magic file cookies :-)
Cheers, Luke
Luke Gorrie wrote:
Sundar Narasimhan sundar@itasoftware.com writes:
Hi, Luke -- I wonder if there should be a "set-frame-in-repl" command..
This sounds like something that other people have wanted too, more or less. We can look at it in the future, but it's a bit big to slip into slime 1.0, which should go out in a week or two warts and all :-)
Cool!
Ok.. We have code that essentially does a (in-package :xyz) at the top of the file.
The modeline shows what SLIME thinks is the current package. You should see "Slime:xyz", do you?
It does say that and yet c-c c-m puts the cl-user package in front of symbols.. weird.
This is based on a text search for an in-package form, first backwards then forwards. The modeline is updated on an idle timer just for display purposes. Any evaluation/macroexpansion/etc will lookup the package by search afresh each time.
I suppose I should look up the code that does this.. to see if the package is being handled correctly. I'll look into this more.
-
Luke Gorrie -
Sundar Narasimhan