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.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
I have a twisted TCP server to listens to client, processes requests, do
mysql database operations if needed (using adbapi Connection pool) and
return the result. Before deploying this in production, I want to know
right way to configure the server.
Since twisted is single threaded, how can I leverage multiple cores of my
production machine (which has 6 cores and 16 GB RAM) ?
One approach that I thought of was to start multiple instances of twisted
server on different ports. This would help in using the other cores as
well. What do you guys suggest ?
As commented by @glyph
Since we've added the buildbot link to trac pages, force-builds.py is
basically obsolete. I think we should just scrub all mentions of it,
and probably delete it.
I have created a ticket to remove it and clean documentation:
Is there anyone else still using this tool?
Should we keep it and rather than removing it, improve its documentation?
To help with the review process I would like to ask permissions for
triggering buildbot builds.
Is there a wiki page describing what are the steps required for a regular
contributor to get permissions to run buildbot tests and get write access
to the repo?
In the same time, maybe we can write a few words about the steps required
for a new contributor to become a full reviewer. Ex.
1. Contribute a few patches (ex 10) and learn the basic review process.
Observe how reviewers respond to your patch.
2. Start doing review as junior reviewer, without merging. Once you are ok
with the patch, invite another core developer to take a final view and
merge the patch
3. Once you have reviewed a few patches without errors (ex 10) you can ask
for full review permission or a core developer will let you know that you
can merge the patch without asking someone else.
This can be part of the current review process page:
What do you think?
Is not much, but should provide some guidance and hope!
Some of you may have heard rumors of some work in progress on a
replacement for Twisted's IConsumer/IProducer interfaces.
Tubes have been largely Glyph's effort (though a lot of people have
contributed in one way or another). And a large effort it's been.
Development is proceeding in a Twisted branch and comes to over three
thousand lines of additions so far.
Given the large size of the implementation and the long time that this
effort has been underway (I remember the Twisted meetup at the Rackspace
offices that *I* attended when I was visiting SF... a year and a half
ago... at which point tubes wasn't exactly a brand new project) I'd like
to re-raise the idea that the best next step for the project is to see
some distribution in its *current* state.
Specifically, I think it would be beneficial to set up a tubes project
on Github under the Twisted organization and try for a release in the
very near future.
I think this has several advantages over the status quo:
1) As an independent project, tubes will attract more attention than it
presently gets as a relatively unknown ticket & branch of Twisted.
2) As a separate Python package, the logistics of actually using tubes
are simpler (just consider how you might declare a dependency on a
branch of Twisted - keeping in mind you may want to use tubes in a
project that already depends on some version of Twisted). It may not
make sense to say that it is the same quality as Twisted proper right
off the bat (on the other hand, it may well - I suspect tubes in its
current form actually is a lot higher quality than large sections of
Twisted) but that doesn't mean people (not to mention the tubes project)
can't benefit from being able to experiment with it.
3) Decoupling tubes from Twisted frees tubes from certain of Twisted's
policies which are more challenging to follow for the kind of non-
trivial, brand new code base that tubes is. Technically we could just
say that these policies don't apply to a tubes package *in* Twisted but
this kind of subtle distinction is often lost on users (ie application
a) Twisted's compatibility policy need not apply. It could either be
sped up or abandoned more thoroughly. I'm generally a fan of being
backwards compatible even when you have few users because it actually
makes development easier, but loosening the policy to say things might
break if it's just really inconvenient to keep them working (whereas
Twisted goes to the inconvenience to keep them working) seems
b) tubes can undergo a faster release cycle to benefit more from user
4) At this point, a normal review of the tubes branch is going to be a
problem. We do not have good tools or mechanisms for dealing with
branches this large. The code in the current tubes branch can just
become master of a new project. Development going forward from this
point should continue to follow the feature-branch, small-changes, pre-
commit-peer-review process. But those 3k lines are written already.
Short of an extremely expensive effort to break the work up into
smaller, self-contained pieces there's simply never going to be a *good*
review in the typical style.
Additionally, it may turn out that tubes can remain independent
indefinitely. Someday perhaps Twisted would come to depend on it to
allow the various protocols and applications implemented in Twisted to
benefit from the superior abstractions it provides. Or maybe once it
has undergone a few iterations it will make sense to bring it back to
Twisted. I don't think this needs to be decided now.
There are downsides, of course. All of the boring maintenance involved
with having a separate project - setting up CI, actually doing the
releases, etc. Perhaps we could find some volunteers to help out with
these tasks, though, in exchange for getting some great code out there?
I'm curious what the folks out there who develop applications using
Twisted would find to be the easiest path forward. I'm also curious to
hear what Glyph thinks about all this. ;)
I found some time for adding a stub of SyslogObserver to the new t.p.logger.
Babel - a business unit of Par-Tec S.p.A. - http://www.babel.it
T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.
Jean-Paul raised a salient point about documentation on a ticket <https://twistedmatrix.com/trac/ticket/4804#comment:21> recently. To quote that:
We seem to be going the direction of "document every possible thing" these days. This stems from good intentions but the result is ever more bloated developer documentation of which any individual contributor has an ever shrinking knowledge. Rather than continuing to block the docs even further ... I think we need to get serious about pursuing a different strategy - for example, making twistedchecker a piece of software we could actually maintain and the output of which we could actually rely on (this really is just an example - the notion of a tool that tells you every single thing that's wrong with a piece of software is, of course, quite enticing - but perhaps unachievable).
I think we've been moving in the direction of making twistedchecker maintainable, although it does still present some challenges. For example, I've been wanting to eliminate this <https://github.com/twisted/twistedchecker/issues/75 <https://github.com/twisted/twistedchecker/issues/75>> for a while, but I just haven't been able to figure it out.
I am also thinking that we may want to create a category of private implementation details that don't require docstring coverage. In a public API, every parameter, every attribute, every detail should have accompanying prose and type annotations. In the innards of an implementation, these details can crowd out the code they're supposed to be elucidating.
As a first approximation, I think we could ask twistedchecker to stop enforcing docstring requirements for objects directly matching a "private" naming pattern.
line = '%s - - %s "%s" %d %s "%s" "%s"\n' % (
in 13.2.0 (twisted/web/http.py line 1920), and it's
u'"%(ip)s" - - %(timestamp)s "%(method)s %(uri)s %(protocol)s" '
so basically the client IP now gets wrapped within double quotes, e.g. a
log line that was looking like:
184.108.40.206 - - [25/Oct/2004:12:31:59 +0000] "GET /dummy HTTP/1.0" 123 - "-" "-"
it now looks like:
"220.127.116.11" - - [25/Oct/2004:12:31:59 +0000] "GET /dummy HTTP/1.0" 123 - "-"
as one can see in the unit tests in test_web.py too.
What's the reason for this change?
It feels it can potentially break code that parses log files and it also
seems to diverge from the format described on the Apache web site:
I just want to let you know about a piece of code I was working on.
I wanted to import and export Putty and SSH.com (Tectia) SSH keys in Python
and I could not find any existing code for that... my final goal is to
replicate the puttygen functionality.
I have extended the current twisted.conch.ssh.key.Key class to
import/export Putty and SSH.com keys
Code is here: https://github.com/chevah/chevah-keycert
Not sure if it make sense to have it integrated in Twisted. If there is
someone willing to review (part of) and merge this code I am happy to send
Right now it depend on Twisted but only because of the original Key and
packing/unpacking MP/NS values...
Have a nice day!