Mailman 3 September 2003 - pypy-dev

Re: [pypy-dev] Extended goals (was: needed 18 month plan ofwhat we would do in developing PyPy if we got funding.)
by roccomoretti＠netscape.net Sept. 13, 2003

Sept. 13, 2003

Samuele Pedroni <pedronis(a)bluewin.ch> wrote: >someone has a large C++ codebase and - yes - he knows it is a pain to >maintain and to add new functionality, PyPy-Python seems cool but what can >it do for him? > >1) well he can rewrite all his code in Python > > bzzt, wrong answer ( :) ) > Or, he could have PyPy rewrite it for him: If we continue on the track of maximum generality, we should be able to hook a C/C++ parser/code generator into the front end of PyPy. And with a flexible enough backend, instead of PyPy-Psyco emitting machine code or C, it should be able to emit Python code. The trick is to write such a beast such that comments are preserved and the emitted python code is readable. -Rocco __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

2 1

NOBODY expects the Spanish Inquistion!
by Laura Creighton Sept. 13, 2003

Sept. 13, 2003

See: http://www.codespeak.net/pypy/index.cgi?lists (JARRING CHORD) (The door flies open and Cardinal Ximinez of Spain (Palin) enters, flanked by two junior cardinals. Cardinal Biggles (Jones) has goggles pushed over his forehead. Cardinal Fang (Gilliam) is just Cardinal Fang) Ximinez: NOBODY expects the Spanish Inquisition! Our chief weapon is suprise...surprise and fear...fear and surprise.... Our two weapons are fear and surprise...and ruthless efficiency.... Our *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the Pope.... Our *four*...no... *Amongst* our weapons.... Amongst our weaponry...are such elements as fear, surprise.... I'll come in again. (Exit and exeunt)

1 0

Re: [Python-Dev] Making python C-API thread safe (try 2)
by Armin Rigo Sept. 12, 2003

Sept. 12, 2003

Hello Harri, Sorry for the private e-mail about the Python threading issue you raied in pypy-dev; I guess you got quite some of these. I'm sending a copy of this mail to the pypy-dev mailing list -- Christian, this is one more application not to forget to list in the goals :-) I wanted to point you to the PyPy project, whose goal is to create a more flexible Python interpreter, by writing it completely in Python instead of C. The kind of trivial-but-tedious global transformation that you suggest to make multiple independent interpreters in the same process is exactly the kind of change that we aim for, thanks to extra flexibility. We are writing the interpreter in such a way that it can be automatically translated into efficient C code. This translator can be tailored to different usages, for example to add an extra "PyInterpreterState*" argument to each C function it produces. So if you are genuinely considering patching the whole CPython source code, consider that it is not only tedious but is a nightmare to maintain if you want to keep up-to-date with CPython's evolution. There are several people in the PyPy project that have tried to do exactly that for other kind of changes (Psyco/Stackless). It is one of the motivations behind PyPy. And besides the new flexibility, it is much more fun to write a Python interpreter in Python than in C :-) http://codespeak.net/pypy/ Armin

1 0

Tortoise SVN probs
by Christian Tismer Sept. 11, 2003

Sept. 11, 2003

Hi Holger, I can check out the complete pypy repository (which tells me btw. about "external items" whatever that may be), but when I try to do an update with TortoisSVN, I get error messages like "REPORT response handling failed to complete the editor drive" I had that problem yesterday, already. Is this a known problem, do I have to upgrade something? ciao - chris -- 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/

2 3

Re: I cannot connect to codespeak.
by Laura Creighton Sept. 10, 2003

Sept. 10, 2003

In a message of Wed, 10 Sep 2003 17:50:12 +0200, holger krekel writes: >[Laura Creighton Wed, Sep 10, 2003 at 05:47:41PM +0200] >> I get connection refused. > >hello laura, > >you really are hitting the second we are changing something on >codespeak and this (unexpectedly, unfortunately) affected the >apache service. > >i guess this might take up to 30 minutes to fix, would that be ok? > > holger No problem. Just wanted to let you know in case it was unexpectedly down. Laura

2 2

I cannot connect to codespeak.
by Laura Creighton Sept. 10, 2003

Sept. 10, 2003

I get connection refused.

2 1

PyPy "Berlin" sprint (29th Sep - 4th Oct 2003)
by holger krekel Sept. 7, 2003

Sept. 7, 2003

hello python developers, the fourth PyPy coding sprint will take place in Berlin (Germany) from (morning of) 29th of September to (evening of) 4th of October 2003. All Python developers are welcome to join the sprint. See below for participation details. What is PyPy? ------------- PyPy is a remimplementation of Python in the Python language itself. Simplicity and flexibilty are the foremost goals. With PyPy we want it to be easy to extend the language or generate a more minimal language implementation. One key technique to making this feasible is to specialize our abstract/general PyPy-Python implementation into native code (e.g. C-code). Eventually the concepts of PSYCO and Stackless are to be integrated into PyPy. There is, of course, much more to it so feel free to consult some documents especially our Oscon-2003 paper on this page: http://codespeak.net/pypy/index.cgi?doc We know that many areas and issues are still somewhat vague although PyPy can already run many python programs [*]. Fortunately, Python is pretty tolerant about expressing ideas in vague ways. After all, hacking at PyPy aims (and already proved!) to preserve the fun of hacking in Python. History, status and Berlin goals -------------------------------- The project started in Jan/Feb 2003 with an initiative from Christian Tismer, Holger Krekel and Armin Rigo. During the course many more developers joined our sprints and there are now between 5 and 15 people involved in developing PyPy. The three sprints resulted in a fully working interpreter, some development infrastructure and the "standard object space" which is an abstraction for operations on standard (CPython) objects. There is no public release yet, you more or less have to install a subversion-client and checkout the trunk. Here is our 'howtosvn' which contains up-to-date clients for multiple platforms along with some instructions how to get started: http://codespeak.net/pypy/index.cgi?doc/devel/howtosvn.html Main goals for the Berlin sprint are - integration/enhancement of a Python parser and the compiler package - generating native code from our Python interpreter/types implementations - enhancing/correcting/completing what we have (various tasks) How to participate in Berlin (29th of Sept. to 4th of October) -------------------------------------------------------------- If you are interested to participate please subscribe at our sprint organization list http://codespeak.net/mailman/pypy-sprint and please list yourself at http://codespeak.net/moin/pypy/moin.cgi/SprintAttendants so that we can organize accomodation and arrange details. Costs should be pretty low (except from travelling costs, of course). Currently nine people are scheduled to come. Btw, the sprint starts early on the 29th of september so it's best to arrive on sunday, 28th. Also we probably want to have one day off during the sprint week to do some sight (or cafe+pub) seeing. Actually it's much better to participate the whole week to better get into it. cheers, holger [*] and currently only 20-40 thousand times slower than CPython! which clearly shows that we are successfully follow the "premature optimization is the root of all evil" maxime.

1 0

pypy home page says 'no date set for the Berlin Sprint'
by Laura Creighton Sept. 4, 2003

Sept. 4, 2003

please update it when you get a chance. Thanks very much, Laura

1 0

"Unwrap" Concidered Harmful
by roccomoretti＠netscape.net Sept. 3, 2003

Sept. 3, 2003

Maybe I overstate the subject line, but there are serious limitations on the .unwrap() concept. The limitation stems from the "blackbox" concept for object spaces. In general, we cannot be sure that unwrap will give a valid object. It may work for a direct representation of Python objects (such as trivial and standard object spaces), but when we start to use object space representations that do not exactly mirror Python semantics, unwrap isn't guarranteed to work. For example, if an annotation-like object space represents obects as type & bool (for truth tracking, for example), upon calling wrap(), it discards all information about value. So there is no way we can say that s.unwrap(s.wrap(x)) == x. Even if an object space keeps some kind of info on the wrapped object such that it can be unwrapped, there is no guarrantee that something valid will remain after any sort of operations on it, as a different object space may induce a different or multiple path(s) through the code. This is probably tractable within the object space itself, as any sort of vagarities in the wrapping can be compensated for on a space by space basis. However, if we wish to have a general code evaluation framework for multiple object spaces, the code evaluation code has to be general. At the moment there are a number of places in the code evaluation framework which call unwrap(). - I think it is mostly for unwrapping code objects. The reason I bring this up is I think that this is the reason the general builtin-module import code I posted earlier crashes for the annotation object space. The code attemped to unwrap attributes of the sys module, assuming that normal Python sematics are valid. This doesn't hold for annotation object space ... hence the crash. So if we wish to be general in the execution framework, we need to limit the use of unwrap() to uses which are guarranteed to be semantically valid by the obect space interface. (At least for the subset of object spaces we wish to use for a particular code execution framework.) A small but significant correllary to this is that the semantics of the operations within a general object space should not be assumed to be Python-like. That is, operations on object space obects should be performed for object space effects, not for execution level effects. This poses significant problems for the application space helpers to compute execution level relevant results. I'm not sure how to address this yet. -Rocco P.S. I appologize if this has been discused before on IRC. Has any progress been made in creating an archive of IRC logs? I get the impression a fair number of significant points have been made on IRC, and it would be best to archive them such that others not present can benefit from them as well. __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

3 3

Request for viewcvs
by Jacob Hallén Sept. 1, 2003

Sept. 1, 2003

I found this request in the IRC. Seems reasonable to do this. Jacob 20:12:18] <azazel> hi guys! [20:16:34] <azazel> you are doing a real intersting piece of work, but please install viewcvs from its cvs repository, it supports Subversion repositories as well, take a look here [20:16:46] <azazel> http://nautilus.homeip.net/cgi-bin/viewcvs.cgi/ [20:17:23] <azazel> if you want to take a look at viewcvs subversion support! [

2 1