Hi,
In CMUCL, is it possible to mask the debugger. For example, if I type an
unbound symbol at the prompt I will get a message followed by an option
to deave debugger etc ...
In most cases, I enter the debugger due to a typo and reading the error
message is enough, no need to enter the debugger.
I'm hoping to stop CMUCL from entering the debugger when an error occurs
at the TOP-LEVEL, say when a parameter *no-debug* is non-nil.
1. I don't know what will be the sideeffects of this.
2. I don't know how to do it, and can't find it in the CMUCL manual.
Thanks,
Tunc
Tunc Simsek <······@tudor.EECS.Berkeley.EDU> writes:
> Hi,
>
> In CMUCL, is it possible to mask the debugger. For example, if I type an
> unbound symbol at the prompt I will get a message followed by an option
> to deave debugger etc ...
>
> In most cases, I enter the debugger due to a typo and reading the error
> message is enough, no need to enter the debugger.
>
> I'm hoping to stop CMUCL from entering the debugger when an error occurs
> at the TOP-LEVEL, say when a parameter *no-debug* is non-nil.
Well, it is easy to stop the implementation from entering the debugger
by using cl:*debugger-hook* (and this works portably):
(defun silly-debugger-hook (condition hook)
(declare (ignore hook))
(format *debug-io* "~&IGNORED ~A~%" condition)
(abort condition))
(setq *debugger-hook* #'silly-debugger-hook)
* xxxxx
IGNORED Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable XXXXX is unbound.
*
The hard thing is to decide _when_ not to enter the debugger: There
exists no easy way to tell whether something happened on the top-level
or inside functions that were called from the top-level.
In CMUCL you can use the debugger-interface (documented in the user
manual) to examine the backtrace that led to the fault. Since the
ways that errors are signalled (i.e. what's called in between the
top-level interactive-eval and the final entry into the debugger)
differs markedly between different kinds of errors and/or forms, I
don't see easy ways to do the right thing. OTOH if you experiment a
bit, you might be able to devise a heuristic that fit's your error
profile and your preferences.
Here's a debugger-hook that will display the backtrace and some
information for each frame in addition to ignoring the error. Hope
this helps...
(defun silly-debugger-hook (condition hook)
(declare (ignore hook))
(loop for frame = (di:top-frame) then (di:frame-down frame)
while frame
do
(print frame *debug-io*)
(let ((df (di:frame-debug-function frame)))
(format *debug-io* "~&~A => ~A~%" df
(di:debug-function-function df))))
(format *debug-io* "~2&IGNORED ~A~%" condition)
(abort condition))
> 1. I don't know what will be the sideeffects of this.
There should be no unknown side-effects. In effect the debugger-hook
has the same effect as if the user had invoked the nearest abort
restart manually. Since the top-level conditions you probably have in
mind don't usually occur in environments that establish nested abort
restarts, this should usually be alright. You might however consider
using compute-restarts and use the last abort restart you can find
instead. This should then be pretty safe.
> 2. I don't know how to do it, and can't find it in the CMUCL manual.
I hope the above gives you some hints an how to do it, though it might
turn out to be harder than expected... OTOH I might have missed
something...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]