M
Michael Hudson
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 "Deliverable 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!
Cheers,
mwh
--
your head, away from the organ most normal guys think with.
-- Mark Hammond & Tim Peters, comp.lang.python
============
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 "Deliverable 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!
Cheers,
mwh
--
That's because you're Australian! So all the blood flows to
your head, away from the organ most normal guys think with.
-- Mark Hammond & Tim Peters, comp.lang.python