Well it's good to know it isn't my imagination, at least, though it's rather concerning that this has been known since 2003.<br><br>There's actually another looming problem.  Package names aren't resolved correctly during conflict after a boot.  My current assumption is that the only reason they work correctly before a boot is because they're loaded after compiling into the runtime.<br>
<br>
-----------------------<br>
<br>
-module(a.foo).<br>
-export([shared/0, unique_a/0]).<br>
<br>
shared()   -> "I am a.foo".<br>
unique_a() -> "I am a.foo's unique.".<br>
<br>
-----------------------<br>
<br>
-module(b.foo).<br>
-export([shared/0, unique_b/0]).<br>
<br>
shared()   -> "I am b.foo".<br>
unique_b() -> "I am b.foo's unique.".<br>
<br>
-----------------------<br>
<br>
-module(c.foo).<br>
-export([shared/0, unique_c/0]).<br>
<br>
shared()   -> "I am c.foo".<br>
unique_c() -> "I am c.foo's unique.".<br>
<br>
-----------------------<br>
<br><br><br>If you compile each of those, they will all work as expected until you reboot the VM.  <br><br>    7> c("/scratch/a/foo.erl").<br>    {ok,'a.foo'}<br>    8> c("/scratch/b/foo.erl").<br>
    {ok,'b.foo'}<br>    9> c("/scratch/c/foo.erl").<br>    {ok,'c.foo'}<br>    10> a.foo:shared().        <br>    "I am a.foo"<br>    11> b.foo:shared().<br>    "I am b.foo"<br>
    12> c.foo:shared().<br>    "I am c.foo"<br><br><br><br>After you reboot the VM, you will no longer be able to call any of them directly.<br><br>    2> a.foo:shared().<br>    ** exception error: undefined function 'a.foo':shared/0<br>
    3> b.foo:shared().<br>    ** exception error: undefined function 'b.foo':shared/0<br>    4> c.foo:shared().<br>    ** exception error: undefined function 'c.foo':shared/0<br><br><br><br>If you pretend there's no namespace, Erlang will clearly expose that the binary is the last one compiled.<br>
<br>    5> foo:shared().<br>    ** exception error: undefined function foo:shared/0<br>    <br>    =ERROR REPORT==== 24-Mar-2009::10:42:03 ===<br>    beam/beam_load.c(1035): Error loading module foo:<br>      module name in object code is c.foo<br>
<br><br><br>I suspect that the problem is that the .beam naming structure doesn't indicate package structure; x.y.z.quux is stored on disk as quux.beam, which is ambiguous.  The two natural solutions seem to me to be either to make the /lib directory structure reflect the package structure (which is sensible given that source is required to do the same) or to make the filenames something like x.y.z.quux.beam.  In both cases, backwards compatability is slightly broken, in that someone will have to recompile their stuff or suffer lots of missing errors, but if they're in the middle of upgrading the VM they probably have to do that anyway (I don't know the toolchain very well, so for all I know .beams are migrated or something.)<br>
<br>That packages/namespaces can collide in naming kind of defeats the purpose of packages/namespaces, and makes them relatively dangerous in that they can apparently take out the standard library.<br><br>This really should, IMO, be fixed before r13 stable.<br>
<br><br><br><br><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 1:43 AM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf.wiger@erlang-consulting.com">ulf.wiger@erlang-consulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">John Haugeland wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My gut instinct is that my namespaced module sc.file is somehow<br>
</blockquote>
> conflicting with the real module file.<br>
<br></div>
A loong time ago, when I played around with packages, I noticed<br>
that dotted file names didn't go well with embedded boot code<br>
loading. It was the erl_prim_loader module, I think.<br>
<br>
Even if you're not using embedded code loading, the kernel<br>
and stdlib modules are always pre-loaded. I have no idea<br>
if this issue was ever addressed.<br>
<br>
<a href="http://erlang.org/pipermail/erlang-questions/2003-November/010741.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2003-November/010741.html</a><br>
<br>
BR,<br>
Ulf W<br><font color="#888888">
<br>
-- <br>
Ulf Wiger<br>
CTO, Erlang Training & Consulting Ltd<br>
<a href="http://www.erlang-consulting.com" target="_blank">http://www.erlang-consulting.com</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>---<br>GuaranteedVPS.com - bandwidth commitments and root starting from $12.98/mo<br>