[pypy-dev] Build and test failures

[Samuele Pedroni]

Armin Rigo wrote:
> 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).
> 
> 

at least the PyPy codebase doesn't show such kind of conversion issues 
anymore. Now we are with some functionality missing the rtyper and nasty 
issues related to faking code and appearing PyObjects.

I should updated the ISSUES file, with the list of error that 
translate_pypy with -t-insist produces.