RE: embed or swig?

I'm working on a wxWindows port for Ruby (called, predictably, wxRuby),
using Swig. Its odd but the last three days I've discovered Swig and it is
really a form of black magic. While not quite as straightforward as the
example that set off this discussion, it will not be anywhere near as
difficult as coding it all by hand.

I have a site at sourceforge set up (no code uploaded yet, but that will
change soon) and a proposed site at savannah. I've already started on this
and I hope to upload some code soon. Folks who want to contribute should let
me know and as soon as I decide in the next few days which site finally to
host it at (looking like sourceforge, since I already have it up there),
we'll get a team going.

Sincerely,

Bob Calco

%% -----Original Message-----
%% From: Tom Sawyer [mailto:[e-mail]]
%% Sent: Sunday, August 04, 2002 7:28 AM
%% To: ruby-talk ML
%% Subject: Re: embed or swig?
%%
%%
%% i was just reading over a little of the swig docs and HOLY CODING! from
%% my limited reading it appears that once a swig interface definition is
%% created you can generate a wrapper for any of the supported scripting
%% languages. is that true? i imagine there might be a need to make some
%% minor changes for a large/realistic source. but perhaps not? with this
%% then it should be rather trivial to wrap a number of libraries for ruby
%% that already have swig interfaces for python. can anyone confirm this?
%%
%% if what i gather from the above holds, then a wxWindows binding for ruby
%% should be pretty sraight foward for anyone with ruby and swig
%% experience. the same holds true for ParaGUI, and certainly a number of
%% other apis.
%%
%% please confirm speculations.
%%
%% ~transami
%%
%%
%% On Sat, 2002-08-03 at 21:36, [e-mail] wrote:
%% > "Massimiliano Mirra" <[e-mail]> wrote in message
%% > news:[e-mail]...
%% > > On Sun, Aug 04, 2002 at 07:56:21AM +0900, Phil Tomson wrote:
%% > > > We started off wanting to do unit testing of our C++
%% classes so I tried
%% > > > out Swig1.3.13 to wrap our classes.  Let's say you have
%% three classes,
%% > > > we'll call them Line, Polygon and Point and let's say you
%% want to have
%% > > > them live in a namespace called Geo.  You would define an
%% interface file
%% > > > as an input to swig that would looks something like:
%% > > >
%% > > > %module Geo
%% > > > %{
%% > > > #include "Line.h";
%% > > > #include "Polygon.h";
%% > > > #include "Point.h";
%% > > > %}
%% > > > %include "Line.h";
%% > > > %include "Polygon.h";
%% > > > %include "Point.h";
%% > > >
%% > > > //end of Geo.i (probably not completely right, I'm doing from
%% > > > memory)
%% > >
%% > > Wait a minute.  Do you really mean that, after you've
%% written your C++
%% > > classes, you just feed nine lines to Swig and after some
%% crunching you
%% > > have them available in Ruby?  Or are you just simplifying?
%% > >
%% > > Massimiliano
%% >
%% > That is not simplifying at all for basic functionality.
%% Certainly depending
%% > on your C/C++ code and how you want it to act in Ruby could
%% mean you must
%% > learn more advanced SWIG features.
%% >
%% > SWIG in the last few months has made great strides with C++.
%% You used to
%% > have to do lots of tricks to fool it into doing the right
%% thing, but now
%% > some pretty complex C++ features and types are supported out
%% of the box:.
%% > There are also new library functions for automatically translating STL
%% > vectors into Ruby arrays, and more on the way.  SWIG is being _very_
%% > actively developed right now.  It's a great tool with very responsive
%% > developers.
%% >
%% > We've been using C++/Ruby exactly how Phil is describing for
%% over a year,
%% > and the progress SWIG has made in that time is astounding.
%% Lyle Johnson has
%% > made sure that the Ruby module is one of the best/most up-to-date SWIG
%% > modules for supporting new features in the SWIG core.  (We
%% also wrap the C++
%% > classes into Perl and Tcl using SWIG as well... but those
%% bindings are not
%% > as popular with the users of our toolkit despite the size of
%% the knowledge
%% > base in those two languages where I work).
%% >
%% > Of course, that doesn't mean there aren't things missing that
%% would be nice
%% > (even if some aren't possible)... i.e., a unified SWIG
%% interface for setting
%% > up callbacks from C++ into the target scripting languages, for
%% example...
%% > support for faking multiple inheritance in Ruby by adding wrappers for
%% > secondary/tertiary ancestors directly into the subclass's Ruby class
%% > methods...
%% >
%% > Using SWIG is really quite easy... managing shared libraries that are
%% > dynamically loaded into various versions of perl/ruby/tcl on mutiple
%% > platforms... well that can get really ugly (especially when
%% one of those
%% > platforms is evil HPUX with its horrible, horrible dynamic loader).
%% > Certainly the embedding approach simplifies that aspect,
%% especially if you
%% > statically link Ruby (or whatever scripting language you are using SWIG
%% > for).
%% >
%% >
%% >
%% >
%% --
%% ~transami
%%
%%