Instabilities in wxRuby 1.9.6

I have recently started to use wxRuby, because I have used the wxWidgets
library from C++ for a few years and found it an excellent toolkit. I
am
using Ubuntu 8.04 and version 1.9.6 of wxRuby.

A problem though is a number of instabilities. This may be due to my
own
ignorance, but I have usually found C++/wxWidgets, once the program
compiles
it will at least stay working, if at times incorrectly. With wxRuby,
the
program sometimes just crashes out, or the event handler appears to
freeze.

The code below reproduces one problem. After opening one or two child
frames and then closing one of them, the program soon fails. I find
that
the frames stop receiving events, don’t redraw themselves when covered,
etc. Sometimes this happens very quickly, sometimes after a minute or
so.
Is this a bug, or should I be doing something different to show/hide
child
frames?

Thanks for any help with this.

Peter.

class ChildFrame < Wx::Frame
def initialize parent
super(parent, -1, “Child frame”)

viewMenu = Wx::Menu.new
viewMenu.append(Wx::ID_CLOSE, "Close\tCtrl-W", "Close this window")
evt_menu(Wx::ID_CLOSE) { show false }

menuBar = Wx::MenuBar.new
menuBar.append(viewMenu, "&View")
set_menu_bar menuBar

end
end

class TestFrame < Wx::Frame
def initialize
super(nil, -1, “Test Frame”)

menu = Wx::Menu.new
menuItem = Wx::MenuItem.new(menu, -1, "Show child")
menu.append_item menuItem
evt_menu(menuItem) { ChildFrame.new(self).show }

menuBar = Wx::MenuBar.new
menuBar.append(menu, "&View")
set_menu_bar menuBar

end
end

class TestApp < Wx::App
def on_init
TestFrame.new.show
end
end

TestApp.new.main_loop

Hello Peter,

Unfortunatly, the truth of the matter is, that this is a miss or hit
problem
we’ve been having lately with wxRuby, and the Ruby 1.8.6 p114. We’re
restricting the versioning to 114, due to the fact that any later
version
(The Pre 1.8.7), totally messes up the internal works all together. We
got
a nice suprise from the p114, which is part of the reason why we are
getting
instabilities. But truely, it’s more of a gotcha on our part, that we
should have programmed it differently then what we did.

More then likely, if your getting freezes on your app, it segfaulted,
but
has no console in which to report what is going on. You have to
realize,
that even though you’ve worked with wxWidgets and C++ in the past, we’re
using 3 different libraries to bring wxRuby together.

1.) wxWidgets ofcourse.
2.) SWIG, which gives us our Glue between Ruby and wxWidgets.
3.) Ruby’s core libraries.

At any point, any one of these libs can and more likely will fail, when
we
do major revisions to the backend, giving us all kinds of bugs to track
down. Often times then not, we end up releasing libraries that are
bugged
beyond what we can test for, and have to rely on users to find some bugs
for
us, and create examples for us to find the bugs, and pound out the bugs
from
the examples.

Unfortunatly, due to the change in the Garbage Collection system since
Patchlevel 114, they have dis-allowed creation of Objects while in a
Garbage
Collection Mark/Sweep, which was giving us our biggest headache. Ovious
reasons make it smart to not be creating objects while running a GC mark
loop, but in our case, we was simply creating a block to iterate over
our
internal hash of all created wxRuby Objects. So we pretty much had to
re-write it to use pure C Ruby Library functions, instead of relying on
rb_iterate, like was doing before. This is where our “faults” are
coming
from mostly.

As you can see with the Windows MSVC version of wxRuby, we’re having
major
problems in that area. Which is why among the others here, I’ll be glad
to
be rid of MSVC all together, but alas, we will still be making MSVC
versions
as long as people still use the MSVC version of Ruby. On the other
hand,
I’ll be working the MinGW version into working, which it has been doing
flawlessly (Aside from the bugs ofcourse), without all these problems of
needing to create manifests, and installing runtime dlls for several
different compiler environments. (5.0, 6.0, 7.0, 8.0, 9.0 20201.0 (I kid
there))

Alright, back to work on getting things stable with wxRuby!

L8ers,

Peter Lane wrote:

I have recently started to use wxRuby, because I have used the
wxWidgets library from C++ for a few years and found it an excellent
toolkit. I am using Ubuntu 8.04 and version 1.9.6 of wxRuby.

A problem though is a number of instabilities. This may be due to my
own ignorance, but I have usually found C++/wxWidgets, once the
program compiles it will at least stay working, if at times
incorrectly. With wxRuby, the program sometimes just crashes out, or
the event handler appears to freeze.
Thanks for the report. I can reproduce it and have filed this on the bug
tracker:
http://rubyforge.org/tracker/?func=detail&atid=218&aid=20255&group_id=35

I’m not yet sure where the problems lies, between SWIG, wxRuby and Ruby
itself. I think some recent “stable” ruby developments have created
problems for SWIG-generated code, or it could also be something I’ve
accidentally introduced in 1.9.6. If it’s convenient, perhaps could you
try with wxRuby 1.9.5 or .4

alex