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
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.
* Specifically, is there any way to hack into define-prim functions?
* As mentioned above, line-based breakpoints are a problem.
* 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.
* There are probably more issues I haven't run into yet.
If anybody has any advice, or wants to help out, let me know.
William Cook Assistant Professor UT Austin Computer Sciences
PS: The fact that this is going to be a general purpose debugging interface is interesting. It could easily work for Ruby, Python, Perl, in addition to other versions of Scheme.
Afficher les réponses par date
I don't want to insult you by stating the obvious (at least, for people who've read this list for a while), but are you aware of Dominique Boucher's Schemeway project, which is a Scheme plugin for Eclipse:
http://sourceforge.net/projects/schemeway
If it doesn't do precisely what you want, perhaps you can build upon it.
Brad
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
Marc,
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.
William
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:
- "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).
- 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)
- 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
-
Bradley Lucier -
Marc Feeley -
William Cook