[gambit-list] Debugging Scheme in Eclipse
feeley at iro.umontreal.ca
Mon Jun 2 13:41:30 EDT 2008
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
> 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:
> 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
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.
More information about the Gambit-list