Nicolas Martyanoff

I have similar issues; in practice, Anything from `eunit_proc` should also be removed (or even `eunit_*`). Is this library still maintained ?

I'm using the Rebar3 plugin. I had this problem in the past with data coming from Rebar3 in general, and the only way to do it properly is to get...

Note that even if it is not currently supported when rebar3 is started as an escript, the shell module could still call `c:erlangrc()`. I guess the trick would be to...

Got it. I'll try to work on a minimal version and submit a pull request for comments.

For future reference, this kind of feature would break the API. Is this ok ? It feels like it would be quite convoluted to support both the presence and absence...

This one would allow escripts to embed shared libraries for NIFs, right ? This would be a nice step toward fully independant executables.

Any news regarding this issue ? If I am not mistaken, this is the only thing preventing the creation of escripts with NIFs.

I would expect this kind of property to at least support strings, binaries and tuples: as Michał said, there are multiple reasons to use a multi-valued label, e.g. `{acceptor, }`,...

You need to separate formatting of strings (lists or binaries) and other terms; using `~p` for strings will return quoted values (e.g. `"foo"` and ``). Something such as: ```erlang case...

Anyone ? Is libyaml even maintained ?