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 an xml file in my application,
I have created an element using
Example goes like this.........
and i appeneded it by using append() method.
But how i can reflect this change to my xml file?
and one more thing is i want to create element with some other parameters....
<abc m=" " n=" ">
and i have m and n values as strings with me.
can anybody help me to create this element and write it to the existing xml file
as a child of an existing element?
Thanks in advance..
Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php
On 18 May 2004, the following message was posted to this mailinglist:
Jp Calderone exarkun at divmod.com wrote:
>Daniel Newton wrote:
> I have a simple XML-PRC server similar to the example below:
> from twisted.web import xmlrpc, server
> class Example(xmlrpc.XMLRPC):
> """An example object to be published."""
> def xmlrpc_add(self, a, b):
> """Return sum of arguments."""
> return a + b
> if __name__ == '__main__':
> from twisted.internet import reactor
> r = Example()
> reactor.listenTCP(7080, server.Site(r))
> I want to be able to get the address of the client that calls the
> method can anyone help me with this?
This solution didn't work because 'transport' isn't a property of the
I'm currently in the process of changing from a customized
SimpleXMLRPCServer to a twisted XMLRPC server solution and I need to
insert the client IP into the attributes passed to the called xmlrpc
method. Anyone who knows the answer and is willing to share the info?
Having done the builds with two curious guinea pigs by my side, we are
triply pleased to announce the second 11.0.0 pre-release.
Tarballs for the second pre-release are available at:
The main differences between this release and the first pre-release
are changelog and setup.py tweaks.
Please test aggressively! Barring the discovery of regressions, we are
going to cut a final release *this weekend (April 2/3)*.
Many thanks to thijs and exarkun for feedback and improvements on the
first pre-release, and to glyph for overseeing the pre-release
is it possible to run several services from a single app?
i currently have a few services/apps and would like to put them all
into a single app so i can use cx_freeze to create a single exe file
for windows to allow easy testing.
maybe something like this:
factory1 = protocol.ServerFactory()
factory1.protocol = Protocol1
application1 = service.Application("Server1")
factory2 = protocol.ServerFactory()
factory2.protocol = Protocol2
application2 = service.Application("Server2")
-----BEGIN PGP SIGNED MESSAGE-----
I'm doing some performance testing of one of our Twisted applications.
And what I came across was a surprising amount of time being spent in
We're doing a fair amount with exceptions. And under cProfile, I found this:
29 0 0.4081 0.2940 twisted.python.failure:416(__getstate__)
+34492 0 0.1141 0.0235 +twisted.python.reflect:557(safe_repr)
So under profiling, we spent 408ms in __getstate__. I then changed
Failure.cleanFailure to just 'return', and I saw a real-world
improvement of ~480ms down to about 240ms. I then restored cleanFailure,
but changed Failure.__init__ to always set 'tb=None' before it does
anything. And in that case the time went down to 180ms. (And when I dug
into it, 150ms of that is time spent waiting for an XMLRPC response.)
I'm wondering if there is a tasteful way to disable Traceback processing
in a production machine. I realize you never know when you are going to
need the state in order to figure out what went wrong. But it is costing
2-5x runtime speed. (The other answer is to write all of our code to
In our case, there are many exceptions that are used as 'signaling'
rather than indicating a real failure. I suppose one option would be a
whitelist/blacklist that would indicate whether a given exception class
is worthy of a traceback. Thoughts?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----