[fxruby-users] FLTK2

[Sander Jansen]

well, yes, FOX currently always includes debug symbols. strip
--strip-debug libFOX.*  should reduce the size to normal proportions.

Sander

gga wrote:
> Lyle Johnson wrote:
>> Since I haven't seen the source code for your FLTK2 bindings, I can't  
>> say for sure why there would be such a significant size difference  
>> between it and FXRuby. I am a little curious about how you're  
>> handling things like overriding virtual function calls in Ruby, as  
>> well as garbage collection related issues. I know that the code  
>> required to support those things takes up a significant part of the  
>> FXRuby code base.
>>   
> While it is not likely I'll make an announcement until I have fluid
> fully written in ruby, you can already take a look at the source with:
> 
> svn checkout svn://rubyforge.org/var/svn/fltk
> 
> Things different from FXRuby:
> - inheritance and virtuals are handled by SWIG, using directors and
> tracking. 
> This change reduces the code to maintain in the binding to about 1/2 of
> what FXRuby is currently using, as there's no need for Rb* classes as in
> FXRuby. 
> Well, technically, SWIG DOES create something equivalent to Rb* classes
> itself and I had the SWIG team more or less rewrite their SWIG director
> code for 1.3.29 onwards to handle this better.  Have not delved deeply
> into the FXRuby source to see if the Rb* classes have any merit over the
> SWIG ones.  Mind you, directors for ruby in swig were pretty much broken
> until I got to debug them over swig 1.3.28, so you do need some recent
> swig version.
> To do a mapping between C/Ruby classes at any point, SWIG's tracking
> uses a hash mapping.  Personally, I think SWIG's code could still be
> improved here, by using a faster hash, like google's densehashmap.
> - Callbacks are also handled in C, unlike FXRuby's overriding of
> method() in ruby.  I use duck typing within the C code.  Mainly also
> because Matz has forgotten to expose rb_cMethod in the 1.8 branch.
> - Exceptions are also handled by SWIG itself.
> - Drawing functions are exposed also directly, sans going thru ruby.
> - FLTK2.0's binding takes advantage of mapping :symbols to method
> callbacks within C directly.  This is still not as generic as I would
> like, due to Ruby's limitations internally, but the idea is to allow both:
> 
>       w.callback( method(:myfunction_cb) )
>       w.callback( :myfunction_cb )   # treat :symbol as a method in the
> running scope, automatically
>                                                         # binding to the
> method.
>                                                         # (currently
> this works for global methods in Object only, sadly)
> 
> - FLTK2.0's binding takes advantage of Ruby's DSL features, by using
> instance_eval within blocks instead of yields on its constructor.  This
> allows:
> 
>   window = Window.new( 300, 180 ) {
>     callback :window_callback
>     color(RED)
>   }
> 
> instead of a more convoluted:
> 
>   window = Window.new( 300, 180 ) { |w|
>     w.callback :window_callback
>     w.color(RED)
>   }
> 
> or:
>   w = Window.new( 300, 180 )
>   w.callback :window_callback
>   w.color(RED)
> 
> However, the other syntaxes are also efficiently supported.
> 
> 
> SWIG/FLTK still pending issues:
> 
> - Currently, there are still I think some issues using SWIG classes
> across multiple DSOs, but for something simpler like FLTK which is just
> 1 dso, it is no issue.
> - There's still some segfault issues, albeit these seem more FLTK2
> issues, than binding issues.  Currently, the fonts listing api will
> often segfault on my machine.  This happens to me also with FLTK in C++,
> thou, but I cannot get the FLTK developers to reproduce it on their
> environment. It seems something funky is going on in FLTK's X11 code for it.
> - Sometimes if ruby rises a syntax error, upon quitting SWIG does seem
> not to handle its unloading properly and sometimes it will also raise a
> segfault.  I still need to delve into this one also more fully, but it
> is not 100% critical.  It might be unavoidable, due to use Ruby's
> internal use of longjmp?
> 
> Off the list, I was also talking to Jeroen about FXRuby's size.  He did
> seem to have found a bug in the Makefile and a way to reduce Fox symbols
> size a little bit more.
> He also made me realize that for FXRuby and my own FLTK's bindings, it
> could be interesting to compile the actual FOX/Fltk library as a static
> library within the ruby dso, as that would remove all symbols from it,
> which would bring the FXRuby lib to 4mb and the FLTK lib to about 400Kb
> from their 12Mb and 4Mb size.   The only disadvantage of doing so would
> be that Ruby users would need to recompile the extension every time they
> upgrade the underlying toolkit library.
>