<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 22.10.13 18:27, Christian Tismer
wrote:<br>
</div>
<blockquote cite="mid:5266A754.40901@stackless.com" type="cite">On
22.10.13 16:24, John Ehresman wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">On 21.10.13 22:10, John Ehresman wrote:
<br>
<blockquote type="cite">
<br>
I think I see the problem; to me, at least, it's useful to
see the
<br>
stackless version of object.h at
<br>
<a class="moz-txt-link-freetext" href="http://www.stackless.com/browser/Include/object.h">http://www.stackless.com/browser/Include/object.h</a> It looks
like
<br>
stackless moves the fields defined in PyHeapTypeObject into
<br>
PyTypeObject, adds at least one additional field, and then
#define's
<br>
PyHeapTypeObject to PyTypeObject. This leads to two
problems, which
<br>
are somewhat separable --
<br>
<br>
1) When compiling, there is no ht_type field in
PyHeapTypeObject. This
<br>
is what Christian's patch addresses.
<br>
</blockquote>
</blockquote>
<br>
Wouldn't it be possible to use something like the following in
shiboken's basewrapper.h (untested code below):
<br>
<br>
/// PyTypeObject extended with C++ multiple inheritance
information.
<br>
#ifndef STACKLESS
<br>
<br>
struct LIBSHIBOKEN_API SbkObjectType
<br>
{
<br>
PyHeapTypeObject super;
<br>
SbkObjectTypePrivate* d;
<br>
};
<br>
<br>
#else // STACKLESS
<br>
<br>
// Work around stackless's modification of PyTypeObject and
PyHeapTypeObject
<br>
struct LIBSHIBOKEN_API SbkObjectType
<br>
{
<br>
struct {
<br>
PyTypeObject ht_type;
<br>
} super;
<br>
SbkObjectTypePrivate* d;
<br>
};
<br>
<br>
#endif
<br>
<br>
This would have the advantage of not sprinkling macros across
the code base. It does not address the binary compatibility
problem.
<br>
</blockquote>
<br>
Hmm, good idea!
<br>
That would really be a minimal patch with much less ugliness and
clutter.
<br>
Well, not sure yet if I want to try that really right now...maybe
<br>
</blockquote>
<br>
Tried this -- does not work.<br>
While a good idea, the introduced differences are too big to go away
with<br>
this simple trick.<br>
The thing breaks in for instance<br>
<br>
<blockquote type="cite">/Users/tismer/src/pyside-setup/pyside_build/py2.7-qt4.8.5-64bit-release/pyside/PySide/QtCore/PySide/QtCore/qbitarray_wrapper.cpp:1626:38:
error: no member named 'as_number' in
'SbkObjectType::<anonymous struct at
/Users/tismer/src/pyside-setup/pyside_install/py2.7-qt4.8.5-64bit-release/include/shiboken/basewrapper.h:99:5>'<br>
memset(&Sbk_QBitArray_Type.super.as_number, 0,
sizeof(PyNumberMethods));<br>
~~~~~~~~~~~~~~~~~~~~~~~~ ^<br>
</blockquote>
<br>
The problem is difficult because in stackless object.h we have at
the end of typeobject:<br>
<br>
<blockquote type="cite">
<meta charset="utf-8">
</blockquote>
<pre>415 #ifdef STACKLESS</pre>
<pre class="moz-signature" cols="72">
416 /* we need the extended structure right here */
417 PyNumberMethods as_number;
418 PyMappingMethods as_mapping;
419 PySequenceMethods as_sequence; /* as_sequence comes after as_mapping,
420 so that the mapping wins when both
421 the mapping and the sequence define
422 a given operator (e.g. __getitem__).
423 see add_operators() in typeobject.c . */
424 PyBufferProcs as_buffer;
425 PyObject *ht_name, *ht_slots;
426 slp_methodflags slpflags;
427 #endif
428 } PyTypeObject;
These fields are embedded into typeobject, without the ht_type around it.
I tried the following:
// Work around stackless's modification of PyTypeObject and PyHeapTypeObject
struct LIBSHIBOKEN_API SbkObjectType
{
union {
struct {
PyTypeObject ht_type;
} super;
PyTypeObject super;
};
SbkObjectTypePrivate* d;
};
but that doesn't work, because "super" may not occur twice.
A possible, but even more ugly solution would be to do a union,
where we have the following layout:
// Work around stackless's modification of PyTypeObject and PyHeapTypeObject
struct LIBSHIBOKEN_API SbkObjectType
{
union {
struct {
PyTypeObject ht_type;
};
<insert all of the object fields here, loong list>
} super;
SbkObjectTypePrivate* d;
};
I tried this modification and it works!
Unfortunately with verbose copying of all fields...
This is a bit ugly, but could be made better by a little script that extracts
all the fields from object.h and builds an include file dynamically.
I have the impression that changing it this way would make the patch even worse.
And all the things that have now my macroes, will eventually change, anyway,
when we go to Version 2 with runtime compatibile layout.
On the other hand:
I could put this whole craziness into stackless itself. That would then
work without changing PySide at all, just recompile...
What do you think?
cheers - Chris
(patch attached)
--
Christian Tismer :^) <a class="moz-txt-link-rfc2396E" href="mailto:tismer@stackless.com"><mailto:tismer@stackless.com></a>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* <a class="moz-txt-link-freetext" href="http://starship.python.net/">http://starship.python.net/</a>
14482 Potsdam : PGP key -> <a class="moz-txt-link-freetext" href="http://pgp.uni-mainz.de">http://pgp.uni-mainz.de</a>
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? <a class="moz-txt-link-freetext" href="http://www.stackless.com/">http://www.stackless.com/</a></pre>
</body>
</html>