[slime-devel] Backup tags handling for M-.
I was using Emacs to do some Lisp code browsing the other day. Along the way, I was trying to jump around to some definitions. I tried using M-. but the code had not been compiled or loaded into the inferior Lisp process. As a result, SLIME complained that it didn't know about the defun I was looking for. I turned off SLIME mode and generated a tags file using standard emacs. Using standard emacs Lisp-mode, I was able to browse the definitions using the tags file. So, the question is, is it possible for SLIME to fall back to using the tags file like emacs Lisp-mode when it's standard behavior fails? Now, I could just go around turning off slime-mode every time I load a file, but that's really a pain. Since I have set up a mode hook, every Lisp file loads with slime-mode by default, which is how I want things most of the time when I'm developing. The problem is when trying to browse a library. Even if you turn slime-mode off for one file, it turns itself back on as soon as you use M-. with standard lisp-mode. -- Dave Roberts <ldave@droberts.com>
Dave Roberts <ldave@droberts.com> writes:
I was using Emacs to do some Lisp code browsing the other day. Along the way, I was trying to jump around to some definitions. I tried using M-. but the code had not been compiled or loaded into the inferior Lisp process. As a result, SLIME complained that it didn't know about the defun I was looking for. I turned off SLIME mode and generated a tags file using standard emacs. Using standard emacs Lisp-mode, I was able to browse the definitions using the tags file.
So, the question is, is it possible for SLIME to fall back to using the tags file like emacs Lisp-mode when it's standard behavior fails?
Certainly this is possible, but why not compile/load the module that you're browsing instead? Otherwise (define-key slime-mode-map "\M-." 'find-tag) would rebind M-. to use TAGS in slime-mode. The original bindings can then by restored with (load "slime"). -Luke
On Fri, 23 Apr 2004, Luke Gorrie wrote:
tags file like emacs Lisp-mode when it's standard behavior fails?
Certainly this is possible, but why not compile/load the module that you're browsing instead?
Because the box is under too much strain already, or loading the module would take too long, or the module is not in a loadable state. The first one is frequently the case for me. I've lost processes to OOM killer often enough to be wary when I have eg. long builds in progress. Cheers, -- Nikodemus
Nikodemus Siivola writes:
On Fri, 23 Apr 2004, Luke Gorrie wrote:
tags file like emacs Lisp-mode when it's standard behavior fails?
Certainly this is possible, but why not compile/load the module that you're browsing instead?
Because the box is under too much strain already, or loading the module would take too long, or the module is not in a loadable state.
Concur. This is what ILISP does, and I think it's fine behaviour. One often wants to view some files "read only", not polluting the state of the underlying lisp world with undesired symbols. I'd imagine something like: (defvar *slime-follow-reference-style* 'slime-references-use-inferior-lisp-only "Could also be set to slime-references-fallback-on-tags") so the user can choose what they like.
Alain.Picard@memetrics.com writes:
Nikodemus Siivola writes:
On Fri, 23 Apr 2004, Luke Gorrie wrote:
tags file like emacs Lisp-mode when it's standard behavior fails?
Certainly this is possible, but why not compile/load the module that you're browsing instead?
Because the box is under too much strain already, or loading the module would take too long, or the module is not in a loadable state.
Concur. This is what ILISP does, and I think it's fine behaviour. One often wants to view some files "read only", not polluting the state of the underlying lisp world with undesired symbols.
Okay, I'll surrender in to the rising "fallback on tags" movement before it gets ugly :-) Now you can do this: (setq slime-edit-definition-fallback-function 'find-tag)
Hello, I'm a CL newbie (though reading cll for several months) and i'm trying to write an application based on araneida, and ... using slime :) I'm using a threaded http listener instance (from araneida), and i'd like to be able to get to the repl of a (background) thread when a url handler fails. In the "troubleshooting" section of araneida documentation, there is an indication explaining how to that with slime : (setf *restart-on-handler-errors* (swank:slime-debugger-function)) but swank:slime-debugger-function doesn't seem to exist. After some googling, i found several mails from D.Barlow on this list archives describing that, with the further indication that this has to be written from the *slime-repl* buffer for all the threads to know about that (or so i understood, anyway :) ). It didn't work either. I insisted a bit and grep'ed my HEAD working copy of slime (updated today). While i actually read about slime-debugger-function being added (see Changelog line "2003-11-29 Daniel Barlow <dan@telent.net>"), i can't find it in the source. :-( Has it been replaced by something else ? I'm using : - slime HEAD (updated today) - sbcl 0.8.10 - linux 2.6.4 (with Con Kolivas patches) Thanks for your help -- Pierre-François Gomez GnuPG: 0xA38AE42C
Pierre-François Gomez <pierre-francois.gomez@NOSPAM-laposte.net> writes:
Has it been replaced by something else ?
Sort of. I'm not familiar with Araneida, but it might work if you do: (setf *restart-on-handler-errors* #'swank:swank-debugger-hook) Cheers, Helmut (wondering how we could write a test for this stuff)
Helmut Eller writes:
Pierre-François Gomez <pierre-francois.gomez@NOSPAM-laposte.net> writes:
Has it been replaced by something else ?
Sort of. I'm not familiar with Araneida, but it might work if you do:
(setf *restart-on-handler-errors* #'swank:swank-debugger-hook)
Nope, araneida:*restart-on-handler-errors* is a function of one argument, the condition. This should work, though: (setf *restart-on-handler-errors* 'swank::debug-in-emacs) What I do is something like this: (defvar *debug* t) (defmethod handle-request :around ((handler my-handler) request) (if *debug* (let ((*debugger-hook* 'swank:swank-debugger-hook)) (handler-bind ((error #'invoke-debugger)) (call-next-method))) (call-next-method))) When *debug* is true, the call to handle-request (which in turn calls the various handle-request-* functions) is wrapped in code that catches any errors and sends them to the slime debugger. Of course, my app already needed that :around method for other reasons. I assume this will all work right with the threaded listener; I use the serve-event based one. -- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
"Thomas F. Burdick" <tfb@OCF.Berkeley.EDU> writes:
Helmut Eller writes:
Pierre-François Gomez <pierre-francois.gomez@NOSPAM-laposte.net> writes:
Has it been replaced by something else ?
Sort of. I'm not familiar with Araneida, but it might work if you
What do you mean by "sort of" ? Has it been renamed ? Not that this is really important : i'm just curious :)
do:
(setf *restart-on-handler-errors* #'swank:swank-debugger-hook) (snip the test by Thomas f. Burdick) I assume this will all work right with the threaded listener; I use the serve-event based one.
I confirm your assumption : it works with the threaded listener, too. I simply added the setf form just after having loaded araneida (it's a separate sbcl image dedicated to my future app) and when a handler produces an error (i just added an 'assert' form), i now have this message in the *slime-repl* buffer : debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread 25738: invalid number of arguments: 1 I then discovered M-x slime-list-threads and i was able to "enter" the thread using 'd' on its id. I have the following backtrace : Restarts: 0: [CONTINUE] Continue from interrupt. 1: [ABORT-RESPONSE] Abort this response and answer another request 2: [DESTROY-THREAD] Destroy this thread (25738) Backtrace: 0: ("XEP for SWANK-DEBUGGER-HOOK" 1 #<SIMPLE-ERROR {941DD01}> #<unused argument>)[:EXTERNAL] 1: (ARANEIDA::HANDLER-DEBUGGER-HOOK #<SIMPLE-ERROR {941DD01}> #<unavailable argument>) 2: (INVOKE-DEBUGGER 1 #<SIMPLE-ERROR {941DD01}>)[:EXTERNAL] 3: (ERROR 1 #<SIMPLE-ERROR {941DD01}>)[:EXTERNAL] 4: (SB-KERNEL:ASSERT-ERROR 3 (TMP-OF HANDLER) NIL NIL)[:EXTERNAL] 5: ((HANDLE-REQUEST-RESPONSE (TEST-ERROR-HANDLER T T)) #<unavailable argument> #<unavailable argument> #<TEST-ERROR-HANDLER {9DCF159}> #<unavailable argument> #<REQUEST {92926B9}>) 6: ((HANDLE-REQUEST (HANDLER T)) #<unavailable argument> #<unavailable argument> #<TEST-ERROR-HANDLER {9DCF159}> #<REQUEST {92926B9}>) 7: ((HANDLE-REQUEST (HANDLER T)) #<unavailable argument> #<unavailable argument> #<DISPATCHING-HANDLER {9F68351}> #<REQUEST {92926B9}>) 8: ("LABELS ARANEIDA::DO-IT" #<THREADED-HTTP-LISTENER {9DCF319}> #<FILE-STREAM for "a constant string" {91B28D9}>) 9: (ARANEIDA::THREADED-HTTP-LISTENER-ACCEPT-ONE-REQUEST #<THREADED-HTTP-LISTENER {9DCF319}> #S(ARANEIDA::HTTP-THREAD :PID 25738 :LAST-HIT NIL :QUITTING NIL)) 10: ("#'(LAMBDA NIL (LOOP #))") 11: ("XEP for #'(LAMBDA NIL (LOOP #))" 0)[:EXTERNAL] 12: ("#'(LAMBDA NIL (LET # # ...))") 13: ("foreign function call land: ra=#x805B011") 14: ("foreign function call land: ra=#x805AE2D") I now have access to the debugger, which is what i wanted. I'm a little confused with the "debugger invoked" message, though. I'm not yet fluent with the debugger, but it seems there's another error than my assert here, isn't it ? I'll continue to dive into this. Now that i have access to the debugger, i think i can manage. And it's a good way to learn :) I'll try to figure out what happens and if i find something interesting for slime, i'll post it. I think i'm ok with this now. I now have a starting point, at least. Thank you ! :) -- Pierre-François Gomez GnuPG: 0xA38AE42C
Pierre-François Gomez <pierre-francois.gomez@NOSPAM-laposte.net> writes:
Has it been replaced by something else ?
Sort of. I'm not familiar with Araneida, but it might work if you
What do you mean by "sort of" ? Has it been renamed ? Not that this is really important : i'm just curious :)
The new mechanism is swank:swank-debugger-hook. The internals are now quite different than they where then, and the new hooks finds the corresponding streams itself. That was different before and was the reason that the old function had to be called in SLIME's REPL. Helmut.
"Thomas F. Burdick" <tfb@OCF.Berkeley.EDU> writes:
Nope, araneida:*restart-on-handler-errors* is a function of one argument, the condition. This should work, though:
(setf *restart-on-handler-errors* 'swank::debug-in-emacs)
Sorry, my first reply concerned Helmut Ellers' solution, i had forgotten yours :) I'll try it now. Sorry for the bandwith :-( -- Pierre-François Gomez GnuPG: 0xA38AE42C
Pierre-François Gomez <pierre-francois.gomez@NOSPAM-laposte.net> writes:
"Thomas F. Burdick" <tfb@OCF.Berkeley.EDU> writes:
Nope, araneida:*restart-on-handler-errors* is a function of one argument, the condition. This should work, though:
(setf *restart-on-handler-errors* 'swank::debug-in-emacs)
Sorry, my first reply concerned Helmut Ellers' solution, i had forgotten yours :) I'll try it now.
That works well with a threaded listener, too. When the handler hits my assertion, the sldb buffer instantly fires up. Great ! :) Thank you for your help. -- Pierre-François Gomez GnuPG: 0xA38AE42C
participants (7)
-
Alain.Picard＠memetrics.com -
Dave Roberts -
Helmut Eller -
Luke Gorrie -
Nikodemus Siivola -
Pierre-François Gomez -
Thomas F. Burdick