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

[Ulf Wiger]

I'm not sure my example was really relevant to this thread, but I still think it's pretty cool. :)

/Ulf W

Ulf Wiger, Feuerlabs, Inc.
http://feuerlabs.com

7 sep 2013 kl. 23:22 skrev Ulf Wiger <ulf@REDACTED>:

> 
> 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
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions