Glad to hear that!
https://www.assembla.com/spaces/clojure/tickets/213-Invariants-and-the-STM
On Sun, Nov 29, 2009 at 3:05 PM, Rich Hickey wrote:
> On Tue, Nov 24, 2009 at 3:14 AM, Christophe Grand
> wrote:
> > On Mon, Nov 23, 2009 at 11:56 PM, John Harrop
> wrote:
> >>
> >> I'm starting to th
On Tue, Nov 24, 2009 at 3:14 AM, Christophe Grand wrote:
> On Mon, Nov 23, 2009 at 11:56 PM, John Harrop wrote:
>>
>> I'm starting to think that for some tasks Clojure could use a concept of
>> "row locking" with maps. It would mean having a map-of-refs type that was
>> integrated with the STM,
On Nov 24, 7:50 pm, Krukow wrote:
> On Nov 14, 5:42 pm, André Thieme wrote:
>
> > But in real programs things are not so easy. We have refs in refs.
>
> This is just a thought experiment. But what about actually having refs
> in refs? I'm not sure if I am reinventing mutable object here, so
> p
On Nov 14, 5:42 pm, André Thieme wrote:
> But in real programs things are not so easy. We have refs in refs.
This is just a thought experiment. But what about actually having refs
in refs? I'm not sure if I am reinventing mutable object here, so
please shoot me down ;-)
Clojure 1.1.0-alpha-SNA
On Mon, Nov 23, 2009 at 11:56 PM, John Harrop wrote:
> I'm starting to think that for some tasks Clojure could use a concept of
> "row locking" with maps. It would mean having a map-of-refs type that was
> integrated with the STM, so multiple updates whose keys didn't collide could
> occur concu
On Mon, Nov 23, 2009 at 4:34 PM, Sergey Didenko wrote:
> Hi,
>
> Andre, Danny's first approach is about "syncing" only on the root
> object, so that every piece of data is behind one deref:
>
> (def root (ref {:persons [ ... no other refs here... ]))
>
> This approach is simpler to code but can le
On Mon, Nov 23, 2009 at 22:46, Sergey Didenko wrote:
> BTW I'm also coding the simple persistence for Clojure data
> structures. Though I took Prevayler approach (http://prevayler.org),
> so I journal function calls that change my root object.
>
> This approach is better than simple snapshotting w
BTW I'm also coding the simple persistence for Clojure data
structures. Though I took Prevayler approach (http://prevayler.org),
so I journal function calls that change my root object.
This approach is better than simple snapshotting when your data grows
big, so you can't do the snapshots very oft
Hi,
Andre, Danny's first approach is about "syncing" only on the root
object, so that every piece of data is behind one deref:
(def root (ref {:persons [ ... no other refs here... ]))
This approach is simpler to code but can lead to a lot of retried
transactions under heavy concurrent load, as I
On Nov 15, 9:05 am, Danny Woods wrote:
> > Danny, could you maybe hack up a possible very simple example of what
> > you mean?
>
>
>
> > I can not simply store a copy of the Karl person in Tinas :friends
> > slot,
> > because when Karl gets one year older, then I don‘t want to go through
> > al
> In the example I made up Tina has the friend Karl.
> I can not simply store a copy of the Karl person in Tinas :friends
> slot,
> because when Karl gets one year older, then I don‘t want to go through
> all persons, looking for Karls, and have their age updated.
> Instead it is preferred to have
> Danny, could you maybe hack up a possible very simple example of what
> you mean?
> I can not simply store a copy of the Karl person in Tinas :friends
> slot,
> because when Karl gets one year older, then I don‘t want to go through
> all persons, looking for Karls, and have their age updated.
On 14 Nov., 20:32, Danny Woods wrote:
> André Thieme wrote:
> > How can we handle this situation?
> > Is it possible to implement a function “deep-deref” which works
> > as blindingly fast as deref does?
> > I find this very important, and this is of great practical relevance
> > for me. Please
On 14 Nov., 20:22, John Harrop wrote:
> On Sat, Nov 14, 2009 at 2:11 PM, John Harrop wrote:
> > On Sat, Nov 14, 2009 at 11:42 AM, André Thieme <
> > splendidl...@googlemail.com> wrote:
>
> >> Dereferencing *persons* will result in:
> >> {"Tina" #,
> >> "Jeff" #,
> >> "Karl" #}
> >> Great so far
André Thieme wrote:
> How can we handle this situation?
> Is it possible to implement a function “deep-deref” which works
> as blindingly fast as deref does?
> I find this very important, and this is of great practical relevance
> for me. Please share your ideas
Hi André,
I had a similar issue wi
On Sat, Nov 14, 2009 at 2:11 PM, John Harrop wrote:
> On Sat, Nov 14, 2009 at 11:42 AM, André Thieme <
> splendidl...@googlemail.com> wrote:
>
>> Dereferencing *persons* will result in:
>> {"Tina" #,
>> "Jeff" #,
>> "Karl" #}
>> Great so far.
>>
>> People can become friends, so we need
>> (defn
On Sat, Nov 14, 2009 at 11:42 AM, André Thieme
wrote:
> Dereferencing *persons* will result in:
> {"Tina" #,
> "Jeff" #,
> "Karl" #}
> Great so far.
>
> People can become friends, so we need
> (defn add-friend [#^String person #^String friend]
> (dosync
>(let [p (get @*persons* person)
>
17 matches
Mail list logo
