wxruby users - Aug 2006 - Progress on crashing

I''m using my SpaceMonkeys game as a testbed to try to get rid of
crashing problems. Earlier today, it would crash for me almost
immediately, every time. Now, I was able to get about 50 turns into the
game!

I mentioned the first big change in a different email. The new change I
just checked in was to add the DISOWN flag to Window#set_sizer. This is
the first time (that I know of) that we are really taking advantage of
the new SWIG 1.3.29 memory handling features.

When a sizer is created in ruby, SWIG assumes that ruby owns it and will
eventually delete it. But when you pass it to Window#set_sizer, wx now
assumes IT has ownership, and it will in fact delete it. Later, when
ruby collects its garbage, SWIG attempts to delete the sizer that was
already deleted...crash!

The DISOWN flag tells SWIG that wx is now responsible for deleting the
object. Whether the ruby object is garbage collected first, or the wx
object is deleted first, neither will cause problems for the other. 

There are a LOT of methods that will have to be decorated with ownership
annotations. But now that I see how it works, and I am starting to
better understand the debugging output, I hope progress can be pretty
rapid.

For those of you who have been helping write and update .i files, please
take a look at swig/classes/include/wxWindow.h and see what I did around
SetSizer. I tried to find a way to do that in the .i file instead of
the .h file, but nothing I tried worked. If any of you can find a way to
do it in the .i file, that would be great! You can tell it had an effect
by looking in the generated src/Window.cpp and seeing the
SWIG_POINTER_DISOWN flag in the _wrap_wxWindow_SetSizer function.

I''m feeling better about the upcoming release.

Cheers,

Kevin

On Fri, 2006-08-25 at 23:47 -0400, Kevin Smith wrote:
> I mentioned the first big change in a different email. The new change I
> just checked in was to add the DISOWN flag to Window#set_sizer. This is
> the first time (that I know of) that we are really taking advantage of
> the new SWIG 1.3.29 memory handling features.
Of course, Roy already added DISOWN for menubars back in April! Ok, so
I''m only a few months behind!

His implementation was in the .i file, as I had wanted, so I have
changed Window to be the same way. It happens that for all the Window
methods that accept wxSizer''s as parameters, those sizers become owned
by the Window. So it works great. We may not always be so lucky.

Thanks Roy!

Kevin

Kevin,

Great work!  That was next on my list of things to do.  I''m cleaning up
problems in the inheritance chain in wxDialog.  I''m trying to fix 
bigdemo as best I can.

Roy

Kevin Smith wrote:
> On Fri, 2006-08-25 at 23:47 -0400, Kevin Smith wrote:
>   
>> I mentioned the first big change in a different email. The new change I
>> just checked in was to add the DISOWN flag to Window#set_sizer. This is
>> the first time (that I know of) that we are really taking advantage of
>> the new SWIG 1.3.29 memory handling features.
>>     
>
> Of course, Roy already added DISOWN for menubars back in April! Ok, so
> I''m only a few months behind!
>
> His implementation was in the .i file, as I had wanted, so I have
> changed Window to be the same way. It happens that for all the Window
> methods that accept wxSizer''s as parameters, those sizers become
owned
> by the Window. So it works great. We may not always be so lucky.
>
> Thanks Roy!
>
> Kevin
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>

Kevin Smith wrote:
> I''m using my SpaceMonkeys game as a testbed to try to get rid of
> crashing problems. Earlier today, it would crash for me almost
> immediately, every time. Now, I was able to get about 50 turns into the
> game!
>   
sounds like and Roy are making real progress with SWIG. I agree the 
typemaps API is horrible. If stability is a lot better on Linux, maybe a 
good time to go for a release? Looking better on OS X, generally, mostly 
crashes on specific methods.

cheers
alex

On Sat, 2006-08-26 at 13:22 +0100, Alex Fenton wrote:
> If stability is a lot better on Linux, maybe a 
> good time to go for a release? Looking better on OS X, generally, mostly 
> crashes on specific methods.
If we can decide on a gem version number, I''m ok to do a release
quickly. I''m also ok waiting a few more days as patches continue to
flow
in.

Either way, there are a couple "showstoppers" before release, which
are
sample copyrights (which I can do), and documenting as many specific
known problems as possible.

Kevin

Kevin Smith wrote:
> If we can decide on a gem version number, I''m ok to do a release
> quickly. I''m also ok waiting a few more days as patches continue
to flow
> in.
>   
I like your suggestion of wxruby2-preview-0.x.x for an alpha series, 
then bumping to 0.9.0 or 1.9.0 when we get to beta quality and (for 
0.9.0 at least) wxruby 0.6.0 backwards compatibility.

The pseudo-gem thing should work if needed to force people to move onto 
a new series. We can use the ''extensions'' option to run an
executable
when the gem installs, which would warn about the need to upgrade and 
how to do it (and perhaps to uninstall the old preview gem or gems - 
looking at the way Rubygems searches for libs to load this might be 
required - but again should be a single command).
> Either way, there are a couple "showstoppers" before release,
which are
> sample copyrights (which I can do), and documenting as many specific
> known problems as possible.
Sounds good - where to document the known problems that aren''t going to
be fixed for this release?

alex

On Sun, 2006-08-27 at 13:16 +0100, Alex Fenton wrote:
> I like your suggestion of wxruby2-preview-0.x.x for an alpha series, 
> then bumping to 0.9.0 or 1.9.0 when we get to beta quality and (for 
> 0.9.0 at least) wxruby 0.6.0 backwards compatibility.
We won''t ever have full 0.6.0 compatibility, but 0.9.0 (or maybe 0.7.0
to give us more breathing room) should be a superset of 0.6.0
functionality, as much as possible. The differences would include things
like require ''wx'' vs. ''wxruby'', a few
documented subtle changes to the
api (like returning nil vs. false), perhaps a few API changes to make us
more like wxPython, etc.

We are also intentionally dropping a few classes that were supported in
0.6.0 but which we now want to encourage using the standard Ruby
equivalents.
> Sounds good - where to document the known problems that aren''t
going to
> be fixed for this release?
Maybe the README could point to another text file that would list the
problems. KNOWN-PROBLEMS.txt maybe, or TODO? I don''t have strong
feelings about it.

Kevin

Kevin Smith wrote:
> We won''t ever have full 0.6.0 compatibility, but 0.9.0 (or maybe
0.7.0
> to give us more breathing room) should be a superset of 0.6.0
> functionality, as much as possible. 
>   
Agreed, also re dropped classes.

Could be an argument for 1.9 as beta, but I don''t feel strongly about
it
- let''s decide that later.
> Maybe the README could point to another text file that would list the
> problems. KNOWN-PROBLEMS.txt maybe, or TODO? 
TODO sounds right and fairly standard to me, with, as you suggest, a 
note in README that says ''there are known issues... please see
TODO''

cheers
alex