SWIG is being used in an increasing number of applications, most of which are related to research and development, prototyping, software testing, and construction of specialized systems. This page describes some of the ways in which SWIG is currently being used.
(Note : the opinions expressed here do not necessarily reflect those of any given employer or organization).
David Beazley (dmb@viking.lanl.gov) and Peter Lomdahl (pxl@viking.lanl.gov)
SWIG is being used to construct a Python interface to the SPaSM molecular dynamics code at Los Alamos National Laboratory. Currently this code is being used to perform large-scale simulations of fracture, shock waves, and dislocation dynamics. The system runs in parallel on a 12 processor Sun Enterprise 4000 server and is implemented with MPI and Solaris multithreading. The Python interface is used to provide users with an interactive data analysis, visualization, and prototyping environment. Users can also interact with underlying C data structures and "steer" computations as needed. One of the advantages of SWIG is that it allows interfaces to be easily constructed from existing code. The SPaSM system consists of nearly 300 C functions and the Python interface is automatically generated during compilation. This work was recently featured on the cover of "Computers in Physics" (June, 1997).
John Schmidt (jas@cs.utah.edu)
I am using SWIG to integrate four stand alone software packages into a unified system controlled by Tcl/Tk scripts. The unified software system is used to design and test defibrillation electrodes via computer simulations of a human subject. The individual software pieces include: a visualization package written in C++ using OpenInventor and Motif, an unstructured mesh generator written in C, a Finite Element Solver written in C, and a segmentation software written in C++ using OpenGL and Motif. SWIG has been crucial to the development of this project. With SWIG, the integration of the individual pieces was trivial.
David Brydon (brydon@lanl.gov)
We are using swig with python to retrieve, analyze, and visualize very large data sets from ocean model simulations on parallel computers. We have written C routines that access our data. Graphics libraries and Matlab are used to visualize the data. We are very happy with the flexible, programmable, powerful tool that results.
Mike Weiblen (mew@paradigmsim.com)
Paradigm sells modular C toolkits for developing visual simulation/virtual reality graphics applications called Vega and another for spatial audio simulation called AudioWorks. I've used SWIG to wrap Vega's and AW's APIs with Silicon Graphics' "sgitcl" to create "vgTcl" and "awTcl". Exploiting the power of interactive scripting languages, they provide the full power of the APIs at runtime, without an application developer having to anticipate flexibility a priori. SWIG has enabled our customers to interact with our toolkits in fundamentally new ways.
Several years ago (I believe we discussed this stuff way back in 1994 ;-), I created a set of C preprocessor macros that did SWIG-like things. It was a very tedious process, making it difficult to follow changes to an evolving API, but it was useful for proof-of-concept. When SWIG 1.1B1 came out in October, I was generously given a R&D budget to reimplement my project in SWIG. The project has been a resounding success!
Jonah Lee (jonah@melab.uafsoe.alaska.edu)
[We're using SWIG for] wrapping up engineering applications using finite element method including pre- and post-processing. My program is somewhat general and is used to solve problems for engineering materials--metals, polymers and ice-- undergoing plastic (permanent) deformations. It's mainly used for rapid prototyping, development and testing. The code runs on workstations, Cray Y-MPs and Cray T3E (when I get there... that is).
Jody Winston (jody@sccsi.com)
I have used SWIG to wrap an API that controlled two stepper motors and a CCD camera on a Linux system that gathered real time image data. In Windows, I wrapped an application's C++ API and used SWIG to embed a Python (pywin) interpreter into the C++ application. I also used SWIG to wrap a FORTRAN API that was used to read and write data into a custom data base.
SWIG has allowed me to move the time critical code into C, C++, or FORTRAN while having the application being controlled by Python. I can quickly embed an interpreter into an application.
Peter Lister (p.lister@cranfield.ac.uk)
I'm using [SWIG] for a Perl scriptable version of Van Jacobson's libpcap packet capture library. I can now use Perl regular expressions to process packets on the fly. My main reason is to extract information from ARP packets and automatically maintain our database of IP/MAC address mappings directly from perl rather than hacking the output of arpwatch or tcpdump.
Harald Singer (singer@itl.atr.co.jp)
[We are using SWIG for] wrapping C libraries to Python for speech recognition research at ATR Interpreting Telecommunications Laboratories.
We are working in a multi-vendor environment (HP-UX, OSF1, Linux, SunOS, Solaris) and writing new applications has become very tedious. Therefore, we decided to employ python, but at the same time we would like to have access to our signal processing libraries etc. that were and are still written in C.
The advantages of using Python become more evident every day. For example, it was fairly easy to write a GUI using python/tk. We are using this now for interactive error analysis. A typical scenario is like this:
SWIG helps us in taking away part of the error-prone task of making the C routines accessible from python and has considerably improved our efficiency.
Dominique Dumont (domi@ss7serv.grenoble.hp.com)
I'm using SWIG to generate a perl5 API on top of HP's OpenCall TCAP API. TCAP is the top protocol layer of HP's SS7 stack of telecom protocol. The perl5 API developemnt effort is a part of the systematic testing approach we're implementing in the division.
The usual way was to write test programs in C. The main drawback being that developing and running the tests consumes a lot of time.
Now the goal is to write all (or at least most of) the test in perl allowing a faster cycle time between modifying the API and testing it. (We'll also be able to debug faster the test programs).
Perl's power also enables us to write test using oo methodology (although the API is strictly procedural), thus we can easily develop complex test scenarios.
Hopefully (i.e. if we have some spare time), the next step will be to combine Tk with Perl and SWIG so we'll be able to monitor with a user friendly interface the progress of the test suite.
Daniel Michelson (Daniel.Michelson@smhi.se)
A collegue and I are using SWIG for two purposes, both of which centre around the creation of a Python-based environment for analysis and visualization of data from the Swedish national weather radar network:
We have a couple of other collegues, also at SMHI R&D, who are working in satellite-based remote sensing activities and who will be starting to use SWIG in the near future for their purposes.
Roger Burnham (rburnham@cri-inc.com)
Thanks again for SWIG... Its fun, allows great productivity while avoiding much tedium...
The current application (there will be many spin-offs/variations) is in polarization microscopy. We manufacture electronically controllable retarder plates, and along with a scientist at the Marine Biological Lab in Woods Hole have developed an algo/method that allows us to visualize a sample's retardance (direction and magnitude) over the whole image. Conventional methods allow you to see this structure only along one axis at a time... The main tools I'm using are Python/Tkinter/PIL/NumPy/SWIG.
So, I've use SWIG to:
Simon Gibson (gibson@dstc.qut.edu.au)
I have been using SWIG to create a Python interface for our prototype implementation of GSSAPI. This is being done so that we can incorporate security into the Hector project here at DSTC. It also means that I can write Python application programmes. Also now we have a standard interface to GSSAPI and any implementation should be able to be plugged in.
Hector is described in an article in the January/February 1997 - Distributed Objects Dr. Dobb's Sourcebook.
Mark Hammond (MHammond@skippinet.com.au)
I'm using [SWIG] to write a commericial application, which runs as an NT service. It uses the COM extensions to talk native MAPI to exchange server, the service extensions to run unattended on NT, and the pipe, file and event modules to manage the service control messages and named pipe connections from clients. All modules named above were generated by SWIG. The COM extensions will allow (once the .i file is up to it :-) any native COM interface (ie, not IDispatch (eg, VB/Word/Excel) based) to be supported by Python.
Michael Bell (michaelb@gold.net.au)
I've used SWIG on a Linux platform to create Python modules for graphing and database access.
The PGPLOT Graphics Subroutine Library is a Fortran library by Tim Pearson (tjp@astro.caltech.edu). I understand it is often used by astronomers. It may also be built into a C library.
I used SWIG to wrap the C library wrapping the Fortran library (!) into a Python module, using some straightforward typemaps to convert one and two dimensional Python Numeric arrays into the appropriate pointers. I haven't methodically tested the full functionality, but everything I tried works just fine.
I've also used SWIG to wrap up a library of Fortran subroutines developed within the Western Australian Department of Environmental Protection to manage databases of time series meteorological and air quality data. I used SWIG to generate a simple shadow class which I then extended further to make the interface nicer.
The original library provided, for instance, subroutines opendb(), writdb(), readdb() and closdb(). My module, epadb.py, provides a database class, epadb.DB, which is instantiated, d=epadb.DB(). The database instance then provides methods d.open(), d.read(), d.write() and d.close(), returning data as Python lists and arrays.
I'm particularly pleased that I managed to do these things with my reading only knowledge of C, and lots of cutting and pasting.
Soeren Henkel (soeren@hni.uni-paderborn.de)
We are currently in the process of redeveloping OOPUS, a system for modeling plant systems and generate plant control software from a model. (Don't ask what OOPUS stands for -it's a German acronym.) We decided to reimplement its user inteface using Tcl/Tk. OOPUS puts its models into an OODBMS, namely POET. So we needed an integration of POET (which is tightly coupled to C++) with Tcl/Tk, and we've successfully done that with SWIG.
Peter A. Tinker (patinker@msmail4.hac.com)
We're using SWIG to "glue" Tcl/Tk to custom and third-party libraries. In particular, SWIG provides an elegant means for controlling Sense8 Corporation's WorldToolKit (WTK) virtual environment development system from a Tk GUI. The result is highly portable code that is independent of WTK's proprietary GUI yet allows access to virtually all WTK functions from a Tcl script and/or a Tk GUI. This approach is being used in a variety of projects involving advanced 3D visualization on a variety of imcompatible systems.
Peter-Pike Sloan (ppsloan@cs.utah.edu)
I have been using SWIG for several projects, mostly to streamline working with OpenGL under Tcl/Tk. Examples are a time-critical framework for viewing Lumigraphs (basically a digital hologram) and a proof of concept application for optimizing texture coordinates based on relative importance (determined by analyzing the existing texture and user specification.) Using SWIG has dramatically reduced my development time allowing me to develop code and debug state in an interpreted environment (currently Tcl, but I think I am going to move to Python).
Chris Myers (myers@beamtech.com)
We at Beam Technologies, Inc. have used SWIG to begin developing an interpreted Python interface to our PDESolve library. PDESolve is a C++ class library for formulating and solving partial differential equations (using either finite difference methods or finite element methods), and makes use of OO technology to present a high-level symbolic interface to the programmer. This makes the description of PDE-based problems concise, and enables the embedding of PDE-based models in larger computational frameworks (e.g., to do PDE-based design optimization or coupled PDE-based systems). SWIG has allowed us very quickly to develop a prototype Python interface to that library. Such an interface holds the promise of: (1) allowing even more rapid prototyping of models, (2) dynamic formulation of models and solution methods, and (3) a method for conveniently integrating PDESolve with other packages (i.e., through the Python substrate). My hope is to make a Python-enabled PDESolve a tool for PDEs something like what Matlab provides for linear algebra, i.e., a high-level, interpreted environment for rapid prototyping and interactive exploration, with an embedded programming language for scripting complex codes.
And while I have been looking for a while for a powerful and extensible interpreted language for use as a front-end to compile codes (which Python is), SWIG has made the interfacing of that code vastly easier than it would have been otherwise. While we are still in the prototyping stages of this overall approach, SWIG enabled us to get up and running quickly with a Python interface to PDESolve, and demonstrate the utility of such an approach for a complex C++ library (something that SWIG was not originally designed to really tackle).
Vladimir I.Ulogov (gandalf@starship.skyport.net)
SWIG is being used to create a Python interface to CLIPS expert system shell inside my general research job under OODBMS DNET. This extention module provide full control from Python environment to expert system: Change a global valiables, register a fact, manipulation with agenda, fact lists, modules, functions, classes and instances. You can dynamicaly create and execute CLIPS commands using clips.RouteCommand function call. Module interface are similar to CLIPS Advanced API, who described into CLIPS documentation. All additional documentation, Python classes are distributed too. Module was be tested on Windows/NT and SUN Solaris 2.4 host platforms, CLIPS version: 6.04, Python version 1.4. This module consist about 270 functions. This job took 3 days of my job at october 1997.
Pinhong Chen (phchenb@tsmc.com)
I got a page for EDA applications using SWIG.
BLADE. A web publishing environment.
PyJava. Provides Python access to Java methods (Kevin Butler).
Pilot Manager. Hook your US Robotics PalmPilot up to your Sun workstation (Bharat Mediratta).
PyWTK. A Python interface to the WorldToolKit (a virtual reality modeling toolkit). (Roberto Lopez Gulliver)
A Python interface to BSD DB 2.7.x (Robin Dunn).
wxPython. A Python extension module that encapsulates the wxWindows GUI classes.
Net-Pcap. A Perl interface to the libpcap library (Peter Lister).
X11::Wcl. A Perl interface to the Widget Creation Library (Joe Buehler).