Am 02.10.12 17:06, schrieb Lisandro Dalcin:
> After successfully porting mpi4py to PyPy 1.9
Very cool, and thanks for reporting on it.
>, I want to share a few
> issues I've encountered. The most serious ones are on PyPy's side
Definitely.
>, but Cython do require a cuple of very minor fixes.
>
> 1) Cython uses _PyLong_AsByteArray() to convert integers of unknown
> sizeof larger than long long. I had to cinclude the following code to
> get the C sources compile:
>
> static int
> _PyLong_AsByteArray(PyLongObject* v, unsigned char* bytes, size_t n,
> int little_endian, int is_signed)
> {
> PyErr_SetString(PyExc_RuntimeError,
> "PyPy: _PyLong_AsByteArray() not available");
> return -1;
> }
Looks like we should just special case the conversion for PyPy here so
that it stops using that function.
> 2) PyPy's implementation of PyBuffer_FillInfo() has a bug, it ignores
> the "readonly" parameter instead of generating an error if readonly=1
> and PyBUF_WRITABLE is on. I had to to cinclude the following code to
> monkeypatch it:
>
> static int
> PyBuffer_FillInfo_PyPy(Py_buffer *view, PyObject *obj, void *buf,
> Py_ssize_t len, int readonly, int flags)
> {
> if (view == NULL) return 0;
> if (((flags & PyBUF_WRITABLE) == PyBUF_WRITABLE) &&
> (readonly == 1)) {
> PyErr_SetString(PyExc_BufferError,
> "Object is not writable.");
> return -1;
> }
> if (PyBuffer_FillInfo(view, obj, buf, len, readonly, flags) < 0)
> return -1;
> view->readonly = readonly;
> return 0;
> }
> #define PyBuffer_FillInfo PyBuffer_FillInfo_PyPy
I would prefer it if they fixed that one on their side. I assume you
filed a bug report on their tracker?
> 3) In PyPy, PyCode_GetNumFree() accepts a PyObject*, not
> PyCodeObject*. I've monkeypatched as follow:
>
> #define PyCode_GetNumFree(o) PyCode_GetNumFree((PyObject *)(o))
Cython could do that as well, although I think PyPy should fix it
themselves. AFAIK, the current PyPy C-API isn't versioned (at least not
independently of the PyPy version), so applying such a work-around on
our side would mean that it's going to fail again at some point when
they fix it.
Still, if it makes things work for the time being, so be it...
> 4) mpi4py uses @classmethod decorator for many methods in cdef
> classes. I really do not know what's going on, but method lookups do
> not return the classmethod, but the original "unwrapped" method. I've
> found a way to trick it, but again, I have no idea why it is working.
> Basically, I have to execute hasattr() (in Python code, not Cython
> code) on every class method: The hack reduces to adding the following
> code at the very end of Cython code (note that I'm using "exec"):
>
> if PYPY: exec """
> def _pypy_setup():
> for klass in (
> Status,
> Datatype,
> Request,
> Message,
> Op,
> Group,
> Info,
> Errhandler,
> Comm,
> Win,
> File,
> ):
> for name in klass.__dict__:
> meth = klass.__dict__[name]
> if (isinstance(meth, classmethod) or
> isinstance(meth, staticmethod)):
> hasattr(klass, name)
> _pypy_setup()
> del _pypy_setup
> """
>
>
> I think (1) and (3) can be trivially handled in Cython, (3) is not an
> issue for Cython as PyBuffer_FillInfo() is not directly used. And
> about (4), we really need help from PyPy folks, they implement
> PyType_Modified() as a non-op
> (https://bitbucket.org/pypy/pypy/src/release-1.9/pypy/module/cpyext/typeobject.py#cl-726)
> but that is not playing well with Cython.
PyType_Ready() is also incomplete.
> Below, the relevant pieces of code in mpi4py containing all the code
> I've described previously.
>
> https://code.google.com/p/mpi4py/source/browse/src/atimport.h#324
> https://code.google.com/p/mpi4py/source/browse/src/MPI/MPI.pyx#280
It would be nice if you could write up pull requests for the necessary
work-arounds above.
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
