[erlang-questions] Tracing and debugging

[Vlad Dumitrescu]

The major difference is that you can trace intermediary results without
polluting the code with dummy ?trace calls. Having the variables selected
automatically is nice too, no way to forget some or refer to the wrong one.
Some more advanced stuff can be done too, like only tracing variables whose
values have changed.

In other words, why do things manually if it was possible and efficient to
have them don for you by the compiler?

regards,
Vlad




On Tue, Jan 13, 2015 at 1:54 PM, Fred Hebert <mononcqc@REDACTED> wrote:

> On 01/13, Vlad Dumitrescu wrote:
> > So, I thought, what if, instead of interpreting a module in order to
> debug
> > it, we compile it with a special parse transform that inserts tracing
> calls
> > after each expression in the code, automatically keeping track of the
> > variables visible in the scope and their values?
> >
> > The output can be via io:format, et:report_event, or something else
> > (configurable).
> >
> > Could this "trogging" or "logtracing" be useful, or am I delusional?
> Maybe
> > there already is such a thing, the Erlang ecosystem is getting difficult
> to
> > keep in the working memory :-)
> >
>
> How would this be different from tracing BIFs and the libraries built on
> top? These even let you specify things if you want to look at values put
> in a function, and returned from it.
>
> I'm guessing the part that's too annoying could be selecting the
> functions that require tracing, maybe? Or that adding debug id functions
> (`trace(X) -> X.', then trace on ?MODULE:trace/1) is too cumbersome?
>
> You could probably use stuff like xref to find all calls that take place
> in a module, and then fill the input into trace BIFs to get an
> equivalent result, though there's probably no great scaffolding in place
> for this today.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150113/2d557c9a/attachment.htm>