Mailman 3 April 2004 - Twisted

[Twisted-Python] Twisted Python 0.7.0 Prerelease Testing
by Glyph Lefkowitz 05 Aug '21

05 Aug '21

hi there, folks: I'd really like to release 0.7.0 but I would like it to be at least a little bit tested before I do so. Could those of you with CVS trees check everything out and see if it performs as advertised? Deeper bugs than that will have to wait for the next release, but I'd at least like to know if it works for someone other than me. Thanks. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/

4 5

[Twisted-Python] twisted on os x: cfreactor or kqreactor?
by rayg 07 May '04

07 May '04

i just created a fink package for PyKQeue (http://sourceforge.net/tracker/index.php?func=detail&aid=940552&group_id=17…) and this now allows me to use kqreactor. if i'm not not planning on using any cocoa functionality, is there any advantage to use cfreactor over kqreactor on os x? i wasn't able to find any direct comparison between the mechanisms behind kqreactor and cfreactor, but i did see that NSRunLoop is asynchronous, like kqueue. i've tested both reactors on a simple script and noticed cfreactor doesn't stop() 75% of the time, so i'm inclined to just use kqreactor, instead of tracking down why cfreactor isn't behaving...

3 3

[Twisted-Python] Is multicast supported on windows platform?
by Pierre Rouleau 29 Apr '04

29 Apr '04

Hi everyone! I am just starting to learn Twisted. My first attempt is to write a small client app that will join to a multicast group and then read the receive stream. The code would have to run on Windows and *nix. As I'm reading the docs and browsing the code I stumbled across the twisted.internet.udp MulticastMixin docstring that states: class MulticastMixin: """Implement multicast functionality. Initial implementation, probably needs some changes for Windows support. """ My first question therefore: "is multicast supported under Windows?" Thanks for any help. Pierre

2 1

[Twisted-Python] twisted.internet.error.ConnectionDone, Connection was closed cleanly
by Matteo Giacomazzi 29 Apr '04

29 Apr '04

Hi all, in my network (client) application I have to defer an action in a thread using deferToThread. I add an errBack to the deferred returned from the deferToThread in order to handle exceptions and, then, I add a callBack in order to return a response *anyway*. Now the problem: if the thread completes its execution without exception, everything works pretty fine. If an exception happens in the thread, then the errBack is invoked, the callBack is invoked and the transport.write is invoked but... at the end of the chain the protocol receives a "connectionLost" call and the factory receives a "clientConnectionLost" call, both with the reason you can see in the subject. What does it mean? Any help would be greatly appreciated. Python 2.3.3 Twisted 1.2.0 Best regards Matteo

1 1

[Twisted-Python] Zope3 components port status
by Itamar Shtull-Trauring 28 Apr '04

28 Apr '04

All tests pass, except 3 in test_components that test features which we no longer support. I am running my woven app with it right now and meanwhile everything is working great. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html

1 0

[Twisted-Python] Bug in reactor.iterate()?
by Sam Couter 27 Apr '04

27 Apr '04

Twisted version: 1.2.0 Attached is a minimal test case to demonstrate behaviour I consider a bug in reactor.iterate() in the default reactor. You'll need to change the DB name, user and password, and pick a table that exists in your DB. The callbacks are never called while iterate() runs, but are called if iterate() is replaced with run(), or if run() is called after iterate(). Am I correct in considering this a bug? I found this while creating a unit test following the example at the bottom of http://www.twistedmatrix.com/documents/current/howto/test-standard. -- Sam "Eddie" Couter | mailto:sam@couter.dropbear.id.au Debian Developer | mailto:eddie@debian.org | jabber:sam@teknohaus.dyndns.org OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C

2 2

[Twisted-Python] Progress report on splitting packages
by Itamar Shtull-Trauring 27 Apr '04

27 Apr '04

Since Chris didn't send one in. Hope this is accurate. News was split off, backwards compat code is in, site is up: http://projects.twistedmatrix.com/lowdown/ Remaining tasks: 1. Release automation and making a lowdown release. 2. Buildbot support. 3. Linking to projects from main site, and updating main site to explain all this. Many thanks to Chris and JP for all their work on this. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html

14 44

[Twisted-Python] twisted gtk-reactor bug 552
by David E. Konerding DSD Staff 26 Apr '04

26 Apr '04

Hi, I'm checking in again to see if anybody had taken a look at my bug report, http://www.twistedmatrix.com/users/roundup.twistd/twisted/issue552 I discussed it a little bit on a slow day on IRC, but nobody had any solutions. However, it was reproduced on NetBSD-current w/ pygtk-2 and gtk-2.4, so I'm pretty sure it's not specific to my location. In summary: I'm using the gtk2reactor, and periodically scheduled events (invoked via reactor.callLater->reactor.callInThread) are not being fired in a timely fashion. When I originally mentioned the bug on the mailing list, people thought I was calling 'sleep' in the main (reactor) thread, but actually, sleep is only called in another thread, and it works fine with the plain reactor and the wx reactor. Here is the example program (you should see 'TestThingy message' every 0.1 seconds or so..) Note that the bug report has two lines improperly indented. import time, sys from twisted.internet import gtk2reactor gtk2reactor.install() from twisted.python import threadable threadable.init() from twisted.internet import reactor from twisted.python import log log.startLogging(sys.stdout) class TestThingy: def __init__(self): print "TestThingy created" def run(self): print "TestThingy run" for i in range(10): print "TestThingy message" time.sleep(0.1) print "TestThingy done" class ThingyManager: def __init__(self): pass def submitThingy(self): log.err("ThingyManager submitting") f = TestThingy() log.err("ThingyManager created") reactor.callInThread(f.run) log.err("ThingyManager calledInThread") def ticker(*args): log.err("ticker: %d" % time.time()) reactor.callLater(1, ticker) t = ThingyManager() reactor.callLater(0, ticker) reactor.callLater(3, t.submitThingy) reactor.run() log.err("Reactor done") Dave

1 0

[Twisted-Python] The Argument I Lost
by Glyph Lefkowitz 25 Apr '04

25 Apr '04

I was confused by the recent discussion of the recent tmlabs.* hierarchy, so there was a long discussion on IRC tonight about how exactly the various splits are going to proceed. We almost reached a consensus about how things should work, except foom (James Knight) managed to win the argument about how it should work eventually. However, I'm more irritating than he is, so we're still doing things my way. To recap, James's way, which is similar to what was discussed on the list before, is: Keep everything in the same repository, but provide different top-level directories for Twisted and the new split-off packages, e.g. svn://.../trunk/Twisted/twisted/internet/..., svn://.../trunk/TwistedNews/twisted/news/... (previously we were going to keep everything in different repositories, but we agreed that this was unnecessary and came with several unpleasant restrictions) Move code in new subdirectories to the tmlabs.* hierarchy for marketing purposes because it provides a cleaner separation between core and applications. However, I feel that there are lots of other hierarchy reorganizations that are potentially a good idea, and this is another step. Set up buildbot to run application packages against both last-released core and most-current core. My way is: For now... The repository mostly stays how it is. Buildbot keeps running against trunk, but against a series of application packages instead of twisted.test. Package names do not change. Eventually, one or all of these may need to change. However, all that will be happening to split out packages is: Modules in protocols/, test/, and tap/ move to an appropriate top-level package, with backward-compatibility wrapper. The release script will be changed to generate separate tarballs for various top-level packages. We will create a topfiles/ directory or somesuch to contain READMEs, setup.py's, etc., for each subproject. Barring any strong objections, this smaller, simpler plan is now how the releases should proceed. We do still intend to do new websites and download areas for each subproject (sorry maintainers, you're not getting out of writing HTML!), just not new repositories. Hopefully this will be a bit easier on users as we will get decoupled release cycles, but aside from protocols moving, it should require no code changes to remove all import-related deprecation warnings. The main point in this change in plan is to avoid doing too many things at once, to make sure that the whole split finishes before someone implements some crazy new features. Therefore, issues such as how to version APIs, re-organize modules, or re-name packages will be addressed *after* the appropriate changes for this split have been prepared, but feel free to discuss them beforehand. I will be replying to James's setversion proposal soon.

4 5

[Twisted-Python] do you want docs on a simple server to server pb example?
by john nielsen 23 Apr '04

23 Apr '04

Now that I have it working and I don't think it is documented how to have 2 pb servers talk to each other, I am willing to write some documentation for it. Would you want it? john -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

3 2