Mailman 3 October 2001 - Twisted

Re: [Twisted-Python] Hacking Reality
by Chris.Hadgis＠mincom.com Oct. 10, 2001

Oct. 10, 2001

>>>>> On Wed, Oct 10, 2001 at 10:21:20AM +1000, Chris.Hadgis(a)mincom.com wrote: > I would be interested in helping to develop reality further. > > Where do I sign? > > ChrisH, back after two and a half weeks away from computers Well, your timing is interesting. I just got a phone call last night from Glyph, and we talked a bit about how the new spatial simulation system is _not_ to be developed inside twisted.reality, but as a separate package. Twisted.reality still does need a lot of work, and glyph pointed out a few things to me that need done: 1) Re-do the broadcasting system. It's kind of a mess now. I've taken a _look_ at this, but I'm not really sure where to take it. IIRC you were the guy who was interested in this before, so if you could do a little work in this area it'd be great. <<<<< Yes, that is me. I did have some code ready for 0.10.2 (or whatever was current two weeks ago). As soon as I get some time I will see how this fits in with 0.11.0. I suspect any changes would be minimal, though I will need to change TRDemo and Inheritance. >>>>> 2) Get rid of the 'reality' reference inside things. Glyph says this would apparently reduce memory footprint by a huge amount. I think I'll analyze exactly how much work getting rid of this is going to mean. Obviously it's not just a simple "ok, delete all code using thing.reality" -- it's a big structural change (Realities should reference things, and not the other way around) 3) Get rid of the global object dicts. This would probably be a lot of work as a lot of code would get touched by this. As glyph has preached before, "Twisted represents a huge directional graph" -- things can get references to each other any number of ways, without a global thing store. <<<<< I have not looked into these two points much. I will look at them when I get some time, after I have made my changes for the broadcast system. [snip brain-dump] >>>>> Ehh, that last paragraph was pretty much a braindump. But I am kinda tired of being completely clueless about how all this stuff is gonna fit together. <<<<< Like I said, whatever time I can get to work on Twisted I will be happy to give. 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.

1 0

Re: [Twisted-Python] Hacking Reality
by Chris.Hadgis＠mincom.com Oct. 10, 2001

Oct. 10, 2001

I would be interested in helping to develop reality further. Where do I sign? ChrisH, back after two and a half weeks away from computers -- 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] debuggabilly
by Kevin Turner Oct. 9, 2001

Oct. 9, 2001

Am I supposed to be able to learn anything from this? Perspective Broker Traceback: Traceback (innermost last): File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 1194, in _recvMessage netResult = object.remoteMessageReceived(self, message, netArgs, netKw) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 259, in remoteMessageReceived return self.object.remoteMessageReceived(broker, message, args, kw) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 182, in remoteMessageReceived return broker.serialize(state, self, method, args, kw) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 1096, in serialize return self.jellier.jelly(object) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/jelly.py", line 159, in jelly return typfn(object) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/jelly.py", line 258, in _jelly_dictionary jval = self.jelly(val) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/jelly.py", line 159, in jelly return typfn(object) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 794, in _jelly_instance tup = instance.remoteSerialize(self.broker) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 311, in remoteSerialize return remote_atom, broker.registerReference(self) File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 1006, in registerReference puid = object.processUniqueID() File "/home/kevint/cvs/zaibach/Twisted/twisted/spread/pb.py", line 305, in processUniqueID return (id(self.perspective), id(self.object)) AttributeError: object

1 0

[Twisted-Python] Problems with bdist_rpm on 0.11.0
by Jeff Epler Oct. 9, 2001

Oct. 9, 2001

I had problems building 0.11.0 with "python2 setup.py bdist_rpm" on my system. (redhat 6.2, python 2.1 rpm from tummy) There were two syntax errors in twisted/mail/pb.py, and twisted/spread/cBanana.c was not being included in the tarball that bdist_rpm build (I think this is equivalent to 'python2 setup.py sdist', if non-rpm folks want to see the problem). This patch fixes the syntax errors (missing close parens), and adds cBanana.c to MANIFEST.in. I'm not sure that this is the correct fix for the extension, but It Works For Me(tm) Please copy me (jepler(a)inetnebr.com) on any discussion. Jeff

1 0

RE: [Twisted-Python] Teud
by Jürgen Hermann Oct. 9, 2001

Oct. 9, 2001

> > * xmldoc.py should emit a SAX2 stream, not write to a > file directly. > Makes sense. Unfortunately, on a first look pydoc makes this hard (by returning string values to build a result). I have to take a deeper look whether it's possible. > > xmldoc.dtd (which I wrote and committet): > > * submodule should contain a description, not #PCDATA > the #PCDATA is the description in all elements. Still, there is sometimes a description element and sometimes not. And it's not clear why. > > * class/@parents should be @bases (cf. __bases__) > OK. Changed and committed. Also added optional doctype & encoding. I also added my own versions of stylesheet & css, the stylesheet takes parameters and is thus easily adapted to dynamic page generation. Ciao, Jürgen -- Jürgen Hermann, Developer (jhe(a)webde-ag.de) WEB.DE AG, http://webde-ag.de/

2 1

[Twisted-Python] Teud
by Jürgen Hermann Oct. 9, 2001

Oct. 9, 2001

Hi! I'll (ab)use the twisted list for the moment, if someone thinks we should open a separate list, say so. Things that I noticed: * xmldoc.py should emit a SAX2 stream, not write to a file directly. xmldoc.dtd (which I wrote and committet): * submodule should contain a description, not #PCDATA * class/@parents should be @bases (cf. __bases__) * <other> should contain <value> (note that variables might get docstrings in the __future__, just like functions), and value should have a @type attribute * modelling of function attributes? Ciao, Jürgen -- Jürgen Hermann, Developer (jhe(a)webde-ag.de) WEB.DE AG, http://webde-ag.de/

2 1

[Twisted-Python] Process.write still blocks
by Matt Campbell Oct. 8, 2001

Oct. 8, 2001

I just grabbed Twisted 0.11.0 and checked twisted.internet.process to see if Glyph fixed is so that writing to the process's stdin pipe doesn't block. It doesn't look like anything changed here; stdout and stderr are read in non-blocking mode, but writes to stdin still block. I've already fixed this in my application with a call to fcntl after the process starts, and it doesn't break anything. So it would be helpful to make this change in the standard Twisted package as well. Thanks. -- Matt Campbell <http://www.pobox.com/~mattcampbell/>

2 1

[Twisted-Python] misc nits on glyph's big commit
by Kevin Turner Oct. 8, 2001

Oct. 8, 2001

twisted.passport.challenge.__doc__ says: > This is a method rather than a module-level function because it is > anticipated that we will want to change this to store salted passwords. but the update moved challenge so it *is* a module-level function. Should that docstring not have been cutnpasted and still be on passport.Identity.challenge, or did the reasoning change in which case the docstring needs updating? ---------- > Update of /cvs/Twisted/doc/examples Now pbsimple.py has the class named "Echoer" and pbecho.py has the class named "SimpleService". Is supposed to be that way? Seems backwards. ---------- > Update of /cvs/Twisted/twisted/python > > Modified Files: > defer.py > diff -b -u -d -r1.7 -r1.8 > --- defer.py 2001/10/07 12:25:15 1.7 > +++ defer.py 2001/10/07 12:54:46 1.8 class Deferred: # [...] def runCallbacks(self, result, isError): """Run all callbacks and/or errors that have been added to this Deferred. Each callback will have its result passed as the first argument to the next; this way, the callbacks act as a 'processing chain'. If this deferred has not been armed yet, nothing will happen. """ self.called = isError + 1 if self.armed: for item in self.callbacks: callback, args, kw = item[isError] args = args or () > @@ -72,12 +73,15 @@ > kw = kw or {} > try: > # print callback, result, args, kw > + # print 'defres:',callback,result > result = apply(callback, (result,)+args, kw) > + if type(result) != types.StringType: > + isError = 0 # # I don't get it -- what's this typecheck for? Is there documentation # on the meaning of return values for Deferreds that I'm missing? # > except: > io = StringIO() > traceback.print_exc(file=io) > gv = io.getvalue() > - print gv > + print 'Deferred Error', gv > result = gv > isError = 1 > else: [...] -- Kevin Turner <acapnotic(a)twistedmatrix.com> | OpenPGP encryption welcome The moon is waning gibbous, 73.4% illuminated, 19.9 days old.

1 0

[Twisted-Python] Re: pretzel (and mudbot theory)
by Gavin Cooper Oct. 7, 2001

Oct. 7, 2001

> And for a bit of history -- this idea started with skreech and > his old 'mudbot' program which he used to connect Quake servers, > IRC, and his MUD. We thought it'd be fun to reimplement it (much > better) in Twisted, so I'm helping him out. pretzel already seems to be gone from CVS for some unexplained reason. But maybe since it is I who had the original vision, I could possibly explain what pretzel/mudbot is suppose to be. It started when I hung out on a private mud a lot. A group of friends liked to mud and eventually we setup a private mud and all we did on it was talk. That is where Mudbot started, all it did was connect to the mud and function as any other IRC bot would do. It did some uninteresting things like executed certain commands and gave the output of them to the mud, such as 'uptime' or the like. The next step was to make it connect to more than one mud. That was completed, and intermud communication was possible just like the ry bot on #python. When the capability for 3 or more muds was hacked in, something resembling the pretzel infrastructure began to materialize. Eventually I wanted to be able to display a file easily to other people on the mud without copying or pasting. Looking through python docs I discovered 'fifos' and hacked it into mudbot. All I had to do was "cat file > mudbot/fifo" and it was chatted onto the mud. At this point I discovered that it could be possible to direct anything to this fifo and have it display on the mud. I could "tail -f logfile > mudbot/fifo" to a logfile, and it'd go to the mud. I liked this. Then I tried starting a quake server on Linux, the local output of which is text to the console, and redirecting this to the fifo made it possible for people to play quake and for there to be something of an "audience" on the mud. As we all liked to play quake, this was quite fun. Sometime around here I hacked in a little IRC support. I made it possible for IRC <---> Mud communication. Naturally, this also allowed for IRC <---> Fifo(and thus quake/logfiles)... coding in a real console interface increased the number of input/output combinations. Then I had The Idea. I decided to recode mudbot completely. It was a desperate hack, I hard-coded nearly everything. So I wrote some base mudbot code and rewrote mud/irc/console/fifo capability into separately loadable modules. At this timepoint however, I lost interest in muds because the people I hung out with decided it was more fun to harass me and my then-56k connection, so for personal reasons I didn't go back to the mud, and thus I lost interest in ALL muds, leaving Mudbot as more or less only an IRC bot on crack. So coding stopped before Mudbot's second incarnation fully materialized. And so it was left non-functional stuffed into a far corner in my home directory. So what was this idea... my idea was that everything connected to the mudbot had the capability to interact with everything else connected to the mudbot in some orderly, standard way. Descriptions of Pretzel have been so vague because we believe there's almost no limit to what it would be able to accomplish. Naturally, the first module coded for Pretzel (or UserAgent if you wish to call the module that) would be IRC input/output support. That would allow Pretzel to talk to IRC. Perhaps the second module would not be an input/output module, but a data processing module, one that would simply test the concept. When given a signal, it would output "Hello, world!". Data that comes through IRC that says "hi" would signal (perhaps just call a method of) the hello-world module, and the output of the hello-world module is returned to the IRC module. The IRC module would be told to print whatever comes from this hello-world module. The end result: <skreech> pretzel: hi <pretzel> Hello, world! Other modules would be implemented. Data-processing modules that, say, run programs and return their output, or perhaps generate a fortune using the fortune program and return that. Or, for the ry killer, a module that would simply take what is input and output it to another input/output plugin. An ry killer could consist of four pieces: 1) IRC connection to efnet 2) IRC connection to ircnet 3) IRC connection to opn 4) Mirroring plugin Where text coming in from every IRC connection would be directed towards the mirroring plugin, and the mirroring plugin would be designed to retransmit that message to every other IRC connection. So what? That could be coded with Twisted within 30 minutes, you say. Part of my goal, however, is to be able to program Pretzel's behavior without touching any code. I should be able to rip out the mirroring plugin, shove in a logfile plugin, connect the IRC connections to the logfile plugin (I keep getting the mental image of PVC pipe pluming) and make it a log-keeping bot, without seeing any code or even restarting the bot. Granted, the flexibility of the bot will be limited if you decide not to touch any code. If you use Pretzel and decide, "hmm, I want people to know my uptime." then you could code a module that adhered to the pretzel standard, shove it in to your pretzel bot, hook it up to your IRC connection, and you'd have it. The beauty of the system is that you coded it with the intention of using it on IRC, but because it is a pretzel plugin, others can use the same code to display the uptime on a Mud connection, or on Twisted.words, or heck, a Quake server. So that is my Mudbot/Pretzel theory. Thats the big idea. Any existing IRC bot ought to be able to be replaced with Pretzel and a combination of plugins, easily. Love it or hate it, give me your thoughts. But again, its mysteriously missing from CVS as of about 5am zaibach-time saturday. Gavin Cooper 'skreech'

4 5

[Twisted-Python] f33r the API docs
by Itamar Shtull-Trauring Oct. 7, 2001

Oct. 7, 2001

Check this out: <http://itamarst.org/twisted-docs/twisted.html> The output will be that much more cleaner and informative if you add a __all__ list to your package. __all__ is the list of objects you want to be exported when somone does "from yourmodule import *" and is used by my documentation program to decide what to document. It is a simple list of strings. For example: =========================================== import sys _list = [] def addToList(object): """add an object to the list""" _list.append(object) CONSTANT = 3 __all__ = ["addToList", "CONSTANT"] ===========================================

1 0