Mailman 3 September 2002 - Twisted

[Twisted-Python] Minor buglet in spread.sturdy?
by Andrew Bennetts Sept. 13, 2002

Sept. 13, 2002

If you do: foo = sturdy.PerspectiveConnector(...) foo.startConnecting() foo.callRemote('echo', ...) ... You'll actually connect to the remote server *twice*. Which of these is the real bug: - callRemote sets self.connecting = True instead of startConnecting - startConnecting isn't for external use, and should be renamed "_startConnecting"? -Andrew.

1 0

[Twisted-Python] Patch for tapconvert manpage
by Samuel Bronson Sept. 13, 2002

Sept. 13, 2002

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 RCS file: /cvs/Twisted/doc/man/tapconvert.1,v retrieving revision 1.1 diff -u -2 -r1.1 tapconvert.1 - --- doc/man/tapconvert.1 11 Sep 2002 20:07:00 -0000 1.1 +++ doc/man/tapconvert.1 13 Sep 2002 04:44:30 -0000 @@ -3,5 +3,5 @@ ~ tapconvert \- convert Twisted configurations from one format to another ~ .SH SYNOPSIS - -.B tapconvert -i \fIinput\fR -o \fIoutput\rR [-f \fIinput-type\fR] [-t \fIoutput-type\fR] [-d] [-e] +.B tapconvert -i \fIinput\fR -o \fIoutput\fR [-f \fIinput-type\fR] [-t \fIoutput-type\fR] [-d] [-e] ~ .B tapconvert --help \fIapptype\fR ~ .SH DESCRIPTION @@ -26,4 +26,8 @@ ~ \fB\--encrypt\fR, \fB\-e\fR ~ Encrypt output. +.SH EXAMPLE +Convert web.tap into a web.tas, so we can understand it: + + tapconvert -i web.tap ~ .SH AUTHOR ~ Written by Moshe Zadka, based on tapconvert's help messages -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEXAwUBPYFue1veIDzBO6cgFAPvoQP/dt1QDyiLk3tdqQ9FJo/nPsyno4lXjuWI VzmVu2BWM/gho+elUdnFmfQ4rGO1Evjf8AQammpD26TyxjeEeLRG4Bp1l4PqKRpk hGD13vZK8eLj0qLj8xOgxGBNuxWv5+6Y6iXo505mrJX7tQNNS7bpY9zNnp6qq8uZ z+Ozmcjz9scD/1AcOtsZ+8vnxX+hAAZx/mW3sSO+dX8RXHm3vbS4qILKT2JQOAaE eF176LQe3DwMSKFCH0W5xW+XeojcnJEsd5roC8DWTNi7EbIhNdPHnnltnGiJymI9 jyNSuwI6VTX2fHKq5JifNw6OPQEyo93vTD7IhPzXQTJuPdgZKYd9V66B =0FGR -----END PGP SIGNATURE-----

1 0

[Twisted-Python] Mailing list archives -- ideal for Twisted?
by Andrew Bennetts Sept. 13, 2002

Sept. 13, 2002

Random IRC snippet: <jdub> what would be really cool <jdub> is to get rid of mhonarc and static http archives <jdub> and have, perhaps, an nntp-based archive system <jdub> with a web front end <spiv> Hmm. <spiv> That would suit Twisted nicely. <jdub> there are a few of these around <spiv> Hmmm.... <jdub> but it would be cool for twisted Basically, a unified web/nntp mail archive, that uses a common backend, but has a twisted.web and twisted.news front-ends could make for a really cool Twisted app. Any thoughts? ("Yes! I will write this!" particularly welcome ;) -Andrew.

1 0

Re: [Twisted-Python] Another proposal for new look for website
by Laura Creighton Sept. 12, 2002

Sept. 12, 2002

> http://itamarst.org/twisted_homepage.png > > Courtesy of MAXIMA Multimedia (http://www.maximam.com). > > -- > Itamar Shtull-Trauring http://itamarst.org/ > Available for Python, Twisted, Zope and Java consulting > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python(a)twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python Itamar Shtull-Trauring, you are a very silly man. Thank you. Laura Creighton

2 1

Re: [Twisted-Python] version control, QA, branching ...
by Laura Creighton Sept. 12, 2002

Sept. 12, 2002

> > There are four new version control systems that sound interesting to me: > > * BitKeeper > http://www.bitkeeper.com/ > > The most mature of the four (?). Not fully free software, although I think i > t > is freely usable for open source projects. > > * Subversion > http://subversion.tigris.org/ > > Also relatively mature. > > * Arch > http://www.regexps.com/arch.html > > There is a nice comparison between arch and subversion somewhere on that site > . > > * OpenCM > http://www.opencm.org/ > > The least mature of the four, but the one with the most impressive > intellectual provenance. > > > I don't really know what the tradeoffs are among these four. Personally, I'm > > continuing to use CVS for everything for now. > > Regards, > > Zooko > http://mnet.sf.net/ Anders Qvist, quest(a)lysator.liu.se (the Project Lead for the Python-In-a-Tie Snake Farm was looking at Arch, and still is.) I think he actually started chaning all the perl scripts to use python, but I don't know how far along that project got. People whose opinions on elegance, beauty, and usuability I trust have embarked on a campaign to convince me that Arch is the way to go and we should store all our code that way. Right now I am too busy to listen, so I personally have no experience or opinions, beyond 'sure sounds nice'. Laura Creighton

2 1

[Twisted-Python] Twisted: the comics
by Itamar Shtull-Trauring Sept. 12, 2002

Sept. 12, 2002

isometric, one of the coolest web comics in existence, had write-ins for plots. So I submitted one. The result: http://isometric.spaceninja.com/_/twisted_plutonium/

1 0

[Twisted-Python] Job posting on dice
by Itamar Shtull-Trauring Sept. 12, 2002

Sept. 12, 2002

3 month contract in Portland, $65K. http://www.dice.com/DandL/s/sofor001.E-010.html

1 0

[Twisted-Python] version control, QA, branching ...
by Kevin Turner Sept. 11, 2002

Sept. 11, 2002

I caught some bits of a discussion on #twisted on my way to bed last night, and thought "Hey, I should read that." So I plundered the logs and did a lot of pruning and here you are, a discussion involving quality maintance practices with version controlled branches and unit tests and things. [attached] Keep in mind that this log HAS been trimmed by me, and while I have made an effort to maintain context, it's quite possible that you aren't seeing the full context for every remark made. Random notes from me: * Michael Schwem was telling me about [http://aegis.sourceforge.net/ Aegis], which sounds like it's *much* better at branches than CVS is, and pays much stricter attention to the entire QA process. * In my recent romp through CVS resources, I found [http://codestriker.sourceforge.net/ CodeStriker]. I haven't talked to anyone who's used this, but it has some ideas in it. [05:26] <glyph> radix and I had some discussions about release procedure today, btw :) [05:26] <glyph> we came to some pretty radical conclusions [05:27] <itamar> glyph: and they were? [05:27] <glyph> itamar: release candidates should always be made from HEAD [05:27] <glyph> itamar: Twisted developers need to learn how to use branches for developing experimental features; HEAD should *always* be releaseable [05:27] <itamar> branches, here we come [05:28] <glyph> itamar: the better tests we have, the less craziness with branches is necessary. [05:36] <fzZzy_> glyph: shall I check in highly untested domtemplate=>microdom code? or wait, and test it some more? [05:36] <fzZzy_> I guess this goes back to the cvs branch issue [05:37] <dash> fzZzy_: well, isn't testing it easy? =D [05:38] <fzZzy_> dash: not at 2:30 am [05:38] <fzZzy_> and no, I never wrote any domtemplate tests [05:39] <dash> fzZzy_: no domtemplate tests?! gasp [05:39] <dash> fzZzy_: you sound like me [05:39] <fzZzy_> ok I'm going to bed instead since glyph didn't respond instantaneously ;-) [05:39] <fzZzy_> I'll be banging on it tomorrow [05:40] *** glyph has changed topic to "Welcome to the Twisted project: sleazeware produced in a drunken fury by college dropouts!" [05:40] <dash> glyph: !!! [05:40] <dash> glyph: I GRADUATED [05:40] <glyph> dash: you didn't write most of twisted :) [05:40] *** dash waves diploma madly [06:15] <glyph> jml: much like linux; even very stable kernels with frozen APIs contain "experimental" drivers and such [06:15] <jml> glyph: so the trick is to mark them as such? [06:15] <glyph> itamar: I don't think that's the case; in Twisted's history we've had releases that were pretty stable and didn't require a lot of after-the-fact tweaking [06:16] <jml> glyph: for many commercial packages, it's not that long after release that you get SP1.. no one really thinks it a bad thing. [06:16] <jml> just as long as code-breaking changes aren't slipped under the door. [06:17] <glyph> jml: I am increasingly confident in our test suites lately [06:17] <glyph> jml: we seem to have had relatively few problems with code-breaking stuff slipping in without anyone noticing :) [06:17] <jml> glyph: btw, how's the test-first design going? I've found it hard in the past to keep disciplined about it. [06:18] <glyph> jml: it's hard to keep disciplined about it for me too :-(. When I can do it, it's *definitely* better than the other way. [...a big discussion on one-point-oh philosophy intervenes here. Only a few tangentially related bits are included in this log excerpt...] [06:22] <glyph> itamar: in "policy": we don't have a policy for continuing development of Twisted after 1.0, in terms of legacy support of APIs that may need to change for some reason. (Yes, some large portion of twisted.internet is stable, but what is our support policy for the *other* portions of twisted that you *need* to use for a useful app? Are they just unsupported continuing forward?). We don't have a policy for releases which is sustaina [06:23] <glyph> this includes things like "when should developers use a branch?" and "how should the release manager interact with users in order to decide whether we mihgt be breaking something important?" [...] [06:27] <glyph> itamar: but then, a developer has some feature they want to play around with, which they believe to be potentially unstable, but doesn't break any tests [06:27] <glyph> what are the guidelines for them to work with that? [...] [06:52] <moshez> glyph: which reminds me. [06:52] <glyph> moshez: hmm? [06:52] <moshez> glyph: tell radix to fix ReleaseProcedure [06:52] <glyph> moshez: we've talked about changes to ReleaseProcedure [06:52] <moshez> glyph: I left a note there what he should fix [06:52] <glyph> moshez: OK [06:53] <moshez> glyph: I'm not talking about changes to the procedure, just bring the document up todate on reality. [06:53] <glyph> moshez: I don't see the note :) [06:54] <moshez> ---- This part is sorely out of date -- document the new Debian way -- [06:54] <itamar> oh [06:54] <itamar> new policy is to do all major devel on brances? [06:55] <itamar> better mail the list then [06:55] <glyph> itamar: that's a proposa, still need to hash it out, and to make sure that it is SUPER EASY for developers to do this [06:55] <itamar> it sounds painful [06:55] <moshez> glyph: it isn't. [06:55] <itamar> but it probably is easy [06:55] <moshez> glyph: it isn't even mildly easy [06:55] <moshez> glyph: I'm not sure I like that propsal actually. [06:56] <glyph> moshez: I figured you wouldn't :) [06:56] <itamar> here we go again [06:56] <glyph> but I'm not really sure what you wouldn't like [06:56] <itamar> it may make more sense to branch on each release [06:56] <moshez> glyph: merging is hell on earth [06:57] <glyph> moshez: that gives the developer incentive to integrate early, as well as provide backwards compatibility hooks and good tests so that he doesn't have to hang out in a branch for too long :) [06:58] <warner> my exp: each branch doubles the total effort. don't branch unless you know you won't do much work on one of the paths [06:58] <glyph> moshez: when radix and I discussed the policy, we were also debating the need for coverage tools in order to qualify particular changes for branches [06:58] <moshez> glyph: how do you decide which changes go on a branch and which go on HEAD? [06:58] <glyph> like if the module you are planning to restructure has 95% unit test coverage, chances are you can get away with not having a branch at all, provided you don't change tests [06:59] <moshez> glyph: and woulnd't it just make sense to say "never break unittests"? [06:59] <glyph> moshez: yes, that makes sense [06:59] <itamar> possibly the effort should go into more tests [06:59] <itamar> instead of branches [06:59] <glyph> itamar: that would be optimal [06:59] <itamar> ugh [06:59] <itamar> this is too distracting [06:59] *** itamar has quit IRC ("must work") (~itamar(a)line102-187.adsl.actcom.co.il) [07:00] <glyph> i win! [07:00] <moshez> "Finish Him" [07:00] *** glyph isn't clear what that would entail, since itamar's already disappeared [07:01] <glyph> moshez: So yes, "never break unittests" is good, but if you're doing work on, for example, cReactor, there just isn't good enough coverage to be sure that you're OK to check in to a branch which should be always-releaseable (HEAD), even if unittests are A-OK [07:02] <moshez> glyphy: and when would the merge from the branch to HEAD happen? [07:02] <glyph> moshez: after our army of simean warriors bashes on the code for several weeks [07:03] <moshez> glyph: in other words "after several weeks pass" [07:03] <glyph> moshez: i need to read up on the exact mechanics of branches in order to understand your concerns, I think [07:03] <moshez> glyph: ok. do so. [07:03] <glyph> is it not possible for a developer to continuously re-integrate patches to HEAD into their branch? [07:03] <moshez> glyph: wait. [07:05] <moshez> glyph: http://www.lerner.co.il/~moshez/cvs/cvstut34.html [07:05] <warner> glyph: in my experience, yes [07:05] <warner> glyph: however the question of "should I or not" takes up as much time as doing the commit separately to both branches [07:06] <glyph> warner: hmm [07:06] <glyph> warner: what was your experience working with branches? [07:07] <moshez> http://cvsbook.red-bean.com/cvsbook.html#Going_Out_On_A_Limb__How_To_Work_W… [07:08] <glyph> moshez: ugghh [07:08] <glyph> moshez: the 'spurious conflicts' bit is ... interesting [07:09] <warner> well, the workfolk kept alternating between the "current on HEAD" and "current on branch" schemes [07:09] <warner> the biggest problem was that people expected the merge features to mean they could do less work [07:09] <warner> but the real issue was who decided which bugs/features should get done in which releases [07:10] <moshez> glyph: I am evil [07:11] <glyph> warner: hmm [07:11] <warner> basically foisting developer work off to the config mgmt people, who didn't know the code well enough to say yes or no [07:11] <glyph> okay, I worked with branches in perforce [07:11] <glyph> they made *waaaay* more sense than this [07:11] <glyph> I think cvs's semantics are broken [07:12] <warner> yup, P4's scheme is easier to work with [07:12] <glyph> at the very least, they're not what I want ;) [07:12] <warner> the workfolk took the other path out: ClearCase [07:12] <warner> That was two years ago and they're still trying to figure out how it works. [07:12] <moshez> glyph: well, if we moved to SVN, we'd have easier branching [07:13] <warner> But at least it's expensive. They get good use out of their big NetApp boxes too. [07:13] <jml> I suppose subversion is out of the question? [07:13] <warner> I tend to see CVS's painful branching as similar to the 8-char tabstops in the linux kernel.. [07:14] <warner> .. a bug that makes you aware of just how bad it is to overuse that thing.. [07:14] <warner> .. if you were to fix it (or find a tool that did it better), you'd be tempted to use it more, and that would be bad. [07:16] <glyph> jml: Well, I originally really didn't want to consider it, because I thought that there would be funding for a Twisted-based version control system in the near future [07:17] <jml> understandable. I disagree though. [07:18] <glyph> jml: Well, the funding didn't appear as expected (though it still will at some point, most likely about a year from now), and this is the first time I've really wanted a feature which svn potentially implements better [07:18] <glyph> svn's infrastructure strategy frankly scares me though [07:19] <warner> twisted.revisions? my brain hurts [07:20] <jml> glyph: yeah, fair enough. I'm quite happy to have at least one or two network apps that aren't twisted, but that's me. [07:20] <warner> or maybe that's just the lack of sleep [07:20] <glyph> warner: your brain hurts? *your* brain hurts? [07:20] <glyph> warner: YOU HAVE NOT YET COME TO KNOW PAIN, MORTAL [07:20] *** warner laughs [07:23] <phed__> twisted.revision features: every client is also a server. you create a branch every time you edit a file. versioning is measured in minutes. realtime versioning. integrated QA [07:25] <warner> "integrated QA": my current learn-as-I-go Twisted project is a tinderbox-like distributed build network, including various forms of 'make test' stages [07:25] <glyph> warner: awesome! [07:25] <glyph> warner: is this going to be publicly available? [07:26] <warner> I'm basing it off CVS commit messages, but direct-from-VC would be better [07:26] <warner> glyph: yup. I did a similar thing for work (before I found twisted), now I'm rewriting it without the shackles of employment [07:27] <glyph> warner: are you using CVSToys? [07:27] <warner> glyph: nope. whazzat? [07:27] <glyph> warner: ooooohhhh [07:27] <glyph> http://twistedmatrix.com/users/acapnotic/cvs.png [07:27] <moshez> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAI… [07:27] <glyph> warner: talk to acapnotic :) [07:29] <warner> glyph: will do. if I guess correctly about what it does, it would get rid of yet another piece of code I need to write. Just like twisted did for the entire serialization and transport layer. [07:30] <warner> (if I wait long enough, the rest of the necessary code will disappear too. love it.) [07:31] <glyph> warner: cool :) [07:31] <glyph> warner: hey wait [07:31] <glyph> warner: you know, we could really use something like that [07:31] <glyph> warner: I keep meaning to write an automated unit-test runner with e-mail notification [07:33] <glyph> I'm going to go to sleep for about 16 hours right now [07:33] <glyph> talk to you crazy cats later [07:33] <warner> glyph: that'd be part of it. Of course with twisted you'd get an IRC bot too. The motivation back at work was to punish folks who broke the build. The status output was a web page they'd refresh every once in a while until they saw their changes were built successfully. But I'm planning on Gtk clients too. [07:34] <warner> catch you later glyph. I'll let you know what I code up.

1 0

[Twisted-Python] man pages
by Moshe Zadka Sept. 11, 2002

Sept. 11, 2002

All utilities in bin/ should be accompanied by man pages. Violators will be eaten.

1 0

[Twisted-Python] Re: [XML-SIG] Can anyone recommend a sensible XML parser for Python?
by Uche Ogbuji Sept. 10, 2002

Sept. 10, 2002

> > Uche Ogbuji writes: > > Wouldn't it be better for Python/XML to offer a *separate*, specialized > > function for cloning nodes, rather than doing weird things with cloneNode? > > Why? I'd rather make cloneNode() do the right thing, and it seems > rather clear what that should be. Certainly more clear than for > DocumentType nodes. ;-) So you think it should do what I mentioned before? 1) Create a new documenType and document node 2) clone all child nodes 3) set the ownerDocument of each of the new nodes to the new document? If we have it do that, then let us please 1) Document it properly 2) Point out that it is not standard DOM behavior I am not at all clear that this is the "right thing". I still think the right thing is to throw an exception. I know the above behavior would throw me as I expect the ownerDocument of cloned nodes to be the same as the ones from which they were cloned. But I certainly don't care enough about it to oppose such an addition. I'd just like to make sure we call it out properly. Least surprise and all that. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitl… 1EA5A2CF4621C386256BBB006F4CEC

2 1