Hi Tasos, On Wed, Feb 2, 2011 at 1:15 AM, Tasos Vogiatzoglou <[email protected]> wrote: > You are right. My mistake. It was picking the 2.6 32bit python. Now is > working and tests are passing
A few extra notes. What is needed to make this work is three-fold: * make sure that in the C code, "intptr_t" is generated instead of "long" for lltype.Signed, and similarly "uintptr_t" instead of "unsigned long" for lltype.Unsigned. This involves mainly fixing translator/c/primitive.py to declare types using "intptr_t" instead of "long", and probably fixing a number of other uses of "long" in the .py files in that directory. * make sure that in the hand-written headers translator/c/src/*.h, we use "intptr_t" instead of "long" whenever it's needed (mostly everywhere, I suppose, but not absolutely everywhere, e.g. not in calls to external C functions that are declared to take or return a long). The changes above should fix the generation of code. Now the third part is the longest, probably. You need to distinguish the two types used in RPython, which are lltype.Signed and rffi.LONG, and which are equal so far. Of course rffi.LONG should remain equivalent to the C long. This probably needs looking around in all modules and in pypy/rlib/, to make sure that we use the correct one, either lltype.Signed or rffi.LONG. Fortunately, errors resulting from this confusion will probably just give translation-time errors, so we can fix the places one after the other. But you need to carefully check the declaration of external functions that are implemented in translator/c/src/*.h, like pypy/module/signal/interp_signal.py (this one happens to use mostly rffi.INT, so it should work right now, with the exception of LONG_STRUCT that uses a lltype.Signed). A bientôt, Armin. _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
