[erlang-questions] lager and dynamic log cutting via compiled module

[Ulf Wiger]

If library applications are listed in reltool.config as {App, load}, they will not be started.

Also, as regards dependencies for parse transforms, I recently wrote a fairly
complex parse transform that I thought is both well-contained and fairly 
easy to understand and maintain.

https://github.com/uwiger/locks/blob/master/src/locks_watcher.erl

A brief explanation. In the module being transformed, a pseudo-call to
locks_watcher/1 is replaced by code returning {erl_eval, exprs, [Es,Bs]},
which is then used in spawn/4, in order to launch a script on a remote
node.

watch_node(N) ->
    {M, F, A} =
        locks_watcher(self()),  % expanded through parse_transform
    spawn(N, M, F, A).

The parse_transform function actually lifts the abstract code from its own
debug info, and also inlines any local calls made from the lifted function.
The transform and inlining code is only ca 80 lines of code and should
be fairly reusable (sans the slight absurdity of generating abstract abstract
code).

So in the linked module above, lines 22-65 contain the code that's lifted
into the transformed module. It's plain Erlang, with the only real complication
that recursion is done using funs.

BR,
Ulf W

On 27 Aug 2013, at 05:14, Andrew Thompson <andrew@REDACTED> wrote:

> On Mon, Aug 26, 2013 at 09:56:55PM -0500, Paul Davis wrote:
>> Andrew,
>> 
>> Can you explain the reticence about having compiler and syntax_tools as
>> dependencies? At first I was mostly assuming you wanted lager to handle
>> compiler logging or some such so it was a question of startup ordering.
>> Given goldrush I'm wondering if it were a more a general concern about just
>> removing dependencies for file sizes and so on.
> 
> It was mainly the complexity incurred for application startup by
> depending on those applications, even though they're only library
> applications, the application controller insists they be 'started'.
> 
> That complexity seems to be mostly handled by lager now, so the original
> reasons may not have any grounding anymore.
> 
> Andrew
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

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