Hello ...
I''m a newbie to ruby and wxruby.
I''m trying to
create 1 frame (the app) that creates 2 dialog boxes. Each dialog box
has wxtextctrl, and 1 dialog class has 1 thread and the other has 2
threads.
At first, I suspect the problem is with the thread
interaction between ruby and wxwidget. I spent countless hours to try
to figure out why the hang. Yes, I know the trick to use the Timer
class to work ...
Just out of curiosity, I tried to run the same
code with no changes on Windows XP running under Parallels on my
Leopard, and to my surprise, it works like a champ .....
Any advise on what I might be doing wrong?
Thanks in advance!
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users
Hi Zhang Peng wrote:> I''m a newbie to ruby and wxruby.Welcome> > I''m trying to create 1 frame (the app) that creates 2 dialog boxes. > Each dialog box has wxtextctrl, and 1 dialog class has 1 thread and > the other has 2 threads.Why are you using separate threads - what sort of work is being done in the subordinate threads? Is it the GUI that is hanging, or the non-GUI tasks? I would definitely not advise running wxRuby GUI code outside the main GUI thread.> Just out of curiosity, I tried to run the same code with no changes on > Windows XP running under Parallels on my Leopard, and to my surprise, > it works like a champ ..... > > Any advise on what I might be doing wrong?Hard to say anything further without seeing a short working example. cheers alex
Hi Alex, Thanks for the quick reply. I appreciate it. My apps has 3 user threads: 1. A dialog box that shows numbers in flashing fashion. This dialog has a number thread that shows a number, sleep, show next number, sleep, .... 2. A dialog box that shows running time (one thread), and another thread running waiting for the number thread to finish showing the numbers, and wait for a user to type in the result of adding up those numbers. BTW, at one point, my code is working fine on leopard, but it keeps giving me the following error once every 5 tries or so: *** Exception handlers were not properly removed. Some code has jumped or returned out of an NS_DURING...NS_HANDLER region without using the NS_VOIDRETURN or NS_VALUERETURN macros. And, I was trying to so many things to try to get rid of that error, and I''m now in a state where when I run the code, it works like a champ in the 1st try, but when I try it again for the second time, the whole thing hang .... I.e., beach ball spinning, and I have to kill the process to get out of it. Note that as I said in my original post, the same code runs fine on Windows XP .... I could be wrong, but I don''t think I run GUI thread ... I have a dialog based class, and I create a thread or two inside the class. In other words, I do not use Thread.new to initiate the dialog class. I tried to make smaller example, but the problem did not show up. The project itself is not big since I''m trying things out. only 4 small ruby files. I do not mind sending the files if you are interested in seeing and running it. Sincerely ... Zhang Peng ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Monday, February 18, 2008 8:42:15 AM Subject: Re: [wxruby-users] hang on leopard Hi Zhang Peng wrote:>I''m a newbie to ruby and wxruby. Welcome> >I''m trying to create 1 frame (the app) that creates 2 dialog boxes.>Each dialog box has wxtextctrl, and 1 dialog class has 1 thread and>the other has 2 threads. Why are you using separate threads - what sort of work is being done in the subordinate threads? Is it the GUI that is hanging, or the non-GUI tasks? I would definitely not advise running wxRuby GUI code outside the main GUI thread.>Just out of curiosity, I tried to run the same code with no changes on>Windows XP running under Parallels on my Leopard, and to my surprise,>it works like a champ ......> >Any advise on what I might be doing wrong? Hard to say anything further without seeing a short working example. cheers alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080218/efe880ae/attachment.html
Zhang Zhang Peng wrote:> 1. A dialog box that shows numbers in flashing fashion. This dialog > has a number thread that shows a number, sleep, show next number, > sleep, .... > > 2. A dialog box that shows running time (one thread), and another > thread running waiting for the number thread to finish showing the > numbers, and wait for a user to type in the result of adding up those > numbers.It sounds like you are using the Threads just to time events rather than carry out more complex background tasks. In this case I would strongly recommend that you use Wx::Timer directly. This will give you more accurate timing than using threads and sleep, and will avoid the complexity of using threads as well. As of 1.9.4, there''s simple idioms for using Timer: Wx::Timer.every(milliseconds) do # repeated event end Wx::Timer.after(milliseconds) do # delayed event end There''s an example of a ticking clock in bigdemo/wxStatusBar.rbw in the samples, which uses Wx::Timer. This might be helpful. cheers alex
Hi Alex, Thanks. I''ll look into it. BTW, just an FYI: The "hang" problem disappears after I restart my leopard machine, and I''m back to my original issues where I kept getting the following message at random times (the code works, however): 2008-02-18 16:00:06.129 ruby[686:10b] *** Exception handlers were not properly removed. Some code has jumped or returned out of an NS_DURING...NS_HANDLER region without using the NS_VOIDRETURN or NS_VALUERETURN macros. Mon Feb 18 16:00:06 djonli-djonlis-macbook-pro-17.local ruby[686] <Error>: CGContextRestoreGState: invalid context What could I had done wrong? Regards ... Djonli. ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Monday, February 18, 2008 11:24:21 AM Subject: Re: [wxruby-users] hang on leopard Zhang Zhang Peng wrote:>1. A dialog box that shows numbers in flashing fashion. This dialog>has a number thread that shows a number, sleep, show next number,>sleep, .....> >2. A dialog box that shows running time (one thread), and another>thread running waiting for the number thread to finish showing the>numbers, and wait for a user to type in the result of adding up those>numbers. It sounds like you are using the Threads just to time events rather than carry out more complex background tasks. In this case I would strongly recommend that you use Wx::Timer directly. This will give you more accurate timing than using threads and sleep, and will avoid the complexity of using threads as well. As of 1.9.4, there''s simple idioms for using Timer: Wx::Timer.every(milliseconds) do # repeated event end Wx::Timer.after(milliseconds) do # delayed event end There''s an example of a ticking clock in bigdemo/wxStatusBar.rbw in the samples, which uses Wx::Timer. This might be helpful. cheers alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080218/c9da6cb7/attachment.html
Hi Alex, An update: The error messages do not happen if I do not do show/hide the 2 dialog boxes. Is there anything that I should do before calling show(false) and show(true)? Thanks in advance! ----- Original Message ---- From: Zhang Peng <zpeng1 at yahoo.com> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Monday, February 18, 2008 4:04:56 PM Subject: Re: [wxruby-users] hang on leopard Hi Alex, Thanks. I''ll look into it. BTW, just an FYI: The "hang" problem disappears after I restart my leopard machine, and I''m back to my original issues where I kept getting the following message at random times (the code works, however): 2008-02-18 16:00:06.129 ruby[686:10b] *** Exception handlers were not properly removed. Some code has jumped or returned out of an NS_DURING...NS_HANDLER region without using the NS_VOIDRETURN or NS_VALUERETURN macros. Mon Feb 18 16:00:06 djonli-djonlis-macbook-pro-17.local ruby[686] <Error>: CGContextRestoreGState: invalid context What could I had done wrong? Regards ... Djonli. ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Monday, February 18, 2008 11:24:21 AM Subject: Re: [wxruby-users] hang on leopard Zhang Zhang Peng wrote:>1. A dialog box that shows numbers in flashing fashion. This dialog>has a number thread that shows a number, sleep, show next number,>sleep, ......> >2. A dialog box that shows running time (one thread), and another>thread running waiting for the number thread to finish showing the>numbers, and wait for a user to type in the result of adding up those>numbers. It sounds like you are using the Threads just to time events rather than carry out more complex background tasks. In this case I would strongly recommend that you use Wx::Timer directly. This will give you more accurate timing than using threads and sleep, and will avoid the complexity of using threads as well. As of 1.9.4, there''s simple idioms for using Timer: Wx::Timer.every(milliseconds) do # repeated event end Wx::Timer.after(milliseconds) do # delayed event end There''s an example of a ticking clock in bigdemo/wxStatusBar.rbw in the samples, which uses Wx::Timer. This might be helpful. cheers alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -----Inline Attachment Follows----- _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080218/ea80be44/attachment-0001.html
Zhang Peng wrote:> The error messages do not happen if I do not do show/hide the 2 dialog > boxes. > > Is there anything that I should do before calling show(false) and > show(true)?Not that I can think of. It might be worth checking the first argument to Dialog.new - I would recommend that the Dialogs are given the frame as the parent, not nil. You may be doing this already.> 2008-02-18 16:00:06.129 ruby[686:10b] *** Exception handlers were not > properly removed. Some code has jumped or returned out of an > NS_DURING...NS_HANDLER region without using the NS_VOIDRETURN or > NS_VALUERETURN macros.I haven''t seen this error message before. If you''re able to isolate the error, please post the code as I use Leopard as my main OS and could give try it out. thanks alex
Yes. I already use frame as the parent. Can I send you the zip file? I isolate it to about 350 lines ... the part that is in question is less than 50 lines. Most of the lines are from the xrc file and setup window/frame/dialog. ========================================= ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Tuesday, February 19, 2008 2:46:12 AM Subject: Re: [wxruby-users] hang on leopard Zhang Peng wrote:>The error messages do not happen if I do not do show/hide the 2 dialog>boxes.> >Is there anything that I should do before calling show(false) and>show(true)? Not that I can think of. It might be worth checking the first argument to Dialog.new - I would recommend that the Dialogs are given the frame as the parent, not nil. You may be doing this already.>2008-02-18 16:00:06.129 ruby[686:10b] *** Exception handlers were not>properly removed. Some code has jumped or returned out of an>NS_DURING...NS_HANDLER region without using the NS_VOIDRETURN or>NS_VALUERETURN macros. I haven''t seen this error message before. If you''re able to isolate the error, please post the code as I use Leopard as my main OS and could give try it out. thanks alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080219/2e9c1dba/attachment.html
Hi Alex,
Finally, I got my code to work properly by not using the show(true) and
show(false) pair within a thread in the classes that subclass from Dialog. The
symptoms I experienced if you put the show(true/false) pair within a Thread, you
get the following problems:
1. The entire application hangs .. beach ball spinning in leopard.
2. I have seen several segmentation fault during my test the past few days.
3. The application kept printing the following errors once every few tests.
2008-02-18 16:00:06.129 ruby[686:10b] *** Exception handlers were not properly
removed. Some code has jumped or returned out of an NS_DURING...NS_HANDLER
region without using the NS_VOIDRETURN or NS_VALUERETURN macros.
and
Mon Feb 18 16:00:06 <computer name> ruby[686] <Error>:
CGContextRestoreGState: invalid context
Now, here are the high level code that causes the problem on 10.5.2 with ruby
version 1.86 and wxruby 1.9.4 (The same source code does not cause any problem
on Windows XP running under Parallels on OS X):
===========================================PROBLEMATIC CODE THAT CAUSES HANG ON
LEOPARD
Within 15 times the button is hit (as soon
as 1 or 2 hits sometimes)
===========================================
def on_button(event)
$dialog1.start
end
class dlg1:
def start
if (@dialog1Thread == nil)
@dialog1Thread = Thread.new {
loop do
$dialog1.show(true)
$dialog2.start
...
$dialog1.show(false)
Thread.stop
end # loop do
} # @flashModeThread = Thread.new
else # if (@ dialog1Thread == nil)
@dialog1Thread.run
end # if (@ dialog1Thread == nil)
end # def start
class dlg2:
def start
if (@dialog2Thread == nil)
@dialog2Thread = Thread.new {
loop do
$dialog2.show(true)
...
$dialog2.show(false)
Thread.stop
end # loop do
}
else
@ dialog2Thread.run
end
end # dialog2Thread
================================================MOVING show(true/false) pair out
from the dialog
thread to the on_button solves the issue
================================================
def on_button(event)
$dialog1.show(true)
$dialog2.show(true)
$dialog1.start
if $WaitTimer == nil
$WaitTimer = Wx::Timer.every(1) do
if $dialog2.done == true
$dialog1.show(false) if $dialog1 != nil
$dialog2.show(false) if $dialog2 != nil
$WaitTimer.stop
end
end
else
$WaitTimer.start
end
end
>From my testing, it surely looks like there is a problem with using
Wx''s show(true/false) within ruby''s Thread.
But hopefully you can see something else that I might had done wrong, because it
is much easier for me to fix my code :-) :-) :-)
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/wxruby-users/attachments/20080220/8fb5d587/attachment.html
Zhang Peng wrote:> Finally, I got my code to work properly by not using the show(true) > and show(false) pair within a thread in the classes that subclass from > Dialog. The symptoms I experienced if you put the show(true/false) > pair within a Thread, you get the following problems:...> From my testing, it surely looks like there is a problem with using > Wx''s show(true/false) within ruby''s Thread.Thanks for posting your code. I agree with your analysis ... but ... The wxWidgets documentation and mailing list are clear that GUI calls in wxWidgets (C++), like show(), should be restricted to a single thread only. Now, ruby 1.8 threads are not the same as OS threads in wxWidgets, but some of the issues may be the same. In particular, the error message that you are getting sounds like OS X is complaining that execution is being prematurely switched out of some core operation. That sounds to me like a possible thread problem.> But hopefully you can see something else that I might had done wrong, > because it is much easier for me to fix my codeI think it is a primarily a design problem. You have a lot of globals, and a lot of Threads. In general, if you have a background task running in a ruby thread, notifications about the status of that thread''s work should be handled either by a properly shared variable (using Mutex if needed), or by posting a Wx::Event from the slave thread to the master GUI thread. If you were able to say a bit more about why you are using these Threads, we''d be happy to be more specific about a safer alternative. alex
Thanks for the explanation, Alex. If it is a thread issue, I wonder why I couldn''t duplicate it on XP? Since I can''t duplicate it on XP, I was thinking that it is not just a pure thread issue, but Wx for OSX + ruby thread combination is the culprit. If it is a pure thread issue, I would think that I should had hit it on XP too since I did an extensive testing on XP without seeing any problem, unless I was really lucky to not hit the thread bug on XP. I''m already using Mutex for shared variables. Thanks for offering help on design choice. I appreciate it ! I don''t actually have a lot of globals and threads ... only 2 globals and 3 threads. Let me try to explain: I have one dialog box that shows a number flashing on the screen one after another, and another dialog box that shows the time and a input text field to collect the answer the user types in for adding up all those numbers from the other dialog. So, I have 2 global variables: one for each instance of the dialog box. I use global because I do not want to destroy and create a new instance of the dialog box every time a user want to do the exercise. I have 3 threads: one to show the flashing number, one to collect answer, and one for showing the time. I use WxTimer.every() for the timer per your suggestion. I use ruby thread for the other 2 as you see in the code I posted yesterday. So, when user hit the button, both ruby threads will start/resume their tasks: one to show the number and one to collect the answer, and WxTimer shows the time. If I can put the show(true/false) pair within the ruby threads, I do not need to create another WxTimer threads on my main thread to check when to "hide" the dialog box. Thanks! ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Wednesday, February 20, 2008 3:13:54 PM Subject: Re: [wxruby-users] hang on leopard Zhang Peng wrote:>Finally, I got my code to work properly by not using the show(true)>and show(false) pair within a thread in the classes that subclass from>Dialog. The symptoms I experienced if you put the show(true/false)>pair within a Thread, you get the following problems: ....> >Frommy testing, it surely looks like there is a problem with using>Wx''s show(true/false) within ruby''s Thread. Thanks for posting your code. I agree with your analysis .... but .... The wxWidgets documentation and mailing list are clear that GUI calls in wxWidgets (C++), like show(), should be restricted to a single thread only. Now, ruby 1.8 threads are not the same as OS threads in wxWidgets, but some of the issues may be the same. In particular, the error message that you are getting sounds like OS X is complaining that execution is being prematurely switched out of some core operation. That sounds to me like a possible thread problem.>But hopefully you can see something else that I might had done wrong,>because it is much easier for me to fix my code I think it is a primarily a design problem. You have a lot of globals, and a lot of Threads. In general, if you have a background task running in a ruby thread, notifications about the status of that thread''s work should be handled either by a properly shared variable (using Mutex if needed), or by posting a Wx::Event from the slave thread to the master GUI thread. If you were able to say a bit more about why you are using these Threads, we''d be happy to be more specific about a safer alternative. alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080220/a90a29cc/attachment.html
Zhang Peng wrote:> If it is a thread issue, I wonder why I couldn''t duplicate it on XP? > Since I can''t duplicate it on XP, I was thinking that it is not just a > pure thread issue, but Wx for OSX + ruby thread combination is the > culprit.Because wxRuby / wxWidgets uses different native platform functions internally, there''s no guarantee that if you''re doing something wrong, it will fail in the same way, or at all, on different platforms. But it should always work if done right ...> Thanks for offering help on design choice. I appreciate it ! > > I don''t actually have a lot of globals and threads ... only 2 globals > and 3 threads. Let me try to explain: > > I have one dialog box that shows a number flashing on the screen one > after another, and another dialog box that shows the time and a input > text field to collect the answer the user types in for adding up all > those numbers from the other dialog.OK. First of all, I really don''t think you need to use threads or globals at all to achieve this. wxRuby like other GUI packages is essentially event driven: updates to the GUI should be driven by events. This includes user interaction (clicking a button) or timed events (a timer ticks).> So, I have 2 global variables: one for each instance of the dialog > box. I use global because I do not want to destroy and create a new > instance of the dialog box every time a user want to do the exercise.Fair enough. You could make them instance variables of your Wx::App class, create them when the app starts, and provide an accessor to them. Then you could access them anywhere in your code with Wx::THE_APP.number_dialog etc.> I have 3 threads: one to show the flashing number, one to collect > answer, and one for showing the time. I use WxTimer.every() for the > timer per your suggestion. I use ruby thread for the other 2 as you > see in the code I posted yesterday.I was suggesting you use Wx::Timer in place of threads. A timer to update the status bar with the current time doesn''t need to be much more complicated than: Wx::Timer.every(1000) { self.status_text = Time.now.to_s } No threads needed...> So, when user hit the button, both ruby threads will start/resume > their tasks: one to show the number and one to collect the answer, and > WxTimer shows the time.You can catch when the button is clicked with evt_button, and then just call a method on the other dialog to tell it to stop displaying numbers. Again, I''m sure you don''t need threads here. Finally, you can catch when characters are entered in a TextCtrl using evt_text. Or, if you want to monitor the TextCtrl''s contents continually, again, just use a Timer and call text_ctrl.value. If you need to stop and start Timed actions, you can capture the return value of Wx::Timer.every and call stop on it: @number_timer = Wx::Timer.every(2500) do display_number # call code to display a new number on the screen end @number_timer.stop # Stop the timer ticking @number_timer.start # Restart it later hth alex
Hello Zhang, As much as we even would like that to be true, the problem is, there is a difference between all three platforms. On Windows, we use Microsoft Visual C++ Compiler to compile wxRuby, as that is the most common compiler used for Ruby. On Linux, we use GCC, as that is the general one. And on Mac OS X, we use Cocoa for the most part, and some GCC. Now with these three different compilers, each is oviously creating a different executable, where certian features are not going to be available. So while, say on Linux and Windows, we could possibly use Threads to work with the GUI Components of wxRuby, on Mac, that may not be the case. On Mac and on Linux, there are certian classes not available, just like on Windows. Cause of all of this, there are bound to be problems on certian platforms, where they wouldn''t arise on others. I''ve ran into this kind of deal, working with various projects between just Windows and Linux, but it can be worse if adding in Mac OS X. Just cause your doing the same thing as far as code goes between different platforms, the actual backends are doing completely different things, to get things to work the way you want them to. L8ers, Mario Steele On 2/20/08, Zhang Peng <zpeng1 at yahoo.com> wrote:> > Thanks for the explanation, Alex. > > If it is a thread issue, I wonder why I couldn''t duplicate it on XP? Since > I can''t duplicate it on XP, I was thinking that it is not just a pure thread > issue, but Wx for OSX + ruby thread combination is the culprit. If it is a > pure thread issue, I would think that I should had hit it on XP too since I > did an extensive testing on XP without seeing any problem, unless I was > really lucky to not hit the thread bug on XP. > > I''m already using Mutex for shared variables. > > Thanks for offering help on design choice. I appreciate it ! > > I don''t actually have a lot of globals and threads ... only 2 globals and > 3 threads. Let me try to explain: > > I have one dialog box that shows a number flashing on the screen one after > another, and another dialog box that shows the time and a input text field > to collect the answer the user types in for adding up all those numbers from > the other dialog. > > So, I have 2 global variables: one for each instance of the dialog box. I > use global because I do not want to destroy and create a new instance of the > dialog box every time a user want to do the exercise. > > I have 3 threads: one to show the flashing number, one to collect answer, > and one for showing the time. I use WxTimer.every() for the timer per > your suggestion. I use ruby thread for the other 2 as you see in the code I > posted yesterday. > > So, when user hit the button, both ruby threads will start/resume their > tasks: one to show the number and one to collect the answer, and WxTimer > shows the time. > > If I can put the show(true/false) pair within the ruby threads, I do not > need to create another WxTimer threads on my main thread to check when to > "hide" the dialog box. > > Thanks! > > ----- Original Message ---- > From: Alex Fenton <alex at pressure.to> > To: General discussion of wxRuby <wxruby-users at rubyforge.org> > Sent: Wednesday, February 20, 2008 3:13:54 PM > Subject: Re: [wxruby-users] hang on leopard > > Zhang Peng wrote: > > Finally, I got my code to work properly by not using the show(true) > > and show(false) pair within a thread in the classes that subclass from > > Dialog. The symptoms I experienced if you put the show(true/false) > > pair within a Thread, you get the following problems: > ... > > >From my testing, it surely looks like there is a problem with using > > Wx''s show(true/false) within ruby''s Thread. > Thanks for posting your code. I agree with your analysis .... but .... > > The wxWidgets documentation and mailing list are clear that GUI calls in > wxWidgets (C++), like show(), should be restricted to a single thread > only. Now, ruby 1.8 threads are not the same as OS threads in wxWidgets, > but some of the issues may be the same. In particular, the error message > that you are getting sounds like OS X is complaining that execution is > being prematurely switched out of some core operation. That sounds to me > like a possible thread problem. > > But hopefully you can see something else that I might had done wrong, > > because it is much easier for me to fix my code > I think it is a primarily a design problem. You have a lot of globals, > and a lot of Threads. In general, if you have a background task running > in a ruby thread, notifications about the status of that thread''s work > should be handled either by a properly shared variable (using Mutex if > needed), or by posting a Wx::Event from the slave thread to the master > GUI thread. > > If you were able to say a bit more about why you are using these > Threads, we''d be happy to be more specific about a safer alternative. > > alex > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > ------------------------------ > Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs> > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080220/af24765f/attachment-0001.html
Hi Alex, Thank you so much for taking time to give me the guidance! I''ll try your suggestion and remove the threads and see what happens ... Thanks again! ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Wednesday, February 20, 2008 5:35:41 PM Subject: Re: [wxruby-users] hang on leopard Zhang Peng wrote:>If it is a thread issue, I wonder why I couldn''t duplicate it on XP?>Since I can''t duplicate it on XP, I was thinking that it is not just a>pure thread issue, but Wx for OSX + ruby thread combination is the>culprit. Because wxRuby / wxWidgets uses different native platform functions internally, there''s no guarantee that if you''re doing something wrong, it will fail in the same way, or at all, on different platforms. But it should always work if done right ....>Thanks for offering help on design choice. I appreciate it !> >I don''t actually have a lot of globals and threads .... only 2 globals>and 3 threads. Let me try to explain:> >I have one dialog box that shows a number flashing on the screen one>after another, and another dialog box that shows the time and a input>text field to collect the answer the user types in for adding up all>those numbers from the other dialog. OK. First of all, I really don''t think you need to use threads or globals at all to achieve this. wxRuby like other GUI packages is essentially event driven: updates to the GUI should be driven by events. This includes user interaction (clicking a button) or timed events (a timer ticks).>So, I have 2 global variables: one for each instance of the dialog>box. I use global because I do not want to destroy and create a new>instance of the dialog box every time a user want to do the exercise. Fair enough. You could make them instance variables of your Wx::App class, create them when the app starts, and provide an accessor to them. Then you could access them anywhere in your code with Wx::THE_APP.number_dialog etc.>I have 3 threads: one to show the flashing number, one to collect>answer, and one for showing the time. I use WxTimer.every() for the>timer per your suggestion. I use ruby thread for the other 2 as you>see in the code I posted yesterday. I was suggesting you use Wx::Timer in place of threads. A timer to update the status bar with the current time doesn''t need to be much more complicated than: Wx::Timer.every(1000) { self.status_text = Time.now.to_s } No threads needed...>So, when user hit the button, both ruby threads will start/resume>their tasks: one to show the number and one to collect the answer, and>WxTimer shows the time. You can catch when the button is clicked with evt_button, and then just call a method on the other dialog to tell it to stop displaying numbers. Again, I''m sure you don''t need threads here. Finally, you can catch when characters are entered in a TextCtrl using evt_text. Or, if you want to monitor the TextCtrl''s contents continually, again, just use a Timer and call text_ctrl.value. If you need to stop and start Timed actions, you can capture the return value of Wx::Timer.every and call stop on it: @number_timer = Wx::Timer.every(2500) do display_number # call code to display a new number on the screen end @number_timer.stop # Stop the timer ticking @number_timer.start # Restart it later hth alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080221/5b81cd75/attachment.html
Hi Mario, Thanks for the explanation. I appreciate it. The _only_ reason I was trying out scripting language is because of the "cross platform" (write once and use everywhere). I''m going to give another try of _not_ using thread and use WxEvent per Alex''s suggestion and see what happens. If it still give the same issues, then I guess I have to rethink my strategy .... Thanks again for the feedback. ----- Original Message ---- From: Mario Steele <mario at ruby-im.net> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Wednesday, February 20, 2008 7:52:48 PM Subject: Re: [wxruby-users] hang on leopard Hello Zhang, As much as we even would like that to be true, the problem is, there is a difference between all three platforms. On Windows, we use Microsoft Visual C++ Compiler to compile wxRuby, as that is the most common compiler used for Ruby. On Linux, we use GCC, as that is the general one. And on Mac OS X, we use Cocoa for the most part, and some GCC. Now with these three different compilers, each is oviously creating a different executable, where certian features are not going to be available. So while, say on Linux and Windows, we could possibly use Threads to work with the GUI Components of wxRuby, on Mac, that may not be the case. On Mac and on Linux, there are certian classes not available, just like on Windows. Cause of all of this, there are bound to be problems on certian platforms, where they wouldn''t arise on others. I''ve ran into this kind of deal, working with various projects between just Windows and Linux, but it can be worse if adding in Mac OS X. Just cause your doing the same thing as far as code goes between different platforms, the actual backends are doing completely different things, to get things to work the way you want them to. L8ers, Mario Steele On 2/20/08, Zhang Peng <zpeng1 at yahoo.com> wrote: Thanks for the explanation, Alex. If it is a thread issue, I wonder why I couldn''t duplicate it on XP? Since I can''t duplicate it on XP, I was thinking that it is not just a pure thread issue, but Wx for OSX + ruby thread combination is the culprit. If it is a pure thread issue, I would think that I should had hit it on XP too since I did an extensive testing on XP without seeing any problem, unless I was really lucky to not hit the thread bug on XP. I''m already using Mutex for shared variables. Thanks for offering help on design choice. I appreciate it ! I don''t actually have a lot of globals and threads ... only 2 globals and 3 threads. Let me try to explain: I have one dialog box that shows a number flashing on the screen one after another, and another dialog box that shows the time and a input text field to collect the answer the user types in for adding up all those numbers from the other dialog. So, I have 2 global variables: one for each instance of the dialog box. I use global because I do not want to destroy and create a new instance of the dialog box every time a user want to do the exercise. I have 3 threads: one to show the flashing number, one to collect answer, and one for showing the time. I use WxTimer.every() for the timer per your suggestion. I use ruby thread for the other 2 as you see in the code I posted yesterday. So, when user hit the button, both ruby threads will start/resume their tasks: one to show the number and one to collect the answer, and WxTimer shows the time. If I can put the show(true/false) pair within the ruby threads, I do not need to create another WxTimer threads on my main thread to check when to "hide" the dialog box. Thanks! ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Wednesday, February 20, 2008 3:13:54 PM Subject: Re: [wxruby-users] hang on leopard Zhang Peng wrote:> Finally, I got my code to work properly by not using the show(true) > and show(false) pair within a thread in the classes that subclass from> Dialog. The symptoms I experienced if you put the show(true/false) > pair within a Thread, you get the following problems:....> >From my testing, it surely looks like there is a problem with using> Wx''s show(true/false) within ruby''s Thread.Thanks for posting your code. I agree with your analysis .... but .... The wxWidgets documentation and mailing list are clear that GUI calls in wxWidgets (C++), like show(), should be restricted to a single thread only. Now, ruby 1.8 threads are not the same as OS threads in wxWidgets, but some of the issues may be the same. In particular, the error message that you are getting sounds like OS X is complaining that execution is being prematurely switched out of some core operation. That sounds to me like a possible thread problem.> But hopefully you can see something else that I might had done wrong, > because it is much easier for me to fix my codeI think it is a primarily a design problem. You have a lot of globals, and a lot of Threads. In general, if you have a background task running in a ruby thread, notifications about the status of that thread''s work should be handled either by a properly shared variable (using Mutex if needed), or by posting a Wx::Event from the slave thread to the master GUI thread. If you were able to say a bit more about why you are using these Threads, we''d be happy to be more specific about a safer alternative. alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users Never miss a thing. Make Yahoo your homepage. _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -----Inline Attachment Follows----- _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080221/cd533977/attachment.html
Hey Zhang, No problem. If you need help re-structuring the layout of your program, feel free to email me, and I''ll be happy to help you out with it. Good Luck, Mario Steele On 2/21/08, Zhang Peng <zpeng1 at yahoo.com> wrote:> > Hi Mario, > > Thanks for the explanation. I appreciate it. > > The _only_ reason I was trying out scripting language is because of the > "cross platform" (write once and use everywhere). > > I''m going to give another try of _not_ using thread and use WxEvent per > Alex''s suggestion and see what happens. > > If it still give the same issues, then I guess I have to rethink my > strategy .... > > Thanks again for the feedback. > > ----- Original Message ---- > From: Mario Steele <mario at ruby-im.net> > To: General discussion of wxRuby <wxruby-users at rubyforge.org> > Sent: Wednesday, February 20, 2008 7:52:48 PM > Subject: Re: [wxruby-users] hang on leopard > > Hello Zhang, > > As much as we even would like that to be true, the problem is, there is a > difference between all three platforms. On Windows, we use Microsoft Visual > C++ Compiler to compile wxRuby, as that is the most common compiler used for > Ruby. On Linux, we use GCC, as that is the general one. And on Mac OS X, > we use Cocoa for the most part, and some GCC. Now with these three > different compilers, each is oviously creating a different executable, where > certian features are not going to be available. So while, say on Linux and > Windows, we could possibly use Threads to work with the GUI Components of > wxRuby, on Mac, that may not be the case. On Mac and on Linux, there are > certian classes not available, just like on Windows. > > Cause of all of this, there are bound to be problems on certian platforms, > where they wouldn''t arise on others. I''ve ran into this kind of deal, > working with various projects between just Windows and Linux, but it can be > worse if adding in Mac OS X. > > Just cause your doing the same thing as far as code goes between different > platforms, the actual backends are doing completely different things, to get > things to work the way you want them to. > > L8ers, > Mario Steele > > On 2/20/08, Zhang Peng <zpeng1 at yahoo.com> wrote: > > > > Thanks for the explanation, Alex. > > > > If it is a thread issue, I wonder why I couldn''t duplicate it on XP? > > Since I can''t duplicate it on XP, I was thinking that it is not just a pure > > thread issue, but Wx for OSX + ruby thread combination is the culprit. If > > it is a pure thread issue, I would think that I should had hit it on XP too > > since I did an extensive testing on XP without seeing any problem, unless I > > was really lucky to not hit the thread bug on XP. > > > > I''m already using Mutex for shared variables. > > > > Thanks for offering help on design choice. I appreciate it ! > > > > I don''t actually have a lot of globals and threads ... only 2 globals > > and 3 threads. Let me try to explain: > > > > I have one dialog box that shows a number flashing on the screen one > > after another, and another dialog box that shows the time and a input text > > field to collect the answer the user types in for adding up all those > > numbers from the other dialog. > > > > So, I have 2 global variables: one for each instance of the dialog box. > > I use global because I do not want to destroy and create a new instance of > > the dialog box every time a user want to do the exercise. > > > > I have 3 threads: one to show the flashing number, one to collect > > answer, and one for showing the time. I use WxTimer.every() for the > > timer per your suggestion. I use ruby thread for the other 2 as you see in > > the code I posted yesterday. > > > > So, when user hit the button, both ruby threads will start/resume their > > tasks: one to show the number and one to collect the answer, and WxTimer > > shows the time. > > > > If I can put the show(true/false) pair within the ruby threads, I do not > > need to create another WxTimer threads on my main thread to check when to > > "hide" the dialog box. > > > > Thanks! > > > > ----- Original Message ---- > > From: Alex Fenton <alex at pressure.to> > > To: General discussion of wxRuby <wxruby-users at rubyforge.org> > > Sent: Wednesday, February 20, 2008 3:13:54 PM > > Subject: Re: [wxruby-users] hang on leopard > > > > Zhang Peng wrote: > > > Finally, I got my code to work properly by not using the show(true) > > > and show(false) pair within a thread in the classes that subclass from > > > > > Dialog. The symptoms I experienced if you put the show(true/false) > > > pair within a Thread, you get the following problems: > > ... > > > >From my testing, it surely looks like there is a problem with using > > > Wx''s show(true/false) within ruby''s Thread. > > Thanks for posting your code. I agree with your analysis .... but .... > > > > The wxWidgets documentation and mailing list are clear that GUI calls in > > > > wxWidgets (C++), like show(), should be restricted to a single thread > > only. Now, ruby 1.8 threads are not the same as OS threads in wxWidgets, > > > > but some of the issues may be the same. In particular, the error message > > > > that you are getting sounds like OS X is complaining that execution is > > being prematurely switched out of some core operation. That sounds to me > > > > like a possible thread problem. > > > But hopefully you can see something else that I might had done wrong, > > > because it is much easier for me to fix my code > > I think it is a primarily a design problem. You have a lot of globals, > > and a lot of Threads. In general, if you have a background task running > > in a ruby thread, notifications about the status of that thread''s work > > should be handled either by a properly shared variable (using Mutex if > > needed), or by posting a Wx::Event from the slave thread to the master > > GUI thread. > > > > If you were able to say a bit more about why you are using these > > Threads, we''d be happy to be more specific about a safer alternative. > > > > alex > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > ------------------------------ > > Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs> > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > -- > Mario Steele > http://www.trilake.net > http://www.ruby-im.net > http://rubyforge.org/projects/wxruby/ > http://rubyforge.org/projects/wxride/ > http://rubyforge.org/projects/vwmc/ > > -----Inline Attachment Follows----- > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > ------------------------------ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now.<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ> > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080221/6f774203/attachment.html
Hi Mario, Alex and you are great ! I''ll try not to bother you guys too much :-) :-) :-) I''m going to restructure my program and not use ruby threads in WxDialog based class, and use WxEvent instead per Alex''s suggestion. I''m sure you guys will have a chance to help me out again in the near future :-) :-) :-) Sincerely ... Z.P. ----- Original Message ---- From: Mario Steele <mario at ruby-im.net> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Thursday, February 21, 2008 8:14:51 PM Subject: Re: [wxruby-users] hang on leopard Hey Zhang, No problem. If you need help re-structuring the layout of your program, feel free to email me, and I''ll be happy to help you out with it. Good Luck, Mario Steele On 2/21/08, Zhang Peng <zpeng1 at yahoo.com> wrote: Hi Mario, Thanks for the explanation. I appreciate it. The _only_ reason I was trying out scripting language is because of the "cross platform" (write once and use everywhere). I''m going to give another try of _not_ using thread and use WxEvent per Alex''s suggestion and see what happens. If it still give the same issues, then I guess I have to rethink my strategy .... Thanks again for the feedback. ----- Original Message ---- From: Mario Steele <mario at ruby-im.net> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Wednesday, February 20, 2008 7:52:48 PM Subject: Re: [wxruby-users] hang on leopard Hello Zhang, As much as we even would like that to be true, the problem is, there is a difference between all three platforms. On Windows, we use Microsoft Visual C++ Compiler to compile wxRuby, as that is the most common compiler used for Ruby. On Linux, we use GCC, as that is the general one. And on Mac OS X, we use Cocoa for the most part, and some GCC. Now with these three different compilers, each is oviously creating a different executable, where certian features are not going to be available. So while, say on Linux and Windows, we could possibly use Threads to work with the GUI Components of wxRuby, on Mac, that may not be the case. On Mac and on Linux, there are certian classes not available, just like on Windows. Cause of all of this, there are bound to be problems on certian platforms, where they wouldn''t arise on others. I''ve ran into this kind of deal, working with various projects between just Windows and Linux, but it can be worse if adding in Mac OS X. Just cause your doing the same thing as far as code goes between different platforms, the actual backends are doing completely different things, to get things to work the way you want them to. L8ers, Mario Steele On 2/20/08, Zhang Peng <zpeng1 at yahoo.com> wrote: Thanks for the explanation, Alex. If it is a thread issue, I wonder why I couldn''t duplicate it on XP? Since I can''t duplicate it on XP, I was thinking that it is not just a pure thread issue, but Wx for OSX + ruby thread combination is the culprit. If it is a pure thread issue, I would think that I should had hit it on XP too since I did an extensive testing on XP without seeing any problem, unless I was really lucky to not hit the thread bug on XP. I''m already using Mutex for shared variables. Thanks for offering help on design choice. I appreciate it ! I don''t actually have a lot of globals and threads ... only 2 globals and 3 threads. Let me try to explain: I have one dialog box that shows a number flashing on the screen one after another, and another dialog box that shows the time and a input text field to collect the answer the user types in for adding up all those numbers from the other dialog. So, I have 2 global variables: one for each instance of the dialog box. I use global because I do not want to destroy and create a new instance of the dialog box every time a user want to do the exercise. I have 3 threads: one to show the flashing number, one to collect answer, and one for showing the time. I use WxTimer.every() for the timer per your suggestion. I use ruby thread for the other 2 as you see in the code I posted yesterday. So, when user hit the button, both ruby threads will start/resume their tasks: one to show the number and one to collect the answer, and WxTimer shows the time. If I can put the show(true/false) pair within the ruby threads, I do not need to create another WxTimer threads on my main thread to check when to "hide" the dialog box. Thanks! ----- Original Message ---- From: Alex Fenton <alex at pressure.to> To: General discussion of wxRuby <wxruby-users at rubyforge.org> Sent: Wednesday, February 20, 2008 3:13:54 PM Subject: Re: [wxruby-users] hang on leopard Zhang Peng wrote:> Finally, I got my code to work properly by not using the show(true) > and show(false) pair within a thread in the classes that subclass from> Dialog. The symptoms I experienced if you put the show(true/false) > pair within a Thread, you get the following problems:....> >From my testing, it surely looks like there is a problem with using> Wx''s show(true/false) within ruby''s Thread.Thanks for posting your code. I agree with your analysis .... but .... The wxWidgets documentation and mailing list are clear that GUI calls in wxWidgets (C++), like show(), should be restricted to a single thread only. Now, ruby 1.8 threads are not the same as OS threads in wxWidgets, but some of the issues may be the same. In particular, the error message that you are getting sounds like OS X is complaining that execution is being prematurely switched out of some core operation. That sounds to me like a possible thread problem.> But hopefully you can see something else that I might had done wrong, > because it is much easier for me to fix my codeI think it is a primarily a design problem. You have a lot of globals, and a lot of Threads. In general, if you have a background task running in a ruby thread, notifications about the status of that thread''s work should be handled either by a properly shared variable (using Mutex if needed), or by posting a Wx::Event from the slave thread to the master GUI thread. If you were able to say a bit more about why you are using these Threads, we''d be happy to be more specific about a safer alternative. alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users Never miss a thing. Make Yahoo your homepage. _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -----Inline Attachment Follows----- _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -----Inline Attachment Follows----- _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20080221/3cfb20b5/attachment-0001.html