Mailman 3 May 2005 - pypy-dev

dependencies created by the geninterp change
by Christian Tismer May 26, 2005

May 26, 2005

Hi Armin, I just read your conversation about unicode """ [22:32] aleale: in geninterplevel.py line 419-429 is the template for importing and only pypy/lib is added to the path [22:33] arigo: aleale: yes, but this is only if the import statement is at the global level in the app helper [22:33] arigo: in this case, it is "hidden" inside the unicode_encode__xxx function """ This is not true, I fear. The reason why the release crashed was that instead of enabling immediate import, again, you … [View More]

1 0

IRC metting on translator
by Armin Rigo May 25, 2005

May 25, 2005

Hi all, We have an IRC "appointement" to talk about the translator and get us all on the same page. I do apologize for a lack of communication about what Samuele and myself have been working on lately; this is an attempt at fixing that. Everybody is welcome, of course. Wednesday 15:00, Central Europe Time A bientot, Armin.

1 2

who did that?
by hpk＠trillke.net May 24, 2005

May 24, 2005

Hi folks, i am pretty suprised and actually quite shocked to have found the following unveiling picture from our pre-release work: http://spicy.negimaki.com/index.php?showimage=13 Can somebody please explain? cheers, holger

2 1

Re: [pypy-svn] r12768 - pypy/branch/pycompiler/module/recparser/compiler
by hpk＠trillke.net May 24, 2005

May 24, 2005

Hi Ludovic, On Tue, May 24, 2005 at 14:21 +0200, ludal(a)codespeak.net wrote: > Author: ludal > Date: Tue May 24 14:21:39 2005 > New Revision: 12768 > > Added: > pypy/branch/pycompiler/module/recparser/compiler/ > pypy/branch/pycompiler/module/recparser/compiler/__init__.py > pypy/branch/pycompiler/module/recparser/compiler/ast.py > pypy/branch/pycompiler/module/recparser/compiler/ast.txt > pypy/branch/pycompiler/module/recparser/compiler/… [View More]astfactory.py > pypy/branch/pycompiler/module/recparser/compiler/astgen.py > pypy/branch/pycompiler/module/recparser/compiler/consts.py > pypy/branch/pycompiler/module/recparser/compiler/future.py > pypy/branch/pycompiler/module/recparser/compiler/misc.py > pypy/branch/pycompiler/module/recparser/compiler/pyassem.py > pypy/branch/pycompiler/module/recparser/compiler/pycodegen.py > pypy/branch/pycompiler/module/recparser/compiler/symbols.py > pypy/branch/pycompiler/module/recparser/compiler/syntax.py > pypy/branch/pycompiler/module/recparser/compiler/transformer.py > pypy/branch/pycompiler/module/recparser/compiler/visitor.py > Log: > * included modified version of the original compiler module if you plan on reusing the python compiler module, can you do it slightly differently? For modules/packages, that we are taking and modifying from CPython, we usually copy them from svn/pypy/dist/lib-python/2.3.4 to svn/pypy/dist/lib-python/modified-2.3.4 This allows to keep exact track of what got modified and also the base version we started working from. Note though that these modules are then imported at application-level only and if you want to explore if the compiler package can be modified to be translateable (good idea :-) and thus be written at RPython-level then the above place is not quite right. However, i'd still recommend to then do something like e.g.: svn cp http://codespeak.net/svn/pypy/dist/lib-python/2.3.4 \ http://codespeak.net/svn/branch/pycompiler/module/recparser/compiler so that when you perform 'svn log ...' you will see where that version came from. make sense to you? I also notice that you branched in a slightly unusual way, because so far we did the branching like this: svn cp http://codespeak.net/svn/pypy/dist http://codespeak.net/svn/pypy/branch/whatever this makes sure that you can checkout 'whatever' and have a full pypy-dist hierarchy underneath. With your approach you probably need to use an explicit checkout-target, e.g. 'svn co X pypy' (where the latter 'pypy' is the checkout target). cheers, holger [View Less]

2 1

Python-LLVM bindings updated
by js.nospam＠wolke7.net May 23, 2005

May 23, 2005

Hi, I've updated the Python LLVM bindings for LLVM 1.5 (attached). I also thought of setting up a CVS repository for this, but before I do that I thought I'd ask if you want to take the Python bindings to the main LLVM CVS? I noticed that the C language bindings would be maintained there. Changes in Python-LLVM: - Updated to match LLVM 1.5 API - Added Windows build support (created MSVC++ project file) - Added bindings for LLVM Transforms API Systems built on: - Linux 2.6.10 i686 (GCC 3.3.… [View More]

3 2

unicode merge / exception catching
by hpk＠trillke.net May 23, 2005

May 23, 2005

Hi Arre, your merge looks pretty good so far. One issue relating to exceptions though. > Author: ac > Date: Mon May 23 13:05:59 2005 > New Revision: 12735 > ... > ... > --- pypy/dist/pypy/objspace/std/inttype.py (original) > +++ pypy/dist/pypy/objspace/std/inttype.py Mon May 23 13:05:59 2005 > @@ -28,6 +28,15 @@ > space.wrap(e.msg)) > except ParseStringOverflowError, e: > w_longval = … [View More]

1 0

Re: first release of PyPy
by Christian Tismer May 23, 2005

May 23, 2005

Ville Vainio wrote: >>>>>>"Christian" == Christian Tismer <tismer(a)stackless.com> writes: > > > >> PyPy is written in python, if it can be compiled then the programs > >> can > >> be as well. > > Christian> Well, this is not really true. PyPy is written in > Christian> RPython, a sub-language of Python that is implicitly > Christian> defined by "simple and static enough to be compilable". … [View More]

1 0

New unicode implementation
by Anders Chrigström May 23, 2005

May 23, 2005

I am about to merge my 'non-faked-unicode' branch. Given the amount of changes I won't be suprised it it upsets the annotaton and/or code generators. /Arre

1 0

Re: [pypy-svn] r12711 - pypy/dist/pypy/translator
by Christian Tismer May 23, 2005

May 23, 2005

Hi Armin, I dodn't understand completely why this patch is needed: > Modified: pypy/dist/pypy/translator/geninterplevel.py > ============================================================================== > --- pypy/dist/pypy/translator/geninterplevel.py (original) > +++ pypy/dist/pypy/translator/geninterplevel.py Sat May 21 14:19:31 2005 > @@ -77,7 +77,7 @@ > import pypy # __path__ > import py.path > > -GI_VERSION = '1.1.0' # bump this for substantial changes &… [View More]

1 0

PyPy released!
by Armin Rigo May 21, 2005

May 21, 2005

The PyPy 0.6 release -------------------- *The PyPy Development Team is happy to announce the first public release of PyPy after two years of spare-time and half a year of EU funded development. The 0.6 release is eminently a preview release.* What it is and where to start ----------------------------- Getting started: http://codespeak.net/pypy/index.cgi?doc/getting_started.html PyPy Documentation: http://codespeak.net/pypy/index.cgi?doc PyPy Homepage: http://codespeak.net/… [View More]pypy/ PyPy is a MIT-licensed reimplementation of Python written in Python itself. The long term goals are an implementation that is flexible and easy to experiment with and retarget to different platforms (also non-C ones) and such that high performance can be achieved through high-level implementations of dynamic optimisation techniques. The interpreter and object model implementations shipped with 0.6 can be run on top of CPython and implement the core language features of Python as of CPython 2.3. PyPy passes around 90% of the Python language regression tests that do not depend deeply on C-extensions. Some of that functionality is still made available by PyPy piggy-backing on the host CPython interpreter. Double interpretation and abstractions in the code-base make it so that PyPy running on CPython is quite slow (around 2000x slower than CPython ), this is expected. This release is intended for people that want to look and get a feel into what we are doing, playing with interpreter and perusing the codebase. Possibly to join in the fun and efforts. Interesting bits and highlights --------------------------------- The release is also a snap-shot of our ongoing efforts towards low-level translation and experimenting with unique features. * By default, PyPy is a Python version that works completely with new-style-classes semantics. However, support for old-style classes is still available. Implementations, mostly as user-level code, of their metaclass and instance object are included and can be re-made the default with the ``--oldstyle`` option. * In PyPy, bytecode interpretation and object manipulations are well separated between a bytecode interpreter and an *object space* which implements operations on objects. PyPy comes with experimental object spaces augmenting the standard one through delegation: * an experimental object space that does extensive tracing of bytecode and object operations; * the 'thunk' object space that implements lazy values and a 'become' operation that can exchange object identities. These spaces already give a glimpse in the flexibility potential of PyPy. See demo/fibonacci.py and demo/sharedref.py for examples about the 'thunk' object space. * The 0.6 release also contains a snapshot of our translation-efforts to lower level languages. For that we have developed an annotator which is capable of infering type information across our code base. The annotator right now is already capable of successfully type annotating basically *all* of PyPy code-base, and is included with 0.6. * From type annotated code, low-level code needs to be generated. Backends for various targets (C, LLVM,...) are included; they are all somehow incomplete and have been and are quite in flux. What is shipped with 0.6 is able to deal with more or less small/medium examples. Ongoing work and near term goals --------------------------------- Generating low-level code is the main area we are hammering on in the next months; our plan is to produce a PyPy version in August/September that does not need to be interpreted by CPython anymore and will thus run considerably faster than the 0.6 preview release. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback support from numerous people. Please feel free to give feedback and raise questions. contact points: http://codespeak.net/pypy/index.cgi?contact contributor list: http://codespeak.net/pypy/index.cgi?doc/contributor.html have fun, Armin Rigo, Samuele Pedroni, Holger Krekel, Christian Tismer, Carl Friedrich Bolz PyPy development and activities happen as an open source project and with the support of a consortium funded by a two year EU IST research grant. Here is a list of partners of the EU project: Heinrich-Heine University (Germany), AB Strakt (Sweden) merlinux GmbH (Germany), tismerysoft GmbH(Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden) [View Less]

2 2