Re: [MIT-Scheme-devel] help with tracing

[Catonano]

Matt,

thanks for your help !

2014-11-16 19:59 GMT+01:00 Matt Birkholz <address@hidden>:

The DEBUG procedure inspects a continuation (the stack).  My-function
does not return a continuation, so you get an error.  At that point,
typing (DEBUG) inspects the continuation for that error, which is to
return from make-initial-dstate to the (let ((dstate |###|))...) form
in debug-internal.  That is what debug is showing you.

yes, I could see that.

> I would love to see the same break up in subproblems on my own code.
>
> How can I achieve that ?
>
> Thanks
>
> P.S. I also tried with calling bkpt in the middle of my code but in that case
> the debugger shows a window that is not as interactive as the one shown when
> calling debug directly.

You are seeing a breakpoint REPL prompt, similar to the error REPL
prompt.  Type

    (debug)

to inspect the breakpoint's continuation.  That should show you what
will happen when you continue from the breakpoint.  Clear as mud?

It seems to me that if I call (debug) at a breakpoint REPL, the debugger that gets started off is the command line debugger, even if I was in Edwin

Instead, if I place a "(error)" in my code I get propelled into the Edwin debugger.

The Edwin debugger is what I wanted to show, I think it´s better

Also I have discovered the stepper (the thing that is called pressing M-x on an _expression_) and it's part of what I wanted to show.

I was expecting one integrated thing containing both the Edwin debugger AND the stepper. So that I could have see the calls, with the code highlighted AND I could have stepped to see the following phase.

Also I could have called such a harness on any arbitrary piece of code as I can do with the stepper, rather than placing (error) in my code

Instead it seems that the debugger and the stepper are two distinct tools.

I just didn't expect this, that's all.

I showed them both, anyway, with a discreet success. I've been asked a youtube screencast to reinforce the point ;-)