first release of PyPy

[Carl Friedrich Bolz]

Kay Schluehr wrote:
>>Speed isn't even the biggest problem when running PyPy on itself.
>>PyPy still 'fakes' some objects, e.g. borrows them from the underlying
>>Python.
> 
> 
> Does it mean You create an RPython object that runs on top of CPython,
> but is just an RPython facade wrapped around a CPython object?

yes. It means that there are objects that behave like they should in
PyPy but are implemented by keeping creating a regular CPython instance
of the object and delegating all calls on PyPy-level back to the CPython
level.

> So You have four kinds of Pythons:
> 
> RPy  -  translateable into LL code
> APy  -  non-translateable but interpretable by translated RPy
> RPy* -  non-translateable but consistent interface with RPy. Calls
>         APy*
> APy* -  not translateable and not interpreteable by translated RPy
> 
> "Selfhosting" would imply vanishing RPy* and APy*. But the problem
> seems to be that selfhosting must somehow be broken because the system
> needs to interact with OS-dependend librarys. As long as You run the
> system upon CPython the problem does not occur but once You drop it, a
> kind of "extension objectspace" must be created which is translated
> into code with nice interfacing properties. Or do You think that
> RPython translations will be sufficient and another ext-objectspace is
> just useless epi-cycling?

Not exactly sure what you mean here. It's clear that we have to handle
faked objects differently to get a stand-alone PyPy version. One
possibility would be, that the RPython code calls certain functions
which are implemented in Python (can be regular Python), that are not
translated but replaced by a proper C function. For example we have a
function intmask at the moment which takes a long and removes as many
bits from it as neccessary to make it fit into an int again. This
function is left out when translating, since in C an int can obviously
not overflow to a long.

Regards,

Carl Friedrich