[erlang-questions] Installing a module from code?

[Kenneth Lundin]

Packages was introduced many years ago as an experimental feature.
Already from the beginning we where aware of that some
functions/features  would not work
together with packages.
We have not decided if and when packages will be more than experimental.
 If we decide to support packages some day it will most probably not
work exactly as today's solution.
another alternative could be to remove the half -hearted implementation
from the distribution in order to avoid confusion.

We strongly discourage the use of packages in professional projects.
We have no plans to do anything regarding packages until the R13B release.

/Kenneth Erlang/OTP Ericsson

But packages don't work as bad as you think and the problems described
below are actually not
caused by a bug, it works just as it is intended to do. Embedded commnets below.



2009/3/24 John Haugeland <stonecypher@REDACTED>:
> 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'}
The c/1 function compiles and loads the module. The module is given
with full path.
>     8> c("/scratch/b/foo.erl").
>     {ok,'b.foo'}
>     9> c("/scratch/c/foo.erl").
>     {ok,'c.foo'}
>     10> a.foo:shared().
a.foo is already loaded and the call succeeds
>     "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.

I assume that reboot means starting a new instance of the VM and this time
the modules a.foo, b.foo and c.foo are not loaded.
>
>     2> a.foo:shared().
The module a.foo is not loaded and the code path is searched for a
matching module
this means that for each element E in the code path "E/a/foo.beam" is tried
If you started the new VM with the same working directory as the first
one you will have
only one file foo.beam in the working directory and that will not
match, so the module a.foo will not be loaded and thus
can not be called.


>     ** 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
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>