Re: [Swig-user] [Octave module bug?] C #define's are not defined for octave functions

[Alan W. I. <ir...@be...>]

On 2011-01-07 18:10-0800 Alan W. Irwin wrote:

> If you create the following simple example.i for octave;
>
> %module example
> #define SPECIAL_VALUE 42
>
> Then wrap and build it
>
> swig -octave -c++ -o example.cpp example.i
> mkoctfile example.cpp
>
> The variable is available at the octave command-line level, but is undefined
> within octave functions.
>
> octave:1> example
> octave:2> SPECIAL_VALUE
> SPECIAL_VALUE =  42
> octave:3> function test()
>> SPECIAL_VALUE
>> endfunction
> octave:4> test
> error: SPECIAL_VALUE' undefined near line 2 column 1
> error: called from:
> error:   test at line 2, column 1
>
> These "undefined" results for accessing #define'd values from Octave
> functions were obtained with Octave version 3.2.4 and swig version
> 1.3.40-3 from Debian testing.  I also tried putting "global
> SPECIAL_VALUE" in the function, but that did not change the result.

If I define the global attribute for SPECIAL_VALUE before "example" is
invoked to dynamically load example.oct AND also inside the function,
I can get the simple example to work, i.e.,

octave:1> global SPECIAL_VALUE
octave:2> example
octave:3> function test2()
> global SPECIAL_VALUE
> SPECIAL_VALUE
> endfunction
octave:4> test2()
SPECIAL_VALUE =  42

But that is far from an ideal solution.  What the current situation
means for wrapping an API such of that of PLplot is that you must
create some octave script file (call it plplot_stub.m) that is headed
by a zillion different global statements corresponding to your various
C #defines before it loads our oct file (plplot_octave.oct in this
case).  I guess I can parse the *.i file that defines our API for
#defines in order to automatically prepare plplot_stub.m, but that
required additional scripting doesn't seem to be in the spirit of
swig.

What's worse though, is every PLplot user is forced to specifically
set a global attribute for every PLplot #defined value he uses inside
functions. For example, we have 33 different octave script files that
make various test plots within functions.  In order to get those to
work we have to remember to insert global statements for the used
PLplot variables wherever they occur.  So for C #defined values it
turns octave into a strongly typed language like C which is not
exactly in the spirit of octave.

I hope this issue can be solved by some simple change to the swig
octave language module because both parts of the workaround outlined
above are far from ideal.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________