Re: [PyKDE] ANN: Eric3 3.7 available for Mac OS X
El Viernes, 17 de Junio de 2005 06:10, Kevin Walzer escrigué: I have assembled a package installer of the latest version (3.7) of Eric3, the Python IDE written in PyQt, for Mac OS X. Well, I'm trying Eric 3.7, not on OS X but on a G5 with Fedora Core 4. I have downloaded the latest snapshoot of SIP, PyQt and QScintilla but the insallagtion gives me an error saying I need QScintilla 1.3 or snapshoot-20041001 or higher :( I have qscintilla-1.62-gpl-snapshot-20050311 so it's obviously an error. I could enter the eric directory and run python eric3.py and everything seems to work. Best regards, -- Antoni Aloy López Binissalem - Mallorca Linux Registered User # 210825 ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Port to Qt4
Hi I am developping an open source tool based on Qt and PyQt. One of the feature I have to implement now is already present in Qt4 (using QPainter on a QGLWidget). Implementing it for Qt3 is feasible but har,long,error-prone and smells like a waste of time! So the question is: are there any idea of when PyQt will be ported to Qt4, just to know wether I should start implementing what I need in Qt3 or if I should wait a couple of weeks to get it out of the box. BTW, I am willing to help the porting! ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Port to Qt4
Hi I am developping an open source tool based on Qt and PyQt. One of the feature I have to implement now is already present in Qt4 (using QPainter on a QGLWidget). Implementing it for Qt3 is feasible but har,long,error-prone and smells like a waste of time! So the question is: are there any idea of when PyQt will be ported to Qt4, just to know wether I should start implementing what I need in Qt3 or if I should wait a couple of weeks to get it out of the box. BTW, I am willing to help the porting! http://www.riverbankcomputing.co.uk/pyqt/roadmap.php Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Port to Qt4
Phil Thompson a écrit : Hi I am developping an open source tool based on Qt and PyQt. One of the feature I have to implement now is already present in Qt4 (using QPainter on a QGLWidget). Implementing it for Qt3 is feasible but har,long,error-prone and smells like a waste of time! So the question is: are there any idea of when PyQt will be ported to Qt4, just to know wether I should start implementing what I need in Qt3 or if I should wait a couple of weeks to get it out of the box. BTW, I am willing to help the porting! http://www.riverbankcomputing.co.uk/pyqt/roadmap.php Sure, I've seen this web page and it says: At the moment there are no timescales for the release of PyQt v4. But does it mean, there is *really* no timescales, that is we will start thinking/implementing some day, or does it mean that there is a work in progress with beta versions,etc... but the author does not want to commit to a deadline? Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Port to Qt4
Phil Thompson a écrit : Hi I am developping an open source tool based on Qt and PyQt. One of the feature I have to implement now is already present in Qt4 (using QPainter on a QGLWidget). Implementing it for Qt3 is feasible but har,long,error-prone and smells like a waste of time! So the question is: are there any idea of when PyQt will be ported to Qt4, just to know wether I should start implementing what I need in Qt3 or if I should wait a couple of weeks to get it out of the box. BTW, I am willing to help the porting! http://www.riverbankcomputing.co.uk/pyqt/roadmap.php Sure, I've seen this web page and it says: At the moment there are no timescales for the release of PyQt v4. But does it mean, there is *really* no timescales, that is we will start thinking/implementing some day, or does it mean that there is a work in progress with beta versions,etc... but the author does not want to commit to a deadline? It means only that the author does not want to commit to a deadline. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Using debugger inside eric for Zope Test Case
Hi all. I'm using Eric3 on the development of Zope Products, inside Zope Test Cases. While running from the shell, I can use the import pdb pdb.set_trace() codelet to insert a breakpoint and inspect what is going on inside my tests. If I do the same while running the tests from inside Eric3, the output goes to the Shell window and, from there, I'm able to interact with python debugger. Now, I would like to do the same with Eric3 debugger, in order to manually place a breakpoint and invoke the debugger on that. Is this possible? Regards Marco ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Memory leak segfault with deleteLater
Hello, two problems, which are very similar (and maybe related). The first is a segmentation fault: from qt import * app = QApplication([]) w1 = QWidget(None) w2 = QWidget(w1) w2. = w1 w2.deleteLater() del w1 del w2 app.processEvents() Segmentation fault The thing I don't understand is why it does not crash if you don't add a reference to w1 from inside w2. 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(w1) w2.xx = w1 w1.xx = d del d del w1 del w2 gc.collect() 0 app.processEvents() gc.collect() 0 print wd weakref at 00813690; to 'instance' at 00812FD0 d should be collected as w1 and w2 are destroyed. -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] ANN: Eric3 3.7 available for Mac OS X
Am Samstag, 18. Juni 2005 09:51 schrieb Antoni Aloy: El Viernes, 17 de Junio de 2005 06:10, Kevin Walzer escrigué: I have assembled a package installer of the latest version (3.7) of Eric3, the Python IDE written in PyQt, for Mac OS X. Well, I'm trying Eric 3.7, not on OS X but on a G5 with Fedora Core 4. I have downloaded the latest snapshoot of SIP, PyQt and QScintilla but the insallagtion gives me an error saying I need QScintilla 1.3 or snapshoot-20041001 or higher :( I have qscintilla-1.62-gpl-snapshot-20050311 so it's obviously an error. I could enter the eric directory and run python eric3.py and everything seems to work. Best regards, This usually means, that there is an older library somewhere on your disk or the PyQt library it picks up was not compiled with QScintilla support. You can test it yourself by opening a Python shell and entering import qtext. Detlev -- Detlev Offenbach [EMAIL PROTECTED] ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Re: Memory leak segfault with deleteLater
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 reference count is 2. This is because ownership of w2 is with C++ because it has a parent. The extra reference is needed to make sure valuable data isn't lost if the application doesn't keep a reference to the child. w2. = w1 w1 reference count is 2. w2.deleteLater() A DeferredDelete event is posted to w2. del w1 w1 reference count is 1. del w2 w2 reference count is 1. app.processEvents() w2 handles the DeferredDelete event and calls it's own virtual dtor. This is caught by the dtor of an internally generated QWidget sub-class which removes w2's extra reference. w2 reference count is now 0. Python now garbage collects w2, part of which is to reduce the reference count of w1 to 0. As w1 is owned by Python (because the C++ instance doesn't have a parent) it calls the C++ dtor. This then calls the C++ dtor of it's children (ie. w2) - but we are already in w2's dtor. The problem is that we haven't yet executed the base QObject dtor which removes an instance from it's parent and would prevent the recursive dtor call. Segmentation fault The thing I don't understand is why it does not crash if you don't add a reference to w1 from inside w2. w1 will be garbage collected by del w1. This will cause the C++ dtors for w2 and w1 to execute. The w2 dtor will remove the extra reference to w2 (leaving it at 1). del w2 will then cause w2 to be garbage collected. Nothing extra happens here because PyQt knows that the wrapped C++ instance has already gone. 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. The second problem is a memory leak: I'll think about this tomorrow - my head hurts at the moment. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Re: Memory leak segfault with deleteLater
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 variable in the derived destructor) which records if we are already destroying the object? So that, if the derived destructor gets re-invoked as part of a reference cycle, it just silently exits without doing anything. I think you have a similar variable, which records if the C++-side of the object is destroyed or not... maybe you could set that at the very start of the derived destructor. The second problem is a memory leak: I'll think about this tomorrow - my head hurts at the moment. Sure :) -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] PyQt and sip: WId is undefined
On Fri, 10 Jun 2005, Phil Thompson wrote: On Friday 10 June 2005 10:21 pm, Jeremy C. Reed wrote: I am trying to build PyQt-x11-gpl-3.14.1 on Darwin 7.9.0/Mac OS X. You need PyQt-mac-gpl-3.14.1. X11 on Mac is not supported. Okay, I will give this a try. What are the plans for X11 on Mac? Will the PyQt-mac version work with qt-x11-free? We are using X11 version of Qt and hope to use X11 for PyQt also. I don't know PyQt myself (as I am helping with packaging), but we hope to have a consistent environment from Darwin, Mac OS X, Solaris, and NetBSD (which all have X). But maybe the PyQt-mac for Mac OS X will behave the same. Jeremy C. Reed Low cost press releases http://www.reedmedia.net/ ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
