Re: hang on leopard

Desktop wxRuby
1

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
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
[email protected]
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

2

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.

3

Zhang P. 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