[erlang-questions 43] code:lib_dir and .ez archives

[Ulf Wiger]

I packed up EQC Mini and PropEr as a single archive to make it easier to include in an OSS project.

http://github.com/esl/run_eqc

This works very well, except when compiling modules that require the eqc/proper .hrl files. The -include_lib/1 directive doesn't work if the .hrl is inside an archive.

This made me think that the compiler - actually probably file.erl - should support paths where a component is an .ez archive, and do the sensible thing (act as if it were a real path).

But first, I noticed that code:lib_dir/1 acts very strangely when the application is loaded from an .ez archive (see below).

Is this deliberate, or is it a bug?

BR,
Ulf W

$ erl -pa run_proper.ez/proper/ebin
Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.1  (abort with ^G)
1> code:which(proper).
"run_proper.ez/proper/ebin/proper.beam"
2> code:lib_dir(proper).
"./run_proper"
3> {ok,Z} = zip:zip_open("run_proper.ez",[memory]).
{ok,<0.35.0>}
4> zip:zip_get("proper/include/proper.hrl",Z).
{ok,{"proper/include/proper.hrl",
     <<"%%% Copyright 2010 Manolis Papadakis ([hidden email])\n%%%            and Kostis Sagonas (kostis"...>>}}
5> zip:zip_get("proper/ebin/proper.app",Z).  
{ok,{"proper/ebin/proper.app",
     <<"{application,proper,\n             [{description,\"A QuickCheck-inspired property-based testing tool f"...>>}}



Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Eric Merritt-2]

There are a few problems like this in the escript stuff. For example,
there isn't any way to do releases in escript/ez archives. I think the
main problem is that the escript stuff just hasn't been fully
integrated into the erlang world. It seems like its 80% of the way
there but that additional 20% is still hanging out. I would love to
see those extra cases covered.

On Sat, Mar 26, 2011 at 7:06 PM, Ulf Wiger
<[hidden email]> wrote:

>
> I packed up EQC Mini and PropEr as a single archive to make it easier to include in an OSS project.
>
> http://github.com/esl/run_eqc
>
> This works very well, except when compiling modules that require the eqc/proper .hrl files. The -include_lib/1 directive doesn't work if the .hrl is inside an archive.
>
> This made me think that the compiler - actually probably file.erl - should support paths where a component is an .ez archive, and do the sensible thing (act as if it were a real path).
>
> But first, I noticed that code:lib_dir/1 acts very strangely when the application is loaded from an .ez archive (see below).
>
> Is this deliberate, or is it a bug?
>
> BR,
> Ulf W
>
> $ erl -pa run_proper.ez/proper/ebin
> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]
>
> Eshell V5.8.1  (abort with ^G)
> 1> code:which(proper).
> "run_proper.ez/proper/ebin/proper.beam"
> 2> code:lib_dir(proper).
> "./run_proper"
> 3> {ok,Z} = zip:zip_open("run_proper.ez",[memory]).
> {ok,<0.35.0>}
> 4> zip:zip_get("proper/include/proper.hrl",Z).
> {ok,{"proper/include/proper.hrl",
>     <<"%%% Copyright 2010 Manolis Papadakis ([hidden email])\n%%%            and Kostis Sagonas (kostis"...>>}}
> 5> zip:zip_get("proper/ebin/proper.app",Z).
> {ok,{"proper/ebin/proper.app",
>     <<"{application,proper,\n             [{description,\"A QuickCheck-inspired property-based testing tool f"...>>}}
>
>
>
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Steve Davis]

Are the results different if you rename run_proper.ez to proper-0.1.ez ?

[Max Lapshin-2]

There is other problem with escript: it cannot go background.
It would be very convenient for me to distribute erlyvideo in small
single-file launch scripts, but I can't do it because it doesn't allow
to go background.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Håkan Mattsson-4]

On Mon, Mar 28, 2011 at 8:52 AM, Max Lapshin <[hidden email]> wrote:
> There is other problem with escript: it cannot go background.
> It would be very convenient for me to distribute erlyvideo in small
> single-file launch scripts, but I can't do it because it doesn't allow
> to go background.

Yes, you can (forcefully) put it in background with the -detached option:

    %%! -detached

It is ugly, but it works.

Per Hedeland has however implemented a much better solution called delayed
detach, where the detached Erlang node keeps a socket to its parent process so
it may print a decent error message and set an exit code if the
startup fails. It is up
to the application to decide whether the detach should completed or if
it is an error
case. The code has been contributed to the OTP group a long time ago, but was
at that timepoint not included in the distribution due to lack of
time. The code has
proven to work very well.

Delayed detach would be a perfect fit for usage with escripts.

/Håkan
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Max Lapshin-2]

2011/3/28 Håkan Mattsson <[hidden email]>:

> On Mon, Mar 28, 2011 at 8:52 AM, Max Lapshin <[hidden email]> wrote:
>> There is other problem with escript: it cannot go background.
>> It would be very convenient for me to distribute erlyvideo in small
>> single-file launch scripts, but I can't do it because it doesn't allow
>> to go background.
>
> Yes, you can (forcefully) put it in background with the -detached option:
>
>    %%! -detached
>
> It is ugly, but it works.
>

I'll check it.
In fact, I need  os:daemonize()  =)
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Per Hedeland]

Håkan Mattsson wrote:
>
>Per Hedeland has however implemented a much better solution called delayed
>detach, where the detached Erlang node keeps a socket to its parent process so
>it may print a decent error message and set an exit code if the
>startup fails.

Actually I didn't implement it, just hacked it when needed...:-)

> The code has been contributed to the OTP group a long time ago, but was
>at that timepoint not included in the distribution due to lack of
>time. The code has
>proven to work very well.

I guess we could try to dig it out of our repository again, it has
gotten a bit mixed up with Tail-f-specific stuff over the years though.

--Per
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

[Per Hedeland]

Max Lapshin wrote:
>
>Maybe just add something like os:daemonize() ?

Uhh, "just"? Do you have some suggestions for the implementation? I
guess you're thinking of an analogue to the daemon(3) function that can
commonly be found in the C library on *nix. This function calls fork(2),
and subsequently the parent process exits, while execution continues in
the child (which returns from the daemon() call).

Obviously this can't be done in Erlang code, and while a (Unix-only, of
course) BIF that does exactly the same thing as daemon(3) wouldn't be
hard to implement per se, I wouldn't want to even begin to figure out
what effects it would have on the Erlang VM at some arbitrary point in
its execution. If it really is trivial to get it to work, you can "just"
write a NIF...

--Per
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions