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

[slime-devel] Indenting macro bodies
by Arthur Lemmens 17 Oct '04

17 Oct '04

Hi, I'm a happy new user of SLIME (using it with ACL 7.0 beta), but I have one question. After defining and compiling macro with a &body parameter, like (defmacro test ((x) &body body) `(progn (list ,x) ,@body)) I would like all use of such a macro to be indented as follows: (test (1) (do 'a) (do 'b)) but SLIME does it this way: (test (1) (do 'a) (do 'b)) Is there some way to get the indentation I want? It would be even better if this would also work for macros that weren't defined by me but that I just loaded into the system. A better indentation for the bodies of flet and labels-functions would also be nice, by the way. Thanks, Arthur

9 14

[slime-devel] Problem with Clisp on WindowsNT
by Nico 12 Oct '04

12 Oct '04

I use CLisp with Slime on Windows NT. If I work in Slime and save an image, the reload of the saved image cause a stack overflow problem. The exact message is : *** - Program stack overflow. RESET My guess is that the problem is caused by the reloading of Slime that interacts with the Slime that is already in the saved image. The saved image can be loaded without a problem if Slime is not used. What is the workaround ? I have tried to disable the loading of Slime since the Lisp part of Slime should be part of the saved image, but had no success. Any suggestions would be appreciated. Nico Swart.

3 3

[slime-devel] FreeBSD+sbcl: sldb fails to pop up
by Ari Johnson 10 Oct '04

10 Oct '04

I'm running FreeBSD 5.2.1 and sbcl 0.8.12, using GNU Emacs 21.3. The sldb debugger fails to pop up when an error occurs, and instead I have to interact with the sbcl debugger in the REPL buffer. Am I missing a prerequisite somewhere? I threw slime in /usr/local/share/emacs/site-lisp/slime and it loads fine. The pertinent part of my .emacs follows, and I then do M-x slime to start it up. Thanks to anyone who can help me out on this. --- ;;; SLIME (setq inferior-lisp-program "sbcl") (setq slime-startup-animation nil) (require 'slime) (slime-setup)

2 4

[slime-devel] cl-indent / font-lock
by Pascal J.Bourguignon 09 Oct '04

09 Oct '04

In my pjb-cl-faces.el file you can find some Common-Lisp font-locking. I've gathered all Common-Lisp symbols from CLHS, along with their "kind": (mapcar (function first) *kind-to-face-map*) ==> ("Warning" "Variable" "Constant Variable" "Symbol" "System Class" "Class" "Condition Type" "Type" "Type Specifier" "Declaration" "Restart" "Special Operator" "Special Form" "Local Macro" "Macro" "Accessor" "Local Function" "Standard Generic Function" "Function" "Keyword") and defined a face for each of these kinds. Then there is code that generate the font-lock-keywords for all CL symbols. There remains two problems: some symbols are used for different things in different contexts (eg. a type and a function). My font-lock code does not analyses the the syntactic context. And it's rather slow (but usable!). One lesson is that it would be really very useful for CL tool builders to have the CLHS under the form of processable "meta data". One could easily generate all the lisp-indent-function attributes for all CL functions and macros, or we could automatically generate any indentation (or other source analysis) function. -- __Pascal Bourguignon__ http://www.informatimago.com/ Voting Democrat or Republican is like choosing a cabin in the Titanic.

1 0

[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