Armin Rigo wrote: > Hi all, Hi, 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). ciao Anto _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
