wxruby users - Apr 2006 - ComboBox patch files

The following two files correct problems with the ComboBox 
implementation.  You will also need my typemap.i.patch file 
(forthcoming) in order for the void * typemap to work properly (I think).

Roy



_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users

On Sun, 2006-04-23 at 13:08 -0400, Roy Sutton wrote:
> The following two files correct problems with the ComboBox 
> implementation.  You will also need my typemap.i.patch file 
> (forthcoming) in order for the void * typemap to work properly (I think).
I''m not sure which typemap.i patch you''re referring to. When I
applied
these patches, the combobox page of the controls sample bombed for me.
So I can''t accept them as-is.

After selecting the "Really" item, about 30 mysterious debug statement
showed up on the console, and then the standard wx "oops" dialog
appeared offering to terminate the app.

Kevin

On Sat, 2006-04-29 at 16:05 -0400, Kevin Smith wrote:
> After selecting the "Really" item, about 30 mysterious debug
statement
> showed up on the console, and then the standard wx "oops" dialog
> appeared offering to terminate the app.
Ok. This is a bigger issue. Even after removing those patches, I have
seen this behavior a few times. Generally in bigdemo after running it
for a while. Suddenly I get this cascade of errors, and then the wx
crashed-app dialog. Now, the errors are usually:

addr2line: ''wxruby'': No such file
addr2line: ''wxruby'': No such file
addr2line: ''wxruby'': No such file
addr2line: ''wxruby'': No such file
addr2line: ''wxruby'': No such file
addr2line: ''wxruby'': No such file
addr2line: ''wxruby'': No such file

I''m guessing they''re coming from wx, but a quick yahoo search
of the web
didn''t reveal anything. If anyone has any ideas what''s going
on, I would
appreciate it. My best guess at this point is that our object management
is resulting in a bad wx pointer being sent to wx, and it is asserting
and then failing as a result.

Kevin

P.S. The ComboBox patch was still directly responsible for the controls
sample misbehaving, so I''m still not ready to commit it as-is.

Kevin Smith wrote:
> P.S. The ComboBox patch was still directly responsible for the controls
> sample misbehaving, so I''m still not ready to commit it as-is.
Hmm...  I haven''t been using the controls sample.  I don''t
recall it
working correctly for me.  However, a new problem has cropped up when I 
tried to run it.  With Alex''s patch to include the typemaps.i file we 
now have a conflict between the two GetSize methods for Frames and the 
like.  Python renames the second to GetSizeTuple, Perl to GetSizeWH.  
How do you feel about get_size_array?  Or, we could just ignore the 2nd 
one.  I don''t see much use to it if we''ve got the wxSize one.

On Sat, 2006-04-29 at 16:43 -0400, Kevin Smith wrote:
> Ok. This is a bigger issue. Even after removing those patches, I have
> seen this behavior a few times. Generally in bigdemo after running it
> for a while. Suddenly I get this cascade of errors, and then the wx
> crashed-app dialog. Now, the errors are usually:
> 
> addr2line: ''wxruby'': No such file
I figured out that wx has a failing Assert, which was attempting to walk
the stack, but since our (faked) app name is ''wxruby'', when
the walker
invoked an external utility named addr2line, it couldn''t find the
executable file, causing those errors.

I changed App to override OnAssert, and it now throws a Ruby fatal
exception, after printing out the basic information about the cause of
the assertion failure.

Which shows me that my patch earlier today to handle those internal Qnil
objects isn''t good enough. Most of the asserts I''m seeing
appear to be
related. We (I?) need to figure out why those internal values are not
being set correctly by the object tracking code. Or why they are being
cleared. Or why we are looking at the wrong object entirely. Or whatever
it is that''s going on.

Kevin

On Sat, 2006-04-29 at 17:08 -0400, Roy Sutton wrote:
> With Alex''s patch to include the typemaps.i file we 
> now have a conflict between the two GetSize methods for Frames and the 
> like.  Python renames the second to GetSizeTuple, Perl to GetSizeWH.  
> How do you feel about get_size_array?  Or, we could just ignore the 2nd 
> one.  I don''t see much use to it if we''ve got the wxSize
one.
For now, and possibly forever, I''m fine only supporting the wxSize
get_size method.

Kevin