I've extended the Clojure core to extend durability to functions and
closures.
1. Functions with lexical and dynamic bindings are now supported. This
includes functions that generate functions.
1.a. There is a slight overhead applied to all compiled functions; the
bytecode is inaccessible at runtime except through a cache which
maintains an entry for all classes regardless of whether they are
eventually persisted or not. This doubles memory required per class,
but should, in practice, be negligible.
2. Identities of identities are now supported. This means that
persistent data structures of identities can be saved, i.e. you can
have a ref of a hash-map of refs.
3. sorted-map and sorted-set are now supported.
Get it here: git://github.com/kwanalyssa/clojure.git
More testing, especially performance testing, is very welcome.
However, at this point, I've satisfied my own requirements. I'd love
to get this in scope eventually for enhancing Clojure core, if pain-
free persistence is part of the grand vision. Discussion of API and
implementation is also welcome.
> I've extended the Clojure core to extend durability to functions and
> closures.
> 1. Functions with lexical and dynamic bindings are now supported. This
> includes functions that generate functions.
> 1.a. There is a slight overhead applied to all compiled functions; the
> bytecode is inaccessible at runtime except through a cache which
> maintains an entry for all classes regardless of whether they are
> eventually persisted or not. This doubles memory required per class,
> but should, in practice, be negligible.
> 2. Identities of identities are now supported. This means that
> persistent data structures of identities can be saved, i.e. you can
> have a ref of a hash-map of refs.
> 3. sorted-map and sorted-set are now supported.
> Get it here: git://github.com/kwanalyssa/clojure.git
> More testing, especially performance testing, is very welcome.
> However, at this point, I've satisfied my own requirements. I'd love
> to get this in scope eventually for enhancing Clojure core, if pain-
> free persistence is part of the grand vision. Discussion of API and
> implementation is also welcome.
On Sat, Nov 27, 2010 at 1:10 PM, Mark <markaddle...@gmail.com> wrote: > Hi -
> I'm surprised your work doesn't generate more interest from folks. I > wish I had more time, I would definitely jump in and help.
Persistence doesn't seem to generate much interest in general. I posted my own stab at a way of persisting the ref world near-transparently a few weeks ago and it sank without a ripple.
> On Sat, Nov 27, 2010 at 1:10 PM, Mark <markaddle...@gmail.com> wrote:
> > Hi -
> > I'm surprised your work doesn't generate more interest from folks. I
> > wish I had more time, I would definitely jump in and help.
> Persistence doesn't seem to generate much interest in general. I
> posted my own stab at a way of persisting the ref world
> near-transparently a few weeks ago and it sank without a ripple.
On Mon, Dec 6, 2010 at 1:09 PM, Alyssa Kwan <alyssa.c.k...@gmail.com> wrote: > Yes, but why isn't persistence of <em>closures</em> generating more > interest. ;)
> Persistence is "solved", if you're OK with not being truly ACID...
> Seriously though, everyone has their own backends. I don't think > anyone wants to be tied to BDB JE.
> Would there be interest in lazy-loading and -unloading data > structures?
That code I wrote does sort of do lazy loading and unloading data structures. That is, it can be used to make structures that are loaded in pieces, on demand, as an algorithm reaches a particular piece, and that can be referenced without loading them just from hanging onto the thing's address somewhere.
