[erlang-questions] Installing a module from code?

[John Haugeland]

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.

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.

-----------------------

-module(a.foo).
-export([shared/0, unique_a/0]).

shared()   -> "I am a.foo".
unique_a() -> "I am a.foo's unique.".

-----------------------

-module(b.foo).
-export([shared/0, unique_b/0]).

shared()   -> "I am b.foo".
unique_b() -> "I am b.foo's unique.".

-----------------------

-module(c.foo).
-export([shared/0, unique_c/0]).

shared()   -> "I am c.foo".
unique_c() -> "I am c.foo's unique.".

-----------------------



If you compile each of those, they will all work as expected until you
reboot the VM.

    7> c("/scratch/a/foo.erl").
    {ok,'a.foo'}
    8> c("/scratch/b/foo.erl").
    {ok,'b.foo'}
    9> c("/scratch/c/foo.erl").
    {ok,'c.foo'}
    10> a.foo:shared().
    "I am a.foo"
    11> b.foo:shared().
    "I am b.foo"
    12> c.foo:shared().
    "I am c.foo"



After you reboot the VM, you will no longer be able to call any of them
directly.

    2> a.foo:shared().
    ** exception error: undefined function 'a.foo':shared/0
    3> b.foo:shared().
    ** exception error: undefined function 'b.foo':shared/0
    4> c.foo:shared().
    ** exception error: undefined function 'c.foo':shared/0



If you pretend there's no namespace, Erlang will clearly expose that the
binary is the last one compiled.

    5> foo:shared().
    ** exception error: undefined function foo:shared/0

    =ERROR REPORT==== 24-Mar-2009::10:42:03 ===
    beam/beam_load.c(1035): Error loading module foo:
      module name in object code is c.foo



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.)

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.

This really should, IMO, be fixed before r13 stable.





On Tue, Mar 24, 2009 at 1:43 AM, Ulf Wiger
<ulf.wiger@REDACTED>wrote:

> John Haugeland wrote:
>
>> My gut instinct is that my namespaced module sc.file is somehow
>>
> > conflicting with the real module file.
>
> A loong time ago, when I played around with packages, I noticed
> that dotted file names didn't go well with embedded boot code
> loading. It was the erl_prim_loader module, I think.
>
> Even if you're not using embedded code loading, the kernel
> and stdlib modules are always pre-loaded. I have no idea
> if this issue was ever addressed.
>
> http://erlang.org/pipermail/erlang-questions/2003-November/010741.html
>
> BR,
> Ulf W
>
> --
> Ulf Wiger
> CTO, Erlang Training & Consulting Ltd
> http://www.erlang-consulting.com
>



-- 
---
GuaranteedVPS.com - bandwidth commitments and root starting from $12.98/mo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090324/5f654e75/attachment.htm>