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