Mailman 3 February 2003 - pypy-dev

Is anybody planning to give a talk on PyPy for OSCON?
by Laura Creighton 13 Feb '03

13 Feb '03

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? Laura Creighton

3 2

Re: [pypy-dev] Object model
by logistix 13 Feb '03

13 Feb '03

VanL <vlindberg(a)verio.net> wrote: > I think you are envisioning a model interpreter that works (more or > less) like the CPU works in a computer. > > CPUs, especially RISCy ones, usually work with essentially three things: > > 1. Operators (like iadd, fadd, imul, fdiv, or, xor, etc) > 2. Registers > 3. Immediate values > > > It also might suggest a bootstrapping procedure: > > 1. Start with the bytecode, rather than the compiler. Treat the byte > code as "machine code" that we execute and CPython as the compiler. A lot of the stuff he's talking about here is based on the existing Python Interpreter. It runs stack-based bytecode, where the stack simply contains pointers to PyObjects. It's also a little wierd because it turns functions and stuff into code objects that get thrown on the stack instead of trying to represent everything as a monolithic block of memory where you would JSR to a memory address to call a function. Then these code objects can have their own embedded code objects. Since you seem to have a good low-level understanding of things, checking out the documentation for the 'dis' module will show you all the existing "assembly" instructions. ceval.c has the actual implementation of the interpreter loop.

1 0

Re: [pypy-dev] Scons?
by Charles Crain 13 Feb '03

13 Feb '03

(in response to Holger Krekel's question about SCons) I am on the SCons development team, and can answer any questions you have about using SCons for PyPython. It's still "technically" in Alpha, which by our definition simply means it is not feature complete. However, the features it does have are extremely stable and well-tested...we have a very large automated test suite, a rigorous testing process, and a growing user community. We make releases about once a month (we try to anyway), and we are theoretically only a handful of releases away from a first final version. We'd be very entusiastic about being included in a high-profile (and technically really cool) project like PyPython. Please let us know if we can do anything for you. Feel free to email me or post to the scons-users email list (information at www.scons.org). -Charles

2 1

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

13 Feb '03

In a message of Thu, 13 Feb 2003 03:07:50 +0100, Christian Tismer writes: >Laura Creighton wrote: >> 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'm to PyCon already, cannot do them both. > >-- >Christian Tismer :^) <mailto:tismer@tismer.com> >Mission Impossible 5oftware : Have a break! Take a ride on Python's >Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ >14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ >work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 >PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today? http://www.stackless.com/ > Okay, does anybody mind if I submit a proposal to OSCON, 'a report on the Sprint and the project'? If nobody minds, anything you want to make sure I put in the proposal? Laura

1 0

reusing existing work: Parrot
by Tobias Oberstein 12 Feb '03

12 Feb '03

more by accidence, I came across the following stuff http://www.parrotcode.org which might be of interest when it comes to - reusing existing work in PyPy - focusing PyPy (whatever this means) and concentrating manpower .. Parrot will be the new VM written from scratch for Perl6. The developers claim that its generally suitable for dynamically typed languages - which fits Python as well. Also it is designed as an abstract register machine, which they claim will provide better performance. Btw.: JVMs and .NET CLI are stack-based VMs optimized for statically typed languages. Regarding targeting Parrot from Python, there has been some work done: http://www.amk.ca/conceit/parrot.html As I understand it, the main thing lacking is a "port" of Python objects (dicts,..) to Parrot, where there are "PMCs" which are very similar to PyObject. I have no stakes in either PyPy or Parrot - it's just my two pence that it could pay to not reinvent another VM, but port as much modules/objects to pure Python (which is all about PyPy as I understood) and write a Python->Parott Bytecode emitter plus complement with appropriate PMCs. Greets, Tobias

4 4

Updates from the sprint?
by VanL 12 Feb '03

12 Feb '03

For those of us who are unable to get to Germany, is there any way to get updates from the sprint? These don't have to be cooked or processed -- we can do that, and the sprinters can sprint. But being able to follow what goes on would be very interesting. If I could get all I would wish for, we could get: 1. Some sort of recording of the talks given each evening. 2. Presentation materials 3. The code snapshot from the previous night. Would this be possible? Van

5 4

Scons?
by holger krekel 12 Feb '03

12 Feb '03

Hello, i have been following the SCons effort for quite some time without seriously deploying it. I know that Skip Montanero did some tests with the CPython-sources and said he liked it. Is anybody here on the list who knows enough about SCons to tell what the current state of it is? And if it would suite the CPython-build process? Anybody tried anything? If we want to do it i imagine that we could contribute it to CPython if there is interest. Yes, i know there is a bootstrapping problem (as always) but that's secondary IMO. holger

2 1

multiple isolated VMs in a single process
by Tobias Oberstein 10 Feb '03

10 Feb '03

Are there any design plans regarding threading architecture yet? I particular, are you planning to support having multiple interpreters in one process _without_ sharing objects (no free threading but VM-wise locking). Supporting this would require early design decisions like - no global data for the interpreter/VM - no global data in object implementations - but what about extension modules? many have global data .. isn't it? Also, in an C embedding API, will the VM-state be take from thread-local storage or passed into every function by the embedding application via an opaque pointer? I'm thinking of embedding a dynamic language into an multithreaded OODBMS. The different VMs within the server process would share data via objects instantiated from a special extension class that wraps up the OODBMS. Synchronisation on these objects is taken care of by the OODBMS. No need to share objects local to each VM. Sadly, as I was told, fixing above issues for CPython would be hard like shit. It's so sad that global data has not been avoided from the very beginning in the CPython. Tobias

3 6

Wiki content
by Armin Rigo 09 Feb '03

09 Feb '03

Hello everybody, I have put some content into the Wiki. It is some kind of a technical summary of all the aspects we discussed so far -- a very subjective one, anyway. Any different opinion is of course welcome. And if I missed your pet subject, I give you my apologizes (but after you receive them, go ahead and add it to the Wiki :-) http://codespeak.net/moin/pypy/moin.cgi/PyPythonProjects I inserted a couple of links to my own experiments in the Wiki pages: * a Python-interpreter-in-Python toy that I used as bytecode checker http://codespeak.net/moin/pypy/moin.cgi/BytecodeInterpreter * a custom (incomplete) C parser http://codespeak.net/moin/pypy/moin.cgi/LibraryMaintenance * an x86 assembler/disassembler http://codespeak.net/moin/pypy/moin.cgi/RuntimeSystemJit A bientôt, Armin.

1 0

pypy-dev List Summary - 01 Feb 2003 to 08 Feb 2003
by Troy Melhase 09 Feb '03

09 Feb '03

This is a summary of the discussions on the pypy-dev mailing list between 01 February and 08 February 2003. The full archive of the list can be found here: http://codespeak.net/pipermail/pypy-dev/ Compiler Benchmarks ------------------- Logistix posts benchmarks for a pure Python compile module: http://codespeak.net/pipermail/pypy-dev/2003q1/000374.html Oren Tirosh suggests running the same benchmarks with Psyco. Holger Krekel reminds us that the Psyco used in the Minimal project will be a very different beast. Christian Tismer agrees that current performance gains are not indicators of what is possible. Logistix later posts a link to his code, and provides some details: http://codespeak.net/pipermail/pypy-dev/2003q1/000383.html PyMite ------ Dean Hall introduces the PyMite interpreter, "my from-scratch flyweight python interpreter for 8-bit architectures." The source is not available yet, but will be before his presentation at PyCon2003: http://codespeak.net/pipermail/pypy-dev/2003q1/000390.html Web Site -------- Holger sends a note that the project web site is ready for use: http://codespeak.net/pipermail/pypy-dev/2003q1/000399.html The site currently focuses on the upcoming sprint, and has the obligatory wiki and list summaries. The site link is: http://codespeak.net/pypy Multiple, Isolated VMs in a Single Process --------------------------------------- Tobias Oberstein ask about design plans for a threading architecture. He asks out of interest for having multiple interpreters within a process without the need for shared objects. Tobias describes what he sees as design decisions: http://codespeak.net/pipermail/pypy-dev/2003q1/000406.html Holger believes the question should be deferred until the initial PyPython interpreter has a C API, and asks Tobias to create a wish list item: http://codespeak.net/pipermail/pypy-dev/2003q1/000407.html Minimally, -troy

1 0