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?
First, the "PB Copyable: Passing Complex Types" doc is
*great* and the examples are excellent -- my compliments to
all who contributed!
My question is about the pb.Cacheable section
-- specifically the first sentence: 'Sometimes the object you
want to send to the remote process is big and slow. "big" means
it takes a lot of data (storage, network bandwidth, processing)
to represent its state. "slow" means that state doesn't change
I would think that the product of its size and its rate of change
is the applicable metric -- i.e.: the bigger the object is *or*
the faster it changes (not the slower), the more applicable
Cacheable is, no?
I've just subscribed to the list, but I'm using Twisted from a while ago.
I need to do something, and wasn't able to find out how to do it. Well, I
*did* find out, but it's a horrible hack, and actually depends on something
that may be a bug, so it's worth asking here about this :)
In a project I'm doing , I want to catch all problems (unhandled
exceptions), log them and show them in stderr after a bit massaging. My
first approach was to hook me in sys.excepthook, and it worked on some
cases. But I saw some cases where it didn't .
Specifically, when the exception was inside a deferred, it didn't call
excepthook. Why not? I started to check the code, and found the following
snippet, at the end of Deferred._run_callbacks, in defer.py:
if isinstance(self.result, failure.Failure):
if self._debugInfo is None:
self._debugInfo = DebugInfo()
self._debugInfo.failResult = self.result
>From this, I have two questions:
1. The rest of the code only instantiates and uses DebugInfo
"if self.debug". Why this part of the code doesn't care about the
self.debug flag and always uses it? Is it intended and DebugInfo()
not being used for debug is a misname left there for historical
reasons? Should I open a bug about this?
2. I did the following (ugly) hack to achieve my results:
# ugliest thing I saw in a *long* time
def _error_happened(self, failure):
msg = failure.getTraceback()
failResult = property(fset=_error_happened)
twisted.internet.defer.DebugInfo = MyDebugInfo
Is there a better way to do this? Actually, this is working correctly,
but I don't know if it's the right way to do it, and don't want to
depend of DebugInfo() being called always in this case.
Thank you very much!
As reported in <http://twistedmatrix.com/trac/ticket/4652>, some
problems have arisen with cfreactor.
First, recent versions of Pyrex reject the Pyrex source for the support
modules. This makes future development on cfreactor difficult (although
Glyph's branch does resolve this problem - or at least appears to).
Second, the C source files do not build with clang. This seems likely
to become more important on future versions of OS X (the only platform
where this code matters). Even OS X 10.6 makes clang easily available
(according to an Ars Technica article, "Clang is the recommended
compiler, and the focus of all of Apple's future efforts."
Finally, when the cfreactor build fails, distutils prematurely exits,
preventing the rest of the build from completing. This point makes this
a serious problem for Twisted as a whole, rather than an obscure
platform quirk that can be ignored without wide-ranging consequences.
Apple has announced OS X 10.7 for summer 2011. Presumably at some point
prior to this they will freeze on a version of Twisted to package. The
best outcome for Twisted can probably be attained by ensuring this is a
version of Twisted which does not have the build issues reported in
Rather than leaving this to chance, I propose that we remove cfreactor
and all supporting code ourselves, immediately (ie, in 10.2 - hi therve,
go faster next time ;).
I think the relatively small userbase of cfreactor (I don't know of any
projects using it, nor does Google codesearch) and the fact that the
version of cfreactor in trunk segfaults partway through running the test
suite, combined with the potentially time-sensitive nature of this fix,
merits an exception to the normal backwards policy.
Rather than removing it, we could fix it, but the fact that no one seems
to be using it makes me think that no one with the expertise and
interest will step up to so.
If we're going to do this, it would be good to do it in the next few
days (say, by Tuesday) so as not to unduly further delay the 10.2
Hello Jean-Paul, thanks for tracking this down, you rock!
I promise that when I'll have payed all by debts I'll buy one of
those posters of Exarkun to hang on my wall!
> After a few runs, I managed to reproduce the problem. I instrumented the reactor with some extra logging and test_producer.py with a manhole server.
> The sequence of events appears to be something like this:
> OneA has a producer of OneE
> OneA has a consumer of OneB
> At some point OneB gives up and tells OneA to stopProducing (loseConnection)
> OneA.loseConnection stops the reactor from reading OneA and starts it writing
> OneA.doWrite happens
> it finds the send buffer empty
> it finds a registered producer (OneE) and resumes it
> OneE never produces any more bytes
> OneE loses its connection at some point and unregisters itself from OneA
> OneA takes note that it has no more producer, but does nothing about it
> So the bug is likely that FileDescriptor.unregisterProducer doesn't do anything special when disconnecting=True.
> You should be able to reproduce this very simply by setting up a transport-producer/consumer pair, calling loseConnection on the transport, then unregistering the producer.
> This all sounds somewhat familiar, but I don't see an existing ticket for it, so maybe that's my imagination.
Following your indications I attached a minimal example to a new ticket:
Some additional info:
* problem occurs only if more than 64KB of data are written to the
transport before its consumer calls stopProducing on it
* problem occurs only if some time passes before its producer
unregisters itself from the transport
Thanks again for your help! :)