<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 5 Apr 2011, at 15:43, Håkan Mattsson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Thu, Mar 31, 2011 at 8:04 PM, Ulf Wiger<br><<a href="mailto:ulf.wiger@erlang-solutions.com">ulf.wiger@erlang-solutions.com</a>> wrote:<br><br><blockquote type="cite">The change in prim_file gives no overhead in the normal case,<br></blockquote><blockquote type="cite">except for an extra pattern-match on the error value, and - if<br></blockquote><blockquote type="cite">{error, enotdir}, a scan of the file name to see if there is a<br></blockquote><blockquote type="cite">.ez file in the path. If so, the corresponding action is mapped<br></blockquote><blockquote type="cite">on the archive. If the file is to be opened, as with epp,<br></blockquote><blockquote type="cite">a "read_file()" is done, and the contents moved into a<br></blockquote><blockquote type="cite">ram_file, which allows the same operations as prim_file.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">For this last case, I needed prim_ram_file in preloaded…<br></blockquote><br>Is erl_prim_loader:get_file(File) too slow for your needs?<br></div></blockquote><div><br></div><div>Surely not, but how does that help in this case?</div><div><br></div><div>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. (:</div><div><br></div><div>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?</div><div><br></div><div>(<a href="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</a>)</div><div><br></div><div>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.</div><br><blockquote type="cite"><div><br><blockquote type="cite">A minor quirk is that code:lib_dir/1 has been defined to return<br></blockquote><blockquote type="cite">a path *outside* the zip archive, presumably because you cannot<br></blockquote><blockquote type="cite">load DLLs from an archive. Epp uses code:lib_dir/1 too, so even<br></blockquote><blockquote type="cite">with the above changes, epp would fail to find the .hrl<br></blockquote><blockquote type="cite">files. I solved this by having epp call code:where_is_file(Lib<br></blockquote><blockquote type="cite">++ ".app") and then finding the include from there. If that<br></blockquote><blockquote type="cite">fails, it calls code:lib_dir/1 as before.<br></blockquote><br>Would it not be better if epp used code:lib_dir(App, include) instead?<br></div></blockquote><div><br></div><div>That function suffers from the same "problem" as code:lib_dir(App) -</div><div>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.</div><div><br></div><div><div>$ erl -pa run_proper.ez/proper/ebin</div><div>Erlang R14B03 (erts-5.8.4) [source] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]</div><div><br></div><div>Eshell V5.8.4 (abort with ^G)</div><div>1> application:load(proper).</div><div>ok</div><div>2> code:lib_dir(proper,include).</div><div>"./run_proper/include"</div><div>3> code:where_is_file("proper.app").</div><div>"run_proper.ez/proper/ebin/proper.app"</div><div><br></div></div><div>BR,</div><div>Ulf W</div></div><br><div>
<div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com">http://erlang-solutions.com</a></div><div><br></div><br class="Apple-interchange-newline">
</div>
<br></body></html>