[Top][All Lists]

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

progress on embedding octave with swig: DECLARE_OCTAVE_ALLOCATOR

From: Jon H. Davis
Subject: progress on embedding octave with swig: DECLARE_OCTAVE_ALLOCATOR
Date: Tue, 30 Aug 2005 12:18:56 -0400
User-agent: KMail/1.7.2

        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 

        I've attached the files I am currently using to experiment with 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. 

 ~/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> 
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


        // some code
        //some other code
}; // end of class xxx

in many of the <octave/ov-*.h> files.  This expands to 


        // some code
          // .......
          // ........
        //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


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


  octave_value *nil_rep (void) const;

This expands to

        public:     // from DECLARE_OCTAVE_ALLOCATOR
          // ......
        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

        //...... code
}; //end of class

        This will make the code following the DECLARE_OCTAVE_ALLOCATOR have 
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 
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.


Attachment: oig
Description: application/shellscript

Attachment: octave.cxx
Description: Text Data

Attachment: ignores.i
Description: Text document

Attachment: embed.h
Description: Text Data

reply via email to

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