[pypy-dev] Build and test failures

Armin Rigo arigo at tunes.org
Thu Jul 21 19:51:28 CEST 2005


Hi Ben,

On Wed, Jul 13, 2005 at 10:03:28AM +0100, Ben.Young at risk.sungard.com wrote:
> Unfortunately thats exposes a new problem, as there is a function called 
> RaiseException included by windows.h! Maybe all your macros should be 
> prefixed by PyPy_
> or something.

Argh.  I see.  Yes, using a common prefix more systematically looks like
a good idea.

> It sounds like you are getting close to the translate_pypy target. Would 
> it be possible for you to give a summary of the problems you appear to be 
> having with the PBC code (as evidenced by some of the commit messages)? 
> I'm just interested in what the problem appears to be, and whether it's 
> just something you're going to have to live with, or if there is an 
> architectural solution? 

The PBCs are messy in general, I don't think we will find a nice a clean
solution.  At least currently, the annotator says that everything is a
"PBC" if it is any kind of user-defined prebuilt object, but this is
only part of the problem.  The real messiness comes from the fact that
the PBCs are somehow the RPython objects that have the least obvious C
equivalents: the Python classes, some prebuilt instances, and functions
(with some of their full Python parameter passing semantics).  Moreover
they come out of the annotator in families (a SomePBC is a set of PBCs),
so we have to handle such families in various ways depending on how the
objects in the family are actually used.

The flow graph viewer doesn't show all this, because it doesn't really
display complex low-level types and constants nicely.  Not sure if and
how to improve that...

> I don't really understand the PBC side of things. Is there a reason why 
> the object hierarchy can't just mirror the way CPython does it? Or would 
> that be too slow?

Yes, we are indeed trying for each kind of PBC family to figure out the
best C-ish equivalent.  A family of functions should become just a C
function pointer; a family of classes should become a vtable pointer;
etc.  We always planned to do that, and our RPython code is written
accordingly, but the devil's in the details...

It looks like we are mostly done, though.  According to
http://codespeak.net/svn/pypy/dist/pypy/translator/goal/ISSUES.txt
the last remaining problem is about conversions from small to larger PBC
families, which should be easy (typically, no conversion is needed e.g.
to cast a pointer-to-function to a
pointer-to-function-that-can-point-to-more-functions-than-the-previous-one).


A bientot,

Armin



More information about the Pypy-dev mailing list