Re: Swig works (Re: Octave and databases)

[David Grundberg]

Xavier Delacour skrev:
> 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.

Let's straighten out this as soon as possible to reduce
misunderstandings.  The current solution that swig uses with
.oct-interfacing *does not* use the "mex interface".  The mex interface,
i.e. API compatibility with MATLAB, is a feature in Octave.  But it is
there for freeing toolboxes that previously could only run on with the
proprietary software.  Using the mex interface to make new software
isn't recommended.  To get most out of Octave, using dynamically loaded
functions (.oct) are to best way to go.

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

It's possible to put several DEFUN's in one .oct file.  You need to tell
Octave in which files to look for specific functions though.

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

There's support for multifile (with '@classname' directories) classes in
Octave, and has been for some while.  This class system is rather
limited, I'd say.  I guess that's why the proprietary vendor went for a
completely new, separate class system (which is singlefile) in later
versions.  The new class system also support references ("handles").

So the "putting several functions in an oct-file" issue is clearly
separated from the "support for singlefile classes" issue.

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

Yeah, the form class_name.static_func() is very unnatural in Octave, as
of right now.   Octave doesn't have class names as a namespace qualifier
(in fact it has nothing of the sort) and that's why it looks so out of
place.  In the Octave language, using only what you know about multifile
classes to interpret this example, it looks like you are creating an
instance (using the constructor for 'class_name') and dot-indexing it
for the field 'static_func'.

I'm not sure about static methods in the singlefile class system,
can anyone fill this in?  Does Matlab support static methods?

Regardless of that, just a note about instance methods.  In Octave, a
native class (written in a .m multifile class) would call methods in the
form method(object, arg1, arg2).  The singlefile style, which remains
unimplemented, can do object.method(arg1, arg2) (as well as the
multifile style, I believe).

Thanks for your input Xavier.

Grundberg