On 17.10.2010 08:57, Arkady Itkin wrote:

> Robert Klemme wrote in post #950193:
>> On 14.10.2010 10:08, Arkady Itkin wrote:
>>>>
>>> from the saved output. But since the output it's not well
>>> organized/structured it's not an easy task.
>>>
>>> I thought about replacing all puts/print etc. calls that exists in the
>>> code by log4R which can be controlled from outside (and, on the way
>>> provide better structured output).
>>
>> What kind of structure do you expect to get?  As far as I can see
>> changing puts to internally delegate to a Logger can give you only
>> timestamp and maybe thread id because puts itself only accepts message
>> texts.  You can especially *not* get log levels with this approach.
>
> I was thinking about getting information on caller of the "puts" method.
> That will allow me to print out who invoked the "puts" method and even
> print it with indentation reflecting calling stack.

You should then probably look into set_trace_func as another option. 
With that you can do custom logging of all methods invoked.

-------------------------------------------------- Kernel#set_trace_func
      set_trace_func(proc)    => proc
      set_trace_func(nil)     => nil

      From Ruby 1.9.1
------------------------------------------------------------------------
      Establishes _proc_ as the handler for tracing, or disables tracing
      if the parameter is +nil+. _proc_ takes up to six parameters: an
      event name, a filename, a line number, an object id, a binding, and
      the name of a class. _proc_ is invoked whenever an event occurs.
      Events are: +c-call+ (call a C-language routine), +c-return+
      (return from a C-language routine), +call+ (call a Ruby method),
      +class+ (start a class or module definition), +end+ (finish a class
      or module definition), +line+ (execute code on a new line), +raise+
      (raise an exception), and +return+ (return from a Ruby method).
      Tracing is disabled within the context of _proc_.

          class Test
          def test
            a = 1
            b = 2
          end
          end

          set_trace_func proc { |event, file, line, id, binding, classname|
             printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, 
classname
          }
          t = Test.new
          t.test

            line prog.rb:11               false
          c-call prog.rb:11        new    Class
          c-call prog.rb:11 initialize   Object
        c-return prog.rb:11 initialize   Object
        c-return prog.rb:11        new    Class
            line prog.rb:12               false
            call prog.rb:2        test     Test
            line prog.rb:3        test     Test
            line prog.rb:4        test     Test
          return prog.rb:4        test     Test


You can try it out with a simple example like this:

ruby19 -e 'set_trace_func lambda {|*a| p a};5.times {|i| p i}'

> Unfortunately buildR trace is not as useful as ant trace. For example,
> it does not print out the reason why it decides to trigger some task (at
> least I did not find it).
> Besides, contrary to ant, buildR is not pure declaration language but
> allows to write custom code which I want to debug. I wonder if I can use
> ruby debugger ti debug this code (meanwhile all my attempts failed, ruby
> debugger fails to load with builrR).

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/