From: jon@mast.queensu.ca
To: help@octave.org
Subject: Progress on embedding octave with swig: DECLARE_OCTAVE_ALLOCATOR
I have managed to get swig to generate wrapper code for embedding the
functionality some octave header files in a variety of scripting languages.
So far, I have concentrated on the headers used in the Da Coda Al Fine
examples, together with those used in the octave embedding example on
sourceforge.
I've attached the files I am currently using to experiment with this. This
includes an "oig" (octave interface generator) script that lets one worry
only about a single file with the list of the header files one wants to wrap.
Typing
~/develop/ $: for t in python perl java tcl; do ./oig target=$t; done;
will generate subdirectories with code for embedding in python, perl, java,
and tcl. I have resisted the temptation to generate the code for pike, ruby,
php, and several dialects of scheme. Using this path to embed octave inside
the Gimp is something I haven't tried.
This processing is done with a local working copy of the <octave/*.h> files,
modified to keep swig happy. One change is to rename DYNAMIC_CAST to avoid a
collision with swig's use of it. The other problem I've run into is from the
appearance of the sequence
private:
// some code
DECLARE_OCTAVE_ALLOCATOR
//some other code
}; // end of class xxx
in many of the <octave/ov-*.h> files. This expands to
private:
// some code
public:
// .......
private:
// ........
//some other code
}; // end of class xxx
and this (legal c++) causes the internal swig 1.3.24 c++ parser to segfault
when it attempts to parse the file. A workaround for this (from my change to
ov.h) is to structure it as
DECLARE_OCTAVE_ALLOCATOR
private:
static int curr_print_indent_level;
static bool beginning_of_line;
assign_op unary_op_to_assign_op (unary_op op);
binary_op op_eq_to_binary_op (assign_op op);
// DECLARE_OCTAVE_ALLOCATOR
octave_value *nil_rep (void) const;
};
This expands to
public: // from DECLARE_OCTAVE_ALLOCATOR
// ......
private:
//........
private: // original access boundary
// original private code
}; // end of class
This gives a linear progression in the access types of the class, and seems to
keep the swig parser in stable territory.
While looking at header files for this issue, I saw an instance of
protected:
/......
DECLARE_OCTAVE_ALLOCATOR
//...... code
}; //end of class
This will make the code following the DECLARE_OCTAVE_ALLOCATOR have access
that is private: rather than the apparently intended protected: . Whether
this is a problem depends on the existence other code trying to get
protected: access to the class.
With the python wrappers generated, it should be possible to develop a gui
for octave using glade/PyGTK (as well a various other scripting languages),
or develop standalone applications with a gui and using octave as a
computational engine. By wrapping the "right" parts of the octave api, one
could probably develop a user level debugging gui for octave also.
--Jon