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 richhic...@gmail.com wrote:
On Tue, Nov 24, 2009 at 3:14 AM, Christophe Grand christo...@cgrand.net
wrote:
On Mon, Nov 23, 2009 at 11:56 PM, John Harrop
On Tue, Nov 24, 2009 at 3:14 AM, Christophe Grand christo...@cgrand.net wrote:
On Mon, Nov 23, 2009 at 11:56 PM, John Harrop jharrop...@gmail.com 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
On Mon, Nov 23, 2009 at 11:56 PM, John Harrop jharrop...@gmail.com 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
On Nov 14, 5:42 pm, André Thieme splendidl...@googlemail.com 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
On Nov 24, 7:50 pm, Krukow karl.kru...@gmail.com wrote:
On Nov 14, 5:42 pm, André Thieme splendidl...@googlemail.com 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
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
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
On Mon, Nov 23, 2009 at 22:46, Sergey Didenko sergey.dide...@gmail.com 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
On Mon, Nov 23, 2009 at 4:34 PM, Sergey Didenko sergey.dide...@gmail.comwrote:
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
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
On Nov 15, 9:05 am, Danny Woods dannywo...@gmail.com wrote:
Danny, could you maybe hack up a possible very simple example of what
you mean?
snip
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
Danny, could you maybe hack up a possible very simple example of what
you mean?
snip
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.
and if yes updating his age there too.
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.
--
You received this message
On Sat, Nov 14, 2009 at 11:42 AM, André Thieme
splendidl...@googlemail.comwrote:
Dereferencing *persons* will result in:
{Tina #r...@7ae6d: {:name Tina, :age 19, :friends []},
Jeff #r...@125d92c: {:name Jeff, :age 22, :friends []},
Karl #r...@14fa0ef: {:name Karl, :age 20, :friends []}}
On Sat, Nov 14, 2009 at 2:11 PM, John Harrop jharrop...@gmail.com wrote:
On Sat, Nov 14, 2009 at 11:42 AM, André Thieme
splendidl...@googlemail.com wrote:
Dereferencing *persons* will result in:
{Tina #r...@7ae6d: {:name Tina, :age 19, :friends []},
Jeff #r...@125d92c: {:name Jeff, :age
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
On 14 Nov., 20:22, John Harrop jharrop...@gmail.com wrote:
On Sat, Nov 14, 2009 at 2:11 PM, John Harrop jharrop...@gmail.com wrote:
On Sat, Nov 14, 2009 at 11:42 AM, André Thieme
splendidl...@googlemail.com wrote:
Dereferencing *persons* will result in:
{Tina #r...@7ae6d: {:name Tina,
On 14 Nov., 20:32, Danny Woods dannywo...@gmail.com 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
18 matches
Mail list logo
