[PySide] [Stackless] PySide problem, take #2: typeobject clash

[John Ehresman]

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: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
>
>