Debugger Information

[s.j...@berkeley.edu]

I am a current undergraduate staff member for the UC Berkeley CS61AS introductory CS course. We switched from STK Scheme to Racket this summer, and were interested in creating an environment diagram drawer similar to Online Python Tutor for Racket. OPT is available on GitHub and uses a frontend to draws the diagrams from a JSON representation of frames for each step of execution. Backends exist for various languages, but not for Scheme/Racket.

I messaged Dr. Tobin-Hochstadt ("samth") but it turns out he didn't write the debugger, and pointed me here. I was wondering how I could get started with building such a environment diagram drawer backend. Thanks. I've read through parts of drracket/drracket/gui-debugger, and have a vague grasp on the Racket mixin system, plugins, (syntax) objects, but any guidance is welcome.

Tony

[Matthias Felleisen]

When you say debugger, do you mean the algebraic stepper (which is what we use for CS1 and the teaching languages) or do you mean the debugger for plain Racket programs? We don't teach Racket to freshmen. -- Matthias

--
You received this message because you are subscribed to the Google Groups "Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
To post to this group, send email to racke...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/8b60e8c3-8d20-4bf0-8978-7f4901131ec1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Clements]

> On Jul 7, 2015, at 5:57 PM, s.j...@berkeley.edu wrote:
>
> I am a current undergraduate staff member for the UC Berkeley CS61AS introductory CS course. We switched from STK Scheme to Racket this summer, and were interested in creating an environment diagram drawer similar to Online Python Tutor for Racket. OPT is available on GitHub and uses a frontend to draws the diagrams from a JSON representation of frames for each step of execution. Backends exist for various languages, but not for Scheme/Racket.

Building a Racket back-end for OPT would be quite straightforward. I’ve taken a quick look at the interface, and I had an undergraduate take a brief crack at it.

With that said, I’m not sure how I feel about this model of computation; I think the OPT is well-suited for languages that emphasize loops and mutation, but it doesn’t have a nice tidy representation for the program context.

I’d be the first to admit that the stepper is not currently very attractive, though.

John

>
> I messaged Dr. Tobin-Hochstadt ("samth") but it turns out he didn't write the debugger, and pointed me here. I was wondering how I could get started with building such a environment diagram drawer backend. Thanks. I've read through parts of drracket/drracket/gui-debugger, and have a vague grasp on the Racket mixin system, plugins, (syntax) objects, but any guidance is welcome.
>
>
> Tony
>

[Gustavo Massaccesi]

For a Racket version, it would be very helpful to have a special case
for tail calls.

(The support of continuations looks difficult, but they are no very
used in beginners programs)

Gustavo

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/77d6b33c-5057-4143-8313-820172e22efe%40mtasv.net.

[John Clements]

> On Jul 11, 2015, at 9:46 PM, Gustavo Massaccesi <gus...@oma.org.ar> wrote:
>
> For a Racket version, it would be very helpful to have a special case
> for tail calls.

Can you tell me what you mean by this? I’m not sure whether you’re talking about the stepper or OPT.

Thanks!

John Clements

[Gustavo Massaccesi]

About the OPT. I'll try to rewite my sentence:

If someone decides to adapt the OPT interface to show Racket programs,
I think that it will be necessary to add the support for tail calls.
IIRC tail calls are not supported in Python, so I guess that the OPT
don't show them properly, I guess it keeps all the call stack and when
the inner function finish the return values travel to the top.

In Racket, the tail calls are more popular, so I think the tail calls
should be explicitly handled in a "OPT for racket". This may be
confusing for beginners, so perhaps it can be a configurable option.

The main problem is that iterations are usually implemented as tail
calls, so the complete call stack can be very big, so it's confusing
to show them too. (Is it possible to show a few of the first and last
functions calls and hide the 100-ish repeated middle calls?)

Gustavo

[John Clements]

> On Jul 14, 2015, at 10:07 AM, Gustavo Massaccesi <gus...@oma.org.ar> wrote:
>
> About the OPT. I'll try to rewite my sentence:
>
> If someone decides to adapt the OPT interface to show Racket programs,
> I think that it will be necessary to add the support for tail calls.
> IIRC tail calls are not supported in Python, so I guess that the OPT
> don't show them properly, I guess it keeps all the call stack and when
> the inner function finish the return values travel to the top.
>
> In Racket, the tail calls are more popular, so I think the tail calls
> should be explicitly handled in a "OPT for racket". This may be
> confusing for beginners, so perhaps it can be a configurable option.
>
> The main problem is that iterations are usually implemented as tail
> calls, so the complete call stack can be very big, so it's confusing
> to show them too. (Is it possible to show a few of the first and last
> functions calls and hide the 100-ish repeated middle calls?)

Actually, if I recall the OPT interface correctly, tail calls would happen “automatically.” Specifically, OPT is an off-line display tool. It accepts a list of steps, and displays them. The natural notion of a “stack trace” for the stepper would in fact include only those context frames in non-tail position. In fact, the hard part would probably be in *breaking* tail-calling.

John