Robert Feldt actually requested this back in ruby-talk:11158, but
nothing every come of it then (and I’m hurting for it now), so I thought
I’d bring it back up again. I’ll add a RubyGarden RCR after there’s a
bit of discussion.
Why do I need it? Well, currently you’ll find the following at the top
of the at_exit block in test/unit.rb:
set_trace_func DEBUGGER__.context.method(:trace_func).to_proc if
$DEBUG
I need this because the trace_func is no longer registered when at_exit
gets called, so if it’s missing, I can’t debug tests run with unit.rb.
OK, no problem, I can handle that UNTIL… somebody wants to profile
their tests. Uh oh. Now I have two ugly lines like that. And it only
works for those two… not Joe Schmoe’s Nifty Debugger or some other
cool thing that gets done with a trace_func.
If I had Kernel.trace_func (which I think is an OK name… but the name
is not what’s important to me at this point), I could just add a BEGIN
block to unit.rb:
BEGIN { $saved_trace_func = trace_func }
and change the line in at_exit like so:
set_trace_func $saved_trace_func
And it oughta work for any old trace_func that’s thrown at it.
If there’s a better way to handle this, by all means, point me at it.
But if not, what of the RCR?
Comments? Questions? Snide remarks?
Nathaniel
<:((><
···
RoleModel Software, Inc.
EQUIP VI
I think this proposed RCR is a good idea. It allows trace funcs to be
chained together, which is a good thing if you want to trace and profile
at the same time.
It might be nice if the RCR requested that $trace_func be a hooked
global variable.
One problem with chaining trace funcs is that it makes it difficult to
remove a trace func from the chain. Another solution, if you don’t want
to wait for Ruby to change, is to redefine set_trace_func:
$trace_funcs = []
class Object
alias_method :old_set_trace_func, :set_trace_func
def set_trace_func(func)
$trace_funcs.push(func)
end
old_set_trace_func proc { |*args|
$trace_funcs.each { |f| f.call(*args) }
}
end
Any call to set_trace_func will now add the func to the list of trace
funcs instead of replacing the existing one. This makes it easy to
remove a trace func (just write a remove_trace_func method), but will
have the side effect of breaking code that relies on “set_trace_func
nil” removing all existing trace funcs.
Paul
I think this proposed RCR is a good idea. It allows trace
funcs to be chained together, which is a good thing if you
want to trace and profile at the same time.
Before looking at eval.c I didn’t even realize that trace_funcs were
exclusive, i.e., “there can only be one.” But that is, indeed, the case.
I’d personally be satisfied with just being able to grab “the one” that
is set, but I can see benefit in having built-in ability to add multiple
ones. Probably a separate RCR, though.
It might be nice if the RCR requested that $trace_func be a
hooked global variable.
What do you mean by “hooked”?
One problem with chaining trace funcs is that it makes it
difficult to remove a trace func from the chain. Another
solution, if you don’t want to wait for Ruby to change, is to
redefine set_trace_func:
$trace_funcs =
class Object
alias_method :old_set_trace_func, :set_trace_func
def set_trace_func(func)
$trace_funcs.push(func)
end
old_set_trace_func proc { |*args|
$trace_funcs.each { |f| f.call(*args) }
}
end
Any call to set_trace_func will now add the func to the list
of trace funcs instead of replacing the existing one. This
makes it easy to remove a trace func (just write a
remove_trace_func method), but will have the side effect of
breaking code that relies on “set_trace_func nil” removing
all existing trace funcs.
I thought about this solution, and even played with it, but it doesn’t
work at all for my case: the debugger sets its trace_func long before I
get a change to redefine the method.
Nathaniel
<:((><
···
Paul Brannan [mailto:pbrannan@atdesk.com] wrote:
RoleModel Software, Inc.
EQUIP VI
Robert Feldt actually requested this back in ruby-talk:11158, but
nothing every come of it then (and I’m hurting for it now), so I
thought I’d bring it back up again. I’ll add a RubyGarden RCR after
there’s a bit of discussion.
I saw IRC log that Nathaniel worried about this request being
ignored. So I give you ACK. I’m thinking about this,
without getting conclusion yet.
Thanks, matz, it’s great to know you’re thinking about it. Would it help
if I went ahead and added an RCR on RubyGarden, or would it be better to
wait?
Nathaniel
<:((><
···
Yukihiro Matsumoto [mailto:matz@ruby-lang.org] wrote:
RoleModel Software, Inc.
EQUIP VI
It might be nice if the RCR requested that $trace_func be a
hooked global variable.
What do you mean by “hooked”?
rb_define_hooked_variable creates a hooked variable. This is how
$stdin, $stdout, $!, and other variables are implemented. See
README.EXT for an explanation.
I thought about this solution, and even played with it, but it doesn’t
work at all for my case: the debugger sets its trace_func long before I
get a change to redefine the method.
With:
http://rm-f.net/~cout/code/ruby/treasures/RubyTreasures-0.4/lib/hacks/fix_trace_func.rb.html
I can write:
ruby -rfix_trace_func -rtracer -rcrimson_profiler test.rb
and I get both tracing and profiling. I had to use a slightly modified
profiler to get this to work, but I can’t remember why at the moment.
Paul
···
On Sun, Dec 08, 2002 at 03:06:57AM +0900, nathaniel@NOSPAMtalbott.ws wrote:
I thought about this solution, and even played with it, but it
doesn’t
work at all for my case: the debugger sets its trace_func long
before
I get a change to redefine the method.
With:
http://rm-f.net/~cout/code/ruby/treasures/RubyTreasures-0.4/lib/hacks/fi
x_trace_func.rb.html
I can write:
ruby -rfix_trace_func -rtracer -rcrimson_profiler test.rb
and I get both tracing and profiling. I had to use a slightly
modified
profiler to get this to work, but I can’t remember why at the moment.
I know it would work if I made the user require a fix before requiring
the debugger, but that just doesn’t seem right. As a user myself, I want
this to work:
ruby -rdebug my_tests.rb
Nathaniel
<:((><
···
Paul Brannan [mailto:pbrannan@atdesk.com] wrote:
RoleModel Software, Inc.
EQUIP VI
“Yukihiro Matsumoto” matz@ruby-lang.org wrote in message
matz.
p.s.
You will have 1.8.0 preview within this year. Merry Christmas.
Dear Santa,
Can we send you our Christmas wish list then? 
– shanko