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
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?
I'm looking for some example code I can use to build an app from. I
need to 'wait' or sleep for new data in a file. Then wake and process
The file is a regular file, not a pipe. It is the output of a existing
program (i.e., not mine to modify). Needless to say, the API for hugh.
I'm need some help finding the right tools.
I am receiving the following error when i run the <filename>ctl.exe
generated with moonfallen's ntsvc module and py2exe:
Traceback (most recent call last):
File "boot_service.py", line 21, in ?
RuntimeError: No service classes found
Can someone please point me in the right direction??
Important notice: This message is intended for the individual(s) and entity(s) addressed. The information contained in this transmission and any attached, may be confidential and may also be the subject of legal privilege, public interest immunity or legal professional privilege. Any review, retransmission, dissemination or other use of, taking of any action in reliance upon this information by person or entities other than the recipient is prohibited and requires authorization from the sender. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person) you may not copy or deliver this message to anyone. In such cases you should destroy this message and kindly notify the sender by reply email.
WARNING: Although Infocomp has taken reasonable precautions so that no viruses are present in this e-mail, the company cannot accept responsibility for any loss or damage arising from the use of e-mail attachments.
Three thoughts come to mind - coming from someone who has climbed
the Twisted learning curve for the last year.
1) The docs I'd like to see would be of a more tutorial nature - it
would seem to me that they would be the easiest way to reach a
"lights on" stage. The sample code is good - and the finger tutorial
is fine (for what it addresses) - but there are still lots of bits &
pieces that seem to be hidden.
At some point, you reach the "Ah-ha!" stage. The learning curve
greatly flattens out at that point. (At least that was my personal
experience with Twisted-PB.) Once you reach that point, everything
else becomes much easier to learn.
It helps a _whole_ lot to have a specific project / task in mind.
Part of this is understanding your task sufficiently well to be able
to divide it into the components as they apply to Twisted, and build
carefully, step-by-step. (In my case, I built a multi-room chat
server. Not a whole lot of code, but takes advantage of a number of
I think it also helps, as painful as it may seem, to force yourself
to work through the tutorials in the book by typing the code rather
than just reading it. There's a more intimate association that you
develop by going through the actual process than just running the
2) A current road map may help. I've seen various comments about
modules being "not-quite-primetime" or "an old way of doing things"
(specifically, I'm thinking about Enterprise, other than adbapi, and
TAC / TAP files) Yes, Python (and Twisted) is the "Batteries
Included" environment, but as someone pointed out to me at PyCon,
some of those batteries are dead. I'd really like to know what
modules I should avoid.
3) Even something like a directed HOWTO could be incredibly useful.
If you want to build a web server - read Chapter 7, Web
Applications, section 7.1 and look at sample "xxx" - where sample
"xxx" is the simplest and most straight forward first example of a
There's a _lot_ there, and wading through it can be frustrating. The
only way I managed it, was to print out the consolidated HOWTOs in
the book.pdf file and read Chapter 6 repeatedly. After about the
10th repetition, along with working through the samples, things just
started falling into place.
On Tue, 2005-03-29 at 09:00 -0700, James Knight wrote:
> Author: foom
> Date: Tue Mar 29 09:00:10 2005
> New Revision: 13334
> Make log.err and log.msg actually threadsafe, by executing them in the
> reactor-loop if not called from the main thread.
I talked to glyph about this at some point, and he thought that we
shouldn't do this, if you want to make observers thread safe you should
do so yourself. I'm not sure I agree with glyph, though.
The lack of detailed, current documentation for Twisted is an ongoing
problem, especially given how revolutionary and difficult to understand
its underlying programming concepts are. Dave Cook's "just use it for
months" comment is not at all off the mark, but it's a frustrating and
unproductive way to learn. It particularly annoys me that the code
contains so few docstrings -- Python's especially useful and convenient
way to document your code -- and there are so many nonsensical "cute"
names like jelly, banana, etc.
Putting my money where my mouth is, I would be willing to contribute a
few hundred bucks to getting some more docstrings in the code and,
consequently, to a somewhat better lore-generated API specification.
One thought would be to run a "bounty" program using an
actively-generated, hyperlinked web rendition of the latest Twisted SVN
code. For example, participant donors could mark defs, classes, or
blocks of code to indicate where they're willing to "sponsor"
docstrings, and they could also click on newly added docstrings in such
"sponsored" code portions to indicate acceptance and make a bounty
payment from their contribution to the fund or whatever to the person
who wrote the docstring. The proportion of docstring submissions
accepted by a given donor could be a score that potential writers could
look at when deciding whether to do the work or not.
Any thoughts on that idea? Anyone willing to step up as a
co-contributor to such an effort, both financially and with some Nevow
Registered Patent Agent
Open-Source Software Author (yes, both...)
Web Site: http://www.eepatents.com
On Mar 30, 2005, at 12:17 PM, Cory Dodt wrote:
That's not the right way to set the version. It needs to be set in all
projects and in all other files which contain "SVN-Trunk". See what the
release-twisted script does.
I'm using twisted in a thread together with wxPython.
Everything works quite fine, but I'm getting a strange traceback when I exit
here's the scenario:
wx runs in the main thread
twisted runs in a secondary thread which is started like:
_daemon = DaemonLoop(self,self._port)
where Daemonloop is (partial):
def __init__(self, wxEvtHandler, port):
self.ui = UIProxy(wxEvtHandler)
# Run reactor
I stop the application from the main thread using
_daemon.stop() <- should kill the twisted reactor
wx.Exit() <- kills the main thread
The app exits (on linux), but I get this traceback:
Unhandled exception in thread started by <bound method DaemonLoop.__bootstrap
of <DaemonLoop(Thread-1, stopped daemon)>>
Traceback (most recent call last):
File "/usr/lib/python2.3/threading.py", line 451, in __bootstrap
File "/usr/lib/python2.3/threading.py", line 460, in __stop
File "/usr/lib/python2.3/threading.py", line 256, in notifyAll
File "/usr/lib/python2.3/threading.py", line 238, in notify
currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
The problem seems to be on windows. There the app doesn't exit all the time,
just sometimes. On Win the window disappears, but in the process list is
still the application process.
So this looks to me like there are still non daemon threads around which keep
the application from exiting.
On a side note: I'm also using the "deferToThread" method for some longer
running tasks, so it might well be that it's one of those threads causing the
issue. Is there a way to figure out which thread doesn't die?
Any pointers are highly appreciated.
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417