wxruby users - Aug 2005 - Object map

I''ve spent a couple hours tracking through the code and reading Swig 
documentation to try to find out about tracking C objects back to Ruby 
objects.  It''s not so easy to do.  I took at look at wxPython and their
source is a mess!  I wasn''t able to glean anything from them on how
they
do it.  My current hypothesis is to trap SWIG_NewPointerObj calls and 
build a map.  But I haven''t traipsed through enough code yet to really 
see if we can catch the Ruby objects dying.  I note that no ruby object 
owns the wxWindows objects as they''re created.  I''m a little
unsure how
all this works out still and whether garbage collection will cause some 
really bad effects.

I really think I need to either find some way to collaborate on a 
solution to this or set it aside until I''m much more familiar with the 
inner workings of the whole thing.

Anyone have any thoughts?

Roy

Roy Sutton wrote:
> I''ve spent a couple hours tracking through the code and reading
Swig
> documentation to try to find out about tracking C objects back to Ruby 
> objects.  It''s not so easy to do.  
True.
> I took at look at wxPython and their source is a mess!  
> I wasn''t able to glean anything from them on how they do it.  
Yeah, I have found the wxPython code extremely hard to understand. 
That''s part of why I really wanted to build wxruby2 from clean wx api
.h
files that don''t have any ruby-specific clutter (these are the files in
swig/classes/include/). If all the wxXyz (wxruby, fxruby, schemeruby) 
were built from the same set of api .h files, it would be easier to see 
how each project really works.
> My current hypothesis is to trap SWIG_NewPointerObj calls and 
> build a map.  But I haven''t traipsed through enough code yet to
really
> see if we can catch the Ruby objects dying.  I note that no ruby object 
> owns the wxWindows objects as they''re created.  I''m a
little unsure how
> all this works out still and whether garbage collection will cause some 
> really bad effects.
I think the answer lies in directors. Every polymorphic class in wxruby2 
has a director, and that gives us a convenient place to hook in to 
object construction and destruction. If you look at fixdeleting.rb, 
that''s exactly what it''s doing.
> I really think I need to either find some way to collaborate on a 
> solution to this or set it aside until I''m much more familiar with
the
> inner workings of the whole thing.
Yeah, it''s definitely one of the trickier parts. I just set up a new 
wiki page with kind of a raw dump of a couple years of memory management 
discussions and tidbits. It''s horribly ugly, but has tons of good 
information for anyone wanting to learn more about swig/c++/wx memory 
management issues:

   http://wxruby.rubyforge.org/wiki/wiki.pl?Memory_Management

Kevin

I read over that earlier.  It''s pretty much exactly what my plan was. 
I
don''t know whether to feel better or scared that it''s the
recommended
way. ;)  I think we can do this pretty easily.  I''ve been taking a look
at the swig ruby wrappers to see the best way to inject all that stuff 
in there.  I''m hoping we don''t have to resort to the
fixdeleting
method.   It strikes me it would be better to modify the swig actions 
somehow so it always produces what we want.

If I get some time later I''ll try messing with the wiki to make it all 
purty-like.

Roy

Kevin Smith wrote:
> Yeah, it''s definitely one of the trickier parts. I just set up a
new
> wiki page with kind of a raw dump of a couple years of memory 
> management discussions and tidbits. It''s horribly ugly, but has
tons
> of good information for anyone wanting to learn more about swig/c++/wx 
> memory management issues:
>
>   http://wxruby.rubyforge.org/wiki/wiki.pl?Memory_Management