progress on embedding octave with swig: DECLARE_OCTAVE_ALLOCATOR

[Jon H. Davis]

        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

oig
Description: application/shellscript

octave.cxx
Description: Text Data

ignores.i
Description: Text document

embed.h
Description: Text Data