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

[Slime-devel] Freeze for SLIME 2.6
by Luís Oliveira 29 Apr '14

29 Apr '14

Hello everyone, Please focus on testing and fixing regressions since the last release. I plan to release SLIME 2.6 this weekend. Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 0

[Slime-devel] Next release?
by James M. Lawrence 29 Apr '14

29 Apr '14

Hello, Slime-2.5's breakage of interactive restarts and multi-threaded kills (https://github.com/slime/slime/pull/155) are major, at least for me. This was quickly fixed, thanks to João. Could we please have another slime release before the next Quicklisp snapshot? Best, James

2 1

[Slime-devel] [slime-devel] Setting up swank contrib source paths
by Gayane Kazhoyan 29 Apr '14

29 Apr '14

Hi, I was wondering if it is possible to have the Lisp code of Slime contribs in multiple directories. So, I have the official ones in /usr/share/common-lisp/source/slime/ and I would like to, e.g. have the slime-hello-world [1] somewhere else. I tried to push the path to the asdf:*central-registry* and also setting *default-pathname-defaults* in .sbclrc and even starting a swank server with swank-loader::*source-directory* correctly set up, but then the problem is that the *source-directory* is not a list and the path to the default contribs gets lost... So, currently my .sbclrc looks like this: (require :asdf) (pushnew #p"/path/to/slime-hello-world/" asdf:*central-registry* :test #'equal) And when I M-x slime, swank still can't find the slime-hello-world Lisp part. Any ideas? Thanks! Gaya [1] https://github.com/slime/slime-hello-world

2 2

[Slime-devel] slime 2.4 with emacs 24.3.50: Loading problems after M-x slime
by Sian Mountbatten 17 Apr '14

17 Apr '14

Hello. I'm using Debian GNU/Linux (jessie) on amd64 architecture. Usually, I do not have any problems with starting slime, but, now, whenever I issue the command "M-x slime" in Emacs, I get lots of STYLE-WARNING messages from sbcl showing redefinitions of swank functions, followed by "Polling" messages suggesting that I issue the command "M-x slime-abort-connection". I have uploaded the part of my ~/.emacs.d/init.el file concerning the Slime connection to http://paste.lisp.org/+31M2. Could someone look at that paste and tell me what I'm doing wrong? -- Dr Sian Mountbatten http://www.poenikatu.co.uk/ Associate member of the FSF no. 10888 Asocia membro de la Libera Programara Fonduso n-ro 10888

3 5

[Slime-devel] [slime-devel] .swank.lisp
by Gayane Kazhoyan 16 Apr '14

16 Apr '14

Hey, I wanted to pass some s-exps to my Lisp implementation on slime startup and figured out that putting some code into .swank.lisp works. So, in my case it was telling the SBCL compiler where it's sources are: (sb-ext:set-sbcl-source-location "~/workspace/lisp/sbcl/") It looks to me that this solution is quite hacky: writing implementation specific code in the general swank setup file. Does anyone know when and from whom this file is actually being called? Couldn't find anything in the slime / swank sources. And the other question is: Is there actually a better way to do this? Maybe adding a hook on slime-load-hook and executing stuff with slime-rex or something like that... Thanks. Gaya

2 1

[Slime-devel] no whitespace in history
by Robert Brown 02 Apr '14

02 Apr '14

I just tried a recent version of Slime. When I type M-P in the slime-repl buffer I see the previous command I typed, but without any whitespace. For instance, "(cons 1 2)" appears as "(cons12)". In my .emacs file I have slime-repl-history-trim-whitespaces set to t. If I set it to nil, I get the correct history string. It looks like all whitespace is being trimmed, not just leading and trailing spaces. Emacs 24.3, SBCL 1.1.16.84, Bob

2 2

[Slime-devel] SLIME 2.5 released
by Luís Oliveira 01 Apr '14

01 Apr '14

Hello all, SLIME 2.5 is released! https://github.com/slime/slime/releases/tag/v2.<https://github.com/slime/slime/releases/tag/v2.4> 5 Cheers, -- Luís Oliveira http://kerno.org/~luis/

1 1

[slime-devel] Daily ChangeLog diff
by Helmut Eller 03 Apr '13

03 Apr '13

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2397 slime/ChangeLog:1.2398 --- slime/ChangeLog:1.2397 Tue Mar 12 10:49:47 2013 +++ slime/ChangeLog Tue Apr 2 07:41:07 2013 @@ -1,3 +1,14 @@ +2013-04-02 Luís Oliveira <loliveira(a)common-lisp.net> + + Hide SWANK debugger frames on Allegro also when the error is + signalled within threads different from the SLIME REPL's. + E.g. (mp:process-run-function nil (lambda () (error "foo"))). + + * swank-allegro.lisp (find-topframe): look deeper than 11 + frames. Still looking no deeper than 30 frames in the unlikely + event that this function is invoked out of context with a very + large stack. + 2013-03-12 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-read-interactive-args): Use read-shell-command

1 0

Re: [slime-devel] [PATCH] hiding swank frames from debugger backtrace on Allegro
by Luís Oliveira 02 Apr '13

02 Apr '13

On Tue, Apr 2, 2013 at 10:10 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: > I think this should be factored out into an implementation specific method. > I have messed similarly with ABCL to achieve a similar thing. My guess is > that each implementation might have different things it needs to do. The other implementations I looked at definitely do different things. What would, say, the ABCL and ACL backends have in common? Not sure if it's easy to share code amongst SWANK backends. Cheers, -- Luís Oliveira http://r42.eu/~luis/

1 0

[slime-devel] [PATCH] hiding swank frames from debugger backtrace on Allegro
by Luís Oliveira 02 Apr '13

02 Apr '13

Hello, As you well know, SLIME's debugger, when invoked, will inevitably add some frames to the current stack, which SWANK attempts to hide. On Allegro, when signalling an error from the REPL, those extra frames look something like this: 0: ((FLET (:TOP-LEVEL-FORM "swank-allegro.lisp" 4123) SWANK- BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT) #<Function (:INTERNAL SWANK::DEBUG-IN-EMACS 0)>) 1: (SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT #<Function (:INTERNAL SWANK::DEBUG-IN-EMACS 0)>) 2: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR @ #x218114d2>) 3: (SWANK:INVOKE-SLIME-DEBUGGER #<SIMPLE-ERROR @ #x218114d2>) 4: ((:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1)) 5: ((:INTERNAL (:TOP-LEVEL-FORM "swank-backend.lisp" 32198) 0) #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK- DEBUGGER-HOOK 1) @ #x218115f2>) 6: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Function SWANK- DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1) @ #x218115f2>) 7: (SWANK:SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR @ #x218114d2> #<Function SWANK-DEBUGGER-HOOK>) 8: (ERROR "foo") In this case, FIND-TOPLEVEL in swank-allegro.lisp successfully figures out that the first 8 frames are to be hidden. However, if the error comes from some other thread -- this can be reproduced via (mp:process-run-function nil (lambda () (error "foo"))) for example -- there will a couple of extra frames: 0: ((FLET (:TOP-LEVEL-FORM "swank-allegro.lisp" 4123) SWANK- BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT) #<Function (:INTERNAL SWANK::DEBUG-IN-EMACS 0)>) 1: (SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT #<Function (:INTERNAL SWANK::DEBUG-IN-EMACS 0)>) 2: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR @ #x21552f92>) 3: ((:INTERNAL SWANK:INVOKE-SLIME-DEBUGGER 0)) 4: ((:INTERNAL (:TOP-LEVEL-FORM "swank-backend.lisp" 32198) 0) #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:INVOKE-SLIME-DEBUGGER 0) @ #x215530e2>) 5: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Function SWANK- DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:INVOKE-SLIME-DEBUGGER 0) @ #x215530e2>) 6: ((:INTERNAL SWANK:INVOKE-SLIME-DEBUGGER 3)) 7: (SWANK::CALL-WITH-BINDINGS ..) 8: (SWANK:INVOKE-SLIME-DEBUGGER #<SIMPLE-ERROR @ #x21552f92>) 9: ((:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1)) 10: ((:INTERNAL (:TOP-LEVEL-FORM "swank-backend.lisp" 32198) 0) #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK- DEBUGGER-HOOK 1) @ #x2155309a>) 11: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Function SWANK- DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1) @ #x2155309a>) 12: (SWANK:SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR @ #x21552f92> #<Function SWANK-DEBUGGER-HOOK>) 13: (ERROR "foo") Because FIND-TOPLEVEL currently only looks at the first eleven frames, it will fail to find frame #12 in the stacktrace above. Consequently, the extra debugger frames won't be hidden. The attached patch fixes this by looking a bit further (30 frames) taking care not to fail on small stacks. I considered the idea of not hard-coding an arbitrary limit, but in the end went with the more conservative fix since walking through a very large stack takes a while. (However, it seems unlikely that FIND-TOPFRAME would ever be called in a context where SWANK-DEBUGGER-HOOK is not on the stack, modulo protocol changes that would break the whole scheme anyway.) Cheers, -- Luís Oliveira http://r42.eu/~luis

2 1