[pypy-dev] Continuations and sandboxing

[Nathanael D. Jones]

@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-games at 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.ttg at 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 <lac at 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20110111/6175be76/attachment.html>