[pypy-svn] rev 2091 - pypy/trunk/doc/sprintinfo
hpk at codespeak.net
hpk at codespeak.net
Sun Oct 26 22:26:28 CET 2003
Author: hpk
Date: Sun Oct 26 22:26:27 2003
New Revision: 2091
Added:
pypy/trunk/doc/sprintinfo/AmsterdamAnnouncement.txt
pypy/trunk/doc/sprintinfo/BerlinReport.txt
Log:
checked in the Amsterdam announcement and a BerlinReport for
the records. As always, if anyone wants to add/modify go ahead.
Added: pypy/trunk/doc/sprintinfo/AmsterdamAnnouncement.txt
==============================================================================
--- (empty file)
+++ pypy/trunk/doc/sprintinfo/AmsterdamAnnouncement.txt Sun Oct 26 22:26:27 2003
@@ -0,0 +1,124 @@
+PyPy Sprint announcement & news from the project
+================================================
+
+We are coming close to a first experimental release of PyPy,
+a more flexible Python implementation written in Python.
+The sprint to make this happen will take place in Amsterdam,
+a city known to be reachable by cheap flights :-)
+
+This is 1) the announcement for the sprint;
+ 2) news about the current state of PyPy;
+ 3) some words about a proposal we recently submitted
+ to the European Union.
+
+
+Amsterdam Sprint Details
+------------------------
+
+The Sprint will take place from
+
+ the 14th of December to the 21st of December at the
+
+ "Vrije Universiteit in Amsterdam", 14th-21th Dec 2003.
+
+thanks to Etienne Posthumus, who helps us to organize the event. The
+main goal will be a complete C translation of PyPy, probably still using
+a hacked Pyrex-variant as an intermediate layer and using CPython's
+runtime. We also plan to work on some fun frontends to PyPy like one
+based on pygame or a web browser to visualize interactions between
+interpreter and objectspace.
+
+If you want to participate on the sprint, please subscribe here
+
+ http://codespeak.net/mailman/listinfo/pypy-sprint
+
+and list yourself on this wiki page
+
+ http://codespeak.net/moin/pypy/moin.cgi/AmsterdamSprint
+
+where you will also find more information as the sprint date
+approaches. If you are just interested but don't know if you
+come then only subscribe to the mailing list.
+
+
+State of the PyPy project
+--------------------------
+
+PyPy works pretty well but still on top of CPython. The double
+interpretation penalty makes it - as expected - incredibly slow :-) In
+the Berlin sprint we have thus started to work on the "translation"
+part, i.e. how this code should be translated into C. We can now
+translate simple functions to C-like code including some type
+annotations. For convenience, we are reusing a modified subset of Pyrex
+to generate the low-level C code. Thanks to Seo (who joined the project
+from South-Korea) we also have a lisp-backend to fuel the endless c.l.py
+threads about python versus lisp :-)
+
+The goal of the next sprint is to complete this work so that we can
+translate the complete PyPy source into a huge Pyrex module, and then a
+big CPython extension module. True, the result is not independent from
+CPython, as it runs reusing its runtime environment. But it's probably
+an interesting enough state to make a public release from.
+
+The translation is done by generating a control flow of functions by
+means of abstract interpretation. IOW, we run the PyPy interpreter with
+a custom object space ("flowobjspace") which generates a control flow
+graph (including the elementary operations) which is then used to
+generate low-level code for backends. We also have preliminary type
+inference on the graphs, which can be used by the Pyrex generator to
+emit some C type declarations.
+
+Writing transformations and analysis of these graphs and displaying them
+with GraphViz's 'dot' is great fun! We certainly have a greater need
+than ever for graphical interactive tools to see, understand and debug
+all these graph manipulations and run tests of them. Currently it is a
+bit difficult to write a test that checks that a transformed graph
+"looks right"!
+
+What we expect from the Amsterdam sprint is thus:
+
+- a big not-too-slow "cpypy.so" extension module for CPython, where at
+ least integer arithmetic is done efficiently
+
+- interactive tools to display and debug and test PyPy, visualizing
+ control flow, call-graphs and state models.
+
+- improving and rewriting our testing tools to give us more control over
+ the testing process, and to allow more interactive testing sessions.
+
+
+Other interesting News
+----------------------
+
+Before mid October, we also had a quite different Sprint. It was an
+approximately 10-day effort towards submitting a proposal to the EU. If
+it is accepted we will have resources to fund some developers working
+full- or parttime on the project. However, our "sprint driven
+development" will continue to play the central role for development of
+PyPy.
+
+There are especially two technical sections of the proposal which you
+might find interesting to read:
+
+ "Scientific and technological objectives":
+ http://codespeak.net/pypy/index.cgi?doc/funding/B1.0
+
+ "Detailed implementation plan"
+ http://codespeak.net/pypy/index.cgi?doc/funding/B6.0
+
+Maybe you want to read the whole proposal for other reasons, too, like
+making a EU project of your own or competing with us. Actually,
+with our sprints there is usually a lot of room for cooperation :-)
+Anyway, here is the PDF-url:
+
+ http://codespeak.net/svn/pypy/trunk/doc/funding/proposal/part_b.pdf
+
+Everybody who thinks that he/she could help on the project is
+invited to join! Btw, the latest discussions about our sprint
+goals usually take place on the pypy-dev list:
+
+ http://codespeak.net/mailman/listinfo/pypy-dev
+
+have fun,
+
+ Armin & Holger
Added: pypy/trunk/doc/sprintinfo/BerlinReport.txt
==============================================================================
--- (empty file)
+++ pypy/trunk/doc/sprintinfo/BerlinReport.txt Sun Oct 26 22:26:27 2003
@@ -0,0 +1,146 @@
+a sprint report (actually a mail from Holger Krekel on pypy-dev)
+
+Hi Florian,
+
+[Florian Schulze Sat, Oct 04, 2003 at 10:34:25PM +0200]
+> Hi!
+>
+> How well did the sprint work out?
+>
+> I have seen that there is some pyrex code generation now and there are
+> tests, but what where the results in this area during the sprint?
+>
+> Just a very short mail with some information would be grately
+> appreciated.
+
+Here is my take. Other mileages may vary so excuse me if i miss anything.
+
+On Monday morning we made a few design decision which led to the
+implementation of the following abstractions in the next two days:
+
+- a new FlowObjSpace which does abstract interpretation
+ plus some very nice tricks (which we came up with during a
+ long-winded discussion in a restaurant :-) to construct
+ a FunctionGraph. This functiongraph (fully) represents the abstract
+ or symbolic execution of a function. e.g. for this function::
+
+ def while_func(i):
+ total = 0
+ while i > 0:
+ total = total + i
+ i = i - 1
+ return total
+
+ the following graph is generated (shown here in an slightly
+ optimized version):
+
+ http://codespeak.net/~hpk/while_func.ps
+
+
+- the pyrex-translator also takes this objectmodel (in flowmodel.py) and
+ generates Pyrex-Code from it. The generated code looks pretty low-level
+ but this is expected as we eventually want to generate C or assembly
+ directly. For the above function the following pyrex-source code is
+ generated (again with some easy optimizations applied)::
+
+ def while_func(object v413):
+ v419, v420 = v413, 0
+ cinline "Label1:"
+ v422 = v419 > 0
+ if v422:
+ v424 = v420 + v419
+ v425 = v419 - 1
+ v419, v420 = v425, v424
+ cinline "goto Label1;"
+ else:
+ return v420
+
+ btw, the 'cinline' statement is a hack to pyrex and allows to insert
+ arbitrary C-code. An objectspace cannot really identify loops
+ and so we need "goto". We consider goto to be useful unless you have
+ to type and understand them manually :-)
+
+- translator/annotation.py also takes the flowmodel and applies a
+ new technique for type inference: it uses space-operations to
+ note 'assertions' about variables and relaxes those assertions
+ during analysis of the flowgraph. IOW we didn't come up with
+ yet another type-system (which is the classical approach) but
+ reuse the notion of "space-operations" which we had from the beginning
+ of the project. Btw, Armin thinks that this type-inference algorithm
+ is worth a scientific paper but more about this either later and/or
+ from him.
+- we adapted Jonathan David Riehl's Python-Parser (written completly
+ in python using its own "rex"-approach) and adapted it so that
+ it will be a drop-in replacement for CPython's current parser
+ (living the boring life of a C-extension). Actually Jonathan's
+ larger 'basil' project is now in the codespeak-repository and
+ we can easily link it into PyPy or branch off it if neccessary.
+
+So alltogether the Flowgraph/Functiongraph/flowmodel (there is no
+completly fixed terminology yet) is the central point for several
+independent algorithms that - if combined - eventually produce typed C-code.
+
+To sum it up there are the following abstractions:
+
+interpreter interpreting bytecode, dispatching operations on objects to
+
+objectspace implementing operations on boxed objects
+
+stdobjspace a concrete space implementing python's standard type system
+
+flowobjspace a conrete space performing abstract/symbolic interpretation and
+ producing a (bytecode-indepedent) flowmodel of execution
+
+annotator analysing the flowmodel to infer types.
+
+genpyrex taking the (annotated) flowmodel to generate pyrex-code
+
+pyrex translating into an C-extension
+
+As a consequence the former Ann(otation)Space has been ripped apart
+(partly into flowobjspace) and is gone now. Long live the flowspace.
+
+A really nice property of the above abstractions is that they allow
+development and testing *independently* from one another which was
+of invaluable help. Thanks here go to Greg Ewing for Pyrex and sorry
+for the evil cinline-hack :-)
+
+Anybody interested in helping with the next steps might look into
+the TODO file in the pypy-root directory. We also have discussed
+yesterday evening a refactored flowmodel which we want to employ
+soon.
+
+Big thanks go to Tomek Meka and Christian Tismer for organizing the
+sprint and Stephan Diehl and Dinu Gherman for their help in various
+organizational areas. And especially to Jonathan David Riehl who
+made it from Chicago. We hope he can stay with us more often. And
+here is a (hopefully complete) list of people who attended and made
+all of the above possible:
+
+ Armin Rigo
+ Christian Tismer
+ Dinu Gherman
+ Guenter Jantzen
+ Jonathan David Riehl
+ Samuele Pedroni
+ Stephan Diehl
+ Tomek Meka
+ and shame on me if i forgot anyone (i am tired ...)
+
+And of course many many thanks to Laura Creighton (AB Strakt),
+Nicolas Chauvat (Logilab) and Alistair Burt (DFKI) who tried hard to
+work with us on EU-funding-issues. Actually we came up with a nice technical
+2-year plan but a lot of business issues still need to be resolved
+and fixed. Let's hope that the EU-funding effort is as successful as
+our coding sprints this year has been. Ah yes, the next sprint we hope
+to do mid-december probably in Amsterdam. If all goes well (some more
+people helping between the sprints that is :-) we might even do a first
+public release with PyPy prototypically running as a C-extension to CPython.
+
+That's it for now from me. (sprinters: Please correct/fix any issues i
+misrepresented)
+
+cheers,
+
+ holger
+
More information about the Pypy-commit
mailing list