help-octave
[Top][All Lists]
Advanced

[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 14:00:54 -0700

On Wed, Sep 8, 2010 at 1:28 PM, David Grundberg <address@hidden> wrote:
>>> 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.

Correct. Currently swig wrappers use the native "octave API" and
compile to oct-files, etc.

Using mex would be advantageous because the mex interface is more
simple/stable/static and better documented, and because it would allow
swig-generated wrappers to work with matlab.

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

Yes, the question was about putting multiple functions into a single
m-file. I thought that was possible with newer matlab, but I could be
mistaking that for just multiple member functions in their singlefile
class support.

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

Yes, that's right.

I think single vs multi file class support is not really that
essential, it's mainly an aesthetic thing. If you run swig against a
moderate sized library that has >50 classes it will generate hundreds
of m-files, rather than one per class (or fewer?).

More important is the support for handle classes (destructors +
copy-by-ref). That is required to use octave classes to wrap C
classes.

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

Agreed.

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

Hacks like making static methods and variables appear as global
methods and variables are okay. Eg, static methods could be made to
appear as class_name_static_method_name() from octave. Static
variables are a bit trickier since the wrapper needs to told when
assignment happens (so it can assign the C-side variable). xyz_set()
and xyz_get() functions can also be generated for static variable
access.

Xavier



reply via email to

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