Hi Fijal, On Tue, Feb 14, 2012 at 10:50, Maciej Fijalkowski <fij...@gmail.com> wrote: > The thing is noone seriously works on the cython's pypy backend, so > the dirty hacks seem like a very good solution short-to-mid term.
Someone feel free to try them out. However I'm generally negative about the outcome and its portability. Please do keep in mind however that generating C code and having custom macros to compile it either for CPython or for PyPy is *not* going to work --- unless someone very carefully designs some very clever missing piece and we place a number of restrictions about the cases where it works. Stefan: the main problem is that the RPython-to-C translation that we do is not just a one-format traduction. We need to tweak the intermediate code in various ways depending on various settings. The way it is tweaked really depends on these settings in a way that cannot be captured just by C macros. (If it could, we might have written the whole project in C instead of RPython in the first place.) You would end up with a version of the Cython C code that only works on *some* kind of PyPy, like using the minimark GC, without any JIT support, and without sandboxing support. (Just to add an example, I could also say "and without stackless support", but this is no longer true nowadays because we no longer rely on a transformation for stackless.) For this reason, I remain convinced that the best approach for Cython on PyPy is instead to have Cython generate pure Python code that would use some API in the form of a built-in Python module. ctypes may work, but custom alternatives may be better. The built-in module can be implemented just once on PyPy (and optionally on CPython too, mostly for testing). A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
