Mailman 3 February 2003 - pypy-dev

pypy-dev List Summary - 09 Feb 2003 to 16 Feb 2003
by Troy Melhase Feb. 17, 2003

Feb. 17, 2003

This is a summary of the discussions on the pypy-dev mailing list between 09 February and 16 February 2003. The full archive of the list can be found here: http://codespeak.net/pipermail/pypy-dev/ ZODB and Threads ---------------- In a continuation from last weeks thread discussing multiple VMs in a single process, Jeremy Hylton says multi-threaded ZODB applications can use multiple connections. His response prompts Tobias Oberstein to share his belief that the GIL is the real issue. … [View More]

1 0

downtime codespeak/pypy
by holger krekel Feb. 17, 2003

Feb. 17, 2003

Hello, we plan to transfer the codespeak-computer which hosts the pypy site to the sprint-place. This gives us 100 MBit access to our repository among other conveniencies. So expect some downtimes on early sunday afternoon after which the DNS-switch should be completed. mail to the pypy-dev list should be automatically deferred until the host is online again. Of course it would be nicer to have a second computer which could take-over without downtime but Jens-Uwe didn't manage to get … [View More]

2 2

repository access
by holger krekel Feb. 16, 2003

Feb. 16, 2003

Hi again, we plan to use subversion for managing our code. If you want to participate from the outside or otherwise share/contribute code please try to setup a subversion client. I've heard that installing it is not too obvious from the http://subversion.tigris.org website so if you succeed installing it on your system, success stories are certainly welcome. For people using Gentoo Linux i've have success doing an ebuild on "Neon" and subsequently "subversion" which appears to work. … [View More]

4 7

Re: [pypy-dev] Object model
by roccomoretti＠netscape.net Feb. 15, 2003

Feb. 15, 2003

Armin Rigo <arigo(a)tunes.org> wrote: >One of the problems with wrap()/unwrap() is when they are applied to >containers. As they are, they have to "translate" the whole structure >recursively, which is often not a good idea. > >On the other hand, if we define more specialized purpose-oriented methods, we >loose opportunities given by wrap()/unwrap() to let particular routines send >or examine an arbitrary piece of data. I'm thinking about type-based >… [View More]

1 0

Runtime information from tests
by holger krekel Feb. 15, 2003

Feb. 15, 2003

Hello, the following idea has been circulating in my mind quite a bit. I'll put this to discussion on the sprint but you may want to comment here on the list, too. I think that we should generally use our (unit-) tests in combination with our flexible upcoming interpreter to gather type and other information at *runtime*. This dynamically gathered information can later be used to generate C, ObjC or other source code. Or for optimizations debugging and whatnot. So we wouldn't … [View More]

1 0

Memory management
by Richard Emslie Feb. 15, 2003

Feb. 15, 2003

Hi all, This is my first post. I have been enjoying lurking away here, reading the various threads has been interesting despite having to occasionally peel my brain off the frying pan ;-) I have a naive question which I hope some kind sole will help me out on. I have been waiting for memory management (lower level than garbage collecting / ref counting) to be discussed. I'm probably barking up the wrong tree - but a "pypy python" object has to be resident in memory somehow - and this needs … [View More]

4 4

Re: [pypy-dev] repository access
by Laura Creighton Feb. 15, 2003

Feb. 15, 2003

Windows users who would like to connect to subversion through internet explorer can try TortoiseSVN http://tortoisesvn.tigris.org/ I haven't used that myself, but I have seen its big brother TortoiseCVS in action http://www.tortoisecvs.org/ and it makes CVS one heck of a lot easier on Windows. Laura Creighton

1 0

Object model
by Armin Rigo Feb. 14, 2003

Feb. 14, 2003

Hello everybody, I have been experimenting a bit about that distinction I tried to draw between "application-level" and "interpreter-level" objects. I still think the idea to be essential but I "reorganized" my thoughts a little bit. Now I believe in following the idea that CPython's main loop does not assume anything at all about the PyObjects it manipulates, but does every operation via calls to library functions like PyNumber_Add(). All it does is moving PyObjects around, mainly between … [View More]the stack and the locals. Similarily, our own main loop should not assume anything about the objects it stores in the stack and the locals, not even that they have some well-known methods. Instead, we would provide it with the equivalent of PyNumber_Add() & co. Now the fun part of it is that there is no reason to use only one fixed set of functions to do the operations. There are several things we want to be able to do with our interpreter, and these will probably correspond to different ways of "seeing" what an object is. We might try several ways to implement the objects, for example trying different implementations for what the application will always see as a list. And even, we might want to have several concurrent "object spaces" existing at the same time, e.g. to implement the idea of multiple VMs in the same process. Thus it seems natural to define a class ObjectSpace, that defines methods like PyNumber_Add() and PySequence_GetItem(). Each frame would have an ''objectspace'' attribute that holds the space in which it runs. (Maybe shorter, more Pythonic names are better, e.g. add() and getitem().) Thus an object space is: * a way to implement objects; * from the interpreter's point of view, it is the "library" needed to do any operation; * from the application's point of view, it is essentially invisible. Methods: * add(x,y), getitem(x,y), etc. for the operations, that take two "objects" (black boxes for the interpreter) and returns an "object" (black box too). * type(x), taking a black box object and returning a black box object as well. * wrap(a), taking a *normal* object and putting it into a black box. Its what the interpreter does for a LOAD_CONST, for example: it has a real Python object and wants to send it to the object space. For example, if the object space has a custom implementation "class MyList" for lists, then wrap([1,2,3]) should create a MyList instance. * unwrap(x) is the inverse operation. Used by the interpreter in the rare cases where it really needs to observe the object. For example, for a conditional jump, after it obtained the truth-value with (say) a call to the truth() method, it must pull the result out of the object space to know whether it is really False or True. For example, the straightforward object space that just uses real Python objects to implement themselves would be defined like that: class BorrowingObjectSpace(ObjectSpace): def wrap(self, x): return x def unwrap(self, x): return x def add(self, x, y): return x+y def type(self, x): return type(x) ... Cool things can be imagined with other kinds of object spaces. We may even think about a distributed interpreter, running on one machine with object spaces that actually reside on other machines! With this perspective, wrap(x) sends x to the remote machine and returns a handle to it, and unwrap(x) downloads from the remote machine the object whose handle is x. We may even have several concurrently-running object spaces that could communicate, e.g. running a frame in a different object space and marshalling arguments and the return value! Looks like a cool point of view, doesn't it ? A bientôt, Armin. [View Less]

4 6

Re: [pypy-dev] Scons?
by Bram Moolenaar Feb. 14, 2003

Feb. 14, 2003

Holger Krekel wrote (to Charles Crain): > As we plan to run on top of CPython first it makes a lot > of sense to have SCons drive the CPython build and thus > get rid of make/configure dependencies. It's also a good > release goal for our sprint. The real challenge here is > to have a scheme for taking current CPython-cvs as an > "upstream" and have a system for keeping in > sync what we take out of CPython into our CPython-PyPy. As an alternative, you might want to … [View More]

2 2

Re: [pypy-dev] Is anybody planning to give a talk on PyPy for OSCON?
by Laura Creighton Feb. 13, 2003

Feb. 13, 2003

In a message of Thu, 13 Feb 2003 21:32:30 +0100, holger krekel writes: >[Laura Creighton Wed, Feb 12, 2003 at 08:47:09PM +0100] >> This is precisely the sort of thing that Nat Tarkington said >> he wanted for the Python track -- new community efforts, new >> implementations. >> >> Who is going to OSCON here besides me? > >I might go but it's impossible to say now. It's quite >an expensive and faraway-from-here trip. > >Anyway, I am fine with … [View More]

1 0