Phil Thompson <[EMAIL PROTECTED]> wrote:
> 2. w1 and it's C++ instance won't be garbage collected (and the widget
might
> be visible) until the collector is run. Might this be too long to wait?
(It
> would be possible to explicitly run the collector at strategic points in
the
> sip module.)
I thi
Giovanni,
Remember this?
I have a potential fix for this disabled in tonight's SIP snapshot. To try it
out change the #if 1 in sip_api_common_dtor() in siplib.c to #if 0.
What the fix does is to prevent the removal of the hidden extra reference and
leaves it to the cyclic garbage collector to
On Thursday 30 June 2005 12:34 pm, Giovanni Bajo wrote:
> Phil Thompson <[EMAIL PROTECTED]> wrote:
> >>> ignoring the extra reference to wrappers of objects owned by C++.
> >>
> >> Thanks, I just verified that this fixes my problem!
> >
> > I've had to back this out - it's the wrong fix and breaks
Phil Thompson <[EMAIL PROTECTED]> wrote:
>>> ignoring the extra reference to wrappers of objects owned by C++.
>>
>> Thanks, I just verified that this fixes my problem!
> I've had to back this out - it's the wrong fix and breaks other things.
Okie dokie. Is a different fix planned?
--
Giovanni
On Tuesday 28 June 2005 11:38 am, Giovanni Bajo wrote:
> Phil Thompson <[EMAIL PROTECTED]> wrote:
> > Should be fixed in tonight's SIP snapshot. The cyclic garbage collector
>
> was
>
> > ignoring the extra reference to wrappers of objects owned by C++.
>
> Thanks, I just verified that this fixes m
Phil Thompson <[EMAIL PROTECTED]> wrote:
> I think one way around the problem is to avoid the extra reference to the
> Python object and move the data that it contains into a separate data
> structure. In other words, weaken the link between the Python world and
> the C++ world. My concern would t
Phil Thompson <[EMAIL PROTECTED]> wrote:
> Should be fixed in tonight's SIP snapshot. The cyclic garbage collector
was
> ignoring the extra reference to wrappers of objects owned by C++.
Thanks, I just verified that this fixes my problem!
--
Giovanni Bajo
___
On Monday 20 June 2005 4:15 pm, Giovanni Bajo wrote:
> The second problem is a memory leak:
> >>> from qt import *
> >>> app = QApplication([])
> >>> import gc, weakref
> >>> class Data:
>
> ... pass
> ...
>
> >>> d = Data()
> >>> wd = weakref.ref(d)
> >>> w1 = QWidget(None)
> >>> w2 = QWidget
> Phil Thompson <[EMAIL PROTECTED]> wrote:
>
>> I'm not sure if anything can be done to detect and/or prevent the
>> problem.
>> It would be easy enough to contrive the same problem in C++, so I don't
>> really see it as a PyQt problem. I'm open to suggestions.
>
> What about adding adding a flag (
Phil Thompson <[EMAIL PROTECTED]> wrote:
> I'm not sure if anything can be done to detect and/or prevent the problem.
> It would be easy enough to contrive the same problem in C++, so I don't
> really see it as a PyQt problem. I'm open to suggestions.
What about adding adding a flag (static varia
On Monday 20 June 2005 4:15 pm, Giovanni Bajo wrote:
> Hello,
>
> two problems, which are very similar (and maybe related). The first is a
>
> segmentation fault:
> >>> from qt import *
> >>> app = QApplication([])
> >>> w1 = QWidget(None)
w1 reference count is 1.
> >>> w2 = QWidget(w1)
w2 refer
11 matches
Mail list logo
