Hi all, I''m new to wxruby and to wxwindows and such, but I''m setting out to build a largish project using them I''ve been reviewing the site and examples and I noticed that one of the goals for the next release is reducing the swig bloat. I was wondering what consideration had gone into using something like FFI? There is at least one swig2ffi type thing that may be useful: http://www.ruby-forum.com/topic/184766 This would allow the library to skip over swig and even skip having the -dev libraries around at all when installing the gem, etc... maybe worth considering? Anyhow, the project looks nice. I look forward to working with it. Is there an active IRC channel that people hang out on? I can''t seem to find one. --Ian
Hi Ian Ian Duggan wrote:> I''m new to wxruby and to wxwindows and such, but I''m setting out to > build a largish project using them I''ve been reviewing the site and > examples and I noticed that one of the goals for the next release is > reducing the swig bloat. > > I was wondering what consideration had gone into using something like > FFI? There is at least one swig2ffi type thing that may be useful: > > http://www.ruby-forum.com/topic/184766 > > This would allow the library to skip over swig and even skip having > the -dev libraries around at all when installing the gem, etc... maybe > worth considering?It is a nice idea for several reasons - it would also offer the opportunity to switch to alternate ruby implementations (eg JRuby) while still working with wxRuby. As far as I can see, however, FFI is intended to work with C not C++, and wxRuby and wxWidgets make pretty extensive use of the OO features of C++, as supported by SWIG (eg inheritance, virtual "director" methods), as well as a fair amount of custom C++ code to make the binding work. I don''t think FFI deals with this kind of thing at all at the moment. But it''s definitely one to keep an eye on.> Is there an active IRC channel that people hang out on? I can''t seem > to find one. >irc.freenode.net #wxruby - don''t know how active at the moment - I don''t regularly hang out on IRC but Mario and others are there sometimes. cheers alex
> As far as I can see, however, FFI is intended to work with C not C++, and > wxRuby and wxWidgets make pretty extensive use of the OO features of C++, as > supported by SWIG (eg inheritance, virtual "director" methods), as well as a > fair amount of custom C++ code to make the binding work. I don''t think FFI > deals with this kind of thing at all at the moment. But it''s definitely one > to keep an eye on.Hmm. That could present some problems. How much glue code sits between wx and the ruby access points? I noticed that the FFI project has a SWIG generator in it (for c code). I haven''t yet looked into how that might help with the glue-code issues. C++ doesn''t have a runtime, so it should mostly be a matter of dealing with name mangling and such, right? Constructors, destructors, and mangling. Are there any other issues people can foresee? http://kenai.com/projects/ruby-ffi/sources/swig-generator/show I suppose the first step would be to get this working through FFI and see how hard it is. class MyApp def on_init nil end end MyApp.new.main_loop --Ian
Ian Duggan wrote:> Hmm. That could present some problems. How much glue code sits between > wx and the ruby access points? >"Some". It''s basically everything that''s contained in SWIG code literal blocks %{ ... %} in the swig/ directory of the tarball. The most complex stuff deals with object ownership, and synchronisation between Ruby''s GC and wxWidgets object lifetimes. Sometimes an ordinary ruby object that would otherwise be swept by GC needs to be preserved (eg item_data belonging to a Wx control). Sometimes a ruby counterpart to a C++ object needs to be kept alive to make C++->Ruby inheritance work naturally. And Ruby objects need to be released when their C++ counterparts disappear to avoid leaking memory. Other glue code does typecasting between the languages, and making the binding more ruby-natural but these are probably less complex.> I noticed that the FFI project has a SWIG generator in it (for c > code). I haven''t yet looked into how that might help with the > glue-code issues. C++ doesn''t have a runtime, so it should mostly be a > matter of dealing with name mangling and such, right? Constructors, > destructors, and mangling. Are there any other issues people can > foresee? > > http://kenai.com/projects/ruby-ffi/sources/swig-generator/show >Like you say, hard to know without trying it, but as above, wxRuby depends a lot on SWIG''s abilities to inject bits of custom C++ code for compilation into the wrapper.> I suppose the first step would be to get this working through FFI and > see how hard it is. > > class MyApp > def on_init > nil > end > end > MyApp.new.main_loop >If we could get this to work, survive GC and exit without crashing we''d be well on the way. Wx::App is one the more complex classes. If you get a chance to do any further investigation, I''d definitely be interested to hear of the results. alex