[PyQt] Notes on Building PyQt for Qt v4.4rc1
In theory (if Qt maintains backwards compatibility) then the current version of PyQt should build against Qt v4.4rc1. However there is an incompatibility when using gcc. The workaround is to comment out the line QMAKE_LFLAGS += -Wl,--no-undefined in mkspecs/common/g++.conf. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP newcomer questions/complaints
Hi Kevin! Am Montag, 07. April 2008 02:11:24 schrieb Kevin Watters: But when I change one of the sub SIP files, SIP doesn't recognize that its corresponding files need to be regenerated. So the only way I've found to recompile is to touch the root SIP file, which causes SIP to regen ALL of my generated cpp files, and subsequent GCC to recompile ALL of them. Is there an easy solution to this? That would be cool indeed. Seems to be a missing feature. BTW: I am normally using boost::python (which IIRC has been used to wrap Qt4 one, too), which is very comfortable (and may be used to wrap large libraries automatically using pyplusplus, incl. partial recompilations), but most probably more bloated than SIP. However, on the C++-SIG list, Gustavo Carneiro announced his pybindgen, which is supposed to be very lightweight (but maybe not advanced enough to wrap wx or Qt). https://launchpad.net/pybindgen/ 6) The docs show show no comparisons with similar tools. I'm trying SIP to see if the memory usage of a large wxPython app can be reduced--I have seen comparisons claiming that SIP would be slower than hand generated code, but faster than SWIG. This seems to be a fair assumption, since SWIG generates lots of Python shadow classes, and SIP does not. But some data, or even anecdotal advice about what you're going to get out of SIP compared to SWIG might be useful in the documentation. You can be sure that you are not the only one who would be very much interested in such statistics. -- Ciao, / / /--/ / / ANS ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP newcomer questions/complaints
On 4/7/2008 2:11 AM, Kevin Watters wrote: 3) I ended up using the distutils support--which worked great out of the box. But now my scripts are generating enough time to make the compile-link time cycle significant. My SIP files use one root file that %Includes all of the other SIP files so that everything goes into one module. But when I change one of the sub SIP files, SIP doesn't recognize that its corresponding files need to be regenerated. So the only way I've found to recompile is to touch the root SIP file, which causes SIP to regen ALL of my generated cpp files, and subsequent GCC to recompile ALL of them. Is there an easy solution to this? If you look at PyQt3Support (http://www.develer.com/oss/PyQt3Support), in the patch: http://www.develer.com/~naufraghi/PyQt3Support/PyQt3Support_PyQt4.3.3_GPL_r2.patch you will find a cache implementation for PyQt4's configure.py (search for manage_cache). Basically, configure.py is changed so that the output of SIP goes to a temporary directory; then, only the files that changed since last time are actually copied over the compilation directory, so that gcc will compile only those ones. You might grab that code and integrate it within your setup.py. 6) The docs show show no comparisons with similar tools. I'm trying SIP to see if the memory usage of a large wxPython app can be reduced--I have seen comparisons claiming that SIP would be slower than hand generated code, but faster than SWIG. This seems to be a fair assumption, since SWIG generates lots of Python shadow classes, and SIP does not. But some data, or even anecdotal advice about what you're going to get out of SIP compared to SWIG might be useful in the documentation. Such statistics are hard to find because usually developers do not write bindings twice :) There are good reasons for using SIP over SWIG, IMO: 1) Bindings for classes and methods are generated *lazily* on first usage. This means that the initial import is very fast and does not consume much memory; and when the program starts, only the (small) subset of the wxWidget functions actually used by the program contribute to memory occupation. 2) SIP is very Python centric, and has many useful features and shortcuts for binding C++ code into Python. All the /Transfer/ and friends stuff, for instance, is very powerful and elegant (once you get to understand it fully :). Since I switched to SIP from SWIG, I haven't looked back. BTW, I don't know wxWidgets, but if it uses much STL stuff, let me know because I have an unreleased SIP STL meta-binding, which is basically a program which is able to *generate* SIP code for the exact STL subset (= template specializations) used by the library you're writing bindings for; SIP's support for C++ templates is quite weak, so wrapping something like of STL requires abuse of copy paste, which is automated by this tool. -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE extra/kde4xx suggestion
Hey Jim. Do you think it'd be possible to have the extra/kde4xx directories match only against the major (4.x) version, instead of the minor as well (4.x.y)? Speaking as a (Debian) packager, having the PyKDE packages become unbuildable each time a new minor version of KDE is uploaded is, uhm, inconvenient. Is there a reason why the extra/ subdirs could not be shared among minor releases? Thanks in advance, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conference is a gathering of important people who singly can do nothing but together can decide that nothing can be done. -- Fred Allen ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Re: Re: SIP newcomer questions/complaints
6) The docs show show no comparisons with similar tools. I'm trying SIP to see if the memory usage of a large wxPython app can be reduced--I have seen comparisons claiming that SIP would be slower than hand generated code, but faster than SWIG. This seems to be a fair assumption, since SWIG generates lots of Python shadow classes, and SIP does not. But some data, or even anecdotal advice about what you're going to get out of SIP compared to SWIG might be useful in the documentation. I'm finding that to be so in re-writing the bindings for Syzygy http://www.isl.uiuc.edu/syzygy.htm; I don't have numbers, but I'm getting noticeably higher framerates. The generated code is also more readable, easier to debug and maintain, and generates many fewer compiler warnings. But as you've noticed, there's definitely more initial banging of the head against the wall with SIP. Unfortunately after getting 80% done I got pulled away to more mission-critical work, so haven't got anything posted yet. -Jim C. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE extra/kde4xx suggestion
On Monday 07 April 2008 07:25, Adeodato Simó wrote: Hey Jim. Do you think it'd be possible to have the extra/kde4xx directories match only against the major (4.x) version, instead of the minor as well (4.x.y)? Speaking as a (Debian) packager, having the PyKDE packages become unbuildable each time a new minor version of KDE is uploaded is, uhm, inconvenient. If a new version makes it unbuildable, that would be an error, since configure.py should emulate the highest version it knows about. For example, if PyKDE was released for KDE 4.0.2 and you build against 4.0.3, configure.py should treat it as 4.0.2 still. I'd have to look at configure.py to see if that's still handled correctly. In that case, extra/kde402 should already exist, and the h files from that subdirectory would be used, so there shouldn't be a problem (if the new KDE version maintains binary compatibility with the old).. The most likely problem is that I forget to modify the manifest that's used to assemble the tarball and the latest extra/kde* gets omitted. Is there a reason why the extra/ subdirs could not be shared among minor releases? Because there's no guarantee they're the same h files in each version, or a new version won't introduce some problem that requires an h file be shipped with PyKDE instead of accessed from KDE's includes. The problems are either required h files that KDE doesn't install (and that can be errors by minor version), or in one case (the only one, I think), a file that needs to be modified to work with PyKDE.. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE extra/kde4xx suggestion
* Adeodato Simó [Mon, 07 Apr 2008 18:28:21 +0200]: However, I saw this failure [1] in Ubuntu, where your 4.0.2-1 (¹) gets built agains KDE 4.0.3, and it fails because it can't find ksycocafactory.h. Hence I assumed it was expecting extra/kde403. Additionally, after copying extra/kde402 to extra/kde403, the 'rindex' is not a member of 'X' error popped, I guess due to sip/kdeui/kdeui-kde403.diff not being present. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The pure and simple truth is rarely pure and never simple. -- Oscar Wilde ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] ANN: new eric4 4.2 snapshot available
Hi, Yeah sorry... When I pressed send I've forgot to specify this info. This is using Kubuntu Hardy Beta amd with PyQt: PyQt 4.3.3 qscintilla2 (2.1+snapshot20070923) SIP 4.7.3 Qt 4.3.4 (these packages installed using the repository..., maybe those are the problem) In Kubuntu Gutsy, does not happen so far. Cheers. 2008/4/7, Detlev Offenbach [EMAIL PROTECTED]: On Sonntag, 6. April 2008, Gustavo A. Díaz wrote: Hi I've downloaded and installed this snapshot, when i try to access to Preferences i got: Cancelled (core dumped) Works for me. You should give more details about what could cause this (e.g. are you using PyKDE4?) Cheers. 2008/4/6, Detlev Offenbach [EMAIL PROTECTED]: Hi, this is to inform you about the immediate availability of a new eric 4.2 snapshot. Next to fixing bugs it includes these changes. - added double click support for attributes and globals - reorganized the configuration dialog some more - added various startup configuration options (application page) - added functionality to mark all occurrances of a searched text (s.a. configuration dialog editor-searching page) - added hook support for plugins providing autocompletion (get latest rope plugin snapshot for an alternative autocompletion provider) - added action and menu entries to show calltips - a few changes to the PyKDE4 support code to work around a PyKDE4 problem with the Oxygen style (this workaround allows eric4 to use the Oxygen style, when KDE4 dialogs are disabled) - enhanced unicode support (added utf-16 and utf-32) As usual it is available via http://www.die-offenbachs.de/eric/snapshots4 In parallel I uploaded a new snapshot of the rope refactoring plugin, which implements an alternative autocompletion provider for Python. Regards, Detlev -- Detlev Offenbach [EMAIL PROTECTED] ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt -- Detlev Offenbach [EMAIL PROTECTED] -- Gustavo A. Díaz GDNet Projects www.gdnet.com.ar ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
