[erlang-questions] Trace-Driven Development

[Ulf Wiger]

On 5 Jun 2012, at 12:42, Michael Turner wrote:

> Ulf, when I write "seq_trace implements Lamport clocks", please try to
> read it as you would "This ANSI Standard C compiler implements IEEE
> arithmetic." That doesn't mean "this ANSI Standard C compiler *is*
> IEEE arithmetic."

In that particular example, adding it to the documentation is an important
service to the user. Indeed, it might event be part of the requirements for
the compiler.

> By the way, I can't figure out why it's called "sequential tracing".
> If somebody told me, "it has to be called 'X tracing', solve for X,"
> I'd say, "X = 'parallel'", not "X = 'sequential'." Does the
> "sequential" refer to the fact that the (single) tracer process
> receives a stream of events?

It is actually wrong, IMHO. It should be 'sequence tracing'.

The problem was how to dynamically trigger a trace of e.g.
one single call setup flow in a system that handled hundreds
of calls per second. What has usually been done is that you 
turn on tracing on just about everything, then push a single 
call through the system. Obviously, this doesn't work in a live
system, so users (used to similar tracing support in the AXE)
asked for a way to trace on a single sequence of events,
as it triggered various activity in the system.

The huge, overshadowing problem for people needing to trace
on a live system, is that you have to be really careful that whatever
trace you turn on doesn't kill the system you are trying to study.

This is why any such tracing support needs to be extremely well
thought out, and intuitive for the people who are expected to use
it. We are not there today, and the docs need improving, but those
who do need to understand what the intent of the component is
in the first place.

> Scott makes good points, but the documentation for seq_trace carries
> no cautionary notices about relying on the real-time timestamps it
> reports. This seems an odd omission to me, since seq_trace would seem
> to be especially useful in cases where real-time clocks are
> unreliable. You could even dispense with real-time timestamps in
> seq_trace, and what's left would still have a substantial raison
> d'etre.


Agreed, including the "don't get me started…" part. ;-)

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com