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