[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyQt] [SIP] Critical issue since version 4.18
From: Antoine Lambert <antoine.lambert33 () gmail ! com>
Date: 2016-11-14 20:01:28
Message-ID: CAJ0x15NZ3NmtxWbxhb2jSy43=tyuOLbADBAt8CqzFhFi3mnbWg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I have just tested the latest snapshot (sip-4.19.dev1611111241
<https://www.riverbankcomputing.com/static/Downloads/sip/sip-4.19.dev1611111241.zip>)
and the two bugs I have reported are still present.
2016-11-14 19:57 GMT+01:00 Phil Thompson <phil@riverbankcomputing.com>:
> On 14 Nov 2016, at 6:36 pm, Antoine Lambert <antoine.lambert33@gmail.com>
> wrote:
> >
> > Hi,
> >
> > I am the maintainer of the Python bindings for the Tulip framework : an
> open source graph visualization tool. I have recently upgraded to SIP
> 4.18.1 and one critical issue appears in our generated bindings leading to
> a segfault.
> >
> > The bug is the following. We use SIP in order to implement plugins in
> Python for the Tulip framework. Implementing a plugin consists in writing a
> Python class that derives from a Tulip wrapped plugin interface (see
> http://pythonhosted.org/tulip-python/pythonplugins.html). For instance
> to write a general graph algorithm plugin, one has to write a class that
> derives from the 'tlp.Algorithm' Tulip Python class.
> > The 'tlp.Algorithm' class wraps the 'tlp::Algorithm" C++ class (
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/Algorithm.sip). The
> "tlp::Algorithm" class derives from the "tlp::Plugin" class (
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/Plugin.sip), itself deriving
> from "tlp::WithParameter" and "tlp::WithDependency" (
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/WithParameter.sip,
> https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/WithDependency.sip). The issue
> is that now every call to a method from the "tlp.WithParameter" class
> inside a Tulip plugin source code leads to a segfault during the plugin
> execution.
> > I managed to get back to the SIP revision that introduces the regression
> through a session of "hg bisect" : this is revision 1425 (https://www.
> riverbankcomputing.com/hg/sip/rev/14bfbaf7431a). It seems that some
> needed class cast functions are no more generated since that revision which
> then leads to segfault due to incorrect pointer cast (just my guess).
> > As a temporary workaround, i naively patch the SIP source code bundled
> in the Tulip source tree forcing the generation of these cast functions (
> https://sourceforge.net/p/auber/code/11726/).
> >
> > I also found another issue that is not critical but still problematic.
> When wrapping non const global C++ variables, setting their value in Python
> does not modify the content of the wrapped variables. For instance, in the
> Tulip Python bindings, we wrapped some global variables holding some file
> system paths (e.g. "tlp.TulipBitmapDir", https://sourceforge.net/p/
> auber/code/HEAD/tree/tulip/library/tulip-python/bindings/
> tulip-core/TlpTools.sip).
> > Even if it seems that when modifying the variable content it is taken
> into account (in particular when printing it), the content of the wrapped
> variable is not changed.
> > I assumed there is some kind of cache for wrapped const global variables
> but it should not be used for non const ones.
> > That issue was already present in SIP 4.17, I should have report it
> earlier but its was not critical and I managed to workaround it using a
> Python meta-class (https://sourceforge.net/p/auber/code/HEAD/tree/tulip/
> library/tulip-python/bindings/tulip-core/__init__.py).
> >
> > Hope that this report will help to fix those annoying issues for the
> next SIP version.
>
> Have you tried the current snapshot?
>
> Phil
[Attachment #5 (text/html)]
<div dir="ltr"><div>I have just tested the latest snapshot (<a \
href="https://www.riverbankcomputing.com/static/Downloads/sip/sip-4.19.dev1611111241.zip">sip-4.19.dev1611111241</a>) \
and the two bugs I have reported are still present.<br><br></div></div><div class="gmail_extra"><br><div \
class="gmail_quote">2016-11-14 19:57 GMT+01:00 Phil Thompson <span dir="ltr"><<a \
href="mailto:phil@riverbankcomputing.com" \
target="_blank">phil@riverbankcomputing.com</a>></span>:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14 Nov 2016, at \
6:36 pm, Antoine Lambert <<a \
href="mailto:antoine.lambert33@gmail.com">antoine.lambert33@gmail.com</a>> wrote:<br> ><br>
> Hi,<br>
><br>
> I am the maintainer of the Python bindings for the Tulip framework : an open source graph \
visualization tool. I have recently upgraded to SIP 4.18.1 and one critical issue appears in our \
generated bindings leading to a segfault.<br> ><br>
> The bug is the following. We use SIP in order to implement plugins in Python for the Tulip \
framework. Implementing a plugin consists in writing a Python class that derives from a Tulip wrapped \
plugin interface (see <a href="http://pythonhosted.org/tulip-python/pythonplugins.html" rel="noreferrer" \
target="_blank">http://pythonhosted.org/tulip-<wbr>python/pythonplugins.html</a>). For instance to \
write a general graph algorithm plugin, one has to write a class that derives from the \
'tlp.Algorithm' Tulip Python class.<br> > The 'tlp.Algorithm' class wraps the \
'tlp::Algorithm" C++ class (<a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/Algorithm.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/Algorithm.sip</a>). \
The "tlp::Algorithm" class derives from the "tlp::Plugin" class (<a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/Plugin.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/Plugin.sip</a>), \
itself deriving from "tlp::WithParameter" and "tlp::WithDependency" (<a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/WithParameter.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/WithParameter.sip</a>, \
<a href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/WithDependency.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/WithDependency.sip</a>)<wbr>. \
The issue is that now every call to a method from the "tlp.WithParameter" class inside a Tulip \
plugin source code leads to a segfault during the plugin execution.<br> > I managed to get back to the \
SIP revision that introduces the regression through a session of "hg bisect" : this is revision \
1425 (<a href="https://www.riverbankcomputing.com/hg/sip/rev/14bfbaf7431a" rel="noreferrer" \
target="_blank">https://www.<wbr>riverbankcomputing.com/hg/sip/<wbr>rev/14bfbaf7431a</a>). It seems that \
some needed class cast functions are no more generated since that revision which then leads to segfault \
due to incorrect pointer cast (just my guess).<br> > As a temporary workaround, i naively patch the \
SIP source code bundled in the Tulip source tree forcing the generation of these cast functions (<a \
href="https://sourceforge.net/p/auber/code/11726/" rel="noreferrer" \
target="_blank">https://sourceforge.net/p/<wbr>auber/code/11726/</a>).<br> ><br>
> I also found another issue that is not critical but still problematic. When wrapping non const \
global C++ variables, setting their value in Python does not modify the content of the wrapped variables. \
For instance, in the Tulip Python bindings, we wrapped some global variables holding some file system \
paths (e.g. "tlp.TulipBitmapDir", <a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/TlpTools.sip" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/TlpTools.sip</a>).<br>
> Even if it seems that when modifying the variable content it is taken into account (in particular \
when printing it), the content of the wrapped variable is not changed.<br> > I assumed there is some \
kind of cache for wrapped const global variables but it should not be used for non const ones.<br> > \
That issue was already present in SIP 4.17, I should have report it earlier but its was not critical and \
I managed to workaround it using a Python meta-class (<a \
href="https://sourceforge.net/p/auber/code/HEAD/tree/tulip/library/tulip-python/bindings/tulip-core/__init__.py" \
rel="noreferrer" target="_blank">https://sourceforge.net/p/<wbr>auber/code/HEAD/tree/tulip/<wbr>library/tulip-python/bindings/<wbr>tulip-core/__init__.py</a>).<br>
><br>
> Hope that this report will help to fix those annoying issues for the next SIP version.<br>
<br>
</span>Have you tried the current snapshot?<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil</font></span></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic