Hi,
I made a mistake in my previous message, this issue is on Windows, Linux and
Mac. One of my testers gave me incorrect information.
I apologize.
Thank you.
> -Original Message-
> From: rsga...@inbox.com
> Sent: Sun, 14 Nov 2010 15:12:18 -0800
> To: twisted-python@twistedmatrix.com
> Sub
Hi,
I think the best way to debug this is to give you all the source code. You can
find it here: http://bit.ly/doEiEJ
To give you all some background on this project: It is a freeware client that
uses sockets to connect to a multiplayer game server (currently plays Monopoly
and Uno). You will i
Hi,
Yes, it uses the speechd module on Linux (which uses a thread). The speechd
module provided speech output for our visually impaired users. However, when I
run the program without speechd at all, I still have this problem. I'm pretty
sure it is wxreactor and not speechd that is causing this p
On Sun, 2010-11-14 at 09:28 -0800, RSGames Support wrote:
> Hi,
> Well, I close the application (by clicking the X). Then a few seconds later,
> Ubuntu comes up with a dialog asking me if I want to force quit the
> application. gdb reports the following when I force quit: Program terminated
> wi
Hi,
Well, I close the application (by clicking the X). Then a few seconds later,
Ubuntu comes up with a dialog asking me if I want to force quit the
application. gdb reports the following when I force quit: Program terminated
with signal SIGKILL, Killed.
As far as to why it is crashing, I'm alm
On Sun, 2010-11-14 at 16:07 +0100, Dominic van Berkel wrote:
> Hi all,
>
> It appears that I have managed to loop a ProcessProtocol subclass's
> transport.write() right back into its outReceived. It's not directly
> called, which leads me to believe that somehow stdin and stdout got tied
> up.
C
On Sun, 2010-11-14 at 05:29 +, exar...@twistedmatrix.com wrote:
> On 03:56 am, rsga...@inbox.com wrote:
> >Hello,
> >My Twisted Python application with wxReactor crashes every time the
> >user exits the application.
>
> What do you mean when you say "crashes"? A SIGSEGV is probably due to a
On 14-11-2010 16:07, Dominic van Berkel wrote:
> Hi all,
>
> It appears that I have managed to loop a ProcessProtocol subclass's
> transport.write() right back into its outReceived. It's not directly
> called, which leads me to believe that somehow stdin and stdout got tied
> up. Anything thrown
Hi all,
It appears that I have managed to loop a ProcessProtocol subclass's
transport.write() right back into its outReceived. It's not directly
called, which leads me to believe that somehow stdin and stdout got tied
up. Anything thrown at transport.write() doesn't appear to reach the
actual pr
