[PySide] [Stackless] PySide problem, take #2: typeobject clash
Christian Tismer
tismer at stackless.com
Sun Oct 20 06:07:22 CEST 2013
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:tismer at stackless.com]
>> Sent: 8. desember 2012 21:45
>> To: stackless at stackless.com; 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:tismer at stackless.com>
>> 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
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
--
Christian Tismer :^) <mailto:tismer at stackless.com>
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/
More information about the PySide
mailing list