gnupic: Thread: gpsim scripting

As some of you may be aware, I've been working on enhancing gpsim. The 
next item on my list is scripting, as in REAL scripting and not the make 
believe stuff gpsim currently does. But I need some help here.

First, I'm creating a Python interface to gpsim. So far, I've cleaned up
the simulator engine (the stuff in src/) so that it has zero dependencies
on the gui and command line interface. I've written a very simple SWIG
(http://www.swig.org) wrapper for gpsim, compiled it, and was able to
instantiate a P16F84 inside Python!

Interfacing the simulator to Python can either be done by brute force
(e.g. writing the C/C++ wrappers), or by using a tool like SWIG to
(mostly) automate the process. In addition to SWIG, I found three other 
tools, SIG, weave, and boost.python (http://www.boost.org/). 

I like SWIG because in addition to supporting C/C++ to Python interfaces, 
it also supports Perl, TCL, Ruby, Java, guile, scheme, and php. SWIG is 
also distributed with most Linux distros and has been around for about 10 
years.

I like boost.python because it has better support for C++ than SWIG. 
boost.python is relatively new (~5 years old) and is part of the Boost 
distribution (a package containing C++ classes for a variety of technical 
tools).

I'm not even considering SIG and Weave.

Both SWIG and boost.python require interface files. The SWIG interface
files are essentially shadow classes. SWIG cannot parse C++ include files.
You also have to be fairly explicit on the intent (e.g. a pointer that is
parameter to a function must be declared as input, output, or
bi-directional). The boost.python interface files can parse C++ include
files. You essentially #include your C++ include file and write
boost.python interface code to select what portion of your C++ class you
wish to expose. You can also extend the C++ classes with new methods (e.g.
you can customize the python __init__ method).

From a practical point of view, I prefer SWIG because it automatically 
gives us support for other scripting languages. I also found that SWIG is 
easier to install and seems to be widely distributed. From a theoretical 
point of view, I think that boost.python will provide a better C++ 
interface.

The brute-force approach is attractive in that it has zero-dependence on a 
third party package.

Now for the questions. Does anybody have experience with interfacing C/C++
and Python and have an opinion about which approach that should be taken? 
How important is it to have scripting support for other scripting 
languages like Perl?

So far I'm just concerned about the mechanics of interfacing the simulator
to Python. Eventually I'll be concerned with the usefulness of it. To this
end, I intend to expose a good portion of the simulator so that users can
write custom tools for testing stuff out. The first plan will be for 
regression testing of the simulator. The next step will be really useful 
stuff like Python modules that can interact with the simulator. It may 
turn out that the "usefulness" factor affects the decision on how gpsim 
will interface to Python, but I don't know now.

Any advice is more than welcomed.

Scott

On Fri, Feb 27, 2004 at 11:08:41AM -0800, Scott Dattalo wrote:
> Now for the questions. Does anybody have experience with interfacing
> C/C++ and Python and have an opinion about which approach that should
> be taken?  How important is it to have scripting support for other
> scripting languages like Perl?

I made a Python interface to a C++ library a few years ago.  I found
boost.python much easier to use, since as you say it's much better at
C++.  I would chose Python for this out of preference anyway, so I don't
see the lack of other languages as a disadvantage.  :-)

And from a practical point of view, if you wouldn't be using the other
languages yourself you don't really want to be maintaining all the extra
glue bits!

So my vote is for boost.python.

Chris

On Fri, 27 Feb 2004, Chris Emerson wrote:

> So my vote is for boost.python.

That seems to be the consensus on the web too. I'm going to experiment 
with it next.

Scott

>> So my vote is for boost.python.
>
> That seems to be the consensus on the web too. I'm going to experiment
> with it next.

I don't know anything about SWIG and boost.python, but I speak Perl and
Java,
so I was going to propose SWIG. But now it seems that I'll have to learn
python...

I have some experience on Java JVM integration.

And a question:
Is boost.python (or SWIG) supported on WIN32?

Borut

On Sat, 28 Feb 2004, Borut Razem wrote:

> Is boost.python (or SWIG) supported on WIN32?

They both work under Windows. In fact, it appears that boost.python's
preferred OS is Windows. I gather this from their obscure Jam files, which
are nothing more than Makefile replacements. Also, most of the examples
are illustrate within a Windows environment. My general sense is that of
all the scripting languages that Python is most popular among Window's
developers.

Oh incidently, there are packages for MAC OS and BSD too. I remember 
seeing that SWIG runs under Solaris. So, except for Commodore 64, I think 
that covers just about everything. 

Scott