@fijal: I agree that parts of this topic have drifted off-topic for the py-py dev mailing list, so I've created a new mailing list specifically for discussions of collaboratively-edited software.
I'm inviting everyone to join the new mailing list at collaborative-ga...@googlegroups.com As far as the discussion regarding PyPy's capabilities with multiple-sandboxing, reloading, and continuation serialization go, I think that is a relevant discussion for this forum. I'm still very interested in understanding (a) what PyPy can already do, and (b) what is involved in adding the features I need. I'm itching to work on PyPy :) @Laura + William: Alessandro's paper concisely describes what I was planning on doing, with the exception that the sprout() method was taking place in Java. After reading the paper I see the utility of also allowing sprouting within Javascript. I am a bit concerned about data size, however. Loading all world data is an expensive op, even if it creates a simple way to perform psuedo-transactions. Nathanael http://nathanaeljones.com On Tue, Jan 11, 2011 at 6:51 AM, William ML Leslie < william.leslie....@gmail.com> wrote: > Fijal is right, fwiw. There are lots of wonderful things that *could* > be implemented, but what we *have* is the stackless transformation and > a low-level sandbox system. Discussions of python architecture are > always enjoyable, but they don't have a proper place, as far as I > know; I often abuse #python for that. > > On 11 January 2011 22:03, Laura Creighton <l...@openend.se> wrote: > > When I was last in the USA, I met Alessandro Warth, who now works for > > the Viewpoints Research Institute and whose Phd thesis which you can get > > on this page: http://www.tinlizzie.org/~awarth/ is about experiments in > > computer languages to do the sorts of things that you are interested in. > > He had a neat implementation of something he called 'worlds' to show off, > > and gave a talk about it. It's chapter 4 of his thesis. > > I first read this paper as background for pymeta - it's one of those > that you just can't put down. There is one thing I felt was missing > from the worlds thesis though, namely, handling arrays. To treat them > like any other ecmascript object results in strange semantics - if two > worlds push to the one array and both are merged, it is as if only one > of the pushes occurred. Python lists have different usage patterns > than javascript objects, so handling their diffs correctly and > efficiently might require some experiments. > > > They concluded that what they would really like is a programming language > > which multiple heaps -- in the sense of chunks of memory that you get > > when you malloc -- guaranteed to be separate from each other. I couldn't > > tell them how hard this would be to implement in PyPy. Aside from > needing > > to write a custom garbage collector, what else would be needed? > > How would that be different to separate pypy processes? Or is that > more like regions in cyclone, or like subinterpreters in TCL? > > -- > William Leslie > > PS: worlds are an ideal use case for first-class algebraic effects! >
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev