[pypy-svn] r19773 - pypy/dist/pypy/doc/weekly

mwh at codespeak.net mwh at codespeak.net
Fri Nov 11 16:05:38 CET 2005


Author: mwh
Date: Fri Nov 11 16:05:37 2005
New Revision: 19773

Added:
   pypy/dist/pypy/doc/weekly/summary-2005-11-11.txt
Log:
add the summary, sigh


Added: pypy/dist/pypy/doc/weekly/summary-2005-11-11.txt
==============================================================================
--- (empty file)
+++ pypy/dist/pypy/doc/weekly/summary-2005-11-11.txt	Fri Nov 11 16:05:37 2005
@@ -0,0 +1,104 @@
+=======================
+  This Week in PyPy 2
+=======================
+
+Introduction
+============
+
+This is the second of what will hopefully be many summaries of what's
+been going on in the world of PyPy in the last week.  I'd still like
+to remind people that when something worth summarizing happens to
+recommend if for "This Week in PyPy" as mentioned on:
+
+    http://codespeak.net/pypy/dist/pypy/doc/weekly/
+
+where you can also find old summaries.
+
+There were about 100 commits to the pypy section of codespeak's
+repository this week.
+
+
+pypy-c py.py
+============
+
+Over the weekend (while I was being blown around Wales by the remnants
+of hurricane Wilma) Armin and a few others worked on trying to get a
+translated pypy-c to run the interpreted py.py.  This resulted in a
+fixing a welter of small differences between CPython and pypy-c,
+though at the end of it all "we are still left in the dark of
+incomprehensible geninterplevel crashes caused by subtle differences
+between the most internal types of CPython and pypy-c."
+
+
+Multiple Spaces
+===============
+
+In one of the reports we're currently writing for the end of phase 1
+EU review:
+
+    http://codespeak.net/pypy/dist/pypy/doc/draft-low-level-encapsulation.html
+
+we made this claim:
+
+    The situation of multiple interpreters is thus handled
+    automatically: if there is only one space instance, it is regarded
+    as a pre-constructed constant and the space object pointer (though
+    not its non-constant contents) disappears from the produced
+    source, i.e. both from function arguments and local variables and
+    from instance fields. If there are two or more such instances, a
+    'space' attribute will be automatically added to all application
+    objects (or more precisely, it will not be removed by the
+    translation process), the best of both worlds.
+
+And then we tried to do it, and had to tune the claim down because it
+doesn't work.  This is because the StdObjSpace class has a
+'specialized method' -- a different version of the wrap() method is
+generated for each type it is seen to be called with.  This causes
+problems when there are genuine StdObjSpace instances in the
+translated pypy because of limitations in our tools.  We looked at
+these limitations and decided that it was time to rewrite the world
+again, leading in to the next section...
+
+
+SomePBC-refactoring
+===================
+
+One of the more unusual annotations produced by PyPy's annotator is
+that of 'SomePBC', short for 'SomePrebuiltConstant'.  This annotation
+means that a variable contains a reference to some object that existed
+before the annotation process began (key example: functions).  Up
+until now, the annotation has actually explicitly included which
+prebuiltconstants a variable might refer to, which seems like the
+obvious thing to do.  Unfortunately, not all things that we'd like to
+annotate as a prebuiltconstant actually exist as unique CPython
+objects -- in particular the point of specializing a function is that
+it becomes many functions in the translated result.  Also for
+'external', i.e. not written in RPython, functions we want to be able
+to supply annotations for the input and exit args even if there is no
+corresponding CPython function at all.
+
+The chosen solution is to have the SomePBC annotation refer not to a
+CPython object but to a more abstracted 'Description' of this object.
+In some sense, this isn't a very large change but it affects most
+files in the annotation directory and a fair fraction of those under
+rpython/ and translator/.  We're also cleaning up some other mess
+while we're there and breaking everything anyway.
+
+
+Draft-Dynamic-...
+=================
+
+It's not linked from anywhere on the website (yet...) but the report
+that will become "Delieverable 05.1":
+
+   http://codespeak.net/pypy/dist/pypy/doc/draft-dynamic-language-translation.html
+
+has been reviewed and re-reviewed in the last couple of weeks and is
+definitely required reading for anyone who has an interest in the more
+theoretical side of PyPy.
+
+
+Gtbg Sprint in December
+=======================
+
+Hopefully very soon, we'll announce the next PyPy sprint... stay tuned!



More information about the Pypy-commit mailing list