On Sep 5, 8:56 pm, Alyssa Kwan alyssa.c.k...@gmail.com wrote:
Any thoughts on how to marshal functions? What about vars and dynamic
binding?
I don't think marshaling closures will ever happen without changes to
Clojure itself. I haven't looked into how much work it would require,
or how much it
On Aug 30, 5:02 pm, nchubrich nchubr...@gmail.com wrote:
Persistence libraries always end up warping the entire codebase; I've
never succeeded in keeping them at bay. Using data with Incanter is
different from ClojureQL, which is different from just using
contrib.sql, and all of it is
OK... This question is probably better directed at clojure-dev, but my
membership is still pending. I'm having trouble interpreting
LockingTransaction.run. Where exactly are read-locks for ensures set?
And what precisely is in the commutes map and sets set? Why does
membership in sets
How about introducing a second part to the api? (store) creates a
wrapper for the persistent address, and refp then takes one of those
wrappers and the name?
I like that. I would go one step further and say refp should have a
default data store that is used unless you specify anything
Thanks, Constantine! Your work on cupboard is awesome! I'll take a
look at the deadlock detection to see if I can help.
Any thoughts on how to marshal functions? What about vars and dynamic
binding?
Thanks!
Alyssa
On Sep 5, 11:02 am, Constantine Vetoshev gepar...@gmail.com wrote:
On Aug 30,
Revision number is a great idea!
I don't think I want to do copy-on-write within Clojure because it
would require a separate thread for cleanup. The underlying database
should take care of it anyways.
Thanks!
Alyssa
On Sep 2, 8:47 am, Timothy Baldridge tbaldri...@gmail.com wrote:
It checks the
ITA. I was planning on doing what clojure.contrib.sql does with a
global var and with-connection block for dynamic binding. Unless
people don't like that approach...
On Sep 2, 12:56 pm, Mike Meyer mwm-keyword-googlegroups.
620...@mired.org wrote:
On Wed, 1 Sep 2010 15:14:45 -0700 (PDT)
How about introducing a second part to the api? (store) creates a
wrapper for the persistent address, and refp then takes one of those
wrappers and the name?
I like that. I would go one step further and say refp should have a
default data store that is used unless you specify anything else
I'll go one step further and say that we shouldn't have to call
persist namespace. It should be automatic such that a change to the
state of an identity is transactionally written.
Let's start with refs. We can tackle the other identities later.
The API is simple. Call (refp) instead of (ref)
Persistant variable handling is one of the things which I have spent much
time on as a beginner and former SQL-illiterate (Among getting the swank to
finally work (it's a dream!)). I have however got into databases quite a bit
among the way - but it was not my main goal and it has taken some time
It checks the value against memory. If it's
the same, commit data store changes. If not, retry after refreshing
memory with the current contents of the store.
May I suggest we take a page from the CouchDB book here? In addition
to having a id each ref also has a revision id. Let's say the id
On Wed, 1 Sep 2010 15:14:45 -0700 (PDT)
Alyssa Kwan alyssa.c.k...@gmail.com wrote:
I'll go one step further and say that we shouldn't have to call
persist namespace. It should be automatic such that a change to the
state of an identity is transactionally written.
Let's start with refs. We
I'd like to see a day when programmers need to worry about persistence
about as much as they worry about garbage collection now.
Me too, but of course beware of leaky abstractions.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
I'm not aware of any, but +1 for seeing persistence handled as part of
the language. A big project and a long-term one, to be sure, but
could it not be considered a goal?
In my student days, I was talking to a well-known Lisper (name
suppressed for fear of Google indexing) about some data
I'm resurrecting this thread from quite a while ago... I'm very
interested in being able to ensure that the state of a ref is
persisted as part of the same transaction that updates the ref.
Performance is not important; correctness is. Has any further work
been done on this front?
Cool stuff, Dave. I'm interested to see/test it, could you post it as
an attachment to this group or commit it to contrib ?
Cheers,
Razvan.
On Dec 8, 9:08 pm, Dave Griffith [EMAIL PROTECTED] wrote:
Okay, hacking complete. I've got a patch that extends the Clojure STM
so that it will make
Since it requires changes to the Clojure runtime, it probably doesn't
make much sense to put it in contrib. I've posted it as an attachment
to the group.
--Dave Griffith
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Okay, hacking complete. I've got a patch that extends the Clojure STM
so that it will make appropriate callouts to an external transaction
manager that cause the STMs transaction to be atomic/consistent/
isolated with respect to an external transaction, using a dosync-
external macro. Note that
Hi Dave. I think your proposal would be useful to have in Clojure, I
have thought about something similar since I read about the STM. But I
also think there are quite a few difficulties in implementing this in
a sane way. Actually, the more I think about it, the more it seems
that the goal of STM
It often happens that I would like to have gaurantees about the
consistency of in-memory data structures and external resources. For
instance, in the last two large systems I've built, the system would
respond to an external message received via socket, do some complex
processing based on the
20 matches
Mail list logo
