October 2004 - slime-devel - mailman3.common-lisp.net

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 07 Oct '04

07 Oct '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.547 slime/ChangeLog:1.548 --- slime/ChangeLog:1.547 Wed Oct 6 11:08:32 2004 +++ slime/ChangeLog Thu Oct 7 21:33:00 2004 @@ -1,3 +1,8 @@ +2004-10-07 Peter Seibel <peter(a)javamonkey.com> + + * swank.lisp (spawn-threads-for-connection): Bind *debugger-hook* + instead of SETF'ing it. + 2004-10-06 Luke Gorrie <luke(a)synap.se> * swank.lisp (update-indentation/delta-for-emacs): Configure Emacs

1 0

[slime-devel] :spawn clobbers *debug-hook*
by Peter Seibel 07 Oct '04

07 Oct '04

So this seems not so nice. Currently in swank.lisp we have this function: (defun spawn-threads-for-connection (connection) (let* ((socket-io (connection.socket-io connection)) (control-thread (spawn (lambda () (setq *debugger-hook* nil) (dispatch-loop socket-io connection)) :name "control-thread"))) (setf (connection.control-thread connection) control-thread) (let ((reader-thread (spawn (lambda () (setq *debugger-hook* nil) (read-loop control-thread socket-io connection)) :name "reader-thread")) (repl-thread (spawn (lambda () (repl-loop connection)) :name "repl-thread"))) (setf (connection.reader-thread connection) reader-thread) (setf (connection.repl-thread connection) repl-thread) connection))) Consequently after .swank.lisp is loaded (in which I set *debug-hook* to #'swank-debugger-hook) this function runs and clobbers the global value. Threads spawned by AllegroServe seem to inherit their value from the global value so they don't get swank-debugger-hook unless I set it in *inferior-lisp*. Is there some reason this isn't a good patch: Index: swank.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank.lisp,v retrieving revision 1.248 diff -u -r1.248 swank.lisp --- swank.lisp 6 Oct 2004 12:39:35 -0000 1.248 +++ swank.lisp 7 Oct 2004 17:55:14 -0000 @@ -507,14 +507,14 @@ (defun spawn-threads-for-connection (connection) (let* ((socket-io (connection.socket-io connection)) (control-thread (spawn (lambda () - (setq *debugger-hook* nil) - (dispatch-loop socket-io connection)) + (let ((*debugger-hook* nil)) + (dispatch-loop socket-io connection))) :name "control-thread"))) (setf (connection.control-thread connection) control-thread) (let ((reader-thread (spawn (lambda () - (setq *debugger-hook* nil) - (read-loop control-thread socket-io - connection)) + (let ((*debugger-hook* nil)) + (read-loop control-thread socket-io + connection))) :name "reader-thread")) (repl-thread (spawn (lambda () (repl-loop connection)) :name "repl-thread"))) -Peter -- Peter Seibel peter(a)javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

2 2

[slime-devel] Debugger slowness is killing me ...
by Peter Seibel 07 Oct '04

07 Oct '04

I seem to keep doing things that drop me into the debugger with really long error messages. The amount of time it takes for the debugger to return (in Allegro anyway) seems to be proportional to the length of the output that has to be displayed in the *sldb* buffer. It can take many, many tens of seconds before the *sldb* shows up. In the meantime I have no idea what the heck is going on. To get a sense of what's happening try this: CL-USER> (defparameter *c* (make-condition 'simple-error :format-control "foo: ~a" :format-arguments (list (loop for i from 1 to 100000 collect i)))) *C* Then do this, hitting '0' as soon as you see the *sldb* buffer: CL-USER> (time (with-simple-restart (abort "Bail!") (error *c*))) I got: ; cpu time (non-gc) 750 msec user, 10 msec system ; cpu time (gc) 0 msec user, 0 msec system ; cpu time (total) 750 msec user, 10 msec system ; real time 8,289 msec ; space allocation: ; 805 cons cells, 2,463,904 other bytes, 0 static bytes NIL T The I redefined format-sldb-condition in swank-allegro.lisp from: (defimplementation format-sldb-condition (c) (princ-to-string c)) to this: (defimplementation format-sldb-condition (c) (let ((str (princ-to-string c))) (if (> (length str) 256) (format nil "~a ..." (subseq str 0 256)) str))) Now I try again: CL-USER> (time (with-simple-restart (abort "Bail!") (error *c*))) ; cpu time (non-gc) 630 msec user, 0 msec system ; cpu time (gc) 0 msec user, 0 msec system ; cpu time (total) 630 msec user, 0 msec system ; real time 1,102 msec ; space allocation: ; 756 cons cells, 1,269,984 other bytes, 0 static bytes NIL T ~8x faster. I don't think the condition is the only thing that matters. For instance the stack frames can also be quite long. (If you inline the call to MAKE-CONDITION rather than passing a parameter to ERROR it will also be quite slow, even with my change.) However I'm not sure if there's a good principled way to deal with this--it seems the ideal thing would be for SWANK to somehow keep more of the information on its side and send Emacs just enough to display the buffer while allowing emacs to request more information later. For example, we could stash the condition object somewhere on the connection and send emacs an abbreviated version. Then we could provide a keybinding in the *sldb* buffer that causes emacs to send a message to SWANK saying, send me the full condition now which would then be put in the appropriate place in the buffer. Or is that crazy? If not, if someone was feeling really ambitious, maybe this could be developed into a general facility--provide a way for SWANK to send emacs an object that contains a short string and an id which emacs can then use to request a more elaborate string representation. Then on the emacs side provide a function to insert such an object into a buffer with appropriate overlays or properties or whatever to make the short string "live" so clicking on it or hitting a key while the cursor is in it causes emacs to replace it with the longer version. -Peter -- Peter Seibel peter(a)javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

2 4

[slime-devel] Getting into sldb from other threads (I'm losing my mind)
by Peter Seibel 07 Oct '04

07 Oct '04

I can swear I had this working great the other day but I don't remember doing anything special to make it happen. Anyway, here it is: I'm using AllegroServe and when one of the server threads drops into the debugger I want--of course--to be in an sldb debugger. I've given AllegroServe the magic incantation (net.aserve::debug-on :notrap) which causes it to let unhandled errors drop us into the debugger but I'm just getting to Allegro's debugger in *inferior-lisp*. I've got: #+allegro(tpl:setq-default *debugger-hook* #'swank:swank-debugger-hook) In my ~/.swank.lisp for whatever that's worth. What am I spacing on? -Peter -- Peter Seibel peter(a)javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

1 2

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 06 Oct '04

06 Oct '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.545 slime/ChangeLog:1.547 --- slime/ChangeLog:1.545 Tue Oct 5 23:39:58 2004 +++ slime/ChangeLog Wed Oct 6 11:08:32 2004 @@ -1,3 +1,12 @@ +2004-10-06 Luke Gorrie <luke(a)synap.se> + + * swank.lisp (update-indentation/delta-for-emacs): Configure Emacs + indentation settings not just for the symbol name but for all + package-qualified forms of it as well. + + * doc/slime.texi (Credits): Updated the credits list to include + more Lisp implementors who're also SLIME hackers. + 2004-10-05 Luke Gorrie <luke(a)synap.se> * swank.lisp (arglist-for-echo-area): Handle errors and return a

1 0

[slime-devel] Beer (Also: Re: SLIME docs - contributors)
by Luke Gorrie 06 Oct '04

06 Oct '04

Christian Lynbech <christian.lynbech(a)ericsson.com> writes: > In the Credits chapter, there is a footnote about the thanks for DanB > applying to his SBCL personality. > > I am unsure what the definition of "one of us" is but if that is being > listed in the hackers list above, that same footnote should perhaps > also apply to Christophe Rhodes and Martin Simmons. Quite right, and Gary Byers too. Every Lisp implementor who subscribes to slime-devel is doing great things for their karma :-) Also: Christian and I inaugurated the first Stockholm Lisp Beer Drinking Society last week. We're planning to have another one in two weeks (the 19th) if anyone in the area is interested! T'was great fun to meet so many SLIMEers in Amsterdam the other weekend too! It's my pleasure to pass on the thanks from a lot of happy people to SLIME hackerdom at large. I would also like to take this opportunity to announce the exciting new "buy a SLIME hacker a beer" campaign :-) -Luke

3 2

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 05 Oct '04

05 Oct '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.544 slime/ChangeLog:1.545 --- slime/ChangeLog:1.544 Sun Oct 3 14:33:33 2004 +++ slime/ChangeLog Tue Oct 5 23:39:58 2004 @@ -1,3 +1,10 @@ +2004-10-05 Luke Gorrie <luke(a)synap.se> + + * swank.lisp (arglist-for-echo-area): Handle errors and return a + message. + (parse-symbol): Recognise an empty package name as the KEYWORD + package. + 2004-10-03 Reini Urban <rurban(a)x-ray.at> * swank-clisp.lisp (getpid)[win32]: Use

1 0

[slime-devel] SWANK:ARGLIST-FOR-ECHO-AREA drops into the debugger!
by Pascal J.Bourguignon 05 Oct '04

05 Oct '04

Whatever the configuration, slime should not drop in the common-lisp debugger when I'm editing a file! FIND-SYMBOL: There is no package with name "ASDF" [Condition of type SYSTEM::SIMPLE-PACKAGE-ERROR] Restarts: 0: [USE-VALUE] You may input a value to be used instead. 1: [ABORT] Abort handling SLIME request. Backtrace: 0: frame binding variables (~ = dynamically): | ~ SYSTEM::*FASOUTPUT-STREAM* <--> NIL 1: EVAL frame for form (SWANK:ARGLIST-FOR-ECHO-AREA '("asdf:oo")) 2: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.28369") 3: EVAL frame for form (SWANK:START-SERVER "/tmp/slime.28369") -- __Pascal Bourguignon__ http://www.informatimago.com/ To vote Democrat or Republican, it's like changing of cabin in the Titanic.

2 1

[slime-devel] implementation type / name of slime buffers
by Pascal J.Bourguignon 04 Oct '04

04 Oct '04

With ilisp we could launch various implementation invoking by a command of same name (M-x sbcl, M-x clisp-hs, etc). Then, it would create a buffer named for the implementation instead of *ilisp[1]*. It was then easy to know in which implementation we were working and to switch between implementations, because they were distinguished by the buffer name, clearly indicated in the mode line and in the buffer list. Now, slime confuses all this, naming all its buffer *slime-repl[N]*. One thing that could be done is to add the implementation type in the prompt, perhaps with something like: (defun package-string-for-prompt (package) "Return the shortest nickname (or canonical name) of PACKAGE." (concatenate 'string (lisp-implementation-type) " " (or (canonical-package-nickname package) (auto-abbreviated-package-name package) (shortest-package-nickname package)))) but I think it would be better if slime named its buffer for the implementation type. *clisp/slime[1]*, *sbcl/slime[2]*, for example. (It may be useful that the inferior lisp buffer includes the implementation type too, or includes always the same "reference number"). -- __Pascal Bourguignon__ http://www.informatimago.com/ To vote Democrat or Republican, it's like changing of cabin in the Titanic.

3 2

[slime-devel] multiple connections
by Andras Simon 04 Oct '04

04 Oct '04

After starting two inferior lisps (the first with M-x slime, the second with C-u M-x slime), slime-list-connections correctly gives Nr Name Port Pid Type -- ---- ---- --- ---- 1 allegro (127.0.0.1 33032) 10312 International Allegro CL Enterprise Edition * 2 cmucl (127.0.0.1 33036) 10314 CMU Common Lisp But hitting RET on the first line doesn't seem to do anything. Hitting 'd' and then RET does the right thing. Also, I get various errors if I do ,restart-inferior-lisp, or even ,sayoonara. Digging a bit deeper: (slime-process) returns nil when in cmucl's repl, and the reason is probably that the inferior-lisp processes (as given by process-list) are process: #<process inferior-lisp<1>> pid: 10313 <-- shouldn't this be 10314? process: #<process inferior-lisp> pid: 10312 I use the latest cvs slime with GNU Emacs 21.2.1. Helmut says multiple connections work for him, so maybe I'm missing something, or it's an emacs version thing. Andras

2 3