Hi Roger, A first warning: even if you manage to compile your C extension with PyPy, the interfacing is much slower than with CPython. Keep that in mind, given that according to what you write you care enough about performance to try to squeeze a few percents.
On Sun, May 1, 2011 at 12:08 PM, Roger Binns <rog...@rogerbinns.com> wrote: > It looks like PYPY_VERSION being #defined will work > but I'd rather use the "official" way whatever that is. That's the "official" way. > I need the api PyRun_StringFlags as it is used to execute a Python string > and attach the results to the module. If it's not already provided, then you are welcome to contribute it to PyPy in pypy/module/cpyext/. It is known that we don't have 100% coverage even of Python.h (not to mention other headers like compile.h, which will probably never be supported). > Do I have to add an incref for everything that has a static pointer to it? It depends on details of exactly what you do, but it is likely. The exact rule is, like CPython, that any object is freed as soon as its reference counter goes down to zero; but unlike CPython, this does *not* include places like a reference stored in the module's dictionary. In other words, if it seems to work on CPython but not on PyPy, then it is likely that there is actually a (potentially very rare) bug in the CPython version too. For example, the object you have in the static variable could be meant to be kept alive by being also stored in the module's dictionary. If so, what if a user actually delete it from your module's dictionary? Then you get a crash on CPython too. > My next problem is a list allocated with PyList_New(0). I later call > PyList_GET_SIZE on it > and get a SIGSEGV. I put an assertion before that of PyList_Check but that > crashes too. > Unfortunately I can't really do much with the pypy/gdb output: You get easier-to-read tracebacks if you run it without the JIT: "pypy --jit threshold=-1". Of course in order to get the details of, say, the local variables, then you need a custom pypy built with debugging symbols. A bientôt, Armin. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev