[Twisted-Python] twisted and PyQt4
Hi, it seems to me, there is no reactor for PyQt4 yet. What is the preferred way to have a PyQt4 application using the famous twisted framework for networking. Thanks for any hints. Karl
On Tue, 30 May 2006 17:05:08 +0200 (CEST), scalet@yebu.de wrote:
Hi,
it seems to me, there is no reactor for PyQt4 yet. What is the preferred way to have a PyQt4 application using the famous twisted framework for networking.
Thanks for any hints.
Someone will have to write one. Qt4 has numerous improvements which should make it possible to write a reasonable reactor, instead of a shambling horror (like the existing Qt reactor). However, I don't use Qt myself, and I don't know any Twisted developers who do. If there are a sufficient number of Twisted users who are interested in this, it may be possible to add support. One way of demonstrating that there is enough interest would be to have someone donate a buildslave to run tests with Qt. This would be easier for PyQt4 than it is for the current Qt reactor, since PyQt4 won't necessarily require an X11 server to run the test suite. Jean-Paul
Someone will have to write one. Qt4 has numerous improvements which should make it possible to write a reasonable reactor, instead of a shambling horror (like the existing Qt reactor).
I use twisted with a pyQt4 app, so I created a more or less functional port of the current qt recator to qt4. I have attached it for anybody who needs a quick fix, but I don't claim to have taken advantage of Qt4's cleaner architecture and many improvements but I have tested it on both windows and linux and it seems to work ok. You are right that there should be a GUI and non-GUI qt4 reactor options and it may not even be that hard to code if someone has the time and the tests. --gabe
On Tue, 2006-05-30 at 10:14 -0600, Gabe Rudy wrote:
Someone will have to write one. Qt4 has numerous improvements which should make it possible to write a reasonable reactor, instead of a shambling horror (like the existing Qt reactor).
I use twisted with a pyQt4 app, so I created a more or less functional port of the current qt recator to qt4. I have attached it for anybody who needs a quick fix, but I don't claim to have taken advantage of Qt4's cleaner architecture and many improvements but I have tested it on both windows and linux and it seems to work ok. You are right that there should be a GUI and non-GUI qt4 reactor options and it may not even be that hard to code if someone has the time and the tests.
Cool! Could you please open an issue in the tracker with this attached?
Cool! Could you please open an issue in the tracker with this attached?
Alright it's ticket #1770 [1], although I must admit that I have lost a bit of confidence in the cacual coders (me) ability to contribute to Twisted as my previous attempt to post a patch[2] has been wholly ignored for a month, even after a bit of nagging. Maybe this is just the timeline in which people get around to things, or maybe this is a symptom to the everything has a branch/review/merge methodology. [1] http://twistedmatrix.com/trac/ticket/1770 [2] http://twistedmatrix.com/trac/ticket/1324
On 5/30/06, Gabe Rudy <rudy@goldenhelix.com> wrote:
Alright it's ticket #1770 [1], although I must admit that I have lost a bit of confidence in the cacual coders (me) ability to contribute to Twisted as my previous attempt to post a patch[2] has been wholly ignored for a month, even after a bit of nagging. Maybe this is just the timeline in which people get around to things, or maybe this is a symptom to the everything has a branch/review/merge methodology.
Trust me, ticket response time has improved a *lot* since we've switched to this development model. If we haven't responded to previous tickets, it's because a) no developers with the expertise required were available for review; b) the change is controversial or incorrect, or c) the change didn't include sufficient unit tests. Besides, I'm not sure why you're mentioning this, as you don't even seem to be suggesting we include your qt reactor in Twisted since it's untested and not using the new qt4 techniques. Or are you? -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/
On Tue, 30 May 2006 19:13:46 -0400, Christopher Armstrong <radix@twistedmatrix.com> wrote:
Trust me, ticket response time has improved a *lot* since we've switched to this development model.
That certainly seems to be the case, at least subjectively speaking - do we actually have any metrics on this though? It'd be kind of neat to plot a graph.
If we haven't responded to previous tickets, it's because a) no developers with the expertise required were available for review; b) the change is controversial or incorrect, or c) the change didn't include sufficient unit tests.
Generally it's (a), or that the ticket didn't even get noticed. Trac generates a nonstop flood of email to dozens of people and I'm sure most of it gets deleted without being read.
Besides, I'm not sure why you're mentioning this, as you don't even seem to be suggesting we include your qt reactor in Twisted since it's untested and not using the new qt4 techniques. Or are you?
He has *another* ticket which didn't get merged... (it has test cases even). It was itamar who requested he put the qt stuff into the tracker.
On Tue, 30 May 2006 15:13:30 -0600, Gabe Rudy <rudy@goldenhelix.com> wrote:
Cool! Could you please open an issue in the tracker with this attached?
Alright it's ticket #1770 [1], although I must admit that I have lost a bit of confidence in the cacual coders (me) ability to contribute to Twisted as my previous attempt to post a patch[2] has been wholly ignored for a month, even after a bit of nagging. Maybe this is just the timeline in which people get around to things, or maybe this is a symptom to the everything has a branch/review/merge methodology.
[1] http://twistedmatrix.com/trac/ticket/1770 [2] http://twistedmatrix.com/trac/ticket/1324
My apologies. These both look like pretty good reports and they should be reviewed soon. As far as the process being the bottleneck - it's not the process, we just don't have enough manpower. There are currently 619 open tickets in Twisted, and only 11 maintainers. We're overwhelmed. New tickets can't always get the attention they deserve. This isn't particular to Twisted's process - your tickets would require review in pretty much any open source project. (BTW, reviewers; if you are reviewing patches from external contributors, you *don't* need to create branches first. If the branch passes review, simply comment on the ticket and reference it in the commit message.) The easiest way to get a branch reviewed is to look for a reviewer on #twisted on Freenode in real-time. If you make a point of mentioning that your code already includes test-cases, it will probably get reviewed faster. If you want to get your contributed feature-additions to get reviewed and merged REALLY fast, go through the tracker and write patches which fix existing bugs for a while. You will have dedicated maintainers practically at your beck and call ;).
I have a problem I am trying to solve and hope that someone can see an obvious way (particularly since I am new with Twisted). My system is composed of 4 different services: an ftp server, a multicast server, a XML-RPC facility and a service made of a proprietary protocol. The problem I am having is when I shut down the system I have to close down nicely which means that I have to send out a few "I am leaving" messages, etc. The issue is that I can terminate because I get an RPC shutdown request, but also the service getting a SIGINT. Is there some convenient "Twisted" way to capture sigint (or any signals) and route them to shutdown services in my application? Thanks in advance, Chaz.
On 6/8/06, Chaz. <eprparadocs@gmail.com> wrote:
The issue is that I can terminate because I get an RPC shutdown request, but also the service getting a SIGINT. Is there some convenient "Twisted" way to capture sigint (or any signals) and route them to shutdown services in my application?
The stopService() method is called on your service instances, so that is where you must do the clean up. Eric.
I have an application that I am converting to Twisted. One of the things the application does is have three different logs running. Each of the three does something different. In normal python logging I figured out how to have the three different loggers. In Twisted I am not quite sure how to do it. Has someone done this before? Thanks, Chaz.
On 6/10/06, Chaz. <eprparadocs@gmail.com> wrote:
I have an application that I am converting to Twisted. One of the things the application does is have three different logs running. Each of the three does something different.
In normal python logging I figured out how to have the three different loggers. In Twisted I am not quite sure how to do it. Has someone done this before?
You want to write a class or function that will receive a dictionary with 'system', 'message', and possibly 'failure', 'isError', 'debug' and 'printed', and take appropriate action. You may wish to have a look at twisted.python.log.FileLogObserver. Once you have the function or method, you can do a log.addLogObserver(function). You can pass things on to the eventDict as keywords to log.msg, log.error, and log.debug (though the last one is deprecated). If you find that isn't enough for you, it's possible to replace the LogPublisher with something that can gather more data, I currently use one that inspects the stack for which module called it, for example. Moof
Thanks but I think that answers the wrong question. In my original application I have three different named loggers (the original app is written in Python). I have logOp, logTrace, logDebug each of which goes somewhere different (for instance logOp messages go to the operators system, logDebug is sent to a non-rotated file and logTrace goes to a rotating log file). Through out my application I will log message to the appropriate logger, for example messages that I want written out to the debug file I write as logDebug.msg(...). Those that I want to trace objects moving around I will do logDebug.info(...). etc. In Twisted.python.log it looks like there is a single logger and I do: log.startLogging(...). What I need to know is how can I create three different loggers in my new application. Do I need to subclass some twisted class? Chaz. Moof wrote:
On 6/10/06, Chaz. <eprparadocs@gmail.com> wrote:
I have an application that I am converting to Twisted. One of the things the application does is have three different logs running. Each of the three does something different.
In normal python logging I figured out how to have the three different loggers. In Twisted I am not quite sure how to do it. Has someone done this before?
You want to write a class or function that will receive a dictionary with 'system', 'message', and possibly 'failure', 'isError', 'debug' and 'printed', and take appropriate action. You may wish to have a look at twisted.python.log.FileLogObserver. Once you have the function or method, you can do a log.addLogObserver(function).
You can pass things on to the eventDict as keywords to log.msg, log.error, and log.debug (though the last one is deprecated). If you find that isn't enough for you, it's possible to replace the LogPublisher with something that can gather more data, I currently use one that inspects the stack for which module called it, for example.
Moof
On 6/10/06, Chaz. <eprparadocs@gmail.com> wrote:
Thanks but I think that answers the wrong question. In my original application I have three different named loggers (the original app is written in Python). I have logOp, logTrace, logDebug each of which goes somewhere different (for instance logOp messages go to the operators system, logDebug is sent to a non-rotated file and logTrace goes to a rotating log file). Through out my application I will log message to the appropriate logger, for example messages that I want written out to the debug file I write as logDebug.msg(...). Those that I want to trace objects moving around I will do logDebug.info(...). etc.
In Twisted.python.log it looks like there is a single logger and I do: log.startLogging(...). What I need to know is how can I create three different loggers in my new application. Do I need to subclass some twisted class?
The twisted log system has a single "log publisher", known as twisted.python.log.theLogPublisher. This publisher will receive all log messages and add certain essential informaion, and create something called an eventDict. It then passes all eventDict to every LogObserver registered with it. This allows for a central location to receive log messages that decouples potentially slow, blocking, file writing or network sending of log messages from the rest of the asynchronous framework. log.StartLogging(file) literally creates a FileLogObeserver for the file called flo, and then calls StartLoggignWithObserver(flo.emit). You want to create an equivalent to a FileLogObserver, or just subclass it. You can chose to ignore certain messages by checking for flags in the eventDict, and just returning from the method, or you can write it to a file, or send it over the network or whatever. Moof
On Sat, 2006-06-10 at 09:19 -0400, Chaz. wrote:
In normal python logging I figured out how to have the three different loggers. In Twisted I am not quite sure how to do it. Has someone done this before?
I'd suggest continuing using Python's logging module (just don't use its socket or db backends, as they will block your app). -- Itamar Shtull-Trauring http://itamarst.org
participants (9)
-
Chaz. -
Christopher Armstrong -
Eric Faurot -
Gabe Rudy -
glyph＠divmod.com -
Itamar Shtull-Trauring -
Jean-Paul Calderone -
Moof -
scalet＠yebu.de