Code/Hot/Loading

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Code/Hot/Loading

Gokul Evuri
so for instance

f() -> 3.
x() -> F = fun() -> f() end,
       A = f(),
       B = ?MODULE:f(),
       C = F().

right after F hash been defined,

a new version of code for f() is defined as follows

f()-> threeand loaded.

What would be the value of C.

--
*Gokul Reddy Evuri,*
*IT Universitet **G?teborg**,*
*G?teborg,*
*Sverige.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120116/88a82e47/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Code/Hot/Loading

Jon Watte-2
Funs are always bound to the code they are initially loaded from. Only name
look-ups are affected by code loading AFAICT.

This has been a source of exceptions in our previous development, because
the first time you load new code, F is still valid, but the second time you
load new code, the old code is purged and F is now invalid. Any call to it
will generate an exception.

We ended up wrapping our needs for lambdas in a module with state instead.
Not the most elegant, but allows us to get "dynamic lambdas." If all you
need in the fun is module:function, you can use a tuple for that instead of
a fun.

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Mon, Jan 16, 2012 at 6:41 AM, Gokul Evuri <chandu.gokul138>wrote:

> so for instance
>
> f() -> 3.
> x() -> F = fun() -> f() end,
>        A = f(),
>        B = ?MODULE:f(),
>        C = F().
>
> right after F hash been defined,
>
> a new version of code for f() is defined as follows
>
> f()-> threeand loaded.
>
> What would be the value of C.
>
> --
> *Gokul Reddy Evuri,*
> *IT Universitet **G?teborg**,*
> *G?teborg,*
> *Sverige.*
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120116/72194d04/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Code/Hot/Loading

Samuel Elliott
Sorry I'm a little late with my reply, but the situation is not as simple
as that (at least as of R14B02, I have not re-tested R15): funs can migrate
between versions of a module in some situations.

Here's the thread where I asked a similar question:

http://erlang.org/pipermail/erlang-questions/2011-May/058301.html

Another older thread is referenced in that one and it's also interesting.

Sam.

On 17 January 2012 04:31, Jon Watte <jwatte> wrote:

> Funs are always bound to the code they are initially loaded from. Only
> name look-ups are affected by code loading AFAICT.
>
> This has been a source of exceptions in our previous development, because
> the first time you load new code, F is still valid, but the second time you
> load new code, the old code is purged and F is now invalid. Any call to it
> will generate an exception.
>
> We ended up wrapping our needs for lambdas in a module with state instead.
> Not the most elegant, but allows us to get "dynamic lambdas." If all you
> need in the fun is module:function, you can use a tuple for that instead of
> a fun.
>
> Sincerely,
>
> jw
>
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world. Nevertheless,
> whether we get there willingly or not, we shall soon have lower consumption
> rates, because our present rates are unsustainable.
>
>
>
> On Mon, Jan 16, 2012 at 6:41 AM, Gokul Evuri <chandu.gokul138>wrote:
>
>>  so for instance
>>
>> f() -> 3.
>> x() -> F = fun() -> f() end,
>>        A = f(),
>>        B = ?MODULE:f(),
>>        C = F().
>>
>> right after F hash been defined,
>>
>> a new version of code for f() is defined as follows
>>
>> f()-> threeand loaded.
>>
>> What would be the value of C.
>>
>> --
>> *Gokul Reddy Evuri,*
>> *IT Universitet **G?teborg**,*
>> *G?teborg,*
>> *Sverige.*
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120123/be3cdaf5/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Code/Hot/Loading

Björn Gustavsson-2
On 1/23/12, Sam Bobroff <sam> wrote:

> Sorry I'm a little late with my reply, but the situation is not as simple
> as that (at least as of R14B02, I have not re-tested R15): funs can migrate
> between versions of a module in some situations.
>
> Here's the thread where I asked a similar question:
>
> http://erlang.org/pipermail/erlang-questions/2011-May/058301.html
>
> Another older thread is referenced in that one and it's also interesting.
>

This problem has been fixed in R15B. Here is the release note
from the README:

OTP-9667  The calculation of the 'uniq' value for a fun (see
erlang:fun_info/1) was too weak and has been strengthened. It
used to be based on the only the code for the fun body, but
it is now based on the MD5 of the BEAM code for the module.

/Bj?rn

--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB


Reply | Threaded
Open this post in threaded view
|

Code/Hot/Loading

Samuel Elliott
2012/1/23 Bj?rn Gustavsson <bgustavsson>

> On 1/23/12, Sam Bobroff <sam> wrote:
> > Sorry I'm a little late with my reply, but the situation is not as simple
> > as that (at least as of R14B02, I have not re-tested R15): funs can
> migrate
> > between versions of a module in some situations.
> >
> > Here's the thread where I asked a similar question:
> >
> > http://erlang.org/pipermail/erlang-questions/2011-May/058301.html
> >
> > Another older thread is referenced in that one and it's also interesting.
> >
>
> This problem has been fixed in R15B. Here is the release note
> from the README:
>
> OTP-9667  The calculation of the 'uniq' value for a fun (see
> erlang:fun_info/1) was too weak and has been strengthened. It
> used to be based on the only the code for the fun body, but
> it is now based on the MD5 of the BEAM code for the module.
>
> /Bj?rn
>

Thank you! It's great to have that cleared up :-)

Sam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120124/8da2160f/attachment.html>