[erlang-questions] Trace-Driven Development

[Michael Turner]

Ulf, I misinterpreted this:

> The seq_trace system_tracer allows only one [tracer (process)] per node.
>
> A generic lamport clock implementation has no need for
> such limitations.

I read this as claiming that seq_trace tracing is limited to a node,
which is (now, after a good night's sleep) rather obviously an
overstretched interpretation, at best.

That said, however, the seq_trace documentation seems to say
conflicting things on this point, and I assumed you were working from
where it says this:

 "The system tracer will only receive those trace events that occur
locally within the Erlang node. To get the whole picture of a
sequential trace that involves processes on several Erlang nodes, the
output from the system tracer on each involved node must be merged
(off line)."

If the documentation *also* says the following, later --

 "Sequential tracing between nodes is performed transparently. [C-node
part snipped] In order to be able to perform sequential tracing
between distributed Erlang nodes, the distribution protocol has been
extended (in a backward compatible way). An Erlang node which supports
sequential tracing can communicate with an older (OTP R3B) node but
messages passed within that node can of course not be traced."

... then it seems very contradictory to me. I haven't tried to
multi-node work with seq_trace yet, so I don't quite get any of this.
Maybe the two statements can be reconciled (with some fact that's
currently unstated?)

My big concern right now: I'd like to build on seq_trace, but maybe
it's a foundation of shifting sands? It's happened to me before. I
started building a graphics interface last year on the assumption that
gs was going to be around for a while. Then I noticed I seemed to be
taking a long walk on an incompleted pier. I inquired. It turned out
that support for it had been abandoned. Without notice in the
documentation of deprecation. (That notice has since been added.)

-michael turner



> I wrote that the *AXE* was never distributed. As far as I know, it
> still isn't.

Well, then: since the logical clocks of Lamport's scheme address the
problem of *physical* clock skew between systems, if AXE was never
distributed, then it never needed to implement Lamport clocks, and
thus it never implemented the full functionality of seq_trace. So can
we finally lay that claim of simultaneous independent invention to
rest? It seems to have become some kind of assumption among Erlang
insiders, but there's no evidence for it, and (apparently) no
motivation at the time to have done it.

-michael turner

On Wed, Jun 6, 2012 at 1:55 AM, Ulf Wiger <ulf@REDACTED> wrote:
>
> On 5 Jun 2012, at 18:43, Michael Turner wrote:
>
>> Speaking of which, is it really true, as you say, that seq_trace
>> doesn't work between nodes?
>
> It's not true, and I didn't say so.
>
> I wrote:
>
>> However, ordering may not have been a terribly difficult problem
>> to manage in AXE, as it was a single-CPU system, never distributed.
>> When the OTP team implemented similar support, obviously they
>> had to make something that worked in a distributed system
>
> I wrote that the *AXE* was never distributed. As far as I know, it
> still isn't. And I wrote that OTP *obviously* had to make something
> that worked in a distributed system.
>
> BR,
> Ulf W
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>