I did a but more diving into this and found that the default
debug.rb from Ruby is extremely slow (as you guys mentioned) and
therefore eclipseDebug.rb will be slow, too. Thank you for the
extended detail, though!
I have some emails out to the Ruby and Rails email lists about this
as well. Some people have mentioned the Arachno Ruby IDE, which is
not free, but I downloaded it and the debugger is fast. Maybe they
would license the debugger and allow it to be part of the RDT? If
so I'll drum up some donations for you!
I'll let you know if I hear anything more from the mailing lists.
-- Joe
On 1/9/06, *Markus Barchfeld* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> wrote:
>Hi Joe,
>
>I'm relieved (maybe relieved is the wrong word), to hear, that
I'm
not the
>only one who is suffering from the slow debugger. I had a quick
look into
>eclipseDebug.rb some time ago and asked, if porting eclipseDebug
to C could
>be a solution. As noone has answered :-(, I ceased examining the
debugger.
>
>What I've found up to now:
>- eclipseDebug.rb installs a traceProc (set_trace_func at the end
of the
>file)
>- the traceProc is called for every event that occurs in the
interpreter
>(e.g. every line, c-call, c-return, ...). So this probably is the
place that
>eats up all the time. I guess the trace_func is evaluated in
toplevel -
>context, so the profiler shows it as #toplevel
>- you can check, that the trace_proc causes the delay, if you
comment out
>the set_trace_func command at the end of eclipseDebug (but the
debugger is
>rather useless after this).
>
>Maybe the original author of eclipseDebug.rb could give us a hint
where to
>start improving the debugger? Implementing the whole debugger as
C-Code?
>Implementing only the trace_proc in C? Or removing the trace_proc
at all
>(ruby seems to have build in debugging facilities)
>
>
When I started to write the debugger for RDT, I started with the
debug.rb from ruby version 1.6.8. This original code still makes
up a
fair share of the current eclipseDebug.rb. I don't know who the
author
of the original debug.rb is.
My first approach was to just extend the command line debugger
(debug.rb) with additional commands to deliver the information
we need
for RDT and share this code with the ruby release. But then I
found that
there were requirements which made this approach too cumbersome:
* the input read loop may not be in the main thread but must
reside in
its own thread
* the data from the debugger must be readable from RDT and
therefore the
format which pleases the users eye had to be replaced with a format
which is easily to parse: XML was chosen
Dirk, I think your assessment of the code is quite right: the
traceProc
is the part which is called for every new line, function call
and return
and therefore consumes the most time. This is the part where a C
implementation could have the best impact. As opposed to that
the time
consumed in the input reader and command execution is not
relevant. The
C traceProc could be run instead of the traceProc of the current
ruby
implementation and pass control the ruby implementation only if a
breakpoint is hit or an exception occurred.
As far as I can tell a traceProc module written in C would at
least need
the following interface:
* a breakpoint and catchpoint administration, there must be
functions to
add and remove line and exception breakpoints
* if a breakpoint is hit control must be passed to the ruby
debugger
which sends xml to RDT and suspends the thread
* an API to get the information which the current implementation
stores
in @frames, which is the binding, position and file name (next
ot other
things) of every stack frame in every thread. The current
traceProc uses
a Context object for every thread and @frames is an instance
variable of
Context
* an API to set step or next mode. After the step or next is
finished
the control must be passed to the ruby implemenation. The ruby
implementation must be able to differ between a hit breakpoint
and a
step/next end
Unfortunately, I've no idea how the C implementation could be
smuggled
into the interpreter and if there a way to get the C-function in
place
without patching the ruby source code. On the other hand the
gain in
usabality might be worth even a patch. It could even make it
into the
ruby release (there must be other users which need fast tracing).
Don't hesitate to ask if you have further questions about
eclipseDebug.rb
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
<http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
_______________________________________________
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
<mailto:Rubyeclipse-development@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
<https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development>
