Howdy, friends!, today, I solved it! Made a Stackless Python 2.7.5 that works with PySide. (or maybe vice-versa?)
Yappa-Dappa-Duu !! The patch is not that large, but it was a bit involved, to say the least ;-) Hey, life is great, and Stackless is my future, forever! All the best -- Chris -------------------------------------------------------------------- The current version is online at https://bitbucket.org/pydica/pyside-setup/ (official) and will be submitted as a pull request on github, tomorrow. (p.s.: I'm trying to keep this patch as small as possible, but still it involves quite a lot of PySide, going criss-cross over the sub-modules. I have to say that this is a design flaw and not my initial fault. PySide should not poke into internal data structures which are undocumented. I will re-work this ASAP. But for now, I'M INCREDIBLY HAPPY (sorry for screaming) ) cheerioh -- chris (live long and prosper with Stackless PySide) p.p.s.: I can understand if this patch will not be accepted for PySide mainstream, since it is very directly targeted. On the other hand, it is a step towards removal of certain structures that we should abandon. However you decide, I can live with it (and am used to it, you know ;-) ) p.p.p.s.: It is still a bit crazy to know that the compatibility patch for PyQT is just 4 lines -- as it should be ... On 10.12.12 12:39, Kristján Valur Jónsson wrote: > 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 -- 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/ _______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
