From: nathaniel@...
Date: 2002-12-08T03:06:57+09:00
Subject: Re: [RCR] Accessor for trace_func

Paul Brannan [mailto:pbrannan@atdesk.com] wrote:

> 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

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI