[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Swig works (Re: Octave and databases)

From: Xavier Delacour
Subject: Re: Swig works (Re: Octave and databases)
Date: Wed, 8 Sep 2010 12:12:36 -0700

On Wed, Sep 8, 2010 at 9:59 AM, David Grundberg <address@hidden> wrote:
> Søren Hauberg skrev:
>> ons, 01 09 2010 kl. 21:48 +0200, skrev David Grundberg:
>>> Using SWIG together with the database manager's client library is
>>> probably smoothest way to make the interfacing oct file.
>> If memory serves me correct then this is the approach taken by the
>> 'database' package. Sadly, SWIG for Octave is the source of quite a bit
>> of errors, so for this approach to really work, somebody would have to
>> fix SWIG for Octave.
> Yeah, I saw that.  I made a very simple swig input file, and the wrapper
> file swig 1.3.36 produces won't make it through mkoctfile.  It's the
> symbol table changes (3.0 -> 3.2) that messes it up.

Yes, those packages (eg database) aren't presently maintained. They
have a copy of the generated swig sources so folks don't have to
download swig to install the package, but those haven't been
regenerated and updated in octave forge svn.

Swig/octave however is maintained by several people, and has a test
suite of ~330 passing tests.

> Aaaand, guess what, I tried it on swig's trunk, and there it works like
> a charm!  They are using the OCTAVE_API_VERSION_NUMBER define rather
> furiously.
> As it stands now swig has some hack to implement a half-hearted
> module/namespace thing ontop of one single DEFUN.  I wish swig had taken
> another path and prefixed symbols, making each function have its own
> DEFUN.  Or yet even better, have true namespaces/modules implemented in
> Octave :]

I think any rework of swig/octave should have the generated C code
work with the mex interface, and generate m-files for each global
function and classes. The generated m-file code would just be stubs
that call the internal mex interface.

The main thing blocking that is that octave classes need destructors
and copy-by-ref objects (so swig can track and destroy C-side
instantiations), and it would be nice if multiple functions/classes
could be defined per file so that swig generation doesn't produce tons
of little files, but instead one or a few m-files. (I think both items
are supported in latest matlab, in particular "handle classes" [1])

Modifying swig to produce DEFUN per global function is relatively
trivial, but swig requires the language module to support classes. The
work was done before class support was added to octave.

The top-level defun registers "class objects" as global variables
(akin to python type objects). () operator on those implements class
constructor, class_name.func() and class_name.var implement static
functions and variables. The "namespace" object is like a class with
global functions as static functions, and handled as above. Global
functions are also added to toplevel, which should be equivalent to
DEFUN per global function.



> Grundberg
> _______________________________________________
> Help-octave mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]