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
Maybe Matching Threads
- Choosing a Sizer
- [1129] trunk/wxruby2/swig/classes/Window.i: Add DISOWN typemap for ToolTip so it isn''t double-deleted
- [897] branches/wxruby2/wxwidgets_282/swig/classes/Window.i: DISOWN typemap to prevent crash on GC/exit when caret has been set (bug #9093)
- [828] trunk/wxruby2/swig/classes/Sizer.i: Ensure that nested Sizers are disowned and not GC''d (fixes segfault at exit)
- [1033] trunk/wxruby2/swig: GC fixes for nested sizers; fix crashes in html.rb demo