Yes. But, stackless tries to detect if a type has the proper stackless extensions, by a flag in the type's 'flag' entry: Py_TPFLAGS_HAVE_STACKLESS_EXTENSION Therefore, there shouldn't be confusion:
1) if Stackless sees a type defined by Shiboken, even with the shiboken extension, it shouldn't have this flag, and stackless should ignore it. 2) If Shiboken sees a type object from stackless, it won't do anything with it because it only adds the sbk extensions to its own types. The issue is, imho, likely to be a problem with 1), a yet unidentified case in stackless where we assume all internal types to have the extension, i.e. fail to check for the presence of the flag. K > -----Original Message----- > From: Christian Tismer [mailto:[email protected]] > Sent: 8. desember 2012 21:45 > To: [email protected]; Kristján Valur Jónsson; Richard Tew; lars van > Gemerden > Subject: PySide problem, take #2: typeobject clash > > Hi again, > > after some more investigation, I think I found it. > See thread [PySide violates Python API - PyQt does not!] The first message > was not correct, but the second one very likely is. > > As said there, the PyHeapTypeObject is extended like so: > > > /// PyTypeObject extended with C++ multiple inheritance information. > > struct LIBSHIBOKEN_API SbkObjectType > > { > > PyHeapTypeObject super; > > SbkObjectTypePrivate* d; > > }; > > This additional pointer gets aliased to the first 4 bytes (win 32 bit) of > > typedef struct _slp_methodflags { > signed char tp_itemsize; > signed char tp_weaklistoffset; > signed char tp_dictoffset; > signed char nb_add; > signed char nb_subtract; > signed char nb_multiply; > signed char nb_divide; > signed char nb_remainder; > ... > > > The first three seem irrelevant. But the nb_add might influence the way how > __add__ is interpreted. Due to the pointer value, stackless tries to call > __add__ using the soft-switching protocol, which then fails miserably. > > The macro that tries this is: > > #define STACKLESS_PROMOTE_METHOD(obj, meth) \ > (obj->ob_type->tp_flags & Py_TPFLAGS_HAVE_STACKLESS_EXTENSION ? > \ > slp_try_stackless = stackless & obj->ob_type->slpflags.meth : 0) > > and it is used by > > #define STACKLESS_PROPOSE_METHOD(obj, meth) \ > { \ > int stackless = STACKLESS_POSSIBLE(); \ > STACKLESS_PROMOTE_METHOD(obj, meth); \ > } > > Unfortunately, I could not find out if there is a way for Stackless to fall > into > this trap. But a good thing would be a little test: > > Lars, Richard: > Can you please try your crashing examples, by putting > > import stackless > > stackless.enable_softswitch(False) > > right after the program start? > > That makes sure that stackless support of the interpreter is completely > disabled, so the misinterpreted frags are of no influence. > > If that leads to significantly less crashes, then there is a quick fix for > PySide: > Insert a dummy void* into object.h before slpflags: > > > PyObject *ht_name, *ht_slots; > > slp_methodflags slpflags; > > #endif > > } PyTypeObject; > > Hope this helps, but I'm not confident -- Chris > > -- > Christian Tismer :^) <mailto:[email protected]> > Software Consulting : Have a break! Take a ride on Python's > Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ > 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de > phone +49 173 24 18 776 fax +49 (30) 700143-0023 > PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today? http://www.stackless.com/ > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
