------ art_4272_23362573.1196519521644
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
The below is a little long. So here's a summary.
Ideally what I'd like in 1.9, 1.9.1 or 2.0:
* Frame/Block objects which contains
- line, (may be nil)
- method, # of args (may be nil)
- access to a binding object which we can eval for access to that scope
(not nil)
My understanding is this information is around at run time.
* Thread Object which gives access to the Frame/Block above. So access to
the Frame object could be via a something like thread.caller(level-number).
* Enough added to the C-API added (e.g. parts of vm_core.h) to be able to
write code to do the above.
- - -
I've been considering what it would take to update ruby-debug or something
similar so it would work in Ruby 1.9. Since I have great respect for both,
it is with a lot of trepidation that I dare to criticize either.
One thing I'd like to do in ruby-debug for 1.9 is decoupling the frame
handling from the rest of the debugger. This is interesting and useful in
its own right.
I've found Ruby's 1.8 $! (backtrace) information seems a little bit
strange. Compare with say Perl's "caller". From Perl's doc:
($package, $filename, $line) aller;
With EXPR, it returns some extra information that the debugger
uses to print a stack trace. The value of EXPR indicates how many
call frames to go back before the current one.
($package, $filename, $line, $subroutine, $hasargs,
$wantarray, $evaltext, $is_require, $hints, $bitmask) aller($i);
First, $! is set only after an exception. This is very useful, but one would
like to have a way to do this for the current call frame as well. Second, $!
is an array of strings and where each string encodes something like the
first form. Given the capabilities of Ruby, it seems so shellish to encode
bits of information in a string that one might want separately. (On the
other hand, it is also pretty easy to parse out the bits of info). Third, in
Perl's longer version of caller we find the subroutine/method name, whether
it has arguments, and other information.
But again, Ruby is pretty cool, and agile. So I set off to write a class
using the C-API to get all of this. And to my surprise, I realized I was
least surprised! If $! (or a call-frame version) doesn't give things that I
want like the names of the parameters, their values, and access to their
scopes, it's because that information isn't there in the in the frame. Well
not in the C "FRAME" structure. Instead there are SCOPE and BLOCK
structures which have information about variables. Still, one can get the
number of arguments used in the call and the method name; this would be
helpful.
I have such a frame class written for 1.8.x and aside from possibly some
bugs I can make that available in this limited-useful state. In 1.9, things
change around a lot so this code can't be used without change.
So how is it that Ruby's "debug" module is able to show the call stack and
evaluate expressions in the context of outer frames? Well, it does this by
intercepting each call and squirrels away information on a stack that it
will need. (I think irb if not other programs do this too.) Key in this
saved information is a binding. This extra overhead in saving information is
one of the things that slows down "debug". However getting binding could
also be done (sort of) by tracking down run-time thread/frame/scope/block
structures.
When I tried to write this Frame class in 1.9 I run into a problem that a
lot of these thread and control_frame structures are not exposed. In Ruby
1.8 this appears in env.h. In 1.9 the some of corresponding things such as
rb_control_frame_t or rb_block_t seem to be in vm_core.h. One could cut and
paste from this, but this is a poor solution.
Thanks.
------ art_4272_23362573.1196519521644
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
The below is a little long. So here's a summary.<br><br> Ideally what I'd like in 1.9, 1.9.1 or 2.0:<br> * Frame/Block objects which contains <br> - line, (may be nil)<br> - method, # of args (may be nil)<br>
- access to a binding object which we can eval for access to that scope (not nil)<br> My understanding is this information is around at run time. <br> <br> * Thread Object which gives access to the Frame/Block above. So access to the Frame object could be via a something like
thread.caller(level-number).<br> <br> * Enough added to the C-API added (e.g. parts of vm_core.h) to be able to write code to do the above.<br><br>- - -<br>I've been considering what it would take to update ruby-debug or something similar so it would work in Ruby
1.9. Since I have great respect for both, it is with a lot of trepidation that I dare to criticize either.<br><br>One thing I'd like to do in ruby-debug for 1.9 is decoupling the frame handling from the rest of the debugger. This is interesting and useful in its own right.
<br><br>I've found Ruby's 1.8 $! (backtrace) information seems a little bit<br>strange. Compare with say Perl's "caller". From Perl's doc:<br><br> ($package, $filename, $line) aller;<br><br>
With EXPR, it returns some extra information that the debugger<br> uses to print a stack trace. The value of EXPR indicates how many<br> call frames to go back before the current one.<br><br> ($package, $filename, $line, $subroutine, $hasargs,
<br> $wantarray, $evaltext, $is_require, $hints, $bitmask) aller($i);<br><br>First, $! is set only after an exception. This is very useful, but one would like to have a way to do this for the current call frame as well. Second, $! is an array of strings and where each string encodes something like the first form. Given the capabilities of Ruby, it seems so shellish to encode bits of information in a string that one might want separately. (On the other hand, it is also pretty easy to parse out the bits of info). Third, in Perl's longer version of caller we find the subroutine/method name, whether it has arguments, and other information.
<br><br>But again, Ruby is pretty cool, and agile. So I set off to write a class using the C-API to get all of this. And to my surprise, I realized I was least surprised! If $! (or a call-frame version) doesn't give things that I want like the names of the parameters, their values, and access to their scopes, it's because that information isn't there in the in the frame. Well not in the C "FRAME" structure. Instead there are SCOPE and BLOCK structures which have information about variables. Still, one can get the number of arguments used in the call and the method name; this would be helpful.
<br><br>I have such a frame class written for 1.8.x and aside from possibly some bugs I can make that available in this limited-useful state. In 1.9, things change around a lot so this code can't be used without change.
<br><br>So how is it that Ruby's "debug" module is able to show the call stack and evaluate expressions in the context of outer frames? Well, it does this by intercepting each call and squirrels away information on a stack that it will need. (I think irb if not other programs do this too.) Key in this saved information is a binding. This extra overhead in saving information is one of the things that slows down "debug". However getting binding could also be done (sort of) by tracking down run-time thread/frame/scope/block structures.
<br><br>When I tried to write this Frame class in 1.9 I run into a problem that a lot of these thread and control_frame structures are not exposed. In Ruby 1.8 this appears in env.h. In 1.9 the some of corresponding things such as rb_control_frame_t or rb_block_t seem to be in vm_core.h. One could cut and paste from this, but this is a poor solution.
<br><br>Thanks.<br>
------ art_4272_23362573.1196519521644--