[erlang-questions] Re: file operations on zipped files (Re: how to add a module to preLoaded?)
Kresten Krab Thorup
krab@REDACTED
Tue Apr 5 18:29:35 CEST 2011
Can one easily wrap up all of the OTP beams in an ez, and boot from there? That would be perfect for erjang. (erjang doesn't need any of the native binaries, but do need access to various data files in priv folders).
Kresten
On 05/04/2011, at 16.09, "Ulf Wiger" <ulf.wiger@REDACTED<mailto:ulf.wiger@REDACTED>> wrote:
On 5 Apr 2011, at 15:43, Håkan Mattsson wrote:
On Thu, Mar 31, 2011 at 8:04 PM, Ulf Wiger
<<mailto:ulf.wiger@REDACTED>ulf.wiger@REDACTED<mailto:ulf.wiger@REDACTED>> wrote:
The change in prim_file gives no overhead in the normal case,
except for an extra pattern-match on the error value, and - if
{error, enotdir}, a scan of the file name to see if there is a
.ez file in the path. If so, the corresponding action is mapped
on the archive. If the file is to be opened, as with epp,
a "read_file()" is done, and the contents moved into a
ram_file, which allows the same operations as prim_file.
For this last case, I needed prim_ram_file in preloaded…
Is erl_prim_loader:get_file(File) too slow for your needs?
Surely not, but how does that help in this case?
I assume you mean that I could have used that function rather than implementing my own read_file_from_archive()? I definitely would if I had known about it. Since it's even documented, I can only blame my own ignorance. (:
So is your suggestion to call erl_prim_loader:get_file/1 instead of the prim_file:try_zip_read_file/2 that I wrote?
(<https://github.com/uwiger/otp/blob/uw-prim_file-reads-zip/erts/preloaded/src/prim_file.erl#L577>https://github.com/uwiger/otp/blob/uw-prim_file-reads-zip/erts/preloaded/src/prim_file.erl#L577)
or did you have something else in mind? I suspect you are among the few who can claim any depth of knowledge in this area.
A minor quirk is that code:lib_dir/1 has been defined to return
a path *outside* the zip archive, presumably because you cannot
load DLLs from an archive. Epp uses code:lib_dir/1 too, so even
with the above changes, epp would fail to find the .hrl
files. I solved this by having epp call code:where_is_file(Lib
++ ".app") and then finding the include from there. If that
fails, it calls code:lib_dir/1 as before.
Would it not be better if epp used code:lib_dir(App, include) instead?
That function suffers from the same "problem" as code:lib_dir(App) -
in the case of a zip archive, it actually returns what I assume would be the path of the unpacked archive, whereas code:where_is_file(F) actually points to the location inside the archive.
$ erl -pa run_proper.ez/proper/ebin
Erlang R14B03 (erts-5.8.4) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.8.4 (abort with ^G)
1> application:load(proper).
ok
2> code:lib_dir(proper,include).
"./run_proper/include"
3> code:where_is_file("proper.app").
"run_proper.ez/proper/ebin/proper.app"
BR,
Ulf W
Ulf Wiger, CTO, Erlang Solutions, Ltd.
<http://erlang-solutions.com>http://erlang-solutions.com
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list