I was just actually just thinking about this. It would be fantastic to step from Ruby to Java and back again in the debugger (to say nothing of the increased speed).
Here are the things I think would need to be done: 1) JSR 45 support in the generated bytecode to allow the Java debugger to set and match breakpoints to a source file. The JRuby compiler already tracks line numbers so generating an SMAP at the same time shouldn't be too involved. 2) Name local variables for compiled methods that use the stack for local variables. The compiler reserves a JVM register for each local variable when it enters the frame (at least last I looked) so this shouldn't be too involved either. 3) A compile-everything-all-the-time mode (including evals). I know this isn't practical for production (PermGen and all), but maybe for short-lived debugged sessions it doesn't matter? Is this even feasible? 4) IDE editor would need to know that it needs to set breakpoints in the Java debug model for JRuby debugging. 5) IDE support to query the state of the JRuby world via JDI and display appropriately (for example, digging through the frame yourself and then matching that to a variable name would definitely be a drag). (3) probably isn't really strictly necessary. Does it matter if you can't step into eval()s? Does it even make sense? It might be possible to do a poor man's version of (5) with Eclipse's Detail Formatters (along with whatever the equivalent in NetBeans is). I'd volunteer to do (1) and (2) (and (3) if it makes sense), but without IDE support, it's not really worth doing. As an aside, jruby-debug could be quite a lot faster than it is. For example, we currently keep track of the call stack ourselves when we should be able to query the runtime for that as needed. It's still single-threaded (no way around that since we need to follow ruby-debug's behavior) and unavoidably trace-based though... Pete On Mon, Apr 14, 2008 at 9:37 PM, Werner Schuster (murphee) <[EMAIL PROTECTED]> wrote: > howdy, > > since there was talk about planning 1.2: any plans on actually using the > JVMs debugger instead of doing the trace-based debugging? > As far as I understand, IronRuby generates debugging information in the > generated IL (or PDB or whatever it's called), which should mean running > stuff under the debugger shouldn't have much of a overhead (as compared to > trace-based debugging which slows down execution considerably). > > I understand that there are issues, like the fact that only a certain part > of the code is actually turned into bytecode (eg. AST interpreted code vs > JITed/AOTed code) but I was wondering if someone has considered changing the > debugging cost from a cost per executed line to a cost per invoked > breakpoint. > > Yes I'm aware of jruby-debug and this > http://www.sapphiresteel.com/JRuby-Debugging-In-Visual-Studio - but these > are still trace-based. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
