I have some code that adds lines to a STC and scrolls the window if necessary to ensure that the last line is visible. This works fine on Windows, but causes a core dump on our linux boxes. Both are running wxpython 2.9 (2.9.4.0 on windows and 2.9.4.1 on linux).
The STC is declared as follows:
self.outputCtrl = stc.StyledTextCtrl(panel)
numLogLines = 0
The code that adds the line and scrolls the window looks like this:
def __onUpdateDisplay(self, arg1):
self.outputCtrl.AddText(arg1)
self.numLogLines += 1
self.outputCtrl.ScrollToLine(self.numLogLines)
Removing the ScrollToLine bit permits the code to run fine under linux ( except you have to scroll the window manually).
When it crashes it prints this error in the console:
foo.py: Fatal IO error 11 (Resource temporarily unavailable) on X server localhost:10.0.
On Fri, Feb 15, 2013 at 3:18 PM, patrick korsnick korsnick@gmail.com wrote:
I have some code that adds lines to a STC and scrolls the window if necessary to ensure that the last line is visible. This works fine on Windows, but causes a core dump on our linux boxes. Both are running wxpython 2.9 (2.9.4.0 on windows and 2.9.4.1 on linux).
The STC is declared as follows:
self.outputCtrl = stc.StyledTextCtrl(panel)
numLogLines = 0
The code that adds the line and scrolls the window looks like this:
def __onUpdateDisplay(self, arg1):
self.outputCtrl.AddText(arg1)
self.numLogLines += 1
self.outputCtrl.ScrollToLine(self.numLogLines)
Removing the ScrollToLine bit permits the code to run fine under linux ( except you have to scroll the window manually).
When it crashes it prints this error in the console:
foo.py: Fatal IO error 11 (Resource temporarily unavailable) on X server localhost:10.0.
Is the _onUpdateDisplay being called from another thread?
If so that is likely the problem as the UI is not threadsafe. Can work around this in many ways but easiest is likely to use CallAfter to delegate the call the main thread.
On Friday, February 15, 2013 2:18:58 PM UTC-7, patrick korsnick wrote:
I have some code that adds lines to a STC and scrolls the window if necessary to ensure that the last line is visible. This works fine on Windows, but causes a core dump on our linux boxes. Both are running wxpython 2.9 (2.9.4.0 on windows and 2.9.4.1 on linux).
The STC is declared as follows:
self.outputCtrl = stc.StyledTextCtrl(panel)
numLogLines = 0
The code that adds the line and scrolls the window looks like this:
def __onUpdateDisplay(self, arg1):
self.outputCtrl.AddText(arg1)
self.numLogLines += 1
self.outputCtrl.ScrollToLine(self.numLogLines)
Removing the ScrollToLine bit permits the code to run fine under linux ( except you have to scroll the window manually).
When it crashes it prints this error in the console:
foo.py: Fatal IO error 11 (Resource temporarily unavailable) on X server localhost:10.0.
Hmm, I must have misread something then- from the posts I read online it seemed that using pubsub was an approved way to share data between two threads.
So you’re saying the following is not a thread safe way to update a GUI:
On Fri, Feb 15, 2013 at 3:55 PM, patrick korsnick korsnick@gmail.com wrote:
Hmm, I must have misread something then- from the posts I read online it seemed that using pubsub was an approved way to share data between two threads.
So you’re saying the following is not a thread safe way to update a GUI:
Wow thanks for clearing that up! So essentially pubsub doesn’t buy us any thread safety (the only reason we switched to using it). Thus we can get rid of the pubsub stuff and go back to the way we were doing it before: (passing the TextCtrl to the second thread and calling write()) but this time we’ll wrap it with a CallAfter-- wx.CallAfter(theTextCtrl.write(“foo bar baz”)) and if I understand correctly it should be thread safe.
···
On Friday, February 15, 2013 3:01:18 PM UTC-7, Cody Precord wrote:
Hi,
On Fri, Feb 15, 2013 at 3:55 PM, patrick korsnick kors...@gmail.com wrote:
Hmm, I must have misread something then- from the posts I read online it seemed that using pubsub was an approved way to share data between two threads.
So you’re saying the following is not a thread safe way to update a GUI:
Personally I would suggest having interfaces to your GUI object - so
that the rest of your code doesn’t need to know anything else about
what the GUI is made up of and having the CallAfter in those methods
e.g. in your GUI class:
def UpdateStatus(self, NewStatusText):
“”" Update the user display of the status “”"
wx.CallAfter(_theTextCtrl.write(NewStatusText))
and in the non-GUI parts of your code:
ourGUI.UpdateStatus(“foo bar baz”)
Then most of your code will not need to have any awareness of wx or
of what components your GUI is made up of just that it has a
UpdateStatus method, etc., then if you need to use some other method
of displaying your status at some point down the line the changes
are localised to the GUI, e.g. if the user requests that all error
statuses be displayed in red and the rest in black you could extend
UpdateStatus to take an error code as an additional parameter,
defaulting to zero, if it is non-zero set the text colour to red,
otherwise set it to black, (both in a call after), change the text
control to a rich text control and in those places where you are
calling UpdateStatus where it is an error add a non-zero error code
to that call, rather than searching for all occurrences of
theTextCtrl.write and adding code all over the place to change the
colour appropriately. Then the user might request an audible signal
on a new error…
Hopefully you begin to see the advantages of separating GUI from
functional code.
Steve
···
On 15/02/13 22:23, patrick korsnick
wrote:
Wow thanks for clearing that up! So essentially pubsub
doesn’t buy us any thread safety (the only reason we switched to
using it). Thus we can get rid of the pubsub stuff and go back to
the way we were doing it before: (passing the TextCtrl to the
second thread and calling write()) but this time we’ll wrap it
with a CallAfter-- wx.CallAfter(theTextCtrl.write(“foo bar baz”))
and if I understand correctly it should be thread safe.
