[pypy-dev] Work plan for PyPy
anto.cuni at gmail.com
Fri Jun 15 01:01:17 CEST 2007
Armin Rigo wrote:
> Hi all,
sorry, I completely forgot the meeting :-(.
I was even at home and online at that time, but I missed it. At least
I've read the logs :-).
Here are some notes from my side.
My personal short-term plan is to work a bit to make gencli more or less
usable as a general .NET compiler, in particular for generating DLLs to
be imported by others .NET programs.
I personally would like not to work on rpython too much, but I have to
convince my professor first :-).
After having convinced him, I would like to work on the JIT, in
particular to port it to ootype (and then add gencli support).
> * The CPy Object Space is going away initially too because it is based
> on rctypes. It should not be too hard to port it to rtti in order to
> continue supporting compiling extension modules for CPython. We need
> to think a bit more here - how can we compile ext modules for Jython
> and IronPython? - but it's likely not a high priority at the moment.
Armin, I read that you asked how hard would be to generate extension
modules for Jython; the same question apply to IronPython.
I think that the easiest way in the short term is to generate plain
Java/.NET modules that can be imported by any Java/C# program, and rely
on Jython/IronPython's mechanism to import it (thus, not relying on the
CPy objectspace at all).
I've already started in this direction, regarding gencli: the name of
the front-end is SilveRPython, though I think I will rename it to avoid
confusion with microsoft silverlight. Currently it mostly works, but I
have to convince the rtyper not to mangle the name of the classes and
the methods, because they need to be publicly available from the outside.
> Additionally, some of the independent tasks mentioned:
> * port the stackless transform to ootypesystem
I also would have spotted this point if I were at the meeting :-).
I think it could be a nice topic for sprint, couldn't it?
Finally, a note which is not related with the work plan but to a
question that appeared in the logs; someone asked whether we want to
"sell" RPython as a stand-alone product.
Last sunday I gave a PyPy talk at Pycon italy and, surprisingly enough,
RPython was perceived as the only (or the most relevant) usable product
of the pypy project. I tried hardly to explain that rpython is basically
only an accident and not very usable, but people are still impressed by
the 300000% speedup.
It would be interesting to know if this perception is world-wide or only
limited to the attendants of my talk (maybe because I didn't stress
enough the pros of the other pypy goals or the cons of rpython).
More information about the Pypy-dev