On Tue, Jan 11, 2011 at 2:58 PM, holger krekel <hol...@merlinux.eu> wrote: > Hi Maciej, > > it's not clear to me what posts your are refering to. Certainly > not the original post from Nathan? > > If you think it's a general issue then do a top-level posting and please > suggest how "non-active" (defined how?) pypy developers are supposed to > know if some topic is interesting without posting about it. And include > some concrete rules about when side discussions are ok and when not. > Probably all harder to do than improving your ignoring techniques?
Well, I can easily ignore things that are not interesting to me. My point was that discussions about topics (like capabilities) only make sense if there is someone even remotely interested in implementing that in PyPy. Otherwise discussions tend to drift into "but that's also a cool idea", which is off-topic for PyPy, since noone actually wants to implement any of those. For example I would say all GIL-removal discussions are offtopic unless someone has a will to experiment with implementing it. That's, as I said above, my personal opinion, backed by a fact that this is the list for discussing developing PyPy (so some people, like me, feel obliged to read whole discussions here). Feel free to propose some other guidelines for what is on-topic and what is off-topic for that list. As active I mean anyone doing any work on PyPy. Be it a typo in documentation :) Cheers, fijal > > cheers, > holger > > On Tue, Jan 11, 2011 at 09:48 +0200, Maciej Fijalkowski wrote: >> Hello. >> >> This discussion have drifted considerably. In general this is the pypy >> development mailing list, so personally I would like to keep >> discussions only to things that are either very interesting for people >> actively working on PyPy or have remote possibility that someone will >> start working on them. Discussing STM without someone being interested >> in actually looking is out of topic. >> >> PS. Feel free to correct me if anyone working actively on pypy is >> finding this discussion useful for PyPy development. >> >> Cheers, >> fijal >> >> On Tue, Jan 11, 2011 at 9:43 AM, William ML Leslie >> <william.leslie....@gmail.com> wrote: >> > On 11 January 2011 15:25, Nathanael D. Jones <nathanael.jo...@gmail.com> >> > wrote: >> >> Regardng #1: Sandboxing is a major concern for me. Different code will >> >> need >> >> different sandboxing levels depending upon who created/approved the code. >> >> I can't have everything in one sandbox - I need isolated boxes on a >> >> per-request level. >> > >> > You will probably want to implement a capability architecture, where >> > the authority to perform some action is bundled together with the >> > method that invokes it. The language E ( http://erights.org ) was >> > designed for this sort of thing (I think it was written for a MUD >> > originally), and would be worth looking at even if you didn't use the >> > language itself. Capability theory is sadly not well known, >> > considering just how well it solves ever more common problems. >> > >> >> The idea is that if functions return the next function to call instead of >> >> calling them, we have explicit tail-call elimination, and we have an >> >> explicit point at which we can rebuild the sandbox and upgrade the code. >> > >> > Right, this is the "driver loop" implementation of TCE. There are >> > several implementations of TCE kicking around, (including one I did >> > for cpython some time ago, a decorator that would patch load ... call* >> > ... return bytecodes with a call to a class that collects the function >> > and arguments, and wraps the function in a driver loop that is >> > bypassed when the target is marked as recursive, too). >> > >> > Unfortunately, using only implicit continuations, once you enter >> > somebody's function, you have no way to get out of it - that person >> > can except: and trap you there if they like. E has a way to protect >> > against this, but you can't protect against the function busy-looping >> > without something more (a way to kill threads, specifically, which >> > probably means taking down the process). >> > >> >> Much data will be user scoped, and therefore lockable. >> > >> > What does lockable mean in this case? >> > >> > Under what conditions does reloading happen while a user continuation >> > is in play? How do you want continuations to interact with the >> > locking? >> > >> >> On Mon, Jan 10, 2011 at 5:05 PM, William ML Leslie >> >> <william.leslie....@gmail.com> wrote: >> >>> >> >>> On 11 January 2011 07:18, Paolo Giarrusso <p.giarru...@gmail.com> wrote: >> >>> >> The one issue that interests me is where you implement the persistence >> >>> >> boundary - do you go with orthogonal persistence and act as if >> >>> >> everything is preserved, or assume all user code is run within some >> >>> >> sort of (fast and loose) transaction that can be re-entered at will, >> >>> >> providing an API for persistent data access? The second case makes >> >>> >> the reloading question a bit more reasonable, because you can always >> >>> >> throw away the current delta and replay the external effects, assuming >> >>> >> the interface for the external events hasn't changed significantly. >> >>> > >> >>> > The key question is: when would you start and commit such transactions? >> >>> > >> >>> > Apart from that, your idea looks very similar to Software >> >>> > Transactional Memory (STM). STM restarts explicitly-marked >> >>> > transactions in a thread when some other thread modifies the affected >> >>> > data (which would be a data race) and commits its transaction. In your >> >>> > case, a transaction is restarted when some other thread modifies the >> >>> > involved code. >> > >> > I don't think it would be useful at all to have regular STM >> > transactions delimited at the room boundary - there are surely going >> > to be other people interacting with the room at the same time as you, >> > and sending everyone else back to the start of the room every time >> > someone modifies the room is going to get old very quickly. The >> > boundary introduced by modifying code is probably significantly more >> > coarse. >> > >> > If you are storing (as the transaction log) only the external effects >> > (user input, random.* output), however, you can build effect >> > commutators automatically. For example, given a code change to object >> > X, you can initialise it with the previous persistent state, and >> > replay the effects within the current transaction. >> > >> > That said, I think having a transaction per room is too coarse - per >> > input or set of inputs makes even more sense. The idea there is that >> > there is much less code to replay when two effects interfere. >> > >> > -- >> > William Leslie >> > _______________________________________________ >> > pypy-dev@codespeak.net >> > http://codespeak.net/mailman/listinfo/pypy-dev >> > >> _______________________________________________ >> pypy-dev@codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev > -- > _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
