slime-devel April 2013

slime-devel@common-lisp.net

3 participants
5 discussions

[slime-devel] SLIME talk at the Emacs Conference
by Luke Gorrie 08 Apr '15

08 Apr '15

Howdy! Long time no chat :-) I will give a talk at the Emacs Conference (emacsconf.org, London March 31) called "How to write an Emacs-based IDE like SLIME". The idea is to demo SLIME, explain how its development works, and give some encouragement and practical tips to people who might want to build something similar for other languages. If you have some ideas please fire away :) particularly about things I might easily overlook being as my SLIME know-how is about 10 years old! Cheers, -Luke

2 2

[slime-devel] cutting and pasting S-expressions from buffer to REPL
by Faheem Mitha 27 Dec '14

27 Dec '14

Hello everyone, I've recently started using SLIME with SBCl on Debian, where SLIME defaults to using SBCL, at least when it is installed. So far I am very impressed. I haven't been able to take off and fly yet, but I'm on the runway.:-) I'm particularly impressed by the underlining source which has compile errors, and doing a popup on mouseover feature. I don't know whose idea this was, but it is pretty damn cool. Does anyone know the history of this feature? So, I have a question about SLIME. When debugging, or indeed otherwise, I find it useful to copy and paste S-expressions from a buffer to the REPL. I've been using the mouse for this, which is decidedly sub-optimal. I hate using the mouse. I was thinking that it would be handy to have a command which would copy and paste S-expressions from a buffer to the REPL, while at the same time switching the buffer to the REPL. The S-expression would be chosen by having the cusor to the right of the closing expression. I'm not sure if this position has a name. I don't know if this command already exists. I could not find it in the manual. If it doesn't, could someone tell me what code would tell emacs to do this? My knowledge of Emacs programming is non-existent. Please CC me on any reply. Thanks. Regards, Faheem

6 14

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel April 2013