ttb:stop() doesn't fetch - bug or feature?

Ulf Wiger <>
Tue Jun 8 10:18:44 CEST 2010


Playing around with ttb, I have repeatedly been annoyed by
the default behaviour of ttb:stop(). Even if you have set up
a trace with a file handler (i.e. saying that you want to
log to disk), ttb:stop() will not actually fetch the data and
store to disk unless you explicitly call either stop([fetch])
or stop([format]). There is no recovery if you forget; you
simply have to start over.

I would like the default behaviour to be the logical one depending
on how I started the trace. It is not obvious to me as a naive user
that ttb does not in fact store the data on disk until I fetch.

In fact, I have to 'fetch' even if I set up a "diskless" trace,
using the {file,{local,F}} option, even though the traced nodes
are pushing the trace data to the tracer node in real-time via
the trace port.

I would like to change ttb:stop() so that it automatically
fetches if logging to disk has been specified, but this would
of course break BW compatibility. Perhaps a new function,
ttb:stop_trace(), which has the right defaults? Or maybe rather
a ttb:fetch()? The question then would be if it should stop the
tracing by default, or simply flush trace data to disk and
continue tracing? Comments welcome.

To make matters worse, fetch on a "diskless trace" doesn't actually
work, so a test case on this might be in order. It is a rather minor
bug fix, which I could submit later. This made me wonder how many
actually rely on the current behaviour, though...

A final gripe in this area: after fetching, ttb prints to the tty
the name of the directory it just created to store the trace files.
I think it would be much better if the name were returned to the
caller, so that one doesn't have to search the current working
directory to deduce the location of the files, or parse stdout.
This would be an API change, or at least an addition to the API.

Any voices against?

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com



More information about the erlang-questions mailing list