Trace() - display message with traceback to caller

Al Hart

I use this routine trace() to display debug messages from ruby files.

For instance, including:

trace("Entities in model; %s", Sketchup.active_model.entities.length)

in a ruby function, will display something like:

Entities in model; 1
    ^^^trace_sample.rb;24;in `test_trace'

Showing the ruby file name and line number where you placed the trace.

trace(format, values) can be used like puts or printf(), but you do not need to add a \n to get the carriage return. (This saves me millions of keystrokes a month - not typing in \n )

Try the attached file. When you type in: load "trace_sample.rb" you should see a message like:

Entities in model; 1
    ^^^trace_sample.rb;24;in `test_trace'

In actual use, I usually define trace() within each class or module, so that I am not creating a global function. (Which might interfere with, be be overridden by, global functions from other developers.

e.g.


class RPS_class
    def trace(*args)
       ... (rest of code)
    end#def
end#class

Here is the source for trace if you want to grab it and use it:
(Or else get it from the attachment - which also includes a sample use of trace())


def trace(*args)
	scall = caller(1)[0].to_s # who called the routine	
	scall2 = File;;basename(scall) # only the file name itself - no path	
	begin
		smess = sprintf(*args)	
		puts smess + "\n    ^^^" + scall2	
	rescue
		warn "arg ERROR in trace called from; " + caller(1)[0].to_s
	end		
end#def

thomthom

Good stuff.

Though, I have a thought:
Why not define the trace method in a Trace class, and then include the class to the methods you want. That way you don't have multiple copies all over the place?

Al Hart

@thomthom said:

:thumb: Good stuff.

Though, I have a thought:
Why not define the trace method in a Trace class, and then include the class to the methods you want. That way you don't have multiple copies all over the place?

Good idea, I could include it in a module of functions.

But I would still have to distribute the trace module with each application.

And there might be a problem with versions. When a user had installed more than one RPS application, say a new version of A and and old version of B, then A might wind up inheriting from the B version of the module, if the B version was loaded into SketchUp after the A version.

At one point we considered having a common set - called RPS_common. But still the problems of installing and uninstalling became difficult.