gmane.lisp.slime.devel

slime-undefmethod contrib

Madhu — 2008-12-01T15:24:34

Attached is my first contrib submission. M-x slime-undefine-function does not help when you wish to remove a specific method. This contrib adds a new function slime-undefmethod. Invoking M-x slime-undefmethod with the point inside a defmethod definition in your source will find and remove the specific method. I've posted the code before on usenet, but felt it may be more useful if packaged up with slime. Comments welcome. -- Madhu

Re: Call stack when using Lisp debugger from sldb

Nikodemus Siivola — 2008-12-01T13:15:03

Agreed. I would really like to rip the session stuff out and replace it with stream based synchronization. I don't remember what it was that stopped me the last time I was looking at it. Cheers, -- Nikodemus

Re: hacking system internals from Slime

Madhu — 2008-12-01T10:51:53

* "Nikodemus Siivola" <633d72b0812010050l11be3cd8p871f0e2a8dbe38c7< at >mail.gmail.com> : Wrote on Mon, 1 Dec 2008 10:50:07 +0200: | An 80% solution might be being able to tell Slime to stop talking to | the lisp, except for communications triggered by explicit REPL | evaluations. Does this sound like a feasible idea? Any other | suggestions? Using NIL for *COMMUNICATION-STYLE* might work, i.e. by specifying the `"read and process requests sequentially" communication style.' in SETUP-SERVER. -- Madhu

Re: hacking system internals from Slime

Tobias C. Rittweiler — 2008-12-01T10:14:24

Do not use the slime-autodoc contrib, or alternatively, set `slime-use-autodoc-mode' to nil. (Arglists will now be displayed only when you press SPACE. If that's still too much magic for you, set `slime-space-information-p' to nil.) HTH, -T.

Re: hacking system internals from Slime

Helmut Eller — 2008-12-01T09:44:43

I'm not sure that I understand your problem. One problem that I encountered is that calling BREAK inside the compiler isn't very feasible because SLIME calls the compiler for other reasons too. For this situation I use this special break function: (defvar *break-in-compiler* nil) (defun compiler-break (&rest args) (when *break-in-compiler* (apply #'break (or args (list "compiler-break"))))) (compile 'compiler-break) (defun debug-compile-defun (s) (let ((*break-in-compiler* t) (c::*check-consistency* t)) (with-input-from-string (in s) (ext:compile-from-stream in :trace-stream *standard-output* :verbose t :print t :progress t :byte-compile nil)))) COMPILER-BREAK invokes BREAK only if *BREAK-IN-COMPILER* is true. To actually invoke the breakpoint I invoke the compiler via DEBUG-COMPILE-DEFUN.

Re: Call stack when using Lisp debugger from sldb

Helmut Eller — 2008-12-01T09:25:59

It should be possible to call swank:simple-break to get SLDB back. A problem is of course the very unfriendly session management of SBCL's debugger. E.g. it doesn't even print a message that the debugger is waiting for the session. It's also a bit pointless that the debugged thread needs a terminal session when it doesn't even access the terminal. That's the case when the debugger does all I/O over SLIME's streams. Helmut.

hacking system internals from Slime

Nikodemus Siivola — 2008-12-01T08:50:07

Here's a workflow issue that I run into periodically: 1. While working on SBCL I instrument some internal operation to see what is going on -- let's say with BREAK. 2. Before I can run my test-case I need to page my way thru a number of debugger entries (sometimes a HUGE number) due to eg. cursor movement in a Lisp buffer causing the instrumented operation to be used. I'm not looking for a 100% solution, because I doubt anything like that exists. Hacking a live system is always tricky that way... An 80% solution might be being able to tell Slime to stop talking to the lisp, except for communications triggered by explicit REPL evaluations. Does this sound like a feasible idea? Any other suggestions? Cheers, -- Nikodemus

Re: Call stack when using Lisp debugger from sldb

Nikodemus Siivola — 2008-12-01T07:26:07

Perhaps the default should be *not* returning from SLDB before entering the native debugger, since that is not undoable -- whereas "Gaah, Slime frames!" can then be fixed by going to to SLDB and invoking the native debugger with the prefix. ? Cheers, -- Nikodemus

Re: Reincarnate "eval..."

Gábor Melis — 2008-11-30T22:14:46

The attached patch prints CON:sbcl{3/2} where 3 is the number of non-debugged requests and 2 is the number of debugged requests. If the second one is zero it's omitted along with the / character. It used to be "CON:sbcl{debugged..}" which is less informative, imho. Cheers, Gabor

Daily ChangeLog diff

Helmut Eller — 2008-11-30T03:33:01

Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.141 slime/contrib/ChangeLog:1.142 --- slime/contrib/ChangeLog:1.141Sat Nov 22 12:19:26 2008 +++ slime/contrib/ChangeLogSat Nov 29 11:12:39 2008 < at >< at > -1,3 +1,9 < at >< at > +2008-11-29 Tobias C. Rittweiler freebits.de> + +* slime-package-fu.el (slime-goto-package-source-definition): +`(slime-pop-to-location loc 'excursion)' no longer exists; use +`(slime-goto-source-location loc)' instead. + 2008-11-22 Geoff Wozniak wozniak.ca> * swank-c-p-c.lisp (parse-completion-arguments): Change the

Re: slime-package-fu.el

Tobias C. Rittweiler — 2008-11-29T11:13:03

Thanks, should be fixed in CVS. -T.

Re: slime-package-fu.el

Stas Boukarev — 2008-11-29T08:19:02

Apparently, there must be no argument at all, seems to work fine without it.

slime-package-fu.el

Stas Boukarev — 2008-11-29T08:15:24

slime-export-symbol-at-point doesn't work: it calls slime-pop-to-location with argument 'excursion, which it no longer accepts. Though if i change it to 'frame or 'window, it still doesn't work properly.

Daily ChangeLog diff

Helmut Eller — 2008-11-24T03:33:01

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1586 slime/ChangeLog:1.1587 --- slime/ChangeLog:1.1586Sat Nov 22 22:36:40 2008 +++ slime/ChangeLogSun Nov 23 22:11:36 2008 < at >< at > -1,3 +1,18 < at >< at > +2008-11-23 Helmut Eller common-lisp.net> + +`q' in temp buffers should only delete the window if it was newly +created for the buffer. + +* slime.el (slime-display-popup-buffer): New function. Recognize +if the window didn't exist before. Save the created window and +the selected window in buffer local variables. +(slime-make-popup-buffer): Renamed from slime-popup-buffer. +(slime-popup-buffer-quit): Delete the created window (if needed) +and restore the old selected window. Don't touch other windows. + +(slime-edit-value-callback): Calling lisp-mode deletes all local +variables. We need to that inside with-popup-buffer. + 2008-11-22 Helmut Eller common-lisp.net> * slime.el (slime-update-all-modelines): Only walk through

Re: Highlighting of forms from sldb?

Raymond Toy — 2008-11-24T00:41:53

Oh, I see. If I press v, the form is temporarily highlighted. It's a little annoying that when the file is first loaded, the highlighting happens so fast that I often don't see it, but pressing v highlights it again. That's nice. Ray

Re: 'q' in temporary buffer closes the window ratherthan returning to REPL

Brett Hoerner — 2008-11-24T00:27:02

I saw the commit and am using HEAD, but if I pull up docs (I'm using Clojure, should this matter?) - which opens over my REPL and hit 'q', it still closes the window. That said, knowing C-c C-z exists is very handy regardless. Brett

Re: 'q' in temporary buffer closes the window ratherthan returning to REPL

Helmut Eller — 2008-11-23T22:20:58

[...] No, it works just like you described. I just don't mind (to much) that W2 get's deleted. I have a global key binding `C-c s' for slime-selector, which I use a lot. However, in CVS HEAD, W2 should no longer be deleted. It should be deleted only if you started with a single window. Helmut.

Re: 'q' in temporary buffer closes the window ratherthan returning to REPL

Liam Healy — 2008-11-23T13:49:32

For me, C-c b takes me to the REPL from any buffer at all, SLIME-aware or not. This is slime-current-buffer. Liam

Re: Call stack when using Lisp debugger from sldb

Raymond Toy — 2008-11-23T16:15:31

That's a reasonable compromise, because there are times where I wished I could return to sldb. :-) Now I can, if I remember to use a prefix. Not sure which should be the default behavior, but I'm grateful to have a choice. Thanks! Ray

Re: Highlighting of forms from sldb?

Raymond Toy — 2008-11-23T16:11:37

Yes, I've noticed that too. Not sure. I guess my problem is that with xemacs, the highlighting is sometimes removed so fast that I don't even see it. Perhaps that's a bug in xemacs. I'll look in to it a bit and see if the highlighting can be on for a bit longer... Ray

Daily ChangeLog diff

Helmut Eller — 2008-11-23T03:33:01

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1581 slime/ChangeLog:1.1586 --- slime/ChangeLog:1.1581Sun Nov 2 12:05:24 2008 +++ slime/ChangeLogSat Nov 22 22:36:40 2008 < at >< at > -1,3 +1,40 < at >< at > +2008-11-22 Helmut Eller common-lisp.net> + +* slime.el (slime-update-all-modelines): Only walk through +widnow-list not buffer-list. +(slime-restart-or-init-modeline-update-timer): Inrease the timer +interval to 0.5 seconds. + +2008-11-22 Gábor Melis retes.hu> + +Reincarnate "eval..." (almost) + +* slime.el (slime-compute-modeline-connection-state): Return the +number of outstanding requests if connected. +(slime-update-all-modelines): Renamed from slime-update-modelines, +loops through all slime buffers. +(slime-restart-or-init-modeline-update-timer): New function. +(slime-dispatch-event): Arrange for modelines to be updated on +:EMACS-REX and :RETURN. + +2008-11-22 Helmut Eller common-lisp.net> + +* swank.lisp (invoke-default-debugger): New condition type. +(swank-debugger-ho