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 S. [email protected]
To: General discussion of wxRuby [email protected]
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 S.
On 2/20/08, Zhang P. [email protected] 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 F. [email protected]
To: General discussion of wxRuby [email protected]
Sent: Wednesday, February 20, 2008 3:13:54 PM
Subject: Re: [wxruby-users] hang on leopard
Zhang P. 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
[email protected]
http://rubyforge.org/mailman/listinfo/wxruby-users
Never miss a thing. Make Yahoo your homepage.
wxruby-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wxruby-users
–
Mario S.
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
[email protected]
http://rubyforge.org/mailman/listinfo/wxruby-users
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs