Re: Managing State Changes, using Component

2014-05-09 Thread Timothy Washington
Sorry, just reading this now. I've pivoted on that project, and that code is no longer around. We were going to store analytics data in that atom, but instead are going to do JVM and other kinds of profiling. But if you look at my first message, component *:a* would have had the atom. The

Re: Managing State Changes, using Component

2014-05-09 Thread James Reeves
If you only created the atom once, the value of the atom would be the same no matter where you dereferenced it. If you're seeing two different atoms, then the code that created the atom must have been executed more than once. Without seeing your code it's impossible to know for sure how that

Re: Managing State Changes, using Component

2014-05-09 Thread Timothy Washington
I can see this being the case. Nominally, my component looks like this. Before I log a bug however, let's see first, if anyone is seeing this behaviour. (ns a (:require [com.stuartsierra.component :as component] [taoensso.timbre :as timbre])) (defrecord A [env]

Re: Managing State Changes, using Component

2014-05-07 Thread Stuart Sierra
Actually, now that I think about it, that's not right. It shouldn't matter where or when you create the Atom. Instead, what I suspect you have is two or more instances of the component containing the Atom, thus two different Atoms. You can tell if the Atoms are the same object by printing

Re: Managing State Changes, using Component

2014-05-05 Thread Timothy Washington
Responses inlined ... On Mon, May 5, 2014 at 12:35 AM, Atamert Ölçgen mu...@muhuk.com wrote: Hello Timothy, On Sat, May 3, 2014 at 8:49 PM, Timothy Washington twash...@gmail.comwrote: Also, have you tried confirming that only one :a is instantiated? That one *:a* is not the same

Re: Managing State Changes, using Component

2014-05-05 Thread Stuart Sierra
At what point did you **create** the Atom in :a? Any mutable references which need to be shared among all usages of a component must be created in the **constructor**, not the `start` or `stop` methods. -S On Wednesday, April 30, 2014 5:13:15 PM UTC-4, frye wrote: Hi all, I'm having a

Re: Managing State Changes, using Component

2014-05-05 Thread Timothy Washington
Ahh, so that was it then. Yeah, I definitely created that atom in the start method. Thanks very much. Tim Washington Interruptsoftware.com http://interruptsoftware.com On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra the.stuart.sie...@gmail.comwrote: At what point did you **create** the Atom

Re: Managing State Changes, using Component

2014-05-04 Thread Atamert Ölçgen
Hello Timothy, On Sat, May 3, 2014 at 8:49 PM, Timothy Washington twash...@gmail.comwrote: Also, have you tried confirming that only one :a is instantiated? That one *:a* is not the same instance throughout all the dependant components. Seems that it's the [*:core :a*] bit that's passed

Re: Managing State Changes, using Component

2014-05-03 Thread Timothy Washington
Hey, thanks for responding. My responses are inlined. On Thu, May 1, 2014 at 1:34 AM, Atamert Ölçgen mu...@muhuk.com wrote: I am not an expert on Component. But AFAIK it is not for managing mutable state but for assembling and configuring components, that might or might not be mutable

Re: Managing State Changes, using Component

2014-05-01 Thread Atamert Ölçgen
I am not an expert on Component. But AFAIK it is not for managing mutable state but for assembling and configuring components, that might or might not be mutable themselves, in an immutable fashion. However from what I can understand, your component-a has an atom, like: (-component-a (atom