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

Re: [Twisted-Python] no factory.disconnect used the docs!?! (btw thx Itamar )
by exarkun＠divmod.com 23 Apr '04

23 Apr '04

On Fri, 23 Apr 2004 12:50:58 -0500, "john nielsen" <jn(a)who.net> wrote: >Once Itamar mentioned closing connections, then I realized I needed to add: > > d.addCallback(lambda _: factory.disconnect()) > > The descriptors are now cleaned up. > > An interesting point is that I cannot find any documentation that > actually uses: factory.disconnect() > > Did I miss it? Where in the docs do you see this? There is no such method on factories. You want to call transport.loseConnection() (which is not easily accessible for a PB connection, but it can be reached, see list archives for details on how). Jp

2 1

[Twisted-Python] IFoo(x, persist=1)
by Itamar Shtull-Trauring 23 Apr '04

23 Apr '04

I know this is used a lot (the weakref persistence stuff). Should it be option of adaptation or perhaps of adapter registration? Trying to see how to fit this in to zope3's, which doesn't do this, and it'd be nice to have it as part of their core code rather than ours. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html

4 4

[Twisted-Python] no factory.disconnect used the docs!?! (btw thx Itamar )
by john nielsen 23 Apr '04

23 Apr '04

Once Itamar mentioned closing connections, then I realized I needed to add: d.addCallback(lambda _: factory.disconnect()) The descriptors are now cleaned up. An interesting point is that I cannot find any documentation that actually uses: factory.disconnect() Did I miss it? john ----- Original Message ----- From: twisted-python-request(a)twistedmatrix.com Date: Thu, 22 Apr 2004 12:00:05 -0600 To: twisted-python(a)twistedmatrix.com Subject: Twisted-Python Digest, Vol 1, Issue 1218 > Send Twisted-Python mailing list submissions to > twisted-python(a)twistedmatrix.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > or, via email, send a message with subject or body 'help' to > twisted-python-request(a)twistedmatrix.com > > You can reach the person managing the list at > twisted-python-owner(a)twistedmatrix.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Twisted-Python digest..." > > > Today's Topics: > > 1. Re: Transporting pb.Copyable classes? (exarkun(a)divmod.com) > 2. Re: Transporting pb.Copyable classes? (Jasper Phillips) > 3. Unwinding the Twisted Web (a progress report) (David Reid) > 4. Re: Unwinding the Twisted Web (a progress report) > (Itamar Shtull-Trauring) > 5. how to have a server talk to a server (john nielsen) > 6. Re: how to have a server talk to a server (Eric Mangold) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Apr 2004 18:53:37 GMT > From: <exarkun(a)divmod.com> > Subject: Re: [Twisted-Python] Transporting pb.Copyable classes? > To: "Twisted discussion stuff" <twisted-python(a)twistedmatrix.com> > Message-ID: <20040421185337.9235.1895087205.divmod.quotient.13@ohm> > Content-Type: text/plain > > On Wed, 21 Apr 2004 09:57:47 -0700 (PDT), Jasper Phillips <jasper(a)peak.org> wrote: > > > > [snip] > > > > > > All this seems to me like frantic contortion to avoid a bug in jelly. > > Shouldn't it be able to translate passed class objects into the remote > > version, provided they have been properly registered? Is there some reason > > why not that I am missing? > > Indeed. While I would do this differently, jelly should certainly be able to handle your approach. Let's get into specifics, shall we? Here's some code: > > >>> from twisted.spread import jelly > >>> class Foo: pass > ... > >>> f = Foo() > >>> f.bar = Foo > >>> jelly.jelly(f) > ['__main__.Foo', ['dictionary', ['bar', ['class', '__main__.Foo']]]] > > So far, so good. > > >>> from twisted.spread import pb > >>> class Foo(pb.Copyable): > ... pass > ... > >>> f = Foo() > >>> f.bar = Foo > >>> jelly.jelly(f) > ['__main__.Foo', ['dictionary', ['bar', ['class', '__main__.Foo']]]] > > Hmm, that works too. I expected it not to, actually. I suppose something you're doing with globalSecurity or setCopierForClassTree() may be mucking things up. > > > > > I appreciate the code suggestions, but basicaly I just want to know whether > > this is expected behavior, or whether I should post a demonstrative test > > case and suggest a fix. > > Posting a demonstrative test case would be excellent :) I suspect there is no bug in jelly, just a disagreement in expectations which can easily be resolved once there is a concrete example to talk about. > > Jp > > > > ------------------------------ > > Message: 2 > Date: Wed, 21 Apr 2004 14:03:47 -0700 (PDT) > From: Jasper Phillips <jasper(a)peak.org> > Subject: Re: [Twisted-Python] Transporting pb.Copyable classes? > To: Twisted discussion stuff <twisted-python(a)twistedmatrix.com> > Message-ID: <Pine.LNX.4.53.0404211301540.9678(a)a.shell.peak.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > On Wed, 21 Apr 2004 exarkun(a)divmod.com wrote: > > > On Wed, 21 Apr 2004 09:57:47 -0700 (PDT), Jasper Phillips <jasper(a)peak.org> wrote: > > > > > > All this seems to me like frantic contortion to avoid a bug in jelly. > > > Shouldn't it be able to translate passed class objects into the remote > > > version, provided they have been properly registered? Is there some reason > > > why not that I am missing? > > > > Indeed. While I would do this differently, jelly should certainly be > > able to handle your approach. Let's get into specifics, shall we? > > Here's some code: > > I may end up doing it differently, but one thing at a time! I'm in the > midst of upgrading to new cred, and already have plenty of scope with which > to hang myself. ;-) > > I'm not particularily attached to the static class approach, it just > happened to be what came to mind when prototyping. I'm definitely curious > now what you would do... I've been programming in a vacuum for quite a > while. :-( > > > > >>> from twisted.spread import jelly > > >>> class Foo: pass > > ... > > >>> f = Foo() > > >>> f.bar = Foo > > >>> jelly.jelly(f) > > ['__main__.Foo', ['dictionary', ['bar', ['class', '__main__.Foo']]]] > > > > So far, so good. > > > > >>> from twisted.spread import pb > > >>> class Foo(pb.Copyable): > > ... pass > > ... > > >>> f = Foo() > > >>> f.bar = Foo > > >>> jelly.jelly(f) > > ['__main__.Foo', ['dictionary', ['bar', ['class', '__main__.Foo']]]] > > > > Hmm, that works too. I expected it not to, actually. I suppose > > something you're doing with globalSecurity or setCopierForClassTree() > > may be mucking things up. > > This test case doesn't seem quite right... Why doesn't it fail since Foo > hasn't been registered? Hmmm, looks like jelly()'s taster arg defaults to > DummySecurityOptions()... > > What about registering Foo, and then calling with jelly.globalSecurity?: > ---- Code ---- > from twisted.spread import jelly, pb > > class Foo( pb.Copyable ): pass > jelly.setUnjellyableForClass( Foo, Foo ) > #jelly.globalSecurity.allowInstancesOf( Foo ) # uncomment to fix > > if __name__ == '__main__': > f = Foo() > f.bar = Foo > print jelly.jelly( f, taster=jelly.globalSecurity ) > > ---- End Code ---- > > This gives the Insecure Jelly exception I'm seeing, from jelly.py:482... > However, comment out `f.bar = Foo` or uncomment allowInstancesOf() and it > works. > > Oh, and I'm using twisted 1.2 and python 2.3.3. > > > [snip] > > Posting a demonstrative test case would be excellent :) I suspect there > > is no bug in jelly, just a disagreement in expectations which can easily > > be resolved once there is a concrete example to talk about. > > Is this a decent example? As for a fix, it looks like the solution is there > in SecurityOptions.allowsInstancesOf(), but that it's just not exposed. > > -Jasper > > > > > ------------------------------ > > Message: 3 > Date: Thu, 22 Apr 2004 03:56:47 -0700 > From: David Reid <dreid(a)dreid.org> > Subject: [Twisted-Python] Unwinding the Twisted Web (a progress > report) > To: twisted-python <twisted-python(a)twistedmatrix.com>, twisted-web > <twisted-web(a)twistedmatrix.com> > Message-ID: <1082631407.28634.20.camel@localhost> > Content-Type: text/plain > > I had been trying to straighten out the model for the split since my > first post to twisted-web regarding it. Now that radix, and exarkun > have split twisted.news out of the core codebase as "lowdown". Since > then I have begun work on my own source tree of twisted.web, the module > has been split as "unwound" which is my proposed name as mentioned in > the numerous naming threads (to be installed as tmlabs.unwound if > desired.) > > So far I've done the following: > > * duplicate the source tree renaming the toplevel module and changing > the imports accordingly. > > * run the tests (everything passes just as it does in twisted.web) > > * removed modules that were deprecated BY woven, and added a > Deprecation Warning message to unwound.woven.__init__ > > If there are no complaints about this I'm asking someone (like radix) to > help me complete the rest of the steps necessary to make this the > official split so i can start working on changes and enhancements. The > things I can't do on my own, atleast not as part of twistedmatrix.com is > setup the SVN repo and the project page. > > Also it appears if radix and exarkun did not solve (or atleast did not > implmenet a solution for) the tap naming conflicts. I.E. if lowdown or > tmlabs.lowdown is going to use mktap news or mktap lowdown instead. > > Other than that, Unwound is currently a useable tree of twisted.web At > revision 10601. > > (I'm open to changing the name to either tmlabs.web or some cute/catchy > name other than 'unwound', but ultimately I think that is a policy > decision that falls on the core twisted devs.) > > -- > David Reid > Claim to fame: "I actually wrote code that used twisted.web.webwidgets!" > > > > > ------------------------------ > > Message: 4 > Date: Thu, 22 Apr 2004 11:21:46 -0400 > From: Itamar Shtull-Trauring <itamar(a)itamarst.org> > Subject: Re: [Twisted-Python] Unwinding the Twisted Web (a progress > report) > To: Twisted discussion stuff <twisted-python(a)twistedmatrix.com> > Cc: twisted-web(a)twistedmatrix.com > Message-ID: <1082647306.27964.10.camel@sheriffpony> > Content-Type: text/plain > > On Thu, 2004-04-22 at 06:56, David Reid wrote: > > > So far I've done the following: > > > > * duplicate the source tree renaming the toplevel module and changing > > the imports accordingly. > > >From what I've gathered from talking to Donovan and James this is *not* > how the new twisted.web version is going to be developed. Donovan said > he'd write out a roadmap for the mailing list after talking it over. > > -- > Itamar Shtull-Trauring http://itamarst.org > Looking for a job -- http://itamarst.org/resume.html > > > > > ------------------------------ > > Message: 5 > Date: Thu, 22 Apr 2004 10:46:30 -0500 > From: "john nielsen" <jn(a)who.net> > Subject: [Twisted-Python] how to have a server talk to a server > To: twisted-python(a)twistedmatrix.com > Message-ID: <20040422154630.2989779004F(a)ws1-14.us4.outblaze.com> > Content-Type: text/plain; charset="iso-8859-1" > > I see some examples where you have a client call pb.PBClientFactory to talk to a server which called pb.PBServerFactory. > > What if you have 2 servers (both running pb.PBServerFactory) that accept clients and also want to talk to each other? Would the first server also make a pb.PBClientFactory to talk to the second server (seems like you would have to be careful to not leak descriptors since the reactor would never close). > > There's probably a standard way to do it, that I just missed. > > Thanks for any help, > > john > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > > > ------------------------------ > > Message: 6 > Date: Thu, 22 Apr 2004 11:38:55 -0600 > From: Eric Mangold <teratorn(a)world-net.net> > Subject: [Twisted-Python] Re: how to have a server talk to a server > To: Twisted discussion stuff <twisted-python(a)twistedmatrix.com> > Message-ID: <opr6vcm5nfi4eeqj(a)mail.oaktech.net> > Content-Type: text/plain; format=flowed; charset=iso-8859-1 > > On Thu, 22 Apr 2004 10:46:30 -0500, john nielsen <jn(a)who.net> wrote: > > > I see some examples where you have a client call pb.PBClientFactory to > > talk to a server which called pb.PBServerFactory. > > > > What if you have 2 servers (both running pb.PBServerFactory) that accept > > clients and also want to talk to each other? Would the first server > > also make a pb.PBClientFactory to talk to the second server > > Yes. > > > (seems like you would have to be careful to not leak descriptors since > > the reactor would never close). > > Not sure what you mean by that. > > -Eric > > > > > > ------------------------------ > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python(a)twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > > > End of Twisted-Python Digest, Vol 1, Issue 1218 > *********************************************** > -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

[Twisted-Python] server to server leaking descriptors
by john nielsen 23 Apr '04

23 Apr '04

I'm trying to figure out server to server communication. Here is example code that works but it leaks descriptors until you run out. In this example, the client talks to server1 on port 7000, server1 talks to server2 on 7001, then the client gets the result from server2 on 7001. Server1 uses pb.PBClientFactory() to send data to server2, which is the part that leaks descriptors. What is the appropriate way for a server to talk to a server? Thanks for any info, john ------------ from twisted.spread import pb from twisted.internet import reactor, defer from twisted.python import util import time,random def client(port,fun,react=None,data=None): print 'in client',port,fun,data a=[] factory = pb.PBClientFactory() reactor.connectTCP('localhost', port, factory) d = factory.getRootObject() d.addCallback(lambda object: object.callRemote(fun,data)) d.addCallback(lambda result: a.append(result)) d.addErrback(lambda reason: 'error: '+str(reason.value)) #d.addCallback(util.println) if react: d.addCallback(lambda _: reactor.stop()) reactor.run() if a: print 'returning',a[0] return a[0] #return 1 class adder(pb.Root): Result=None def remote_add(self,i): print 'in add' i+=1 print 'calling add2' client(7001,'add2',react=None,data=i) def remote_add2(self,i): print 'in add2',self.Result i+=1 self.Result=i def remote_result(self,stuff): return self.Result port=raw_input('port?').strip() if port: port=int(port) print 'starting on',port reactor.listenTCP(port, pb.PBServerFactory(adder())) reactor.run() else: client(7000,'add',react=None,data=10) print 'got',client(7001,'result',react=1) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

[Twisted-Python] how to do server to server defined at runtime?
by john nielsen 23 Apr '04

23 Apr '04

I am trying to figure out a way to have a server talk to another server, you do not know about except at runtime. In other words, a client tells the server to talk to another server. I figured about the problem I had earlier, and moving the connectTCP outside of PBServerFactory, fixes that problem, which makes sense since it is now not part of the reacotr. But, then I do not know how to specify who to talk to at runtime. For example in this code, how to I move connectTCP into the adder class? factory = pb.PBClientFactory() reactor.connectTCP('localhost', 7001, factory) d = factory.getRootObject() reactor.listenTCP(port, pb.PBServerFactory(adder(d))) reactor.run() Thanks for any info, john -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

[Twisted-Python] PB and hashed passwords
by Uwe C. Schroeder 23 Apr '04

23 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, just found something in pb (twisted version 1.2.0) that's a bit strange. I've written a credentials checker and set self.credentialInterfaces = (credentials.IUsernamePassword,) So far, so good. However the following error is thrown: No checker for twisted.cred.credentials.IUsernameHashedPassword, twisted.cred.credentials.ICredentials, twisted.spread.pb.IUsernameMD5Password I traced it back to pb._PortalAuthChallenger It only implements hashed and md5 passwords. Maybe I don't get it, but where is the sense in sending a password in cleartext over the wire to then md5 it on the "server" side ? I'd rather md5 it on the client side and send the hash to be compared against the password storage, which also stores a md5. I tried to do this by using plaintext passwords, since the routines then simply compare without md5'ing it, but it doesn't seem to be possible to use plaintext with pb without changing something. Can I user-define a class to jump in there ? Any enlightenment is appreciated. THX UC - -- Open Source Solutions 4U, LLC 2570 Fleetwood Drive Phone: +1 650 872 2425 San Bruno, CA 94066 Cell: +1 650 302 2405 United States Fax: +1 650 872 2417 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAiLQBjqGXBvRToM4RAubrAJ44hBC+PYbcBgiWivFowWjpaEWtaACgnaBV vvfUvfSiBfpJhhifqmvhJfo= =Byjg -----END PGP SIGNATURE-----

4 6

[Twisted-Python] how to have a server talk to a server
by john nielsen 22 Apr '04

22 Apr '04

I see some examples where you have a client call pb.PBClientFactory to talk to a server which called pb.PBServerFactory. What if you have 2 servers (both running pb.PBServerFactory) that accept clients and also want to talk to each other? Would the first server also make a pb.PBClientFactory to talk to the second server (seems like you would have to be careful to not leak descriptors since the reactor would never close). There's probably a standard way to do it, that I just missed. Thanks for any help, john -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

[Twisted-Python] Unwinding the Twisted Web (a progress report)
by David Reid 22 Apr '04

22 Apr '04

I had been trying to straighten out the model for the split since my first post to twisted-web regarding it. Now that radix, and exarkun have split twisted.news out of the core codebase as "lowdown". Since then I have begun work on my own source tree of twisted.web, the module has been split as "unwound" which is my proposed name as mentioned in the numerous naming threads (to be installed as tmlabs.unwound if desired.) So far I've done the following: * duplicate the source tree renaming the toplevel module and changing the imports accordingly. * run the tests (everything passes just as it does in twisted.web) * removed modules that were deprecated BY woven, and added a Deprecation Warning message to unwound.woven.__init__ If there are no complaints about this I'm asking someone (like radix) to help me complete the rest of the steps necessary to make this the official split so i can start working on changes and enhancements. The things I can't do on my own, atleast not as part of twistedmatrix.com is setup the SVN repo and the project page. Also it appears if radix and exarkun did not solve (or atleast did not implmenet a solution for) the tap naming conflicts. I.E. if lowdown or tmlabs.lowdown is going to use mktap news or mktap lowdown instead. Other than that, Unwound is currently a useable tree of twisted.web At revision 10601. (I'm open to changing the name to either tmlabs.web or some cute/catchy name other than 'unwound', but ultimately I think that is a policy decision that falls on the core twisted devs.) -- David Reid Claim to fame: "I actually wrote code that used twisted.web.webwidgets!"

2 1

Re: [Twisted-Python] Transporting pb.Copyable classes?
by exarkun＠divmod.com 21 Apr '04

21 Apr '04

On Wed, 21 Apr 2004 09:57:47 -0700 (PDT), Jasper Phillips <jasper(a)peak.org> wrote: > > [snip] > > > All this seems to me like frantic contortion to avoid a bug in jelly. > Shouldn't it be able to translate passed class objects into the remote > version, provided they have been properly registered? Is there some reason > why not that I am missing? Indeed. While I would do this differently, jelly should certainly be able to handle your approach. Let's get into specifics, shall we? Here's some code: >>> from twisted.spread import jelly >>> class Foo: pass ... >>> f = Foo() >>> f.bar = Foo >>> jelly.jelly(f) ['__main__.Foo', ['dictionary', ['bar', ['class', '__main__.Foo']]]] So far, so good. >>> from twisted.spread import pb >>> class Foo(pb.Copyable): ... pass ... >>> f = Foo() >>> f.bar = Foo >>> jelly.jelly(f) ['__main__.Foo', ['dictionary', ['bar', ['class', '__main__.Foo']]]] Hmm, that works too. I expected it not to, actually. I suppose something you're doing with globalSecurity or setCopierForClassTree() may be mucking things up. > > I appreciate the code suggestions, but basicaly I just want to know whether > this is expected behavior, or whether I should post a demonstrative test > case and suggest a fix. Posting a demonstrative test case would be excellent :) I suspect there is no bug in jelly, just a disagreement in expectations which can easily be resolved once there is a concrete example to talk about. Jp

2 1

Re: [Twisted-Python] Transporting pb.Copyable classes?
by exarkun＠divmod.com 21 Apr '04

21 Apr '04

On Tue, 20 Apr 2004 17:48:00 -0700 (PDT), Jasper Phillips <jasper(a)peak.org> wrote: > > On Wed, 21 Apr 2004, Andrew Bennetts wrote: > > > On Tue, Apr 20, 2004 at 04:20:32PM -0700, Jasper Phillips wrote: > > > > > > I've been passing around instances of pb.Copyable classes for some time, > > > registering them via pb.setCopierForClassTree()... However, this doesn't > > > allow me to pass the classes themselves. > > > > > > I dug around in jelly and found jelly.globalSecurity.allowInstancesOf(), > > > which seems to do what I want, but makes me nervious as it's pretty > > > buried... > > > > > > Passing classes seems like a reasonable thing to do, but now I wonder if > > > there is some reason that jelly doesn't allow it (except via a buried > > > method call)? Or is this just an accidental misfeature? > > > > Why not just pass the name of the class, and unserialise that as > > appropriate? > > > > I'm not a PB expert (or even close), but I always lean towards passing data > > rather than code (or code-like things like classes) over remote method calls > > when I can :) > > That's certainly feasible, but then I have an extra unserialize step > cluttering my code as the classes passed have attributes I want to access. > In general I'm passing game state which exists naturally as code, and while > I could always serialize and unserialize it, why bother if I don't have to? > > Plus, isn't unserializing classes based upon their name exactly what jelly > does? > > On the other hand it's debateable whether the things I'm passing _should_ be > classes at all (they represent a type of terrain, with statically accessible > fields describing their game effects). However, the quality of my code is > really a seperate issue. > Just to be sure I'm reading this correctly, you have something like... class Foo: bar = [] Foo.bar.append(baz) someRemoteRef.callRemote('doStuff', Foo) where you want 'remote_doStuff' to receive a class object whose "bar" attribute is [baz] (or possibly [RemoteReference(baz)], or *something* containing baz)? If not, disregard the rest of my post :) Otherwise ... You're going to have difficulty using PB with this approach. PB can serialize classes, but it does so in exactly the way Andrew described: it looks up their name and sends it, and the other side turns the name back into an object. Any mutable class state you change on one side will *not* be reflected on the other side. I'd recommend moving your mutable state off these class objects and onto instances of some sort. Otherwise, you will have to implement special jelliers/unjelliers for the class objects you want treated specially. Jp

3 3

[Twisted-Python] http://www.smartpeer.com -- another twisted success story
by Anthony Baxter 21 Apr '04

21 Apr '04

So Michael Marmor has released a Morphix derivative (a bootable CD version of Linux) that just includes PythonDirector, making the machine a TCP loadbalancer in a box. PythonDirector is of course based on Twisted. I think this is pretty cool, and could be good for the twisted success stories page. See http://www.smartpeer.com/ for the software. (ObDisclaimer: while I wrote PythonDirector, I've not had anything to do with SmartPeer other than offering advice and encouraging words) Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Re: [Twisted-Python] twisted and interactive/command driven input
by exarkun＠divmod.com 20 Apr '04

20 Apr '04

On Thu, 15 Apr 2004 12:58:41 -0000, "Ellers" <ellers(a)ellerton.net> wrote: > > [snip] > > I've got a basic interactive shell going on its own no probs, > and as mentioned I've got a separate basic twisted client going > too. > > Can anyone point me at examples or tips on how to use twisted > for handling the socket comms and still allow interactivity > with the user? > An example of handling stdin input asynchronously is available here: http://svn.twistedmatrix.com/cvs/trunk/doc/examples/stdin.py?view=markup&re… It does not demonstrate how to combine handling stdin input and dealing with sockets, but since nothing special is required for that combination, it should get you going in the right direction. Jp

1 0

[Fwd: Re: [Twisted-Python] Sub-project Naming]
by Christopher Armstrong 20 Apr '04

20 Apr '04

So it's officially counted :-) :: -------- Original Message -------- Subject: Re: [Twisted-Python] Sub-project Naming Date: Tue, 20 Apr 2004 12:47:45 -0700 (PDT) From: Jeremy Noetzelman <jjn(a)kriln.com> To: Christopher Armstrong <radix(a)twistedmatrix.com> FWIW, tmlabs.* has my vote! Stravad -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/

15 20

Re: [Fwd: Re: [Twisted-Python] Sub-project Naming]
by exarkun＠divmod.com 20 Apr '04

20 Apr '04

On Tue, 20 Apr 2004 17:23:56 -0400, Bob Ippolito <bob(a)redivi.com> wrote: > > [snip] > > > So because there are good reasons either way, I say we just stick with > the cute names -- but maybe try a little harder to market them to new > users. An idea would be to have a "protocol matrix" document that is > easy to find from twistedmatrix.com (no more than 1 click away from the > front page, but it could almost be the front page) that is a table of > wire protocols <-> implementation names with perhaps a note about their > stability and completeness. > As a first pass: |Wire Protocol |Impl mod(s) |Framework mod(s) Completeness (IMHO, 1..10) dict t/p/dict.py -- 2 dns t/p/dns.py t/names/ 4 (pending rewrite) finger t/p/finger.py -- 8 ftp t/p/ftp.py -- 5 http t/p/http.py t/web/ 7 (pending rewrite) ident t/p/ident.py -- 10 imap4 t/p/imap4.py -- 8 irc t/p/irc.py t/im/, t/words/ 6 jabber t/p/jabber/ -- not a clue msn t/p/msn.py -- not a clue nntp t/p/nntp.py t/news/ 4 (pending rewrite) oscar t/p/oscar.py -- not a clue pop3 t/p/pop3.py t/mail/ 8 (pending Q changes) sip t/p/sip.py -- not a clue smtp t/p/smtp.py t/mail/ 9 socks v4 t/p/socks.py -- not a clue xml t/p/sux.py -- not a clue telnet t/p/telnet.py -- 4 toc t/p/toc.py t/im/ not a clue echo, discard, chargen, qotd, who, daytime, time t/p/wire.py -- 9 Perspective Broker t/spread/banana.py, t/spread/jelly.py, t/spread/pb.py t/spread/ 8 (pending rewrite) ssh t/conch/ssh/ t/conch/ 9 Btw, looking at the first two columns of this table, I think that Twisted does a kick-ass job of naming most of its modules in an understandable and approachable manner :) Jp

1 0

[Twisted-Python] Library Versioning
by James Y Knight 20 Apr '04

20 Apr '04

Yeah, everyone's probably going to get mad at me for bringing versioning up again, but here goes. I'll structure the first bit as an argument between me and some argumentative type who is unconvinced. ========= Me: I want to be able to have two apps installed that use different, incompatible revisions of twisted or twisted subprojects. Other: You can just install multiple versions of Twisted, in different directories, and set your PYTHONPATH differently for the different apps. And this works *right now*. Me: Yes, that is true. But I want a solution to work for e.g. distributed debian packages. If twisted core makes an incompatible API change and becomes major revision 2, I want to be able to install applications that depend on v1 and applications that depend on v2 at the same time. I want to be able to apt-get install AppA which uses on libtwisted-core-1, and AppB which uses libtwisted-core-2 and have them both work. Other: Okay, so call the newer API twisted_2 and the old one twisted_1 (or just twisted). What's the problem? Me: A few problems. First problem is you have to litter the entire codebase of an application with the version numbers. Every time you import the module you have to add the revision. When you want update your app to use 2.0, you need to change every single file to use twisted_2, even if they otherwise needed no changes. What I really want to do is put the required version in *ONE* place in the app. Perhaps in its __init__.py, or (if it's an app), perhaps in its executable script file. Other: No, you *DON'T* want that, you really do want to specify the version in every import because you want to be able to import both versions in one "app". Me: But it is unlikely that two revisions that don't know about eachother will both work in one app, so while it may look like I can import twisted_1 and twisted_2, mixing them will likely cause my app to blow up. Other: Right, which is why the new version supplies the old interface as well. So the Twisted 2.0 library can provide both twisted_2 *AND* twisted_1 reimplemented in terms of twisted_2. And then you *can* use both in one app and everything will be happy. Me: Yes, that is possible. If you do that, you're not breaking API compatibility, and thus the new version isn't actually a major revision at all. I do concede, it is _always_ better to not break API compatibility if you can avoid it. But I only know of one major opensource library that is making a guarantee to never release a new major version: glibc. Most projects do not have unlimited programmer time, and keeping backwards compatibility forever can take a lot of time and testing. Also note the "again" there. Me: I think that having every API version supported by one library version is a very different thing than just being able to install multiple distinct versions of the library. Even if the goal is to support every API revision for eternity, it's probably not always possible, and at that point, you would want multiple library versions installed simultaneously. ========= Thus, I propose the following magic (I'll have you take for granted that might work, for the moment): This explicitly *DOES NOT* attempt to solve the multiple APIs supported by one installed library version issue. That is a separate issue. - "import twisted; twisted.setversion(xxx)" loads version xxx of the twisted library. If another version has already been loaded, or if the specified version isn't available, raise an exception. - "import twisted" uses the already loaded version if one is loaded, or else looks for the latest installed version and loads that if none have been loaded. After that, you can use twisted.whatever normally. The setversion only needs to be done once per app/library e.g. in the top level __init__.py. It can be done in more places if you want. This has the following desirable characteristics to me: 1) Simple case for beginners -- they don't have to do anything about versioning at all. Just import twisted normally and they get the latest version they have installed (which may very well also be the only version they have installed). 2) Yet, still easy to add the version requirement to an app that didn't have it initially. That you make sure to call setversion only really matters for packaged or widely distributed apps/libs. So if you're package an app that didn't have a setversion call initially, add it -- a one line patch. 3) Allows distro packaging to work sensibly. Incompatible revisions can be installed side-by-side and apps that use the old one can continue working just fine. 4) Doesn't require possibly unfulfillable compatibility promises from developers going forward. This kind of versioning is somewhat similar to that of Python itself: - You have a python app, and you can specify the version required on the first line of the main program (#!/usr/bin/python2.3), or else not (#!/usr/bin/python). - Multiple versions are simultaneously installable. - New versions have some compatibility, but don't promise perfect compatibility. Thus, sometimes you don't need to do anything to make your app work with the new version. But, if you do, there's likely only a few things you need to change, not every file. - If the new version of python implements a compatibility API this is a separate issue from the python version: to get the old API you do nothing, and to get the new API you do: from __future__ import whatever. James PS: (The magic above does seem to be implementable, see PMW, Python Mega Widgets.)

1 0