I took a look at the patch and can't quite understand it (I must admit I didn't apply it). Can someone explain why it's needed?
Thanks, John On 10/20/13 12:07 AM, Christian Tismer wrote: > 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 > > _______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
