On 04/05/2011, at 10:55 AM, Michael Pearson wrote:
I've been writing a lot of system automation tools lately, and one
of the things I'm trying to get right is status output.
But I've been thinking about verbosity and task nesting.
And I'd like to write code that looks like:
Logger.task("Making a new container") do
blobs.each do |blob|
Logger.task("Making new blob #{blob.name}", :verbose => true)
...
end
end
end
Before I go and extend our own libraries, does anybody know of a gem
that already does task-based nested log output?
I have a non-colourised "tracer" module I use and (mostly) really like.
Personally, I don't like most colourised displays; I think whitespace
and very few well-contrasting colours are enough. Anyhow...
I've been meaning to extract it into a separate gem, and would be
happy to work with you on that. The main feature it adds that you
don't mention is support for categories, so you can control exactly
which kinds of messages get included. Any trace may have a category
symbol, and/or a block.
See <https://github.com/cjheath/activefacts-api/blob/master/lib/activefacts/tracer.rb
>.
The ActiveFacts API doesn't actually contain much tracing, but the
rest of the project uses it extensively.
You just include tracer.rb, and can write code like:
trace "Just getting started here"
trace :overview, "I'm doing some big thing here" do
...
trace :detail, "You might not want to know about this" do
...
end
trace :summary, "All done ok"
end
You configure it through API calls, or by setting the "TRACE"
environment variable
to a simple list of category names. As a special case, "all" means
everything,
and "help" means "dump a complete list of the categories that were
encountered
during the run, so I know what I can enable". In addition, if you
specify a category
name with a trailing underscore, then when a block is found of that
category, all
tracing is enabled for the duration of that block (even categories
that weren't
previously enabled). So TRACE=overview_ would enable everything in the
above.
One thing: when debugging traced code, the Ruby debugger wants to step
into the trace method before it yields to the block. It's an annoyance
that it
has no "step to the first line in the block attached to this
statement". However,
I've tried to minimise the number of steps required to get from a
"trace" call
to the first line of the block. if the code looks a little strange,
that'll be why.
Sometimes the code that executed in the interpolated string (a)
contains many
steps to step through and (b) affects runtime performance when tracing
is
disabled. I attempted to get around that by passing a Proc which is only
eval'd if the trace is enabled, but I encountered a performance
degradation
on long test runs which *may* be attributable; so it's disabled. Can
anyone
confirm whether such Procs leak?
Clifford Heath.
--
You received this message because you are subscribed to the Google Groups "Ruby or
Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
