Last week I upgraded from slime-2.0_p20070816 to slime-2.0_p20080731 (these are the gentoo ebuild names). We're looking at a pretty big jump here; these builds are a year apart. In that year, something changed in the debugger that is not to my liking. I am hoping that it is a feature that I can turn off.
When I hit an error in my code, I no longer enter the debugger. Instead, I just get a printed backtrace in the REPL. If I put a (break) in the code, I do enter the debugger. I would like to enter the debugger on all errors, like the good old days.
Does this sound like a feature that was added in the last year? Or do I need to look elsewhere for the cause?
Carlos Konstanski
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
Last week I upgraded from slime-2.0_p20070816 to slime-2.0_p20080731 (these are the gentoo ebuild names). We're looking at a pretty big jump here; these builds are a year apart. In that year, something changed in the debugger that is not to my liking. I am hoping that it is a feature that I can turn off.
When I hit an error in my code, I no longer enter the debugger. Instead, I just get a printed backtrace in the REPL. If I put a (break) in the code, I do enter the debugger. I would like to enter the debugger on all errors, like the good old days.
Does this sound like a feature that was added in the last year? Or do I need to look elsewhere for the cause?
If SWANK:*GLOBAL-DEBUGGER* is T, CL:*DEBUGGER-HOOK* is globally set to the swank debugger which means that all errors should land you into the SLDB.
*GLOBAL-DEBUGGER* is actually T by default, so make sure that your distribution doesn't interfere in some way (e.g. by some site-init.lisp file in SWANK-LOADER:*source-directory*, or ~/.swank.lisp.)
When you can't find the reason yourself, please try to checkout from CVS, and see if it works there. If it does, report the problem to the respective Gentoo maintainer.
HTH,
-T.
On Sat, 9 Aug 2008, Tobias C. Rittweiler wrote:
Date: Sat, 09 Aug 2008 19:16:41 +0200 From: Tobias C. Rittweiler tcr@freebits.de To: slime-devel@common-lisp.net Subject: [slime-devel] Re: new debugger behavior?
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
Last week I upgraded from slime-2.0_p20070816 to slime-2.0_p20080731 (these are the gentoo ebuild names). We're looking at a pretty big jump here; these builds are a year apart. In that year, something changed in the debugger that is not to my liking. I am hoping that it is a feature that I can turn off.
When I hit an error in my code, I no longer enter the debugger. Instead, I just get a printed backtrace in the REPL. If I put a (break) in the code, I do enter the debugger. I would like to enter the debugger on all errors, like the good old days.
Does this sound like a feature that was added in the last year? Or do I need to look elsewhere for the cause?
If SWANK:*GLOBAL-DEBUGGER* is T, CL:*DEBUGGER-HOOK* is globally set to the swank debugger which means that all errors should land you into the SLDB.
*GLOBAL-DEBUGGER* is actually T by default, so make sure that your distribution doesn't interfere in some way (e.g. by some site-init.lisp file in SWANK-LOADER:*source-directory*, or ~/.swank.lisp.)
When you can't find the reason yourself, please try to checkout from CVS, and see if it works there. If it does, report the problem to the respective Gentoo maintainer.
HTH,
-T.
swank:*global-debugger* is T in my REPL. I will try the latest CVS build. Thanks for the help!
Carlos
On Sat, 2008-08-09 at 19:16 +0200, Tobias C. Rittweiler wrote:
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
Last week I upgraded from slime-2.0_p20070816 to slime-2.0_p20080731 (these are the gentoo ebuild names). We're looking at a pretty big jump here; these builds are a year apart. In that year, something changed in the debugger that is not to my liking. I am hoping that it is a feature that I can turn off.
When I hit an error in my code, I no longer enter the debugger. Instead, I just get a printed backtrace in the REPL. If I put a (break) in the code, I do enter the debugger. I would like to enter the debugger on all errors, like the good old days.
Does this sound like a feature that was added in the last year? Or do I need to look elsewhere for the cause?
If SWANK:*GLOBAL-DEBUGGER* is T, CL:*DEBUGGER-HOOK* is globally set to the swank debugger which means that all errors should land you into the SLDB.
*GLOBAL-DEBUGGER* is actually T by default,
hi, on the latest checkout from CVS just now it seems it is NIL .. i set it back to T and stuff works as before again here
* Carlos Konstanski [2008-08-09 18:03+0200] writes:
Does this sound like a feature that was added in the last year? Or do I need to look elsewhere for the cause?
This sounds more like a bug. Is this CCL/Openmcl? As far as I can tell, our backend for CCL is more or less broken.
Helmut.
Helmut Eller writes:
- Carlos Konstanski [2008-08-09 18:03+0200] writes:
Does this sound like a feature that was added in the last year? Or do I need to look elsewhere for the cause?
This sounds more like a bug. Is this CCL/Openmcl? As far as I can tell, our backend for CCL is more or less broken.
Helmut.
OK, I think this has nothing to do with slime, rather it is a problem? feature? of the new sbcl-1.0.19. I can reproduce the issue when running without slime in an sbcl REPL at the command line. I guess the next step is to try sbcl-1.0.18 and see if the issue persists (which it won't), and examine the changelog.
Carlos Konstanski writes:
Helmut Eller writes:
- Carlos Konstanski [2008-08-09 18:03+0200] writes:
Does this sound like a feature that was added in the last year? Or do I need to look elsewhere for the cause?
This sounds more like a bug. Is this CCL/Openmcl? As far as I can tell, our backend for CCL is more or less broken.
Helmut.
OK, I think this has nothing to do with slime, rather it is a problem? feature? of the new sbcl-1.0.19. I can reproduce the issue when running without slime in an sbcl REPL at the command line. I guess the next step is to try sbcl-1.0.18 and see if the issue persists (which it won't), and examine the changelog. -- Carlos
I spoke too soon, as is often the case. I narrowed down the problem to a specific CVS commit in slime. The commit where the problem first appears is:
slime.el: 1.933 swank-sbcl.lisp: 1.194
date: 2008-03-26 09:57:37 -0600; author: trittweiler; state: Exp; lines: +26 -8
On SBCL,
(block outta (let ((*debugger-hook* #'(lambda (c hook) (declare (ignore hook)) (return-from outta 42)))) (error "FOO")))
would kist silently skip over the *DEBUGGER-HOOK*, and pop right into SLDB to handle the error. Fix that.
* swank-sbcl (make-invoke-debugger-hook): New function; returns a hook for SB-EXT:*INVOKE-DEBUGGER-HOOK* that checks for the presence of *DEBUGGER-HOOK*, and calls that if available. (install-debugger-globally): Use it. (call-with-debugger-hook): Ditto.
(getpid): Declaim return type explicitly, to make SBCL shut up about being unable to optimize %SAP-ALIEN in ENABLE-SIGIO-ON-FD.
* slime.el (def-slime-test break): Test additionally that BREAK turns into SLDB even when *DEBUGGER-HOOK* is locally bound. (def-slime-test locally-bound-debugger-hook): New test case; tests that a locally-bound *DEBUGGER-HOOK* is adhered, and not skipped.
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
Carlos Konstanski writes:
OK, I think this has nothing to do with slime, rather it is a problem? feature? of the new sbcl-1.0.19. I can reproduce the issue when running without slime in an sbcl REPL at the command line. I guess the next step is to try sbcl-1.0.18 and see if the issue persists (which it won't), and examine the changelog. -- Carlos
I spoke too soon, as is often the case. I narrowed down the problem to a specific CVS commit in slime. The commit where the problem first appears is:
slime.el: 1.933 swank-sbcl.lisp: 1.194
date: 2008-03-26 09:57:37 -0600; author: trittweiler; state: Exp; lines: +26 -8
On SBCL, (block outta (let ((*debugger-hook* #'(lambda (c hook) (declare (ignore hook)) (return-from outta 42)))) (error "FOO"))) would kist silently skip over the *DEBUGGER-HOOK*, and pop right into SLDB to handle the error. Fix that.
What is your exact test case you're taking judgement on the problem from?
-T.
On Sun, 10 Aug 2008, Tobias C. Rittweiler wrote:
Date: Sun, 10 Aug 2008 20:31:25 +0200 From: Tobias C. Rittweiler tcr@freebits.de To: slime-devel@common-lisp.net Subject: [slime-devel] Re: new debugger behavior?
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
Carlos Konstanski writes:
OK, I think this has nothing to do with slime, rather it is a problem? feature? of the new sbcl-1.0.19. I can reproduce the issue when running without slime in an sbcl REPL at the command line. I guess the next step is to try sbcl-1.0.18 and see if the issue persists (which it won't), and examine the changelog. -- Carlos
I spoke too soon, as is often the case. I narrowed down the problem to a specific CVS commit in slime. The commit where the problem first appears is:
slime.el: 1.933 swank-sbcl.lisp: 1.194
date: 2008-03-26 09:57:37 -0600; author: trittweiler; state: Exp; lines: +26 -8
On SBCL, (block outta (let ((*debugger-hook* #'(lambda (c hook) (declare (ignore hook)) (return-from outta 42)))) (error "FOO"))) would kist silently skip over the *DEBUGGER-HOOK*, and pop right into SLDB to handle the error. Fix that.What is your exact test case you're taking judgement on the problem from?
-T.
Doesn't matter. I found the real problem. It is in araneida. It reassigns *debugger-hook*. Apparently the old slime must have overwritten araneida's reassignment of *debugger-hook* with its own, or something. Just a guess.
Carlos
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
Doesn't matter. I found the real problem. It is in araneida. It reassigns *debugger-hook*. Apparently the old slime must have overwritten araneida's reassignment of *debugger-hook* with its own, or something. Just a guess.
Indeed, that was actually a bug in SBCL's swank backend the commit you cited fixed. You can invoke SWANK:SWANK-DEBUGGER-HOOK in araneida's *DEBUGGER-HOOK* to make the SLDB pop up.
-T.
Tobias C. Rittweiler writes:
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
Doesn't matter. I found the real problem. It is in araneida. It reassigns *debugger-hook*. Apparently the old slime must have overwritten araneida's reassignment of *debugger-hook* with its own, or something. Just a guess.
Indeed, that was actually a bug in SBCL's swank backend the commit you cited fixed. You can invoke SWANK:SWANK-DEBUGGER-HOOK in araneida's *DEBUGGER-HOOK* to make the SLDB pop up.
-T.
What I am about to suggest is not really for personal reasons. I made up my mind today to migrate all my web code to hunchentoot, where I don't think I'll have the same debugger problems that I am having with araneida. Its condition handling looks a lot cleaner than araneida's. Nevertheless, I think slime would be a more convenient debugging tool if it had what I am about to suggest. To me, that is what slime is all about: making it as convenient as possible to debug lisp code. I think it is the best IDE ever, by the way.
My suggestion: have the ability to choose between today's *debugger-hook* functionality (honor the debugee application's condition handling), and that of the pre-April era (unconditionally override the debugee application's condition handling). It would be nice to have the choice to debug any application without concern for how that application handles conditions internally. The old functionality, which supressed even araneida's pervasive condition handling, was a real boon. Anyone who is debugging a web server, where all errors need to be trapped and the debugger must be avoided at all costs, would appreciate this.
Just sort of fishing for opinions at this point.
* Carlos Konstanski [2008-08-11 05:46+0200] writes:
My suggestion: have the ability to choose between today's *debugger-hook* functionality (honor the debugee application's condition handling), and that of the pre-April era (unconditionally override the debugee application's condition handling). It would be nice to have the choice to debug any application without concern for how that application handles conditions internally. The old functionality, which supressed even araneida's pervasive condition handling, was a real boon. Anyone who is debugging a web server, where all errors need to be trapped and the debugger must be avoided at all costs, would appreciate this.
I think this is a policy issue. Whatever we do to install the Slime debugger, an application could just do same to override it. Right? Araneida was written by Dan Barlow, one of the SBCL implementors. It's no wonder that he knows how to suppress any debugger. Even something simple like (handler-case (...) (condition () ...)) suppresses the debugger.
Is there an etiquette for *debugger-hook*? Perhaps there should be one.
Helmut.
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
My suggestion: have the ability to choose between today's *debugger-hook* functionality (honor the debugee application's condition handling), and that of the pre-April era (unconditionally override the debugee application's condition handling). It would be nice to have the choice to debug any application without concern for how that application handles conditions internally.
There should be a ARANEIDA:*TRAP-INTO-DEBUGGER* which you can set to T, and if it's T araneida's DEBUGGER-HOOK should invoke its old value (which is passed along side the condition in fact.) This is application's domain, not something we could do much about.
-T.
PS: That said, with SBCL you could place
#+sbcl (setf sb-ext:*invoke-debugger-hook* swank:swank-debugger-hook)
into your ~/.swank.lisp to overwrite any application-specific debugger-hook.
Tobias C. Rittweiler writes:
Carlos Konstanski ckonstanski@pippiandcarlos.com writes:
My suggestion: have the ability to choose between today's *debugger-hook* functionality (honor the debugee application's condition handling), and that of the pre-April era (unconditionally override the debugee application's condition handling). It would be nice to have the choice to debug any application without concern for how that application handles conditions internally.
There should be a ARANEIDA:*TRAP-INTO-DEBUGGER* which you can set to T, and if it's T araneida's DEBUGGER-HOOK should invoke its old value (which is passed along side the condition in fact.) This is application's domain, not something we could do much about.
-T.
PS: That said, with SBCL you could place
#+sbcl (setf sb-ext:*invoke-debugger-hook* swank:swank-debugger-hook)
into your ~/.swank.lisp to overwrite any application-specific debugger-hook.
This suggestion looked very promising. If it were that easy, it would be exactly what I desired. Unfortunately, .swank.lisp gets loaded too early, and swank:swank-debugger-hook is unbound at that time.
I found the right spot in araneida to put this function call, however. I'll show it here for any araneida users out there. In http-listener.lisp:
(defmacro with-accept-flets (&body body) `(labels ((do-it (listener s) (let ((r (read-request-from-stream listener s))) (handler-case (handle-request-using-listener listener (http-listener-handler listener) r) (response-sent () nil) (http-error (c) (request-send-error r (http-error-code c) :log-message (http-error-message c) :client-message (http-error-client-message c)))))) (accept (listener) (listener-accept-stream listener))) (with-simple-restart (abort-response "Abort this response and answer another request") ;; expectation is that socket-accept will not block, because we ;; are invoked when select() says something is ready. we really ;; ought to set the master socket non-blocking to be sure. (let ((*debugger-hook* (if (and (find-package :swank) (functionp #'swank:swank-debugger-hook)) #'swank:swank-debugger-hook #'handler-debugger-hook))) ,@body))))
Danke sehr für Ihre Hilfe! Jetzt kann ich wieder fehlhafter lisp schreiben!
-
Carlos Konstanski -
Helmut Eller -
Lars Rune Nøstdal -
Tobias C. Rittweiler