So I was checking out whether multi-threaded debugging in Allegro worked and did this:
CL-USER> (mp:process-run-function "foo" #'(lambda () (break)))
One time it seemed to have opened up an SLDB buffer to debug the thread which I didn't notice at first and found later. But I just tried it again from a freshly started SLIME and it didn't go into SLDB.
So two questions: 1) Am I doing something wrong now that's causing it not to use SLDB and 2) Assuming I am, is it supposed to silently create the SLDB buffer? Is there some way to know that a thread has ended up in the debugger?
-Peter
Peter Seibel peter@javamonkey.com writes:
So I was checking out whether multi-threaded debugging in Allegro worked and did this:
CL-USER> (mp:process-run-function "foo" #'(lambda () (break)))
One time it seemed to have opened up an SLDB buffer to debug the thread which I didn't notice at first and found later. But I just tried it again from a freshly started SLIME and it didn't go into SLDB.
The workaround is to put this line in ~/.swank.lisp:
(setq *debugger-hook* #'swank:swank-debugger-hook)
I'm still thinking about the right fix. The problem is that the new thread is not inheriting our *DEBUGGER-HOOK* so it doesn't know to debug with SLDB.
ACL has fancy mechanisms for controlling inheritance of special variables, though at the moment I suspect globally setting *debugger-hook* as above is the right way.
So two questions: 1) Am I doing something wrong now that's causing it not to use SLDB and
No, our bug.
- Assuming I am, is it supposed to silently create the SLDB buffer?
Is there some way to know that a thread has ended up in the debugger?
When a thread hits SLDB the buffer should /always/ pop up. I think in your case SLDB was not invoked at all, and that if you switch to *inferior-lisp* you'll see the TTY debugger there.
-Luke
Luke Gorrie luke@bluetail.com writes:
Peter Seibel peter@javamonkey.com writes:
So I was checking out whether multi-threaded debugging in Allegro worked and did this:
CL-USER> (mp:process-run-function "foo" #'(lambda () (break)))
One time it seemed to have opened up an SLDB buffer to debug the thread which I didn't notice at first and found later. But I just tried it again from a freshly started SLIME and it didn't go into SLDB.
The workaround is to put this line in ~/.swank.lisp:
(setq *debugger-hook* #'swank:swank-debugger-hook)
I'm still thinking about the right fix. The problem is that the new thread is not inheriting our *DEBUGGER-HOOK* so it doesn't know to debug with SLDB.
Okay so I did that and it does pop up SLDB. But another problem seems to have to do with the standard streams--stuff I print from other threads shows up in *inferior-lisp* but nowhere else, that I know of. I guess by default I'd expect it to come out in the REPL window. Though it'd be nice to have a way to give a thread its own buffer for *standard-output*, *standard-input*, *query-io*, etc.
-Peter
Peter Seibel peter@javamonkey.com writes:
Okay so I did that and it does pop up SLDB. But another problem seems to have to do with the standard streams--stuff I print from other threads shows up in *inferior-lisp* but nowhere else, that I know of. I guess by default I'd expect it to come out in the REPL window. Though it'd be nice to have a way to give a thread its own buffer for *standard-output*, *standard-input*, *query-io*, etc.
For now I offer another ~/.swank.lisp workaround:
(setq swank::*globally-redirect-io* t)
Luke Gorrie luke@bluetail.com writes:
Peter Seibel peter@javamonkey.com writes:
Okay so I did that and it does pop up SLDB. But another problem seems to have to do with the standard streams--stuff I print from other threads shows up in *inferior-lisp* but nowhere else, that I know of. I guess by default I'd expect it to come out in the REPL window. Though it'd be nice to have a way to give a thread its own buffer for *standard-output*, *standard-input*, *query-io*, etc.
For now I offer another ~/.swank.lisp workaround:
(setq swank::*globally-redirect-io* t)
Thanks. I'll give it a whirl.
-Peter
Peter Seibel peter@javamonkey.com writes:
Luke Gorrie luke@bluetail.com writes:
Peter Seibel peter@javamonkey.com writes:
Okay so I did that and it does pop up SLDB. But another problem seems to have to do with the standard streams--stuff I print from other threads shows up in *inferior-lisp* but nowhere else, that I know of. I guess by default I'd expect it to come out in the REPL window. Though it'd be nice to have a way to give a thread its own buffer for *standard-output*, *standard-input*, *query-io*, etc.
For now I offer another ~/.swank.lisp workaround:
(setq swank::*globally-redirect-io* t)
Thanks. I'll give it a whirl.
Whirled. No go. Calls to PRINT still send their output to *inferior-lisp*.
-Peter
Peter Seibel peter@javamonkey.com writes:
For now I offer another ~/.swank.lisp workaround:
(setq swank::*globally-redirect-io* t)
Thanks. I'll give it a whirl.
Whirled. No go. Calls to PRINT still send their output to *inferior-lisp*.
I've hopefully fixed this properly in CVS. You should be able to remove both of those ~/.swank.lisp lines and every process with an ancestor created via Emacs should use Emacs for I/O and debugging.
Works for me on Linux in 6.2 at least.
-Luke
Luke Gorrie luke@bluetail.com writes:
Peter Seibel peter@javamonkey.com writes:
For now I offer another ~/.swank.lisp workaround:
(setq swank::*globally-redirect-io* t)
Thanks. I'll give it a whirl.
Whirled. No go. Calls to PRINT still send their output to *inferior-lisp*.
I've hopefully fixed this properly in CVS. You should be able to remove both of those ~/.swank.lisp lines and every process with an ancestor created via Emacs should use Emacs for I/O and debugging.
Works for me on Linux in 6.2 at least.
Same here. Thanks.
-Peter
-
Luke Gorrie -
Peter Seibel