[GSoC '15] Visual debugger

[James Gilles]

Hey pencilcode-dev,

I've put together a rudimentary debugger for javascript as my pre-project for the Visual Debugger project. You can see it here.

It works by transforming the user's source code into an ES6-style generator, which yields events as they happen. It then collects those events and uses them to modify a "call stack" - an array of dictionaries that track changes in actual variables as the code runs. It can step forward and backward, trace into user functions, and pause user code as it runs. (It can't yet really handle array accesses, closures, and user-written generators, but that can be fixed.)

It can't run in all browsers right now, because generators - but that could be fixed with something like es6ify. 

The current demo application is a nodejs command-line thing, because that way I could be sure generators would be supported.

It works with javascript instead of coffeescript, but the same sort of thing would work with both.

Thoughts? Critiques?

Yours,

-James Gilles

[David Bau]

Very cool approach.  I haven't run it on my laptop yet because I'm on node 0.10 (because Pencil Code has some incompatibility with 0.12), and so generators don't work for me.  How much would it take to put together a demo chaining it together with https://facebook.github.io/regenerator/ to eliminate the generator dependency?

Here's a question: how does this approach interact with events, for example, if the user writes a program with setTimeout(myfunc, 1000); or window.addEventListener('click', myfunc);?

David

--
You received this message because you are subscribed to the Google Groups "pencilcode-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pencilcode-develo...@googlegroups.com.
To post to this group, send email to pencilcode-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Gilles]

Regenerator would be pretty simple, I assume you could just throw the generated source code in. It would be better to integrate the non-generator approach with the tool, though - figure out how regenerator does it and base the logic on that.

Callbacks... wouldn't easily work. You'd need a way to cause a callback to run inside another function's scope, or something... It's possible it would be easier to do it when it's not actually using generators.

[David Bau]

Hm, callbacks are a big deal for two reasons.  In classrooms we've found that callbacks are a really effective way to introduce functions.  I.e., instead of starting off with

f = -> fd 100; rt 90; fd 100

We start with

button 'f', -> fd 100; rt 90; fd 100

because it's more visible and understandable why you'd want to write 'some code that doesn't run yet'.  Second reason is that we end up stuck with callbacks in JS whenever we wait for user input.

Is there a way to somehow make "top-level functions" know that they need to run a generator version of the code inside them?

Regenerator seems like a pretty significant effort, and my gut feeling is that maybe it's better to use it rather than duplicate it, if we need to get its effects.

What I had imagined was that the summer project for GSoC would retrospective-only debugging, and not real stepping and breakpoints, but your approach is enticing.  So I guess the questions are:

* Any way to make it work with callbacks?

* If not, are there hybrid approaches that might work, where some code is steppable and other code is not?

David

David

[James Gilles]

Actually, now I think of it, callbacks are only a problem if you're not the one calling them- it would be possible to shadow callback-taking functions, so that when a callback happens, the actual callback is a function that runs user code in a debugger / passes control of user code to some global debugger. (Is user code already sandboxed?)
It wouldn't even be too hard to write a function that does that wrapping.
(I'm not sure what having multiple simultaneous call stacks in a debugger would look like, but that's a surmountable problem.)

-James Gilles