Embed or swig?

I’m working a C++ project for a contract I’m doing. Originally, the
client was thinking that they would like to have a scripting language embedded
into the application eventually (and of course I’ve been advocating Ruby
for this and they have been receptive since Ruby is used elsewhere within the
organization). Yesterday I needed to begin to define a configuration file
format and the thought of parsing the config file in C++ was not
pleasant…

Then it hit me… we alreay wrap all of our C++ objects with Swig so that
we can do unit testing in Ruby using Test::Unit so why not take it a step
further and use Ruby to tie together all of our C++ objects. The idea
being that instead of embedding Ruby into our C++ application we’ll use
Ruby to manipulate the objects defined by C++. All of the comutationally
intensive stuff is already done in those C++ classes so there won’t be any
performance hit. We won’t define a main() function on the C++ side, we’ll
just create the shared library from the swig wrappers and instantiate
those objects in Ruby.

So, I wrote the parser for our input file in Ruby in about an hour (it
would have taken substantially longer in C++) and started creating the
frontend for the C++ part of the application in Ruby. I actually think
this will give us a lot more flexibility when compared to the alternative
of embedding Ruby into the C++ app. And since we were already using Swig
for testing purposes it’s not costing us any extra time and we don’t need
to take any extra time to embed Ruby.

So, why embed when you can swig? (hoping to start a philosophical
discussion :-).

Phil

i am not too fimiliar with swig. but it’s starting to sound like one of
those things that i must take a look at. your notion of using ruby to
control all your c++ objects sounds mighty powerful to me --like having
the best of both worlds.

yet, it is interesting that this comes up at this moment for i just
finished reading Strategies For Scripting, page 44 of the latest Linux
Magazine issue. It talks about PDB, the Gimps procedural database. that
is a very slick notion in itself. the idea being that the Gimp, as well
as applications setting up to script it, register procedures into this
procedural database, and then they are accessible from ANY scripting
language as if NATIVE! like the article suggested, if this approach were
abstracted away from Gimp to stand on its own, it would be the killer
tool. talk about the dreams of REXX! i already forsee the death of SOAP!

so while i think your swig idea rocks and i say rock it, keep one eye to
the sky, the future bomb is pdb.

~transami

···

On Sat, 2002-08-03 at 00:35, Phil Tomson wrote:

I’m working a C++ project for a contract I’m doing. Originally, the
client was thinking that they would like to have a scripting language embedded
into the application eventually (and of course I’ve been advocating Ruby
for this and they have been receptive since Ruby is used elsewhere within the
organization). Yesterday I needed to begin to define a configuration file
format and the thought of parsing the config file in C++ was not
pleasant…

Then it hit me… we alreay wrap all of our C++ objects with Swig so that
we can do unit testing in Ruby using Test::Unit so why not take it a step
further and use Ruby to tie together all of our C++ objects. The idea
being that instead of embedding Ruby into our C++ application we’ll use
Ruby to manipulate the objects defined by C++. All of the comutationally
intensive stuff is already done in those C++ classes so there won’t be any
performance hit. We won’t define a main() function on the C++ side, we’ll
just create the shared library from the swig wrappers and instantiate
those objects in Ruby.

So, I wrote the parser for our input file in Ruby in about an hour (it
would have taken substantially longer in C++) and started creating the
frontend for the C++ part of the application in Ruby. I actually think
this will give us a lot more flexibility when compared to the alternative
of embedding Ruby into the C++ app. And since we were already using Swig
for testing purposes it’s not costing us any extra time and we don’t need
to take any extra time to embed Ruby.

So, why embed when you can swig? (hoping to start a philosophical
discussion :-).

Phil


~transami

You are doing just what I would have done.
My ‘simple’ philosophy would be to use ruby as the base language.
If all code was new, write it all in ruby. Where there are slow
parts, implement those in a faster language. Since your computationally
instensive stuff was already written in C++, there is no rewrite involved.
And swig just helped you to link it into ruby.

So, even though you are in a mixed language environment, you construct
your project around ruby which is much more flexible.
Setting the project up this way would probably mean that ruby would be
the arbiter between languages if your mixed lang environment had
more that two languages.

···

On Sat, Aug 03, 2002 at 03:35:38PM +0900, Phil Tomson wrote:

Then it hit me… we alreay wrap all of our C++ objects with Swig so that
we can do unit testing in Ruby using Test::Unit so why not take it a step
further and use Ruby to tie together all of our C++ objects. The idea
being that instead of embedding Ruby into our C++ application we’ll use
Ruby to manipulate the objects defined by C++. All of the comutationally
intensive stuff is already done in those C++ classes so there won’t be any
performance hit. We won’t define a main() function on the C++ side, we’ll
just create the shared library from the swig wrappers and instantiate
those objects in Ruby.

So, I wrote the parser for our input file in Ruby in about an hour (it
would have taken substantially longer in C++) and started creating the
frontend for the C++ part of the application in Ruby. I actually think
this will give us a lot more flexibility when compared to the alternative
of embedding Ruby into the C++ app. And since we were already using Swig
for testing purposes it’s not costing us any extra time and we don’t need
to take any extra time to embed Ruby.

So, why embed when you can swig? (hoping to start a philosophical
discussion :-).


Jim Freeze
If only I had something clever to say for my comment…
~

Then it hit me… we alreay wrap all of our C++ objects with Swig so that
we can do unit testing in Ruby using Test::Unit so why not take it a step
further and use Ruby to tie together all of our C++ objects. The idea
being that instead of embedding Ruby into our C++ application we’ll use
Ruby to manipulate the objects defined by C++. All of the comutationally
intensive stuff is already done in those C++ classes so there won’t be any
performance hit. We won’t define a main() function on the C++ side, we’ll
just create the shared library from the swig wrappers and instantiate
those objects in Ruby.

This sounds very interesting to me… can you
explain how this actually works?

I’ve never really looked at SWIG. I didn’t
realize it was quite this powerful…

Hal

···

----- Original Message -----
From: “Phil Tomson” ptkwt@shell1.aracnet.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, August 03, 2002 1:35 AM
Subject: embed or swig?

In article 005d01c23b0f$135b6460$0300a8c0@austin.rr.com,

From: “Phil Tomson” ptkwt@shell1.aracnet.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, August 03, 2002 1:35 AM
Subject: embed or swig?

Then it hit me… we alreay wrap all of our C++ objects with Swig so that
we can do unit testing in Ruby using Test::Unit so why not take it a step
further and use Ruby to tie together all of our C++ objects. The idea
being that instead of embedding Ruby into our C++ application we’ll use
Ruby to manipulate the objects defined by C++. All of the comutationally
intensive stuff is already done in those C++ classes so there won’t be any
performance hit. We won’t define a main() function on the C++ side, we’ll
just create the shared library from the swig wrappers and instantiate
those objects in Ruby.

This sounds very interesting to me… can you
explain how this actually works?

I’ve never really looked at SWIG. I didn’t
realize it was quite this powerful…

First take a look at Swig at: http://www.swig.org

Now to explain a bit more what we’re doing:
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)

Now you run swig on the interface file and it generates a wrapper file
which you then compile and link with the object files
(Line.o,Polygon.o,Point.o). (see the Swig/Ruby docs at:
http://www.swig.org/Doc1.3/Ruby.html for more details)

Now from Ruby you can access the objects in the Geo module:

#ruby:
require 'Geo.so
lines = []
line = Geo::Line.new(0,0,5,5)
lines << line
lines << Geo::Line.new(5,5,8,5)
lines << Geo::Line.fromPoints(Geo::Point.new(4,3),Geo::Point.new(5,4))
lines << Geo::Line.new(9,8,7,6)
polygon = Geo::Polygon.new(lines)
#end

So we’re instantiating Line, Point and Polygon objects which were really
defined in C++. Swig essentially makes it easy to create C/C++
extentions.

In our application we’re now parsing an input file which describes some
geometry and then instantiate our C++ objects all from Ruby. So as I said
in my previous post, instead of having a main() function in C++ we just
have a shared library that gets require’d by Ruby and we let Ruby take
care of the parsing, instantiation of C++ objects and then we call some
methods on those C++ objects to make them do their stuff.

…That’s the 10000 foot view of what we’re doing anyway. I’m thinking
that I need to write an article about this methodology (actually there
could be two articles - using Swig and Ruby for C++ unit testing, using
Ruby to tie together C++ objects (gotta think of a better title for that
one))

Phil

···

Hal E. Fulton hal9000@hypermetrics.com wrote:

----- Original Message -----

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

···

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)

First take a look at Swig at: http://www.swig.org

Now to explain a bit more what we’re doing:

[snip]

“Curiouser and curiouser,” said Alice.

Very, very interesting. My to-do list keeps growing.
I’d love to learn SWIG now.

…That’s the 10000 foot view of what we’re doing anyway. I’m thinking
that I need to write an article about this methodology (actually there
could be two articles - using Swig and Ruby for C++ unit testing, using
Ruby to tie together C++ objects (gotta think of a better title for that
one))

Please do write these!

Even if a mag doesn’t publish them, you can always put
them on the web.

I’d vote for the latter (more general) subject first, then
the test-related one.

Thanks, Phil.

Hal

···

----- Original Message -----
From: “Phil Tomson” ptkwt@shell1.aracnet.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, August 03, 2002 5:56 PM
Subject: Re: embed or swig?

Well, from what I see on the SWIG site, it appears
he’s not oversimplifying.

Potentially very exciting, eh?

Hal

···

----- Original Message -----
From: “Massimiliano Mirra” list@NOSPAMchromatic-harp.com.web-hosting.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, August 03, 2002 6:15 PM
Subject: Re: embed or swig?

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?

In article 20020803231558.GA11531@prism.localnet,

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?

Well, that is a bit simplified, though there are cases where that would
probably be true.

In reality you’ll probaby have to write some typemaps - In the example
above I show the the constructor for Geo::Polygon is taking a Ruby array
of Lines - you’d probably have to write a typemape for that.

Also, C++ allows method names to be overloaded based on differing argument
lists, Ruby doesn’t so you would have to use swig’s %rename (see the docs
for details). But other than that swig is actually pretty easy to use.

Phil

···

Massimiliano Mirra list@NOSPAMchromatic-harp.com wrote:

On Sun, Aug 04, 2002 at 07:56:21AM +0900, Phil Tomson wrote:

“Massimiliano Mirra” list@NOSPAMchromatic-harp.com wrote in message
news:20020803231558.GA11531@prism.localnet…

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).

···

On Sun, Aug 04, 2002 at 07:56:21AM +0900, Phil Tomson wrote:

I saw this thread on the Ruby Weekly News and was surprised, that some Ruby
programmers don’t know SWIG!
So I assume that Kalyptus is even more unknown. It is derived from kdoc, which
is the KDE pendant to javadoc, Doxygen, etc.
It produces the same code like SWIG, but has no documentation, no homepage and
should probably have more support from the Ruby community.
URL: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/kalyptus/

Pirmin

···

Am Sonntag, 4. August 2002 01.15 schrieben Sie:

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?


Pirmin Kalberer
sourcepole - Linux & Open Source Solutions
pi@sourcepole.com http://www.sourcepole.com

/me drools copiously

···

On Sun, Aug 04, 2002 at 08:49:02AM +0900, Hal E. Fulton wrote:

Well, from what I see on the SWIG site, it appears
he’s not oversimplifying.

Potentially very exciting, eh?

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, vor_lord@hotmail.com wrote:

“Massimiliano Mirra” list@NOSPAMchromatic-harp.com wrote in message
news:20020803231558.GA11531@prism.localnet…

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

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:transami@transami.net]
%% 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, vor_lord@hotmail.com wrote:
%% > “Massimiliano Mirra” list@NOSPAMchromatic-harp.com wrote in message
%% > news:20020803231558.GA11531@prism.localnet…
%% > > 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
%%
%%

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?
[snip]
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,

As a matter of fact, I attempted to swig a ParaGUI binding for Ruby
earlier this year. IIRC, all that had to be done was create a
Ruby-specific typemap for a callback function; the rest of the interface
definition was already in place, and language agnostic to boot. However,
it didn’t work for some forgotten reason, so I decided to wait for the
Ruby swig module to mature a bit. From what other posters say about
swig’s advances, maybe it’s time to try again. :slight_smile:

  • Leon
···

On Sun, 4 Aug 2002, Tom Sawyer wrote:

Oh I suppose this would help:

http://sourceforge.net/projects/wxruby/

:slight_smile:

Sincerely,

Bob

%% -----Original Message-----
%% From: Bob Calco [mailto:robert.calco@verizon.net]
%% Sent: Sunday, August 04, 2002 8:31 AM
%% To: ruby-talk ML
%% Subject: 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:transami@transami.net]
%% %% 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, vor_lord@hotmail.com wrote:
%% %% > “Massimiliano Mirra” list@NOSPAMchromatic-harp.com wrote
%% in message
%% %% > news:20020803231558.GA11531@prism.localnet…
%% %% > > 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
%% %%
%% %%
%%
%%
%%

hi bob,

i discover your sight about a week or so ago. have been meaning to chat
with you.

i am very very glad to here that you are actively working on this. i
actually just started playing with it myself. as a crap-shoot i tried to
jimmy wxPython to produce me some ruby code. bombed, but it was worth a
shot just to see what would happen.:slight_smile:

i don’t know if you’ve been following the GUI threads at all, but a
binding for wxWindows is very high on the TODO list.

please take a gander at http://www.rubygui.org.

you may not be interested in participating directly with this particular
project (GUtopIa), but i’m marking you down, so to speak, as taking on
the wxWindows binding task that GUtopIa also requires.

i also offer what assistance i can. i’m pretty busy with the meta-API
(among other things) and i’m not much for c coding, but i could help
with docs and such (as i will require them myself) and also see if i can
find anyone else to lend a hand.

i hope its going well!

~transami

···

On Sun, 2002-08-04 at 06:30, Bob Calco wrote:

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:transami@transami.net]
%% 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, vor_lord@hotmail.com wrote:
%% > “Massimiliano Mirra” list@NOSPAMchromatic-harp.com wrote in message
%% > news:20020803231558.GA11531@prism.localnet…
%% > > 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
%%
%%


~transami

In article Pine.LNX.4.40.0208041249280.28543-100000@ngwee.ugcs.caltech.edu,

···

Leon Torres leon@ugcs.caltech.edu wrote:

On Sun, 4 Aug 2002, Tom Sawyer wrote:

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?
[snip]
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,

As a matter of fact, I attempted to swig a ParaGUI binding for Ruby
earlier this year. IIRC, all that had to be done was create a
Ruby-specific typemap for a callback function; the rest of the interface
definition was already in place, and language agnostic to boot. However,
it didn’t work for some forgotten reason, so I decided to wait for the
Ruby swig module to mature a bit. From what other posters say about
swig’s advances, maybe it’s time to try again. :slight_smile:

You definately should try it again. From what I understand swig 1.3.12
was a huge improvement over earlier versions (I started out with 1.3.12,
now 1.3.13 is out ).

Phil

Tom et al.:

I want to make sure the wxRuby port is sufficiently well-thought out to take
advantage of all of the benefits of the proposed meta-API (as you call it).
I am pretty good with C and C++ coding so the Swig part of the general GUI
effort is where I can contribute most uniquely.

Though he’s probably loathe to admit it, Rich Kilmer is a friend of mine,
who lives only a few blocks from me, and so I have been a somewhat silent
but real part of the “rouge” discussions from earlier in the year.
Conceptually the separation of concerns as described by the various layers
(Alpha, Gamma, Delta, Omega or whatever they were all variously called) is
an ideal to be worked toward.

If wxRuby is “done right” it should jive in terms of semantic abstraction
with that separation of concerns and be fairly straightforward to "plug in"
to that architecture (I have FreeRIDE in mind in particular, but it would
really be but one very useful example of a GUI application assembled in this
fashion).

I would be happy therefore to work on, and otherwise be an accomplice to,
GUtopIa, though you are probably aware it was called Utopia once already.
While the realist in me shuns such terminology, and I wouldn’t be caught
dead holding hands to the tune of John Lennon’s “Imagine,” I do think the
world would be a better place with a well thought out GUI architecture for
Ruby, featuring meaningful layers promoting MVC and the separation of
concerns on top of a wicked-cool cross-platform native widget framework like
wxWindows.

:wink:

Bob Calco

%% -----Original Message-----
%% From: Tom Sawyer [mailto:transami@transami.net]
%% Sent: Sunday, August 04, 2002 9:26 AM
%% To: ruby-talk ML
%% Subject: RE: embed or swig?
%%
%%
%% hi bob,
%%
%% i discover your sight about a week or so ago. have been meaning to chat
%% with you.
%%
%% i am very very glad to here that you are actively working on this. i
%% actually just started playing with it myself. as a crap-shoot i tried to
%% jimmy wxPython to produce me some ruby code. bombed, but it was worth a
%% shot just to see what would happen.:slight_smile:
%%
%% i don’t know if you’ve been following the GUI threads at all, but a
%% binding for wxWindows is very high on the TODO list.
%%
%% please take a gander at http://www.rubygui.org.
%%
%% you may not be interested in participating directly with this particular
%% project (GUtopIa), but i’m marking you down, so to speak, as taking on
%% the wxWindows binding task that GUtopIa also requires.
%%
%% i also offer what assistance i can. i’m pretty busy with the meta-API
%% (among other things) and i’m not much for c coding, but i could help
%% with docs and such (as i will require them myself) and also see if i can
%% find anyone else to lend a hand.
%%
%% i hope its going well!
%%
%% ~transami
%%
%%
%% On Sun, 2002-08-04 at 06:30, Bob Calco wrote:
%% > 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:transami@transami.net]
%% > %% 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, vor_lord@hotmail.com wrote:
%% > %% > “Massimiliano Mirra” list@NOSPAMchromatic-harp.com
%% wrote in message
%% > %% > news:20020803231558.GA11531@prism.localnet…
%% > %% > > 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
%% > %%
%% > %%
%% >
%% >
%% >
%% –
%% ~transami
%%
%%

From: Bob Calco [mailto:robert.calco@verizon.net]
Sent: Sunday, August 04, 2002 9:43 AM
To: ruby-talk ML
Subject: RE: embed or swig?

Though he’s probably loathe to admit it, Rich Kilmer is a friend of
mine,
who lives only a few blocks from me, and so I have been a somewhat
silent
but real part of the “rouge” discussions from earlier in the year.
Conceptually the separation of concerns as described by the various
layers
(Alpha, Gamma, Delta, Omega or whatever they were all variously
called) is
an ideal to be worked toward.

I will neither confirm nor deny any friendship with Bob Calco :wink:
(You see, I live in the Washington DC area and such statements are
considered “normal” here)

If wxRuby is “done right” it should jive in terms of semantic
abstraction
with that separation of concerns and be fairly straightforward to
"plug
in"
to that architecture (I have FreeRIDE in mind in particular, but it
would
really be but one very useful example of a GUI application assembled
in
this
fashion).

And our FreeRIDE project’s abstraction via the FreeBASE plugin
architecture will readily support alternate GUI frameworks once in
existence, likely taking 1-2 weeks to complete. Another benefit is that
wx is being ported to Mac OS X, so it will be a first for a
cross-Linux/Win32/OS X client GUI library and would be a wonderful thing
for the Ruby community.

I would be happy therefore to work on, and otherwise be an accomplice
to,
GUtopIa, though you are probably aware it was called Utopia once
already.
While the realist in me shuns such terminology, and I wouldn’t be
caught
dead holding hands to the tune of John Lennon’s “Imagine,” I do think
the
world would be a better place with a well thought out GUI architecture
for
Ruby, featuring meaningful layers promoting MVC and the separation of
concerns on top of a wicked-cool cross-platform native widget
framework

···

-----Original Message-----
like
wxWindows.