[pypy-svn] r19773 - pypy/dist/pypy/doc/weekly
mwh at codespeak.net
mwh at codespeak.net
Fri Nov 11 16:05:38 CET 2005
Date: Fri Nov 11 16:05:37 2005
New Revision: 19773
add the summary, sigh
--- (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
+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:
+where you can also find old summaries.
+There were about 100 commits to the pypy section of codespeak's
+repository this week.
+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."
+In one of the reports we're currently writing for the end of phase 1
+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...
+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.
+It's not linked from anywhere on the website (yet...) but the report
+that will become "Delieverable 05.1":
+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