Mailman 3 August 2001 - Twisted

Re: [Twisted-Python] Reality Servers
by Glenn.Rieger＠mincom.com Aug. 27, 2001

Aug. 27, 2001

I downloaded Twisted 0.10.0 along with Inheritance and TRDemo to continue looking at the .reality side of things. There is bad news and good news... The bad news is the username/password for TRDemo no longer seems to be guest/guest The good news is this does not kill faucet, but results in a cute "oops, unauthorized" message. Hmm, I may look at getting that to appear as a pop-up tk message-box. Am I using the wrong username and password for TRDemo or is something missing somewhere else? The Inheritance demo runs okay. Is anyone currently working on the gtkfaucet? If not, then I would like to know if I can make changes to the core reality product. I will try where possible not to break the gtkfaucet functionality, but since I can't test it I won't make promises :) If there is someone using gtkfaucet, I would appreciate hearing from you to work out some arrangement when I feel I need to change or add to the existing reality scripts. I have created DOS bat files as wrappers for building a reality tap and for running the tap with twistd. It contains the required commands plus a few house-keeping details like removing log and pid files before running. Currently, I have (1) modified the tkfaucet to word-wrap the description and item frames, (2) display them at a reasonable width and height, (3) added the shortcut code from gtkfaucet. I'm not entirely happy about the shortcuts, as I believe the "go north" command should have "n" as a synonym. However, I will leave it as is until I get around to looking at these commands. I don't like the idea that when you "look at" something, like the Colt pistol for example, your location changes to Colt pistol. That is, you have to perform a "look" command before you can move to another location. This is all I have to report at the moment. I would have had more but I got side-tracked playing the IF game Moist (written in TADS). Now *that* would have some interesting possibilities in a multi-player environment :) Cheers, ChrisH -- This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please delete it and notify the sender. The contents of this e-mail are the opinion of the writer only and are not endorsed by the Mincom Group of companies unless expressly stated otherwise.

2 1

[Twisted-Python] Proposed change to API for threadtask.
by Glyph Lefkowitz Aug. 23, 2001

Aug. 23, 2001

I'd like to change twisted.internet.threadtask.schedule from def schedule(function, args=[], kwargs={}): to be def schedule(function, *args, **kwargs): Any objections? -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph

5 9

[Twisted-Python] Logging Framework
by Moshe Zadka Aug. 22, 2001

Aug. 22, 2001

Or: How to do logging the proper way. Disclaimer: I have not profiled the ideas described here yet. twisted.python.log: DEBUG, WARNING, NORMAL, IMPORTANT, CRITICAL = range(5) priorities = 'DEBUG', 'WARNING', 'NORMAL', 'IMPORTANT', 'CRITICAL' class FileLogsink: def __init__(self, fp): self.fp = fp def log(msg, category, priority): now = time.ctime(time.time()) priority = priorities[priority] self.fp.write('[%(now)s] - %(priority)s - [%(category)s] %(msg)s' % vars()) class SysLogsink: ... sink = None min_priority = WARNING min_priorities = {} def msg(msg, category=None, priority=NORMAL): if priority >= min_priorities.get(category, min_priority): sink.log(msg, category, priority) def startLogging(newSink): import sys global sink sink = newSink sys.stdout = SinkFileWrapper('stdout') sys.stderr = SinkFileWrapper('stderr') def startLoggingFile(name): startLogging(open(name, 'ab+')) class SinkFilewrapper: queued = '' def __init__(self, name): self.name = name def write(self, data): data = string.split(self.queued+data, '\n') self.queued = data[-1] for line in data[:-1]: msg(line, self.name, DEBUG) class Logsource: '''mixin for classes wanting to log. Usage: class MyLoggingClass(Logsource): logCategory = 'MyThing' def someMethod(self, foo, bar): if foo==bar: self.log("foo should not be the same as bar", WARNING) ''' logCategory = None def log(message, priority=NORMAL): msg(message, self.logCategory, priority) -- The Official Moshe Zadka FAQ: http://moshez.geek The Official Moshe Zadka FAQ For Dummies: http://moshez.org Read the FAQ

2 1

[Twisted-Python] Remember the thing about Jack and the releasing and the software? Yeah.
by Glyph Lefkowitz Aug. 20, 2001

Aug. 20, 2001

So, I finally managed to kick 0.10.0 out the door, and it didn't even bite me on the way out (yet). However, I think that this release indicates the need for a more defined release process. (This one's for you, Moshe.) As part of the release this time, I wrote some automated acceptance tests to help me run the gauntlet of testing web/reality/tap building/words/manhole/telnet... these were really helpful, and helped dash & I squash at least one bug that we probably wouldn't have known about otherwise :-). So, here's a proposal for a test-and-release plan: --- Step 1: discuss features and declard dates Mailing list discussion of what features are going in to the next release. People give estimates for the associated tasks, and a release date is set. Step 2: ensure compatibility 3 days away from the release date, development should be finishing on all features desired. In cases where it's not, those features will be omitted from the release (and hopefully the developers responsible for them haven't broken anything in CVS). At this point, we will take 1 day to make sure that older versions of data still load properly. (more on this in a later email) If possible (fingers crossed here) we handle out-of-date documentation. This step can be skipped if we don't have any data format changes. Step 3: acceptance testing 2 days before the release date, we enter a code freeze and everybody runs the acceptance tests to make sure that everything still works. If unit tests run and 3 people sign off on the acceptance tests working (in posts to the mailing list) this step is over. Step 4: covering my ass One day before the release date, we make a release of the software and upgrade twistedmatrix.com to use it. This step lasts as long as it takes to run the site for a 24 hrs with no problems :) Step 5: release! With the website (and various other publicly acessible things) in order, publish the release to Freshmeat. --- The 3 goals of this strategy are to follow the XP "always have working code" rule, try to prevent releases from getting held up by a particular feature if there are other things worth releasing, and give ourselves confidence and give the world at large a really positive impression of how robust Twisted is. Feedback appreciated. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph

1 0

[Twisted-Python] ANN: Sunny Days
by Glyph Lefkowitz Aug. 20, 2001

Aug. 20, 2001

AUSTIN, TEXAS (AP): Firmly ensconced in his menacing 12-story "fortress of doom", Glyph today released Twisted, version 0.10.0. After the sun-destroying repercussions of a recent previous release, industry pundits were cautious with their predictions, standing by their ready escape pods. The "fortress of doom", rumored to be carved from a single, giant block of basalt is one of the outlying offices of Ninjaneering. Mr. Lefkowitz was available for a brief press conference. Beaming, Glyph proclaimed "With the power of the Ninjas to aid us, there is no way we can possibly fail!". Although he displayed his characteristic vaguarity about what those goals actually are, he may have actually meant something this time. As promised, Twisted 0.10.0 comes with both "enterprise" and the ability to repair the sun. Gavin "Skreech" Cooper, immediately after mirroring the Twisted repository, perfunctorily restored the sun to its former light and heat providing glory, while Glyph made sure that the Twisted Matrix Labs website was in working order. While everything appeared to go smoothly, Chris Armstrong, press agent for Twisted Matrix, could not be reached for comment, and sources say that he has fled the country, possibly to avoid fallout from the 0.10 series of releases. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph

1 0

[Twisted-Python] "Ports" vs. "Listeners"
by Chris Armstrong Aug. 19, 2001

Aug. 19, 2001

I really do not like that we call our "servers" "Ports". I think a much better term would be "Listener". I've talked to glyph before about this, and he's usually been too busy to discuss it with me (at least, that's what *he* says...), so here it is on the list. What's wrong with using "Listener"? A lot of people get confused by the term "Port". When they think "Port", they don't necessarily think of "something that sits on a port, and listens for incoming connections". That's just how I understand it. Another argument against Port is that it's not only for "waiting for incoming connections" -- clients also allocate ports when they connect to remote hosts. So, even technically, Port is an inaccurate term for this class. You might find other technical details that make "Listener" slightly inaccurate, but it still just Makes Sense to most people (I'm guessing -- DavidC_, after me using the word "Port", and explaining that I'd rather prefer "listener", told me he would've immediately understood what I was talking about if I had used that term from the beginning). So, it should just be known that I am vehemently against using "Port" for this class. If you can come up with something better than Listener (and that also *makes sense* without having it explained to me first), then that's great.

9 20

[Twisted-Python] Testing Debian Packages
by Moshe Zadka Aug. 18, 2001

Aug. 18, 2001

Glyph thought that others would want to build Debian packages out of CVS, so I checked in a small script, build-deb, which assumes a sibling directory "debian-build" and builds the twisted package there. For testing it, I use the following script: >>>>>>>>>>>>> cut here <<<<<<<<<<<<<<<<<<<<<<<<< #!/bin/sh rm -rf ../debian-build mkdir ../debian-build fakeroot debian/rules clean bin/build-deb cd ../debian-build sudo dpkg -i *.deb /usr/bin/mktap --uid 33 --gid 33 web --port 80 --static /var/www /usr/bin/tap2deb -t web.tap -m 'Moshe Zadka <moshez(a)debian.org>' -u sudo dpkg -i .build/*.deb lynx localhost sudo dpkg --purge twisted-web sudo dpkg --remove twisted >>>>>>>>>>>>> cut here <<<<<<<<<<<<<<<<<<<<<<<<< Have fun! -- The Official Moshe Zadka FAQ: http://moshez.geek The Official Moshe Zadka FAQ For Dummies: http://moshez.org Read the FAQ

1 0

[Twisted-Python] Multiplex
by Kevin Turner Aug. 17, 2001

Aug. 17, 2001

Preface: Currently, Napkin blots (the things that get drawn on the napkin) are immutable (in practice, if not in name). They go out over the wire and they're forgotten, presumably having been rendered on the other end. But this evening, dash asked me to revisit the idea of moving around objects which had been previously placed on the napkin. The following is what I would like to have to implement that goal -- but I believe it will be useful for far more than just Napkin. Even now, the core Napkin service has practically nothing to do with the idea of "whiteboards", and is just concerned with the far more general task of distributing information. What I've done with Napkin so far has taught me enough about PB that I can see that this can be done. Of course, there's a possibility that Twisted already does this, and I have not yet uncovered it. If that's the case, speak up! ---- Dramatis personae: Bob -- runs a PB.Multiplex service on twistedmatrix.com. Alec, Amy, and Angus -- are each "Leaf nodes" of the service. They might be called peers, subscribers, listeners, or observers, although the last three terms, describing passive occupations, are probably not most appropriate. kermit -- don't look for him in the dramatis personae, he's just an instance of a Frog. ---- The Goal: is quite simple. When Amy moves the red circle, it moves on Alec and Angus's napkins as well. When Angus hits the "change artist" button, Amy and Alec's players switch tunes too. When Alec clicks on the frog, all three workstations croak. Get the idea? Example: Alec has a Frog object (referred to as 'kermit') from Bob's multiplex service. Alec invokes kermit.shout_croak(). The 'shout_' prefix indicates that this action does not take place locally, but rather it happens world-wide over the multiplexer. Somewhere in kermit's private parts, there is a Proxy referring to kermit's counterpart in Bob's service. kermit does getattr(self._proxy, 'croak'), and a short time later... ...kermit and his other avatars on Amy and Angus's machines get their .remote_croak() methods invoked. Amy and Alec happen to be running the same client, one which provides an audio environment, and a giant "Ribbit" echos through each of their rooms. Angus is running a minimalistic text client on his Wyse 85 terminal, and sees a discrete "kermit: *croak*" message. Somewhere on the far side of the galaxy, a Sirius Cybernetics Genuine People Personality Prototype gets the message, promptly self-terminates, and falls to the floor. ---- As you can see, while kermit's interface is the same in each of the clients, the local implementation of the rendering methods differs. (This is why I thought I might want a Referenced class object I could descend Frog from in each of the clients, but I'm not sure it's practical to broker classes.) This can be achieved through a mechanism very similar to that used for Copied/Copy, there's a tag identifing the copied serialized Frog, and the Copy is constructed with a local implementation of Frog, one of Amy's choosing. On Amy's end, the difference between MultiplexLeaf and Copy is that kermit must retain a link back to Bob's place, where his spreadable self resides in a form resembling Proxied. On Bob's end, the difference between Multiplexed and Proxied is that the Multiplexed kermit must retain references to all the nodes/leaves of himself, so that when someone shout_s at him, he can tell all his selves to do the same. That also means that aside from the construction, a MultiplexLeaf behaves much more like a Referenced object than a Copy. ---- So now we have an object which when we wiggle its toe here, it wiggles its toe there. That's pretty good, but the exciting part is when we use it as a container or a vechile. Say my Napkin is Multiplexed. Now I say napkin.shout_draw(blot), with the Blot class being Multiplexed as well. When the blot gets passed from Bob to Alec and friends, leaves of the blot are constructed in their clients -- and references to those leaves are held in the Multiplexed blot. Now, when I say blot.shout_rotate(90)... Isn't this fun? ---- Questions answered: Q1. Why does Alec have to use the shout_ prefix? Don't the adverb prefixes usually go where the method is defined, on the receiving end? A1. Remember, Alec's Frog is not just a Proxy or a Reference. kermit was constructed an instance of a class defined on Alec's side, a class that likely has methods of its own, which Alec's program would like to use locally. Say Angus has a blot. He'll want that blot drawn in his view locally, while he positions/sizes it, before he commits it to the world. Having an interface to manipulate the blot locally (rather than through the multiplexer) is essential here, as I'm making no distinction between the-local-object-on-my-foo-canvas and the network-object. Issues not addressed here (but not showstoppers): 1) Subscription -- how do you join ranks with Alec, Amy, and Angus? This is closely related to the question of 2) Construction -- do multiplex objects have to be issued by Bob's service, or do they just spring into being whenever someone passes a MultiplexLeaf through the serializer? Just what role *is* Bob's service playing, anyway? But you know something? Bob's service doesn't really have to know anything about Blots or Frogs or Napkins in particular... it just has to pass along the right copyTags, so that compatible objects are constructed in each of the peers. Another cool-thing point: I've found no reason why you shouldn't be able to chain Multiplexed objects. Just have it look like Angus's peer on one side, and one of Bob's multiplexed objects on the other, and it should function in both directions. This lets you build more interesting network-topologies if you don't want all the peers connected to one point. That's all I've got for tonight, boys and girls. Hope you found reading this worthwhile. So tell me, whaddya think? Will it work?

2 4

[Twisted-Python] Synchronized FileDescriptor is bad
by Itamar Aug. 17, 2001

Aug. 17, 2001

The fact that FileDescriptor is synchronized may lead people to think it's thread safe, and it's not (connectionLose not being thread safe even when syncrhonized isn't based not only on conjecture but on actual observed errors.) I think no code should be synchronized in threaded mode unless you absolutely know that it will thereby be made thread safe. Otherwise, what's the point? It's the equivalent of wrong documentation, and it slows things down. Since there is now a generic mechanism for running non-thread safe code from threads (the threadtask module), there is no problem with this.

2 1

[Twisted-Python] Security of PB
by Chris Armstrong Aug. 16, 2001

Aug. 16, 2001

The other day, I think it was Sopwith, was asking about how jelly handles security in certain situations.. I think this brought up a good point for something I could put into the PB docs (which I'm working on), so I'd like to ask for someone to just give me a general overview of the security in twisted.spread. Could a PB application be attacked on a low-level? Thanks a lot, Chris Armstrong

2 1