Re: [PyKDE] PyKDE Change in Plans
On Tuesday 01 April 2003 13:23, Jim Bublitz wrote:
> Following up on Phil's "Incompatible SIP Change" message, I've
> decided to make a slight change in the PyKDE release schedule.
>
> Within the next couple of days, I'll release a snapshot of the next
> PyKDE release. This snapshot will be based on sip 3.5. If you're
> using sip 3.5 it will build as delivered.
>
> To use it with the "incompatible" sip snapshot you'll need to do the
> following before building:
>
> 1. grep the sip files for "sipName":
>
> grep sipName .../sip/*.sip
three dots?
>
> There are only 7 occurances
>
> 2. Replace all occurances of "sipName_module_something" with
> "sipName_something". For example
>
> sipBadVirtualResultType(sipName_kdeui_KDateValidator,
> sipName_kdeui_validate);
>
> becomes:
>
> sipBadVirtualResultType(sipName_KDateValidator, sipName_validate);
Hmm if you have the appropriate commands installed:
grep -l "sipName" ../sip/*.sip | xargs -n 1 -i sed -r -i
"s/(sipName_)([a-zA-Z]+_)/\1/g" {}
Which will do it in one commandline (but with only seven occurences it might
be overkill - however, I've used that to replace defines, code, etc. many
times).
The basic command is:
sed -r -i "s/(sipName_)([a-zA-Z]+_)/\1/g"
which will take:
[EMAIL PROTECTED] kibab $ cat mytestfile
sipName_kdeui_KatePart sipName_kdeui_Mytest
and turn it into:
sipName_KatePart sipName_Mytest
This, of course, assumes that no underscore will be present in module names.
Finally, if I'm wrong and this kills your system, well, oops ;)
--Kaleb
pgp0.pgp
Description: signature
Re: [PyKDE] SIP Roadmap
On Thursday 02 January 2003 11:10 am, Phil Thompson wrote: > For those interested I've added a SIP Roadmap to the website at > http://www.riverbankcomputing.co.uk/sip/roadmap.php which describes the > main objectives and features for SIP v4. > > Comments welcome. > > Phil Looks very good. I'm especially pleased to see builtin support for various c++ operators without the need to handwrite any code as well as support for pointers/references to base types. Thanks. --Kaleb msg03614/pgp0.pgp Description: signature
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 01:42 pm, Martin v. Löwis wrote: > Kaleb Pederson wrote: > > (gdb) thread 1 > > #0 0x4024b1be in select () from /lib/libc.so.6 > > See the source of PyImport_ImportModuleEx. It acquires the import lock, > so you are holding the import lock while QApplication_exec_loop is > running. That means you deadlock. > > gem.src.gui.gui should not run the mainloop, but expose a function to > run the mainloop, which the importer of gui should then invoke. > > Regards, > Martin It works beautifully! Thank you for all the help. It would have taken me a long time to figure that one out by myself. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 01:42 pm, Martin v. Löwis wrote: > Kaleb Pederson wrote: > > (gdb) thread 1 > > #0 0x4024b1be in select () from /lib/libc.so.6 > > [...] > > > #16 0x080a81d2 in PyImport_ImportModuleEx (name=0x818a924 > > "gem.src.gui.gui", globals=0x8145154, locals=0x8145154, > > fromlist=0x8114484) at > > Python/import.c:1658 > > [...] > > >>From my limited knowledge of the Python interpreter, it looks like the > >> lock > > > > only gets acquired once in the third thread. In which case, there would > > be no reason for it to block. But, the first thread also had some > > relevant import calls, so I'm not sure. Where do I look now? > > See the source of PyImport_ImportModuleEx. It acquires the import lock, > so you are holding the import lock while QApplication_exec_loop is > running. That means you deadlock. > > gem.src.gui.gui should not run the mainloop, but expose a function to > run the mainloop, which the importer of gui should then invoke. > > Regards, > Martin Ahh. I'm going to change that right now. I'll let you know. Thank you. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 12:50 pm, you wrote: > Phil Thompson <[EMAIL PROTECTED]> writes: > > You could try instrumenting lock_import(), or replace the mysqldb calls > > with code that still does the imports but nothing else. > > Alternatively, you could also ask your debugger for a stack trace for > all threads. > > Regards, > Martin Hmm switching through the various threads yields: // although I don't display the entire traceback, this thread never acquires the lock. (gdb) thread 1 [Switching to thread 1 (Thread 16384 (LWP 4220))]#0 0x4024b1be in select () from /lib/libc.so.6 (gdb) bt #0 0x4024b1be in select () from /lib/libc.so.6 #1 0x40b76670 in __JCR_LIST__ () from /usr/qt/3-debug//lib/libqt-mt.so.3 #2 0x4053ed39 in QEventLoop::enterLoop() (this=0x8295368) at kernel/qeventloop.cpp:191 #3 0x4053ec52 in QEventLoop::exec() (this=0x8295368) at kernel/qeventloop.cpp:138 #4 0x40524b41 in QApplication::exec() (this=0x81c83b0) at kernel/qapplication.cpp:2471 #5 0x417eb27b in sipDo_QApplication_exec_loop(_object*, _object*) () from /usr/local/lib/python2.2/site-packages/libqtcmodule.so #6 0x080f3ec6 in PyCFunction_Call (func=0x8801cd8, arg=0x8134124, kw=0x0) at Objects/methodobject.c:79 #7 0x0808ae96 in eval_frame (f=0x814d1ac) at Python/ceval.c:2014 #8 0x0808d204 in PyEval_EvalCodeEx (co=0x81462e8, globals=0x81743dc, locals=0x81743dc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #9 0x080828c0 in PyEval_EvalCode (co=0x81462e8, globals=0x81743dc, locals=0x81743dc) at Python/ceval.c:481 #10 0x080a644a in PyImport_ExecCodeModuleEx (name=0xbfffee80 "gem.src.gui.gui", co=0x81462e8, pathname=0xbfffe540 "/home/kibab/JDC/gem/src/gui/gui.pyc") at Python/import.c:505 #11 0x080a6c12 in load_source_module (name=0xbfffee80 "gem.src.gui.gui", pathname=0xbfffe540 "/home/kibab/JDC/gem/src/gui/gui.pyc", fp=0x8189f38) at Python/import.c:787 #12 0x080a76be in load_module (name=0xbfffee80 "gem.src.gui.gui", fp=0x8189f38, buf=0xbfffe9d0 "/home/kibab/JDC/gem/src/gui/gui.py", type=1) at Python/import.c:1371 #13 0x080a8d60 in import_submodule (mod=0x818a224, subname=0xbfffee8c "gui", fullname=0xbfffee80 "gem.src.gui.gui") at Python/import.c:1910 #14 0x080a8525 in load_next (mod=0x818a224, altmod=0x818a224, p_name=0xb2a0, buf=0xbfffee80 "gem.src.gui.gui", p_buflen=0xbfffee7c) at Python/import.c:1766 #15 0x080a7eee in import_module_ex (name=0x0, globals=0x8145154, locals=0x8145154, fromlist=0x8114484) at Python/import.c:1624 #16 0x080a81d2 in PyImport_ImportModuleEx (name=0x818a924 "gem.src.gui.gui", globals=0x8145154, locals=0x8145154, fromlist=0x8114484) at Python/import.c:1658 #17 0x080f617b in builtin___import__ (self=0x0, args=0x813d8e4) at Python/bltinmodule.c:40 // Here we have the second (manager) thread (gdb) thread 2 [Switching to thread 2 (Thread 32769 (LWP 4225))]#0 0x4024988b in poll () from /lib/libc.so.6 (gdb) bt #0 0x4024988b in poll () from /lib/libc.so.6 #1 0x40030d6e in __pthread_manager () from /lib/libpthread.so.0 #2 0x40030fba in __pthread_manager_event () from /lib/libpthread.so.0 // the third thread ... this one calls lock_import() and then apparently gets suspended? (gdb) thread 3 [Switching to thread 3 (Thread 16386 (LWP 4226))]#0 0x4019fd49 in sigsuspend () from /lib/libc.so.6 (gdb) bt #0 0x4019fd49 in sigsuspend () from /lib/libc.so.6 #1 0x40033858 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x400300eb in pthread_cond_wait () from /lib/libpthread.so.0 #3 0x080b5c0e in PyThread_acquire_lock (lock=0x813d418, waitflag=1) at Python/thread_pthread.h:374 #4 0x080a5874 in lock_import () at Python/import.c:166 #5 0x080a81b2 in PyImport_ImportModuleEx (name=0x8182fc4 "types", globals=0x880079c, locals=0x8114484, fromlist=0x87fcc1c) at Python/import.c:1657 #6 0x080f617b in builtin___import__ (self=0x0, args=0x813ab0c) at Python/bltinmodule.c:40 >From my limited knowledge of the Python interpreter, it looks like the lock only gets acquired once in the third thread. In which case, there would be no reason for it to block. But, the first thread also had some relevant import calls, so I'm not sure. Where do I look now? --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pyqt/mysqld thread deadlock
On Wednesday 01 January 2003 11:40 am, you wrote: > On Wednesday 01 January 2003 5:58 pm, Kaleb Pederson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > It turns out, however, that the thread locks in the middle of my run() > > call and never completes. I'm cross-posting this message as I'm not > > familiar with Python extension modules and I don't know if PyQt could > > have caused this, it is a Python bug (or feature) or if there is a > > problem in the mysqldb module code. > > > > So does anyone have any idea what's wrong or how to fix it? Please email > > me as well if you aren't posting to the PyQt/Python list (kibab at > > icehouse dot net). > > To quote the Python source the lock is "to prevent parallel imports of the > same module in different threads to return with a partially loaded module". > What other imports (or the same import in other threads) might be happening > at the same time? > At this point in my application there is nothing else "NEW" going on. That is, I'm in the middle of the event loop and this occurs in response to a button press. The thread, of course, returns control to my application which then waits for more user input. I can think of no reason anything else would be trying to import ListType, TupleType, or exc_info. Furthermore, this is the first thread I spawn (although the behavior is similar for all subsequent threads) thus, I would hope there would be no other blocked threads. Phil, wouldn't the block cease once the "other" thread had successfully imported the module thereby unblocking my thread? Never through the rest of my application life does that thread unblock. Thanks for the info. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] pyqt/mysqld thread deadlock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok. I have a PyQt program using mysql as a database with mysqldb as my database client. I'm spawning qt threads to do all the work before I call a postevent to let my application know I'm done. It turns out, however, that the thread locks in the middle of my run() call and never completes. I'm cross-posting this message as I'm not familiar with Python extension modules and I don't know if PyQt could have caused this, it is a Python bug (or feature) or if there is a problem in the mysqldb module code. Here's my run call: def run(self): """ called after the thread is spawned """ try: # never makes it through the quick_find_customer call self.data = quick_find.quick_find_customer(self.parameters) print "quick find returned:",self.data event = QCustomEvent(self.eventID) event.setData(self.data) QThread.postEvent(self.receiver,event) except Exception, msg: print msg I traced through everything and it seems to be blocking in the mysql code: def _execute(self, query, args): # makes it into the function but ... from types import ListType, TupleType from sys import exc_info # it never makes it this far try: if args is None: r = self._query(query) Once it locks, I get the following backtrace (using a full debug build of Python/PyQt/etc.): #0 0x4019fd49 in sigsuspend () from /lib/libc.so.6 #1 0x40033858 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x400300eb in pthread_cond_wait () from /lib/libpthread.so.0 #3 0x080b5c0e in PyThread_acquire_lock (lock=0x813d418, waitflag=1) at Python/thread_pthread.h:374 #4 0x080a5874 in lock_import () at Python/import.c:166 #5 0x080a81b2 in PyImport_ImportModuleEx (name=0x8182fc4 "types", globals=0x87f56a4, locals=0x8114484, fromlist=0x87f83f4) at Python/import.c:1657 #6 0x080f617b in builtin___import__ (self=0x0, args=0x813ab0c) at Python/bltinmodule.c:40 #7 0x080f3ec6 in PyCFunction_Call (func=0x81379f0, arg=0x813ab0c, kw=0x0) at Objects/methodobject.c:79 #8 0x080cdd9b in PyObject_Call (func=0x81379f0, arg=0x813ab0c, kw=0x0) at Objects/abstract.c:1688 #9 0x0808ea7b in PyEval_CallObjectWithKeywords (func=0x81379f0, arg=0x813ab0c, kw=0x0) at Python/ceval.c:3058 #10 0x0808a3f8 in eval_frame (f=0x852f99c) at Python/ceval.c:1843 #32 0x0808d204 in PyEval_EvalCodeEx (co=0x870c6b0, globals=0x871a6cc, locals=0x0, args=0x81e2d78, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #33 0x080e30df in function_call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at Objects/funcobject.c:374 #34 0x080cdd9b in PyObject_Call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at Objects/abstract.c:1688 #35 0x080d6f80 in instancemethod_call (func=0x870f34c, arg=0x81e2d64, kw=0x0) at Objects/classobject.c:2292 #36 0x080cdd9b in PyObject_Call (func=0x8582af4, arg=0x81e2d64, kw=0x0) at Objects/abstract.c:1688 #37 0x0808ea7b in PyEval_CallObjectWithKeywords (func=0x8582af4, arg=0x81e2d64, kw=0x0) at Python/ceval.c:3058 #38 0x40023ecb in sipEvalMethod (pm=0x8734788, args=0x81e2d64) at siplib.c:2898 #39 0x414a85a4 in sipQThread::sipVH_run(sipMethodCache const*, _sipThisType*) () from /usr/local/lib/python2.2/site-packages/libqtcmodule.so #40 0x414a8553 in sipQThread::run() () from /usr/local/lib/python2.2/site-packages/libqtcmodule.so #41 0x40517726 in QThreadPrivate::start(QThread*) (thread=0x8734778) at kernel/qthread_unix.cpp:79 - ---Type to continue, or q to quit--- #42 0x4051675b in start_thread (_arg=0x87327a0) at kernel/qthread_unix.cpp:98 #43 0x40031160 in pthread_start_thread () from /lib/libpthread.so.0 #44 0x40031262 in pthread_start_thread_event () from /lib/libpthread.so.0 So does anyone have any idea what's wrong or how to fix it? Please email me as well if you aren't posting to the PyQt/Python list (kibab at icehouse dot net). - --Kaleb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+EyxOeAVt8Tl/2kURApe3AJ9Sf5oBy2/+iKN3L5eS5YWsSGwK8ACfQQv8 sUmiu7EUmYRCglp0NkHaM8E= =sxi1 -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Opinions on pyuic Custom Widget Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't have a better suggestion at the time. The way it currently works is very intuitive. Without looking through the documentation, I assumed that it would work that way and when I added custom widgets to my programs everything just "worked". I haven't recently played with uic so I don't remember what it does nor how the two compare. I like the idea of the new way providing more flexibility, however, as I have been considering changing some of my naming conventions. If the change is made, as long as it is well documented, it shouldn't be a problem. - --Kaleb On Saturday 14 December 2002 03:10 am, Phil Thompson wrote: > I've been prompted to look at improving pyuic's support for custom widgets. > > At the moment, if you use a custom widget, pyuic will generate the > following at the start of the module... > > from modname import widgetname > > ...where "widgetname" is the class name of the custom widget - no problem > there. "modname" is the value entered in the Headerfile field of the Edit > Custom Widgets dialog with the .h extension removed. While this works, I'm > told it isn't particularly useful. It also makes dubious assumptions about > how custom widgets have been packaged into modules and make it less easy to > satisfy both uic and pyuic. > > I propose to remove this behaviour. > > A more generic, think about it for 2 minutes, solution is to allow Python > code to be embedded in the Comment field of the Form Settings dialog. Any > line beginning with "Python:" will be copied to the generated module. This > is then completely flexible. > > Before I go ahead and implement this, does anybody have any better > suggestions? Or additional things that could be done for common cases (like > support for PyKDE widgets). > > Phil > > ___ > PyKDE mailing list[EMAIL PROTECTED] > http://mats.gmd.de/mailman/listinfo/pykde -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9+0l/eAVt8Tl/2kURAkdwAKCyqPrCRb9tuV+QVoL7pjZ3Nr/XDACfS5h5 hVyT74apeyPge4plPgq8VBs= =zHEQ -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 06 December 2002 05:05 pm, Bart Verwilst wrote: > On Saturday 07 December 2002 00:43, Kaleb Pederson wrote: > || -BEGIN PGP SIGNED MESSAGE- > || Hash: SHA1 > || > || As a note, I would love to see that done as well, or at least an option > || that can be specified on the command line. I'm a gentoo user and would > || like to see that. > || > || Of course, you can just get around it by doing a simple: > || > || $ echo "yes" | python build.py > || > || But it is better not to. > || > || Bart, do you have any interesting in building ebuilds for the > || snapshots? As I do most of my development using PyQt, I have had to > || build my own for the snapshots. Are these of any interest to you? Also, > || now that eric is a distinct package, I presume we will see an ebuild for > || it here upon the next release? I'll willing to help in these areas. > > Do you have your own eric ebuild already? > Otherwise, it would be great if you could send it to me, saves me some work > :p I'll make sure eric becomes a part of Portage, rest assured :o) I haven't built my own as I finally got around to getting the latest snapshots (through ebuilds) of SIP and PyQt up and running today. If I happen to build one over the next couple days, I'll be sure to send it to you. My PyQt snapshot ebuild does correctly remove the eric stuff though, as that was necessary to get it to install correctly (a fairly trivial modification). - --Kaleb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE98VFreAVt8Tl/2kURArbHAJ9m61m+SZ0Ln7JUMfO12Lv2begt5ACgxFVq QLNsrBZkcsJN8tvriORJN5E= =PDZg -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 06 December 2002 05:04 pm, Bart Verwilst wrote: > On Saturday 07 December 2002 01:30, Phil Thompson wrote: > || On Friday 06 December 2002 11:23 pm, Bart Verwilst wrote: > || > Hi! > || > > || > I'm the packager of pyQT + sip for Gentoo Linux. > || > Could it be possible to abandon the use of explicitly having the user > || > type "yes" before starting the install? Since Portage rules are not > || > to allow user input during the install process, it would be much > || > nicer just to have build.py list something like "By installing this, > || > you automatically accept our license." Or something like it was > || > before... I hope you take this into consideration... > || > || Doesn't Qt require you to do the same? > > Yeah, we patched that too.. > But i think it would be nicer if we wouldn't have to do this at all for > pyqt.. Pretty please? :o) Out of curiosity, how do you get away with that? Is it written somewhere in the license that anyone who installs/uses this program agrees to its license? It has always kind of bugged me (as a developer), but I never investigated as I do agree to their license. (Also, it seemed like someone took the long way around to do that when you could probably echo "Yes" or something to the configure script instead of having to sed it... but that's fairly irrelevant.) - --Kaleb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE98VB8eAVt8Tl/2kURArWIAJ4nLwXL1LcrIMQ72EO2a6ickQm9HACgvISn ubvf81i2uxn9OUgLq3NKxIs= =/ATV -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As a note, I would love to see that done as well, or at least an option that can be specified on the command line. I'm a gentoo user and would like to see that. Of course, you can just get around it by doing a simple: $ echo "yes" | python build.py But it is better not to. Bart, do you have any interesting in building ebuilds for the snapshots? As I do most of my development using PyQt, I have had to build my own for the snapshots. Are these of any interest to you? Also, now that eric is a distinct package, I presume we will see an ebuild for it here upon the next release? I'll willing to help in these areas. - --Kaleb On Friday 06 December 2002 03:23 pm, Bart Verwilst wrote: > Hi! > > I'm the packager of pyQT + sip for Gentoo Linux. > Could it be possible to abandon the use of explicitly having the user type > "yes" before starting the install? Since Portage rules are not to allow > user input during the install process, it would be much nicer just to have > build.py list something like "By installing this, you automatically accept > our license." Or something like it was before... I hope you take this into > consideration... > > And also, when is a new release due? So we can release Gentoo 1.4 with full > and working pyQT support for QT 3.1. > > Thanks in advance! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE98TYveAVt8Tl/2kURArhHAJ9yccagQCMF32TznQ7QdkuaEn+mVwCcC7wk hh0WNG33245u6omJ3ckLkNs= =XOWe -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] destructor not getting called?
On Friday 08 November 2002 07:42, Kaleb Pederson wrote: On Thursday 07 November 2002 10:14 pm, Boudewijn Rempt wrote: > > > Hmmm... What I do is to create a Python class with the settings as member > variables. That makes it easier. But still, the Qt documentation says: > > A typical usage pattern for application exit or 'save preferences': > >QSettings settings; >settings.insertSearchPath( QSettings::Windows, "/MyCompany" ); >// No search path needed for Unix; see notes further on. >settings.writeEntry( "/MyApplication/background color", bgColor ); >settings.writeEntry( "/MyApplication/geometry/width", width ); >// ... > > So, depending on the destructor is not the only way to go. I agree that it shouldn't be the only way to go. I would definitely prefer to have a function that I can call that would write to disk. The source code reveals, however, that a sync() call is only done in the destructor. In fact, I have almost exactly what you mentioned. I have a class that wraps it and provides some convenience functions for me. I added in some print statements so I *know* that settings.write[Num]Entry is getting called with all the correct values. I guess my main question is, therefore, if I have a reference to a PyQt object, in this case QSettings, and at the close of my program the destructor never gets called for the PyQt object, then there _must_ be a memory leak if any memory whatsoever is allocated by that PyQt object. Is there a way that I can purposefully circumvent the destructor of a PyQt object? In my application, I simply let the module level global go out of scope assuming that the destructor would get called; it never does. Under *nix, has anyone ever seen QSettings actually write to the settings file upon a write[Num]Entry? I have monitored the file for existence upon a new write[Num]Entry and for changes upon a write[Num]Entry and None have ever been made until the object goes out of scope. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] destructor not getting called?
>On Fri, 2002-11-08 at 01:50, Kaleb Pederson wrote: >> I'm using a global QSettings object throughout my application. For some >> reason, when the program closes, the destructor on my QSettings object is >not > getting called. As it is the destructor that actually writes everything >to >> disk (in order to cache the data), none of my settings are getting saved. >Can >> I manually call it? I'm pretty sure that this used to work on previous >> PyQt/Qt versions. > > The reason you're having problems is most likely because there is no > such thing as a destructor in Python. I assume that you, like many > before you, are treating the __del__() method as a destructor but the > reality is there is no guarantee that __del__() will be called on > program exit. The Python Language Reference recommends that you only use > __del__() methods to "do the absolute minimum needed to maintain > external invariants". See > http://www.python.org/doc/current/ref/customization.html for more > information. That was not one of my assumptions in this case. I'm using a module level global that contains a reference to my wrapped QSettings class wherein a member variable is assigned the QSettings object. My only assumption was that once the reference count hit zero, that PyQt would call the destructor of the C++ object to avoid any memory leaks. I never explicitly call delete on the object; instead, I simply let it go out of scope at application close. Thanks for the link though. As Python has a GC, writing the __del__ call has never been a priority to me. In fact, I never considered it the destructor of an object but merely a suggestion to the GC. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] destructor not getting called?
>> I agree that it shouldn't be the only way to go. I would definitely >> prefer to have a function that I can call that would write to disk. The >> source code reveals, however, that a sync() call is only done in the >> destructor. > >I've never had a problem with lost settings, so I guess the writeEntry >method does what it needs to. I've attached the complete guiconfig.py >class. Thanks for attaching it. What you have done is almost no different then what I did. We are both wrapping the class and using a module level global. I have no problem with Trolltech's design. In a case like this, however, I need to be guaranteed that the destructor will get called, and I don't know how to guarantee that. >> I guess my main question is, therefore, if I have a reference to a PyQt >> object, in this case QSettings, and at the close of my program the >> destructor never gets called for the PyQt object, then there _must_ be a >> memory leak if any memory whatsoever is allocated by that PyQt object. >> > >No, it doesn't have to be a memory leak. If the process ends, the OS >will reclaim all the memory. It can do that without calling destructors, >after all, the process doesn't run anymore. True. I guess I always considered it a memory leak since certain buggy OS's didn't necessarily reclaim that memory. >> Under *nix, has anyone ever seen QSettings actually write to the >> settings file upon a write[Num]Entry? I have monitored the file for >> existence upon a new write[Num]Entry and for changes upon a >> write[Num]Entry and None have ever been made until the object goes out >> of scope. > >Maybe I was just lucky, and have the QSettings object call the destructor. >Anyway, it's one part of my application where I've never had problems. Maybe. My settings had been working great for the last couple months, as far as I know, and they still work great in Windows. That's why I'm curious to test out under a different version of PyQt. --Kaleb PS: Sorry for my initial response not making it to the list, I sent it using my work account, which isn't subscribed. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] destructor not getting called?
On Thursday 07 November 2002 10:14 pm, Boudewijn Rempt wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > It might be my Java heritage, but I've never trusted destructors... > Couldn't you just connect the LastWindowClosed signal to the save method? > Why I personally to is to write the settings whenever a main window is > closed, from the closeEvent. > For efficiency reasons, QSettings caches all changes that are made using write[Num]Entry(...). The only time that it gets written to disk is when the destructor is called (which calls sync(), the method they have defined for writing to disk). The destructor is the only publicly accessible function for writing to disk. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] destructor not getting called?
I'm using a global QSettings object throughout my application. For some reason, when the program closes, the destructor on my QSettings object is not getting called. As it is the destructor that actually writes everything to disk (in order to cache the data), none of my settings are getting saved. Can I manually call it? I'm pretty sure that this used to work on previous PyQt/Qt versions. Any idea what might be happening? I'm going to try to test it under a different system and will let you know. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] BUG - disconnect
On Wednesday 06 November 2002 04:00 pm, Phil Thompson wrote: > > > > > > Thanks. Although it isn't usually necessary, it will be nice to have. > > There is a bug in PyQt with respect to connections being removed when the > > associated object has been deleted. But I'll try to post some example > > code within the week. > > > > Basically, if I create a parentless object and connect signals to it. > > Upon deletion of the object, any signals that would thereafter have gone > > to it result in a sip runtime error saying the C++ object has been > > deleted. > > This should now be fixed in tonight's SIP snapshot. You should re-build > PyQt with the new version. > > Phil Thank you. It will help a lot. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Request for mugshots
Gee, I'm being voluteered for things ;) If we do get you some mugshots, what resolution would you like the jpg's in, and is there a preferred image size? Are you just looking for thumbnails? Greg, I can provide any screenshots -- windows / linux -- if you like. --Kaleb On Tuesday 05 November 2002 01:28 pm, Greg Fortune wrote: > I'll try to get it setup on a windows box here so I can send you a couple > of shots. Also, if you are mentioning names, please attach Kaleb Pederson > to the Auto Auction stuff. He's responsible for maintaining all the GUI > related stuff :) ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] BUG - disconnect
On Monday 04 November 2002 05:59 am, Kaleb Pederson wrote:
> Thanks. Although it isn't usually necessary, it will be nice to have.
> There is a bug in PyQt with respect to connections being removed when the
> associated object has been deleted. But I'll try to post some example code
> within the week.
>
> Basically, if I create a parentless object and connect signals to it. Upon
> deletion of the object, any signals that would thereafter have gone to it
> result in a sip runtime error saying the C++ object has been deleted.
I just posted a message on the list and forgot to include an attachment. Here
it is.
--Kaleb
#!/usr/bin/python
from qt import *
import sys
class MyDialog(QDialog):
def __init__(self,id = 0,parent = None,name = "MyDialog",modal=0,fl=0):
QDialog.__init__(self,parent,name,modal,fl)
self.id = id
self.count = 0
self.keep_ref = {}
self.setCaption("Testing" + str(id))
main_layout = QVBoxLayout(self,11,6,"main_layout")
self.button1 = QPushButton(self,"button1")
self.button1.setText(u'&Launch')
main_layout.addWidget(self.button1)
self.connect(self.button1,SIGNAL("clicked()"),self.launch)
self.button2 = QPushButton(self,"button2")
self.button2.setText(u'&Fire')
main_layout.addWidget(self.button2)
self.connect(self.button2,SIGNAL("clicked()"),self.fire)
self.button3 = QPushButton(self,"button3")
self.button3.setText(u'&Quit')
main_layout.addWidget(self.button3)
self.connect(self.button3,SIGNAL("clicked()"),self,SLOT("accept()"))
def caught(self):
print "dlg %i caught 'fire()' signal" % self.id
def fire(self):
self.emit(PYSIGNAL("fire()"), () )
def closeEvent(self,event):
print "dlg %i is closing" % self.id
self.emit(PYSIGNAL("closing(id)"),(self.id,))
event.accept()
def accept(self):
self.emit(PYSIGNAL("closing(id)"),(self.id,))
QDialog.accept(self)
def cleanup(self,id):
print "cleaning up id %i" % id
if id in self.keep_ref.keys():
del self.keep_ref[id]
print "references remaining:",self.keep_ref
def launch(self):
# keep a reference so it doesn't get destroyed
dlg = MyDialog(self.count) # no parent
self.connect(self,PYSIGNAL("fire()"),dlg.caught)
# it works fine unless this signal is connected
self.connect(self,PYSIGNAL("fire()"),dlg, SLOT("close()"))
self.connect(dlg,PYSIGNAL("closing(id)"),self.cleanup)
self.keep_ref[self.count] = dlg
self.count += 1
dlg.show()
qapp = QApplication(sys.argv)
mw = MyDialog()
qapp.setMainWidget(mw)
mw.show()
sys.exit(mw.exec_loop())
Re: [PyKDE] BUG - disconnect
> Thanks. Although it isn't usually necessary, it will be nice to have. > There is a bug in PyQt with respect to connections being removed when the > associated object has been deleted. But I'll try to post some example code > within the week. > > Basically, if I create a parentless object and connect signals to it. Upon > deletion of the object, any signals that would thereafter have gone to it > result in a sip runtime error saying the C++ object has been deleted. Okay, I modified my previous example to show what is happening. I highly doubt this is my fault, but if it is, I'm sure you'll correct me ;) I ran it through gdb to see where it was dieing... the last few items in the backtrace gave me the following: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 12956)] 0x4141e740 in lazyMethods_QObject () from /usr/lib/python2.2/site-packages/libqtcmodule.so (gdb) bt #0 0x4141e740 in lazyMethods_QObject () from /usr/lib/python2.2/site-packages/libqtcmodule.so #1 0x0202 in ?? () #2 0x4001f05c in parsePass2 () from /usr/lib/python2.2/site-packages/libsip.so #3 0x4001e89f in sipParseArgs () from /usr/lib/python2.2/site-packages/libsip.so #4 0x413ace9f in sipDo_QWidget_close () from /usr/lib/python2.2/site-packages/libqtcmodule.so #5 0x080d86fd in PyCFunction_Call () #6 0x080b62be in PyObject_Call () #7 0x0807f350 in PyEval_CallObjectWithKeywords () ... Note. If I comment out line 64 then the program works fine and won't segfault. To reproduce what I did, leave line 64 in and then launch the program. Hit "Launch" as many times as you like. Now hit "Fire". All the "child" (although parentless) objects get closed/deleted. Now hit "Fire" a second time. Boom! Another way to reproduce it is to create some child objects by hitting launch. Now close the child objects so they get deleted appropriately. Once all child objects are closed, hit "Fire". Well, please let me know what you find. Even if there is just a work around, it would be nice to know. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] BUG - disconnect
On Sunday 03 November 2002 12:13 pm, Phil Thompson wrote: > On Tuesday 29 October 2002 12:46 am, Kaleb Pederson wrote: > > Disconnect doesn't seem to work as expected. > > > > > > > > which are all very similar to the documentation examples. SIP can't seem > > to tell which method really should be called, and None and 0 aren't > > accepted as valid wild cards so I can't really give it the parameters > > that I need. > > It just isn't supported. I've updated the TODO list and the documentation. Thanks. Although it isn't usually necessary, it will be nice to have. There is a bug in PyQt with respect to connections being removed when the associated object has been deleted. But I'll try to post some example code within the week. Basically, if I create a parentless object and connect signals to it. Upon deletion of the object, any signals that would thereafter have gone to it result in a sip runtime error saying the C++ object has been deleted. --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Python references and the GC
My object _definitely_ gets garbage collected if I don't add that in
(using Python 2.2.1). As soon as my function completes that creates my
modeless/parentless dialog my newly created dialog just flashes on the
screen before it is destroyed. Adding self._keep = self keeps the form
in existence.
Although I can't the messages/webpage that originally gave me this idea,
but I didn't see another good way to do this other than keeping a list
of "alive" objects in the parent and then deleting the given object upon
receipt of a closing signal.
--Kaleb
-Original Message-
From: Mikael Schönenberg [mailto:micke@;ratthing-b3cd.strakt.com] On
Behalf Of Mikael Schönenberg
Sent: Wednesday, October 30, 2002 12:54 AM
To: Kaleb Pederson
Cc: [EMAIL PROTECTED]
Subject: Re: [PyKDE] Python references and the GC
On Tue, 29 Oct 2002, Kaleb Pederson wrote:
> I have a class similar to the below that keeps a reference to itself
so that
> it doesn't get garbage collected.
If my understanding of Python's garbage collection is what I hoped it
was,
your assumption here is rather optimistic.
In essence, if I understand things correctly, the garbage collector is
"smart" in the way that it will identify cyclic references of otherwise
inaccessible objects. Beazley's "Python Essential Reference" illustrates
this with the following example:
a = {}
b = {}
a['b'] = b
b['a'] = a
del a
del b
Now, since the dictionaries refer to eachother, the reference count of
both is indeed greated than 0, but since the objects are not accessible
from any other namespace, the garbage collector will trash them anyhow.
Not digging further into the rest of your code, I believe that this is
what bit you. Keep a reference to the dialog elsewhere, and don't rely
on
it staying alive by just having the line:
self._keep = self
/micke
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Python references and the GC
I have a class similar to the below that keeps a reference to itself so that
it doesn't get garbage collected.
class sample(qdialog):
def __init__(...):
qwidget.__init__(...)
self._keep = self
...
def closeEvent(self,event):
self._keep = None
...
class ...(QWidget):
def myfunc(self):
inst = sample(0,name,FALSE) # created so its modeless with no parent
self.connect(self,PYSIGNAL("closing()"),inst.closeMe)
return
When should I delete the reference to the object? When WDestructive close is
passed as a parameter I get the following:
Traceback (most recent call last):
File "/home/kibab/.../src/gui/MainInterfaceImpl.py", line 1346, in
closeEvent
self.emit(PYSIGNAL("closeChild()"),() )
RuntimeError: Underlying C/C++ object has been deleted
However, the documentation says:
"Note that when a slot is a Python callable object it's reference count is not
increased. This means that a class instance can be deleted without having to
explicitly disconnect any signals connected to its methods."
(http://www.riverbankcomputing.co.uk/pyqt/docs/x225.html).
Disconnecting doesn't work, however, per my last post.
What do other people do when they want to have a modeless non-parented dialog?
Thanks.
--Kaleb
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] BUG - disconnect
Disconnect doesn't seem to work as expected.
Per the Qt documentation (qobject.html#disconnect) I should be able to
disconnect signals as follows.
I've tried various methods:
def sigDiscon(self):
self.disconnect() # Test 1
#QObject.disconnect(self,0,0,0) # Test 2 - or None,None,None
#self.disconnect(PYSIGNAL("fireAway")) # Test 3
#self.disconnect(SIGNAL("clicked()")) # Test 4
#QObject.disconnect(self,SIGNAL("clicked()")) # Test 5
#QObject.disconnect(self,SIGNAL("clicked()"),0) # Test 6 - or None
#QObject.disconnect(self,PYSIGNAL("fireAway")) # Test 7
which are all very similar to the documentation examples. SIP can't seem to
tell which method really should be called, and None and 0 aren't accepted as
valid wild cards so I can't really give it the parameters that I need.
I've attached an example that demonstrates the above.
--Kaleb
#!/usr/bin/python
from qt import *
import sys
class MyDialog(QDialog):
def __init__(self,parent = None,name = "MyDialog",modal=0,fl=0):
QDialog.__init__(self,parent,name,modal,fl)
self.setCaption("Testing")
main_layout = QVBoxLayout(self,11,6,"main_layout")
self.button1 = QPushButton(self,"button1")
self.button1.setText(u'fire')
main_layout.addWidget(self.button1)
self.connect(self.button1,SIGNAL("clicked()"),self.fire)
self.connect(self.button1,SIGNAL("clicked()"),self.fireAway)
self.button2 = QPushButton(self,"button2")
self.button2.setText(u'disconnect')
main_layout.addWidget(self.button2)
self.connect(self.button2,SIGNAL("clicked()"),self.sigDiscon)
self.button3 = QPushButton(self,"button3")
self.button3.setText(u'Quit')
main_layout.addWidget(self.button3)
self.connect(self.button3,SIGNAL("clicked()"),SLOT("accept()"))
def sigDiscon(self):
self.disconnect() # Test 1
#QObject.disconnect(self,0,0,0) # Test 2 - or None,None,None
#self.disconnect(PYSIGNAL("fireAway")) # Test 3
#self.disconnect(SIGNAL("clicked()")) # Test 4
#QObject.disconnect(self,SIGNAL("clicked()")) # Test 5
#QObject.disconnect(self,SIGNAL("clicked()"),0) # Test 6 - or None
#QObject.disconnect(self,PYSIGNAL("fireAway")) # Test 7
def fireAway(self):
self.fire("fireAway")
def fire(self,msg = u"Message"):
mb = QMessageBox(self,"mb")
mb.setCaption(u"Caption")
mb.setText(msg)
mb.exec_loop()
qapp = QApplication(sys.argv)
mw = MyDialog()
qapp.setMainWidget(mw)
mw.show()
sys.exit(mw.exec_loop())
Re: [PyKDE] Borderless Window with SuSE 8.0 Linux
Make sure that your parent widget work doesn't enforce certain window flags. Depending on the parent widget, it doesn't matter what flags you pass in. This works for me: splash = SplashScreen.SplashScreen(None, "splash", Qt.WDestructiveClose | Qt.WStyle_Customize | Qt.WStyle_NoBorder | Qt.WX11BypassWM | Qt.WStyle_StaysOnTop) --Kaleb On Monday 23 September 2002 03:25 pm, Miller, Douglas wrote: > Can anyone recommend an easy way to get a borderless window with SuSE 8.0 > Linux? Qt.WStyle_NoBorder has no effect and in Qt 3.0.5 > Qt.WStyle_NoBorderEx is obsolete. Thanks. > > > ___ > PyKDE mailing list[EMAIL PROTECTED] > http://mats.gmd.de/mailman/listinfo/pykde ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] ANNOUNCING PyQwt-sip34_20020807 - some problems on Win32
On Thursday 19 September 2002 01:01 am, Phil Thompson wrote: > > I am happy to send you the the binary PyQwt windows installer and zip > > builds for the Qt3.0.5 commercial if you want to put them on your > > website. For a binary-only release, according the the commercial qt > > license, I see no problem with sending you also the qt-mt305.dll > > (without the souce of course) so you can run and test the commercial > > version of the win32 PyQwt package yourself. > > Then you need to read your Qt license more closely. Gerard would then > become a developer as far as Trolltech (and I) were concerned and would > need a commercial Qt license (and a commercial PyQt license of course). > > When I've been in this situation in the past, it's been done with me being > given a remote login to the "donor's" development system, and I've asked > for confirmation in writing that the "donor" has the necessary Qt > commercial license in place. > > Phil I haven't yet had to worry about it, but how is a release typically done that uses PyQt? To include the dll and a pyqt build makes them a developer so that won't work. In C++ I presume you would just statically compile the parts of qt that were necessary into your application? Is there a way that you can statically compile the necessary parts of Qt into PyQt? Even if that were so, it doesn't seem like that would stop them from using the parts that were compiled in should they install Python? --Kaleb ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
