------ art_6219_17001171.1201436965646
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Recently I've been working on a module which will show all the trace event
line calls in a Ruby program. This is useful in a debugger to determine if
it makes sense to set a breakpoint on a line. It may also be helpful in
other programs like rcov which is trying to figure out if all traceable
lines are executed.
In testing things, I came across the following weirdness. (Or is it a bug?)
I've long noticed that on conditional statements like "if", "until" or
"while", the line event gets called twice on somewhere in the condition. I
had sort of rationalized it as a call before the condition got executed and
a call afterwards. However this doesn't seem to be true as the following
example shows:
x x0if x
' or
true
If you debug this there are two stops on the line with "true". The first
surprise I have is why there is no stop on the line with x0 But the second
surprise is that even after the first line event on that statement and
before the second line event, the value of x still is what it was before: 2.
So therefore one wonders what the value is of having two line events here
is.
I'd be happy to try to patch the code (presumably eval.c) if it is desired
to change this behavior.
In Ruby 1.9 when I try this I don't get any trace lines listed at all using
tracer.rb even though I get call/return event lines. I thought it might have
something to do with optimizing the condition, but then I don't get a trace
line for x either and I've tried modifying the condition using more
dynamic variables. I may have made a mistake here; I don't have
1.9installed am running out of a compiled source tree. I'd appreciate
it if
others with 1.9 try this and let me know how 1.9 handles line number trace
events on conditional statements.
- - -
I could use some help finding bugs in the code to list a Ruby program's
trace event line numbers. To check out the code:
svn checkout
svn://rubyforge.org/var/svn/rocky-hacks/linecache/linecache/trunk<http://rubyforge.org/projects/rocky-hacks/>
(Sorry no home page yet.) The above example in a slightly different form is
test/data/if5.rb
After building the code you can pick your favorite Ruby program to try and
use lnum-diag.rb to show output and
compare. Here's a run on that data/if5.rb program;
./lnum-diag.rb -P data/if5.rb
data/if5.rb
# [2, 4, 4]
x x0if x
' or
false
# What's weird here is we get two stops on line 4 and both times x is
# 4. In Ruby 1.9 we don't get *any* line traces.
./data/if5.rb:3: warning: found n conditional, should be #0:./data/if5.rb:2::-: x #0:./data/if5.rb:4::-: false
#0:./data/if5.rb:4::-: false
(numbers_for_str):3: warning: found n conditional, should be expecting: [2, 4, 4]
--------------------------------------------------------------------------------
Got what was expected.
lnum_diag.rb has options to turn on or off some of the output below. See
it's --help for those options.
Thanks.
------ art_6219_17001171.1201436965646
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Recently I've been working on a module which will show all the trace event line calls in a Ruby program. This is useful in a debugger to determine if it makes sense to set a breakpoint on a line. It may also be helpful in other programs like rcov which is trying to figure out if all traceable lines are executed. <br>
<br>In testing things, I came across the following weirdness. (Or is it a bug?) I've long noticed that on conditional statements like "if", "until" or "while", the line event gets called twice on somewhere in the condition. I had sort of rationalized it as a call before the condition got executed and a call afterwards. However this doesn't seem to be true as the following example shows:<br>
<br><span styleont-family: courier new,monospace;"> x </span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;"> x0if x 39;a' or</span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;"> true</span><br><br>If you debug this there are two stops on the line with "true". The first surprise I have is why there is no stop on the line with x0 But the second surprise is that even after the first line event on that statement and before the second line event, the value of x still is what it was before: 2. So therefore one wonders what the value is of having two line events here is.<br>
<br>I'd be happy to try to patch the code (presumably eval.c) if it is desired to change this behavior. <br><br>In Ruby 1.9 when I try this I don't get any trace lines listed at all using tracer.rb even though I get call/return event lines. I thought it might have something to do with optimizing the condition, but then I don't get a trace line for x either and I've tried modifying the condition using more dynamic variables. I may have made a mistake here; I don't have 1.9 installed am running out of a compiled source tree. I'd appreciate it if others with 1.9 try this and let me know how 1.9 handles line number trace events on conditional statements.<br>
<br>- - - <br>I could use some help finding bugs in the code to list a Ruby program's trace event line numbers. To check out the code:<br><a href ttp://rubyforge.org/projects/rocky-hacks/"><tt>svn checkout svn://rubyforge.org/var/svn/rocky-hacks/linecache/linecache/trunk</tt></a><br>
<br>(Sorry no home page yet.) The above example in a slightly different form is test/data/if5.rb<br><br>After building the code you can pick your favorite Ruby program to try and use lnum-diag.rb to show output and<br>compare. Here's a run on that data/if5.rb program;<br>
<br>.<span styleont-family: courier new,monospace;">/lnum-diag.rb -P data/if5.rb</span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;">data/if5.rb</span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;"> /span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;"># [2, 4, 4]</span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;">x </span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;">x0if x 39;a' or</span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;"> false</span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;"># What's weird here is we get two stops on line 4 and both times x is</span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;"># 4. In Ruby 1.9 we don't get *any* line traces.</span><br styleont-family: courier new,monospace;"><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;"> /span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;">./data/if5.rb:3: warning: found n conditional, should be /span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;">#0:./data/if5.rb:2::-: x </span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;">#0:./data/if5.rb:4::-: false</span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;">#0:./data/if5.rb:4::-: false</span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;">(numbers_for_str):3: warning: found n conditional, should be /span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;">expecting: [2, 4, 4]</span><br styleont-family: courier new,monospace;">
<span styleont-family: courier new,monospace;">--------------------------------------------------------------------------------</span><br styleont-family: courier new,monospace;"><span styleont-family: courier new,monospace;">Got what was expected.</span><br>
<br>lnum_diag.rb has options to turn on or off some of the output below. See it's --help for those options.<br><br>Thanks.<br>
------ art_6219_17001171.1201436965646--