[gambit-list] Debugging Scheme in Eclipse

Marc Feeley 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  
> 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  
hook.

> * 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




More information about the Gambit-list mailing list