
the a standard reactor in a seperate thread. That situation is less
than
satisfactory for us, so I may pick this up.
Any other PyQt+Twisted users out there?
Yes, very actively. But, it seems to be working fine. I'm using 1.3.0 of Twisted, with the qtreactor, and have not seen any failures from it. What about it is broken? (Or does this apply specifically to 2.0?) Peace, Gary This e-mail message is intended only for the personal use of the recipient(s) named above. This message should be considered a confidential communication, and as such is not subject to disclosure to anyone who is not an intended recipient. If you are not an intended recipient, you may not legally review, copy or distribute this message. If you have received this communication in error, please notify the sender(s) immediately by e-mail and delete the original message from your computer system.

On Thu, 18 Nov 2004 09:32:01 -0500, "Gary Coulbourne" <GCoulbourne@Immunicon.com> wrote:
the a standard reactor in a seperate thread. That situation is less than satisfactory for us, so I may pick this up. =20 Any other PyQt+Twisted users out there?
Yes, very actively. But, it seems to be working fine. I'm using 1.3.0 of Twisted, with the qtreactor, and have not seen any failures from it. What about it is broken? (Or does this apply specifically to 2.0?)
Have you tried the unit tests? Run `trial --reactor qt -R twisted'. I doubt anyone's done this in a long time, so I'm not sure what will happen, but the last time I saw it run, the results weren't pretty. The tests which fail should give you some idea of what functionality doesn't work with Qt (or perhaps just which tests incorrectly depend on unspecified behavior from the default reactor which the Qt reactor does not provide). Jp

On Thu, 2004-11-18 at 15:33 +0000, Jp Calderone wrote:
Have you tried the unit tests? Run `trial --reactor qt -R twisted'. I doubt anyone's done this in a long time, so I'm not sure what will happen, but the last time I saw it run, the results weren't pretty. The tests which fail should give you some idea of what functionality doesn't work with Qt (or perhaps just which tests incorrectly depend on unspecified behavior from the default reactor which the Qt reactor does not provide).
I suspect the Qt reactor is perfectly fine, and that the main issue is with running tests. Like, reactor.iterate() taking way too long or something. I don't think these issues will show up when running real applications.

On Nov 18, 2004, at 11:13 AM, Itamar Shtull-Trauring wrote:
I suspect the Qt reactor is perfectly fine, and that the main issue is with running tests. Like, reactor.iterate() taking way too long or something. I don't think these issues will show up when running real applications.
But of course, we'd never know, because we have no way to test that. Apparently self.qApp.processEvents(delay) (what's used in doIteration) isn't processing network events. Thus reactor.iterate() doesn't work for anything network-related, and nearly every test fails. Changing doIteration to: def doIteration(self, delay=0.0): log.msg(channel='system', event='iteration', reactor=self) self.callLater(delay, self.crash) self.run() seems to help a lot. But it's still failing a bunch of tests. Perhaps this gives someone who wants to maintain qtreactor a head start at figuring out how to fix it the rest of the way. James

On Thu, 2004-11-18 at 13:17 -0500, James Y Knight wrote:
Changing doIteration to: def doIteration(self, delay=0.0): log.msg(channel='system', event='iteration', reactor=self) self.callLater(delay, self.crash) self.run()
seems to help a lot. But it's still failing a bunch of tests. Perhaps this gives someone who wants to maintain qtreactor a head start at figuring out how to fix it the rest of the way.
If it helps enough to get it to not freeze or take hours to do tests, check it in. We can start a qt buildbot and start fixing incrementally.
participants (4)
-
Gary Coulbourne
-
Itamar Shtull-Trauring
-
James Y Knight
-
Jp Calderone