[gambit-list] Debugging Scheme in Eclipse

William Cook wcook at cs.utexas.edu
Mon Jun 2 23:06:17 EDT 2008


Ah, well, its is too bad we didn't get a chance to meet. I'm
glad you like the idea of this project. Do you hang out on an irc channel?

I am currently planning a simple standard-io-based connection between
eclipse and gambit, much like a text-based user debugging session.
The eclipse sample code uses sockets, and this
has a lot of advantages, but it might be harder to set up for
a wide range of language runtimes. Do you have an opinion on this?
Certainly, for remote debugging sockets are probably better. But
its not that big a change, so I might end up supporting both. I'm
worried about getting to hung up on threading while I'm trying to
get the basic debugger going. Eclipse does support multi-threaded
debugging, so that is not the issue.

My idea is something like this. When gambit stops in a REPL,
it will immediately print stack information to stderr, and eclipse
will pick this up (only changed stack frames need be listed). The
format will be XML, with a prefix indicating its a debug line.
So, instead of "STOP IN function..." it will say
"#@!debug <context action="step"><frame name="proc" file="path" 
line="nn"><var name="x" value="3"/>... Its basically a full
dump of the stack, which the user can then inspect visually using
the standard eclipse debugging UI.
This eliminates all need for ,+,-,e and friends.

There will be some other interactions, for example, to allow
users to inspect values (structures and closures), etc.

Then when you click the step button in eclipse, it will send a
command to the REPL (basically a ",s"), then when gambit stops
it will send another <frame>... description, etc.

This is somewhat rough, and its optimized for easy support by any
language. Any comments?

Since you didn't tell me how to get control whenever Gambit stops,
I'll just copy ##repl-within, add my debug stuff. Then I can show
it to you and we can talk about possibilities for true integration.

Once I get basic functionality working (stepping and environments)
we will have to talk about breakpoints/tracepoints on any line in the 
program. I can probably also do some cool stuff with tracing --
by gathering a full trace and then letting the user explore it
incrementally in a tree with filtering.


Marc Feeley wrote:
 > Hello William!  I'm glad to see you are interested in Scheme and
 > Gambit!  It is unfortunate that I didn't have time to go to OOPSLA in
 > Montreal... that would have been a good time to meet you and brainstorm
 > about Gambit and debugging.  I'm really excited about your project and
 > will do what I can at my end to make it happen.  JazzScheme's IDE will
 > certainly be a neat environment for debugging Gambit code, but I think
 > an Eclipse integration will be interesting also for those folks
 > accustomed to its features and feel.  An EMACS integration (beyond
 > gambit.el) would also be neat... at least for EMACS junkies like me.
 > On 1-Jun-08, at 6:50 PM, William Cook wrote:
 >> I'm doing some serious development in Scheme, and want a
 >> good visual debugger. Since none of the scheme developers
 >> I've talked to seem to be interested in the problem (except JazzScheme,
 >> and they are not close to ready), I've
 >> started building one myself, as an Eclipse plugin.
 >> I am modifying the sample to be a general-purpose debugging
 >> interface for any dynamic language:
 >> http://www.eclipse.org/articles/Article-Debugger/how-to.html?
 >> It's going pretty well. Combined with SchemeWay, we might have
 >> a great IDE for Scheme without much effort.
 >> My goal is to support:
 >> * visual stack frame inspection
 >> * incremental inspection of other objects, including closures
 >> * UI for stepping into, over, and out of procedures
 >> * ability to continue with an expression result
 >> * line-based breakpoints
 >> * possibly some extensions for tracing
 > Let me add my wish-list:
 > 1) "live" inspection: if the IDE is observing an object (stack,
 > environment, thread state, etc) then any modification of that object (by
 > a background thread for example) should be reflected in the IDE.
 > Basically it means the IDE interface running in the debuggee must know
 > which objects the IDE is observing and notify the IDE when something it
 > is observing has changed (this can be done fairly efficiently by polling
 > at a "human perceptual scale interval", for example every 1/10th of a
 > second).
 > 2) consistency with the Gambit REPL: the IDE should have the same feel
 > as the REPL (for example: user input in bold) and support the same
 > commands and keybindings (for example: ,b should display the backtrace
 > in a window)
 > 3) multiple REPL model: each thread has its own REPL (selectable with a
 > tab-widget) and the currently selected REPL should determine the
 > backtrace view, the environment view, etc
 > Do you see any reason why any of this would be impossible in Eclipse?
 >> My sense is that I can get much of this without any changes
 >> to the gambit runtime. Line-based breakpoints are one thing that
 >> may not be possible without runtime support.
 >> I have a prototype working now, which gives me confidence
 >> that its possible. I still have a few problems:
 >> * I need to be able to gain control each time the REPL stops.
 >> I know how to do this for exceptions (current-exception-hander),
 >> but i'm not sure how to
 >> do it for stepping, without copying ##repl-within, which i
 >> would prefer not to do.
 > The procedure to redefine is ##step-handler.  I'll see if I can add a 
 >> * Specifically, is there any way to hack into define-prim
 >> functions?
 > Hack what?  In general you can't (set!
 > ##function-defined-with-define-prim ...) because the system assumes that
 > primitives are constants, allowing direct jumps to their code (a "goto"
 > in C).
 >> * As mentioned above, line-based breakpoints are a problem.
 > What is a line-based breakpoint?  If you mean (break-at-line
 > "source.scm" 42) then that's doable but would require a fair amount of
 > work (mainly keeping a list of all the loaded files and adding a code
 > walker to find which code node is at a particular line (all code nodes
 > already have that information)).
 >> * The way that variables are changed to %%n23 is annoying.
 >> I will strip that off, but it's ambiguous what to do with
 >> the transformed form of variables ending in digits, like x1.
 > Yes it is annoying... so don't load ~~/syntax-case.scm!!!  That's one of
 > the reasons I don't use syntax-case.
 > Marc

William Cook
Assistant Professor
UT Austin Computer Sciences

More information about the Gambit-list mailing list