Re: embedding octave 3.2.0

[Jaroslav Hajek]

On Fri, Jun 12, 2009 at 11:51 AM, John W. Eaton<address@hidden> wrote:
> On 12-Jun-2009, Soeren Sonnenburg wrote:
>
> | Dear all,
> |
> | it seems there have been a few changes to octave 3.2's core that break
> | shogun's elwms-interface (www.shogun-toolbox.org) embedding octave...
> |
> | In particular, the following functions/global variables are no longer
> | available:
> |
> | octave_allocation_error - octave_allocation_error = 0; (to recover from 
> exception)
>
> Use
>
>  octave_exception_state = octave_no_exception;
>
> instead.
>
> | global_sym_tab  - global_sym_tab->clear();
>
> There is just a single symbol table now, implemented as a singleton
> object.
>
> Global variables are just in a separate special scope.  The function
> do_clear_globals in src/variables.cc removes all global variables
> using this loop:
>
>      string_vector gvars = symbol_table::global_variable_names ();
>
>      int gcount = gvars.length ();
>
>      for (int i = 0; i < gcount; i++)
>        symbol_table::clear_global (gvars[i]);
>
> (Maybe this should be moved to the symbol_table class so that this
> loop could be replaced by a single call to a
> symbol_table::clear_globals function instead...)

Hmm, I see symbol_table::clear_global_pattern only clears global
variables (matching the pattern) visible in current scope. Is that
expected?

>
> | curr_sym_tab - curr_sym_tab->lookup("results")
>
> Are you looking for a variable value?  If so, then you probably want
>
>  octave_value results = symbol_table::varval ("results");
>
> If you want a reference to a symbol so you can modify its value, then
> you should use
>
>  symbol_table::varref ("results") = new_value;
>
> Or do you actually want to get the symbol_record object corresponding
> to the given name in the current scope?  You can also do that, but the
> definition of the symbol_record object has completely changed and I'd
> guess this is not really what you want to do now.
>
> | Now I wonder what the substitutes could be and also if there is a way to
> | change things such that they would still work with octave3.0.x (that
> | does  not use ifdef's).
>
> Given that the interface for the symbol table has completely changed,
> I don't think you will be able to use the same code for both 3.0.x and
> 3.2.x.
>

I think a possible solution is to use eval and feval. That is going to
be slower, though.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz