wxruby users - Sep 2005 - Tagged wxruby2 v0.0.29, plus added more directors

Since things seemed to be somewhat stable (that is, wxruby2 compiles and 
runs on all three platforms), I tagged what has been there for a couple 
days as v0_0_29. Nothing magic about it, but it had been a while since I 
had tagged.

Then I worked on adding directors to the classes that don''t have them, 
in the hopes of avoiding more segfault crashes during garbage 
collection. I was able to get directors working for 14 more classes, but 
there are still 16 that should have directors but don''t. For me (and 
SpaceMonkeys), the most important are probably Point, Size, MemoryDC, 
and maybe Icon.

A couple of the changes I made seemed a bit surprising, so I think I am 
fighting against and/or taking unfair advantage of some swig bugs. If 
anything doesn''t compile for you with the latest code, let me know and
I
can probably offer some suggestions.

Kevin

I had to change FontDialog.i back to how it was before to get it to
compile on OS X. I also fixed the require for one of the minimal
samples to ''wx'' instead of ''wxruby''. The
project is coming along very
nicely, I have been working on a complex program using it for the last
1.5 weeks and have not hit any snags (hence the lack of patches from
me). The only problem I have is on OS X and trying to type a value
into a cell in wxGrid that has a GridCellStringRenderer and
GridCellTextEditor, I get:

`get_default_editor_for_cell'': stack level too deep (SystemStackError)

I have looked into this a bit and can not find an obvious cause, on
Windows I do not have any problem with the same code, I pound on it
all day long. Any Ideas?

Sean

On 9/9/05, Kevin Smith <wxruby@qualitycode.com>
wrote:
> Since things seemed to be somewhat stable (that is, wxruby2 compiles and
> runs on all three platforms), I tagged what has been there for a couple
> days as v0_0_29. Nothing magic about it, but it had been a while since I
> had tagged.
> 
> Then I worked on adding directors to the classes that don''t have
them,
> in the hopes of avoiding more segfault crashes during garbage
> collection. I was able to get directors working for 14 more classes, but
> there are still 16 that should have directors but don''t. For me
(and
> SpaceMonkeys), the most important are probably Point, Size, MemoryDC,
> and maybe Icon.
> 
> A couple of the changes I made seemed a bit surprising, so I think I am
> fighting against and/or taking unfair advantage of some swig bugs. If
> anything doesn''t compile for you with the latest code, let me know
and I
> can probably offer some suggestions.
> 
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: font_dialog_i.patch
Type: application/octet-stream
Size: 661 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050909/d2f386be/font_dialog_i.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: text_rb.patch
Type: application/octet-stream
Size: 430 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050909/d2f386be/text_rb.obj

Sean Long wrote:
> I had to change FontDialog.i back to how it was before to get it to
> compile on OS X. 
I haven''t applied this, because we *really* need directors to work. Can
you paste in the compile errors you are seeing so we can try to fix them?
> I also fixed the require for one of the minimal
> samples to ''wx'' instead of ''wxruby''. 
Applied, thanks. I suspect text.rb was a throwaway that never should 
have been checked in, but we''ll leave it in for now.
> The project is coming along very
> nicely, I have been working on a complex program using it for the last
> 1.5 weeks and have not hit any snags (hence the lack of patches from
> me). 
That''s really great to hear! And a bit surprising, since my own app 
still crashes at the first garbage collection, which tends to happen as 
soon as you click on the first button.
> The only problem I have is on OS X and trying to type a value
> into a cell in wxGrid that has a GridCellStringRenderer and
> GridCellTextEditor, I get:
> 
> `get_default_editor_for_cell'': stack level too deep
(SystemStackError)
> 
> I have looked into this a bit and can not find an obvious cause, on
> Windows I do not have any problem with the same code, I pound on it
> all day long. Any Ideas?
I can think of a couple debug printfs you can put in to try to track it 
down. First, in src/grid.cpp, in 
SwigDirector_wxGrid::GetDefaultEditorForCell, put printfs before the 
call to get_swig_up, right after it (inside the if), and before and 
after the rb_funcall line. Be sure not to call get_swig_up yourself, 
since calling it affects its state.

You might see the rb_funcall being executed recursively until the stack 
overflows.

Next, try overriding get_default_editor_for_cell in your ruby Grid 
subclass. Just print that you were called, and then invoke super. This 
might show the same results as above, or might affect the problem enough 
to hide it.


There is a pretty good chance that the problem is caused by us not 
correctly specifying the class hierarchy and all the virtual methods. 
You might compare the relevant .h files in swig/classes/include/ against 
those in the Mac wx directory. Definitely wxGrid, and probably the 
various grid cell and event classes.

Does your app have any idle processing or multithreading? Those would be 
another possible cause of problems with the get_swig_up mechanism.

Kevin

Sean Long wrote:
>>>I had to change FontDialog.i back to how it was before to get it to
>>>compile on OS X.
>>
>>I haven''t applied this, because we *really* need directors to
work. Can
>>you paste in the compile errors you are seeing so we can try to fix
them?
>>
> 
> 
> Here is the output I get:
> src/FontDialog.cpp: In constructor
> ''SwigDirector_wxFontDialog::SwigDirector_wxFontDialog(VALUE,
> wxWindow*)'':
> src/FontDialog.cpp:1145: error: no matching function for call to
>
''wxGenericFontDialog::wxGenericFontDialog(wxWindow*&)''
Ok. I just checked in a fix that omits that constructor on Mac. It''s 
just another platform-specific variation.

Let me know if this fixes it for you. If not, it''s probably something 
silly I did that you could fix yourself.

Thanks,

Kevin

Sean Long wrote:
> The rb_funcall is being called recursively like you said it might.
Ick.
> (I know that wxGridTableBase.h is not currently run through swig but I
> cleaned up the *.h for it anyway)
Ah. There''s a pretty good chance that this is the problem. If you could
create a .i file for it, I would definitely appreciate it. If that 
doesn''t solve it, could you create a tiny sample that demonstrates the 
problem? That would make it easier for me to debug. You could start with 
the bigdemo grid sample if you want, although something even smaller 
would be ideal.

Thanks,

Kevin

Kevin Smith wrote:
> Sean Long wrote:
> 
>> (I know that wxGridTableBase.h is not currently run through swig but I
>> cleaned up the *.h for it anyway)
> 
> Ah. There''s a pretty good chance that this is the problem. If you
could
> create a .i file for it, I would definitely appreciate it. If that 
> doesn''t solve it, could you create a tiny sample that demonstrates
the
> problem? That would make it easier for me to debug. You could start with 
> the bigdemo grid sample if you want, although something even smaller 
> would be ideal.
Actually, I meant to say "create a .i file for it, and integrate it into 
the parent hierarchy as appropriate".

But looking more at it, it''s not obvious to me how it it actually used.
Does wxGrid use a wxGridStringTable by default?

I no longer suspect GridTableBase, although it would be cool if we could 
wrap it. But only if we also have a sample that shows how it would be used.

I still suspect that the problem is a virtual method somewhere that is 
not indicated as being virtual (or perhaps one that isn''t virtual but
we
have it flagged as being virtual). It could be in any class, if the call 
stack from get_default_editor goes through it.

A small sample is definitely going to help narrow it down.

Kevin

Sean Long wrote:
> I cleaned up a whole bunch of the Grid related code but it has not
> solved this problem, but atleast it is helping the project along ;)
Forgot to say:  "Applied, thanks!"

Kevin

> Ok. I just checked in a fix that omits that constructor on Mac.
It''s
> just another platform-specific variation.
> 
> Let me know if this fixes it for you. If not, it''s probably
something
> silly I did that you could fix yourself.
Works. I should have saw that, I guess that is what I get when I only
work on the Mac version late at night.

Sean

> But looking more at it, it''s not obvious to me how it it actually
used.
> Does wxGrid use a wxGridStringTable by default?
Not sure.
> I no longer suspect GridTableBase, although it would be cool if we could
> wrap it. But only if we also have a sample that shows how it would be used.
In all my years using wxWidgets I have never used GridTableBase
directly so I am not going to mess with it any more than I have. I do
not think the problem is located there anyway.
> A small sample is definitely going to help narrow it down.
I might write a small sample this week, but not tonight.

Sean