Charles O Nutter wrote:
Tom and I were discussing what would be necessary to hook RDT's
debugging capabilities into JRuby, and determined in the end it might
be pretty easy. Anyone want to give me a dime tour of how debugging
works today in RDT?
If we were to add debugging hooks into JRuby, what would they need to
look like? What information, callbacks, etc would RDT want?
- Charlie
There are two options
1. Don't use the java part of the RDT debugger at all
2. Implement the protocol between the java and ruby part of the debugger
Most of the debugger functionality of Eclipse comes from the Eclipse
debug framework, which provides an API which can be implemented for
particular languages. That API does handle the communication between
Eclipse and debugee in both directions:
* events which come from the debugee and
* commands to query the state of the debugee
The Eclipse part of the RDT debugger implements this API, the Ruby part
of the debugger runs in the process of the debugee.
After the launch of the debugee (with -reclipseDebug) the Eclipse part
connects as client to the debugge with the ruby part running a tcp
server in the debugee's process. On Eclipse's side the socket input is
polled in a thread and delivers the events (breakpoint hit, exception
occurred, step end) to the Eclipse debug framework. The socket output
direction is used to send commands to the debugee (e.g. to add or remove
a breakpoint, query for local variables and so on).
Lets come back to the initial options: it would have been possible to
define a protocol between debugger and debugee which would be suitable
for a lot of dynamic languages like perl, ruby, python. Such an approach
has also been started (http://www.xdebug.org/docs-dbgp.phpand) but there
is nobody who has implemented Eclipse's debug framework API for that
protocol. Instead every language plug-in provides its own
implementation. The reason might be that the implementation on Eclipse's
side is fairly easy because the Eclipse debug framework already covers
most of the functionality and most of the work has to be done on the
side of the debugee.
So, while this seems to imply the first option, for JRuby and Ruby
implementing the second option might be better suited because of their
tight relationship. So, we'd definitely need another launch
configuration. Instead of a Ruby process we would start a JRuby Java
process and then let the Eclipse RDT debugger connect to it. Then the
debugee would have to implement the debugger protocol. The protocol is
nowhere described formally, but it is covered from the following testsuite:
org.rubypeople.rdt.debug.core.tests/src/org/rubypeople/rdt/debug/core/tests/FTC_DebuggerCommunicationTest.java
You can follow the "talk" also on the nightly test suite log (OK, it's
no real fun to read):
http://213.239.199.113:8080/cruisecontrol/home/bma/cruiseControlWorkspace/logs/RDT/log20060108162004L0.7.0.601081620NGT.xml
If you have to implement the debugee's part of the protocol entirely
from scratch or can reuse eclipseDebug.rb, depends on how compatible
JRuby is with Ruby:
Does JRuby provide
... trace callbacks with set_trace_proc (see my last post this list)?
... access to thread information?
... bindings and eval?
Did you have a look at eclipseDebug.rb already? How much rewriting do
you think is necessary?
Markus
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
