Re: When/how are top-level side effects in a namespace executed?

[Thiago Massa]

1. It depends, if you reload the namespace for some reason, the value will
be reset to what is specified in the file, otherwise it's just once. By
using defonce you avoid it being reset.

2. Attemping what, reloading your code? I believe this is some scenario
people don't care too much about. Also atoms work well when accessed by
different threads, because its value is changed by an atomic
operation(swap!).

I hope my answer was somehow useful, happy hacking!

On Sun, May 22, 2016 at 5:35 PM, Colin Yates  wrote:

> Others will have more idea, but my observation is that it is evaluated
> once, so a namespace which is required by multiple namespaces will only
> be evaluated once. Should you explicitly re-evaluate it then it will of
> course be evaluated again.
>
> You might be interested in reading Stuart Sierra's 'reloaded workflow'
> and using the resultant Component library which has some input on this.
>
> The other machinery you might want to look at is defonce, which does
> exactly what it says :-).
>
> To give you peace of mind you could experiment with:
>
> (ns a)
> (def m (atom 0))
> (swap! m inc)
>
> (ns b
>  (:requires [a]))
>
> (ns c
>  (:requires [a]))
>
> And then load 'a' and 'b'. My expectation is that a/m will be 1
>
> As I say, this is from observation rather than inspecting the underlying
> machinery.
>
> HTH.
>
> lvh writes:
>
> > Hi,
> >
> >
> > Suppose I have a namespace that has some ns-level side effect, e.g.
> `(def atom {})`.
> >
> > 1. When is that executed? How often? (I think, from observation, that
> the answer is “when it is first required”, and “exactly once”; but it’s
> important for the correctness of my program that this is the case.)
> > 2. Is there a mutex preventing multiple threads from attempting that at
> the same time? If so, is that an accident, or a language guarantee?
> >
> > I don’t know if it matters, but in this case the side effect will be a
> method call on a jnr-ffi binding, so internally it will go off and
> synchronously initialize a C library. It’s fine if it gets called multiple
> times, but only if it has been executed by exactly 1 thread first. (It sets
> some state to signify that it’s initialized; if you call it when it’s
> already initialized, it just exits. It is _not_ re-entrant.)
> >
> > If these guarantees don’t hold, is there a convenient/canonical way to
> execute that side-effect synchronously? I’d like to prevent users of my
> library to have to remember to call an init fn in their main- if I can.
> >
> >
> > thanks
> > lvh
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: When/how are top-level side effects in a namespace executed?

[Colin Yates]

Others will have more idea, but my observation is that it is evaluated
once, so a namespace which is required by multiple namespaces will only
be evaluated once. Should you explicitly re-evaluate it then it will of
course be evaluated again.

You might be interested in reading Stuart Sierra's 'reloaded workflow'
and using the resultant Component library which has some input on this.

The other machinery you might want to look at is defonce, which does
exactly what it says :-).

To give you peace of mind you could experiment with:

(ns a)
(def m (atom 0))
(swap! m inc)

(ns b
 (:requires [a]))

(ns c
 (:requires [a]))

And then load 'a' and 'b'. My expectation is that a/m will be 1

As I say, this is from observation rather than inspecting the underlying
machinery.

HTH.

lvh writes:

> Hi,
>
>
> Suppose I have a namespace that has some ns-level side effect, e.g. `(def 
> atom {})`.
>
> 1. When is that executed? How often? (I think, from observation, that the 
> answer is “when it is first required”, and “exactly once”; but it’s important 
> for the correctness of my program that this is the case.)
> 2. Is there a mutex preventing multiple threads from attempting that at the 
> same time? If so, is that an accident, or a language guarantee?
>
> I don’t know if it matters, but in this case the side effect will be a method 
> call on a jnr-ffi binding, so internally it will go off and synchronously 
> initialize a C library. It’s fine if it gets called multiple times, but only 
> if it has been executed by exactly 1 thread first. (It sets some state to 
> signify that it’s initialized; if you call it when it’s already initialized, 
> it just exits. It is _not_ re-entrant.)
>
> If these guarantees don’t hold, is there a convenient/canonical way to 
> execute that side-effect synchronously? I’d like to prevent users of my 
> library to have to remember to call an init fn in their main- if I can.
>
>
> thanks
> lvh

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

When/how are top-level side effects in a namespace executed?

[lvh]

Hi,


Suppose I have a namespace that has some ns-level side effect, e.g. `(def atom 
{})`.

1. When is that executed? How often? (I think, from observation, that the 
answer is “when it is first required”, and “exactly once”; but it’s important 
for the correctness of my program that this is the case.)
2. Is there a mutex preventing multiple threads from attempting that at the 
same time? If so, is that an accident, or a language guarantee?

I don’t know if it matters, but in this case the side effect will be a method 
call on a jnr-ffi binding, so internally it will go off and synchronously 
initialize a C library. It’s fine if it gets called multiple times, but only if 
it has been executed by exactly 1 thread first. (It sets some state to signify 
that it’s initialized; if you call it when it’s already initialized, it just 
exits. It is _not_ re-entrant.)

If these guarantees don’t hold, is there a convenient/canonical way to execute 
that side-effect synchronously? I’d like to prevent users of my library to have 
to remember to call an init fn in their main- if I can.


thanks
lvh

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.