Hi all,
A quick note to mention that I've pushed some patches that integrate the
debugger and the repl. Now if you have an error, you will be dropped
into a recursive repl:
scheme@(guile-user)> (eval '(let a 10) (current-module))
Throw to key `syntax-error':
ERROR: In procedure macroexpand:
ERROR: let: bad let in (let a 10)
Entering a new prompt. Type `,bt' for a backtrace or `,q' to return to the
old prompt.
scheme@(guile-user) [1]>
You see the [1] in the prompt, showing that you aren't at the bottom
level any more.
scheme@(guile-user) [1]> ,help debug
Debug Commands [abbrev]:
,backtrace [COUNT] [#:width W] [#:full? F]
[,bt] - Print a backtrace.
,up [COUNT] - Select a calling stack frame.
,down [COUNT] - Select a called stack frame.
,frame [IDX] [,fr] - Show a frame.
,procedure [,proc] - Print the procedure for the selected
frame.
,locals - Show local variables.
The commands that were part of the debugger are now meta-commands in the
repl:
scheme@(guile-user) [1]> ,bt
In ice-9/boot-9.scm:
1056: 5 (#<procedure 3030ab0 ()>)
61: 4 (call-with-prompt prompt0 #<procedure 2ee45e0 at syst...> #)
In unknown file:
3 (eval (let a 10) #<directory (guile-user) 2647510>)
In ice-9/eval.scm:
457: 2 (#<procedure 26537e0 at ice-9/eval.scm:451:4 (exp)> (# ...))
In ice-9/psyntax.scm:
1223: 1 (chi-top (let a 10) () ((top)) e (eval) (hygiene #))
In unknown file:
0 (scm-error syntax-error macroexpand "~a: ~a in ~a" (...) #f)
scheme@(guile-user) [1]> ,frame
0 (scm-error syntax-error macroexpand "~a: ~a in ~a" (...) #f)
scheme@(guile-user) [1]> ,locals
No local variables.
scheme@(guile-user) [1]> ,up
In ice-9/psyntax.scm:
1223: 1 (chi-top (let a 10) () ((top)) e (eval) (hygiene #))
scheme@(guile-user) [1]> ,locals
Local variables:
$1 = e = (let a 10)
$2 = r = ()
$3 = w = ((top))
$4 = m = e
$5 = esew = (eval)
$6 = mod = (hygiene guile-user)
$7 = type = core-form
$8 = value = #<procedure 2614400 at ice-9/psyntax.scm:2078:19 (e r...>
$9 = e = (let a 10)
$10 = w = ((top))
$11 = s = #f
$12 = mod = (hygiene guile-user)
$13 = x = #<undefined>
The module is whatever was current when the repl began. I don't think
the behavior of the "repl" command in the old debugger was very useful,
you often didn't have the bindings you expect -- though of course you
can switch modules while in the recursive repl. (Hm, should save the
module excursion there, I guess).
If you run debugging commands at the base repl you'll just get an error
message:
scheme@(guile-user) [1]> ,q
ERROR: In procedure macroexpand:
ERROR: let: bad let in (let a 10)
scheme@(guile-user)> ,bt
Nothing to debug.
In the future we should be able to customize this behavior using repl
options (for example, a user should be able to say "always give me a
backtrace, but don't bother dropping me into a recursive
repl"). Feedback appreciated regarding what the default option should
be, of course. Or any other feedback folk might have is welcome.
Regards,
Andy
--
http://wingolog.org/
