Re: Managing State Changes, using Component
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 *:updater* and *:reader* components were referencing that. Now, if there's any duplication like what you describe, it would have to come where I set up the component system/map. But my code's perspective, I only created that atom once. Sorry I don't have immediate access to that code. I can't show it to you either. But if need be, I can go back in git history, and troubleshoot the codebase as it was on April 30th. But again, my description abouve fairly captures the situation. Lemme know Tim Washington Interruptsoftware.com http://interruptsoftware.com On Wed, May 7, 2014 at 1:31 PM, Stuart Sierra the.stuart.sie...@gmail.comwrote: 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 them, which shows a unique hash of each Atom's identity. -S On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote: Ahh, so that was it then. Yeah, I definitely created that atom in the start method. On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: 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. -- 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: Managing State Changes, using Component
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 occurred. There's nothing obvious in the pseudocode you presented that would indicate where the atom is being created more than once. - James On 9 May 2014 22:49, Timothy Washington twash...@gmail.com wrote: 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 *:updater* and *:reader* components were referencing that. Now, if there's any duplication like what you describe, it would have to come where I set up the component system/map. But my code's perspective, I only created that atom once. Sorry I don't have immediate access to that code. I can't show it to you either. But if need be, I can go back in git history, and troubleshoot the codebase as it was on April 30th. But again, my description abouve fairly captures the situation. Lemme know Tim Washington Interruptsoftware.com http://interruptsoftware.com On Wed, May 7, 2014 at 1:31 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: 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 them, which shows a unique hash of each Atom's identity. -S On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote: Ahh, so that was it then. Yeah, I definitely created that atom in the start method. On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: 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. -- 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: Managing State Changes, using Component
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]
component/Lifecycle
(start [component]
(assoc component :a (atom {*...*})))
(stop [component]
(dissoc component :a)))
(defn component-a [env]
(map-A {:env env}))
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
On Fri, May 9, 2014 at 6:40 PM, James Reeves ja...@booleanknot.com wrote:
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
occurred. There's nothing obvious in the pseudocode you presented that
would indicate where the atom is being created more than once.
- James
On 9 May 2014 22:49, Timothy Washington twash...@gmail.com wrote:
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 *:updater* and *:reader* components were referencing that.
Now, if there's any duplication like what you describe, it would have to
come where I set up the component system/map. But my code's perspective, I
only created that atom once. Sorry I don't have immediate access to that
code. I can't show it to you either. But if need be, I can go back in git
history, and troubleshoot the codebase as it was on April 30th. But again,
my description abouve fairly captures the situation.
Lemme know
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
On Wed, May 7, 2014 at 1:31 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
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 them, which
shows a unique hash of each Atom's identity.
-S
On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote:
Ahh, so that was it then. Yeah, I definitely created that atom in the
start method.
On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
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.
--
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: Managing State Changes, using Component
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 them, which shows a unique hash of each Atom's identity. -S On Monday, May 5, 2014 6:25:55 PM UTC-4, frye wrote: Ahh, so that was it then. Yeah, I definitely created that atom in the start method. On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: 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. -- 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: Managing State Changes, using Component
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 instance throughout all the dependant components. Seems that it's the [*:core :a*] bit that's passed to all the components in the *'start* *'stop* functions. I say this, because when one of my dependant components updated an atom in it's own [*:local :a*], it was [*:core :a*] that reflected that change. I'm not sure if I follow correctly. Looking at your code, (ca/component-a env) should be called exactly once and the resulting value should be the :a. Then, when other components that depend on :a gets initialized, their [:local :a]'s should be exactly the same value. If the value we're talking about is an atom, i.e. ca/component-a returns an atom, then modifying this atom in one component (as you say above [:local :a]) would cause it's value, when [:core :a] is dereferenced, to be the new value. So if I'm not missing something, the situation you describe above is exactly how it should work. Yes, so modifying an atom in [*:local :a*] (in ca/component-a) *did*reflect in the new [*:core :a*]. The problem I found, was that if I later try to access [*:local :a*] (in ca/component-a), I *did not* see that change reflected. If you, however, say add a debug print in ca/component-a, and see that it's called more than once, you should file a bug report. I just assumed that this was the expected behaviour. But I'll check it to see if it's a bug. -- Kind Regards, Atamert Ölçgen -+- www.muhuk.com Thanks Tim Washington Interruptsoftware.com http://interruptsoftware.com/ -- 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: Managing State Changes, using Component
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 weird state problem with
Componenthttps://github.com/stuartsierra/component.
Let's say I have a system component, like in fig.1. Starting / stopping and
loading state is fine.
However, let's say I have 2 other components (:updater , :reader) that use
component :a. This is the problem that occurs.
1. When *:updater*, modifies an atom in *:a*, that change appears in
path [*:core :a*], not path [*:updater :a*] or [*:a*].
2. Because of the abouve, when *:reader* goes to it's local path [
*:reader :a*] to read that change, it doesn't see those modifications.
3. Using this scheme, *:a* is duplicated 4 times, in the system map.
However, the modifications only appear in path [*:core :a*]. Thus
:reader is unable to access it (it's local [*:a*] is unchanged).
(def system-components [:a :updater :reader])
(defrecord Core [env] component/Lifecycle
(start [this] ...)
(stop [this] ...))
(defn component-core [env]
(component/system-map
:a (component/using
(ca/component-a env)
{})
:updater (component/using
(cs/component-updater env)
{:a :a})
:reader(component/using
(cs/component-reader env)
{:a :a})
:core (component/using
(map-Foobar {:env env})
{:a :a
:updater :updater
:reader :reader })))
*fig.1 *
I was hoping to use Component to manage all internal application state.
But maybe it's not designed for this use case (state changes between
components). I imagine that immutability is preventing all those duplicates
from seeing the modifications. However, in this case I do need an update to
:a in one component, to be accessed by another component.
Any suggestions on patterns here? I'm also looking at
component/update-systemhttps://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj#L116.
But again, I don't have access to the core *system* var, from within my
components.
Any insights appreciated
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
--
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: Managing State Changes, using Component
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 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 weird state problem with
Componenthttps://github.com/stuartsierra/component.
Let's say I have a system component, like in fig.1. Starting / stopping and
loading state is fine.
However, let's say I have 2 other components (:updater , :reader) that
use component :a. This is the problem that occurs.
1. When *:updater*, modifies an atom in *:a*, that change appears in
path [*:core :a*], not path [*:updater :a*] or [*:a*].
2. Because of the abouve, when *:reader* goes to it's local path [
*:reader :a*] to read that change, it doesn't see those
modifications.
3. Using this scheme, *:a* is duplicated 4 times, in the system map.
However, the modifications only appear in path [*:core :a*]. Thus
:reader is unable to access it (it's local [*:a*] is unchanged).
(def system-components [:a :updater :reader])
(defrecord Core [env] component/Lifecycle
(start [this] ...)
(stop [this] ...))
(defn component-core [env]
(component/system-map
:a (component/using
(ca/component-a env)
{})
:updater (component/using
(cs/component-updater env)
{:a :a})
:reader(component/using
(cs/component-reader env)
{:a :a})
:core (component/using
(map-Foobar {:env env})
{:a :a
:updater :updater
:reader :reader })))
*fig.1 *
I was hoping to use Component to manage all internal application state.
But maybe it's not designed for this use case (state changes between
components). I imagine that immutability is preventing all those duplicates
from seeing the modifications. However, in this case I do need an update to
:a in one component, to be accessed by another component.
Any suggestions on patterns here? I'm also looking at
component/update-systemhttps://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj#L116.
But again, I don't have access to the core *system* var, from within my
components.
Any insights appreciated
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
--
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: Managing State Changes, using Component
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 to all the components in the *'start* *'stop* functions. I say this, because when one of my dependant components updated an atom in it's own [*:local :a*], it was [*:core :a*] that reflected that change. I'm not sure if I follow correctly. Looking at your code, (ca/component-a env) should be called exactly once and the resulting value should be the :a. Then, when other components that depend on :a gets initialized, their [:local :a]'s should be exactly the same value. If the value we're talking about is an atom, i.e. ca/component-a returns an atom, then modifying this atom in one component (as you say above [:local :a]) would cause it's value, when [:core :a] is dereferenced, to be the new value. So if I'm not missing something, the situation you describe above is exactly how it should work. If you, however, say add a debug print in ca/component-a, and see that it's called more than once, you should file a bug report. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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: Managing State Changes, using Component
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 themselves, in an immutable fashion.
Agreed, this is what I've found. Component isn't for the use case of state
changes between components.
I'm actually looking at Datascript
https://github.com/tonsky/datascriptas a way of managing internal,
runtime, changing RIA state.
However from what I can understand, your component-a has an atom, like:
(-component-a (atom something))
Which should be OK. I mean it shouldn't matter from which path you are
accessing this atom.
Can you share the constructor/definition of the components?
I can't really share actual client code. But the system definition in
fig.1. pretty much describes how the real components are stitched together.
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 to all the
components in the *'start* *'stop* functions. I say this, because when one
of my dependant components updated an atom in it's own [*:local :a*], it
was [*:core :a*] that reflected that change.
On Wed, Apr 30, 2014 at 9:13 PM, Timothy Washington twash...@gmail.comwrote:
Hi all,
I'm having a weird state problem with
Componenthttps://github.com/stuartsierra/component.
Let's say I have a system component, like in fig.1. Starting / stopping and
loading state is fine.
However, let's say I have 2 other components (:updater , :reader) that
use component :a. This is the problem that occurs.
1. When *:updater*, modifies an atom in *:a*, that change appears in
path [*:core :a*], not path [*:updater :a*] or [*:a*].
2. Because of the abouve, when *:reader* goes to it's local path [
*:reader :a*] to read that change, it doesn't see those
modifications.
3. Using this scheme, *:a* is duplicated 4 times, in the system map.
However, the modifications only appear in path [*:core :a*]. Thus
:reader is unable to access it (it's local [*:a*] is unchanged).
(def system-components [:a :updater :reader])
(defrecord Core [env] component/Lifecycle
(start [this] ...)
(stop [this] ...))
(defn component-core [env]
(component/system-map
:a (component/using
(ca/component-a env)
{})
:updater (component/using
(cs/component-updater env)
{:a :a})
:reader(component/using
(cs/component-reader env)
{:a :a})
:core (component/using
(map-Foobar {:env env})
{:a :a
:updater :updater
:reader :reader })))
*fig.1 *
I was hoping to use Component to manage all internal application state.
But maybe it's not designed for this use case (state changes between
components). I imagine that immutability is preventing all those duplicates
from seeing the modifications. However, in this case I do need an update to
:a in one component, to be accessed by another component.
Any suggestions on patterns here? I'm also looking at
component/update-systemhttps://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj#L116.
But again, I don't have access to the core *system* var, from within my
components.
Any insights appreciated
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
--
Kind Regards,
Atamert Ölçgen
www.muhuk.com
--
--
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: Managing State Changes, using Component
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 something))
Which should be OK. I mean it shouldn't matter from which path you are
accessing this atom.
Can you share the constructor/definition of the components?
Also, have you tried confirming that only one :a is instantiated?
On Wed, Apr 30, 2014 at 9:13 PM, Timothy Washington twash...@gmail.comwrote:
Hi all,
I'm having a weird state problem with
Componenthttps://github.com/stuartsierra/component.
Let's say I have a system component, like in fig.1. Starting / stopping and
loading state is fine.
However, let's say I have 2 other components (:updater , :reader) that use
component :a. This is the problem that occurs.
1. When *:updater*, modifies an atom in *:a*, that change appears in
path [*:core :a*], not path [*:updater :a*] or [*:a*].
2. Because of the abouve, when *:reader* goes to it's local path [
*:reader :a*] to read that change, it doesn't see those modifications.
3. Using this scheme, *:a* is duplicated 4 times, in the system map.
However, the modifications only appear in path [*:core :a*]. Thus
:reader is unable to access it (it's local [*:a*] is unchanged).
(def system-components [:a :updater :reader])
(defrecord Core [env] component/Lifecycle
(start [this] ...)
(stop [this] ...))
(defn component-core [env]
(component/system-map
:a (component/using
(ca/component-a env)
{})
:updater (component/using
(cs/component-updater env)
{:a :a})
:reader(component/using
(cs/component-reader env)
{:a :a})
:core (component/using
(map-Foobar {:env env})
{:a :a
:updater :updater
:reader :reader })))
*fig.1 *
I was hoping to use Component to manage all internal application state.
But maybe it's not designed for this use case (state changes between
components). I imagine that immutability is preventing all those duplicates
from seeing the modifications. However, in this case I do need an update to
:a in one component, to be accessed by another component.
Any suggestions on patterns here? I'm also looking at
component/update-systemhttps://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj#L116.
But again, I don't have access to the core *system* var, from within my
components.
Any insights appreciated
Tim Washington
Interruptsoftware.com http://interruptsoftware.com
--
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.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
--
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.
