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
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
