Re: ROctave

[Paul Kienzle]

----- Original Message -----
From: "Andy Adler" <address@hidden>
To: "John W. Eaton" <address@hidden>
Cc: "Duncan Temple Lang" <address@hidden>;
"octave-maintainers mailing list" <address@hidden>
Sent: Monday, December 16, 2002 1:31 PM
Subject: Re: ROctave


> On Mon, 16 Dec 2002, John W. Eaton wrote:
> >   octave_init ();  // perhaps with an argument to say not interactive?
> >
> >   // other stuff...
> >
> >   for (;;)
> >     {
> >        // ...
> >
> >        octave_value result = parse_and_execute_octave_command (???);
> >
> >        // or some other method of controlling Octave...
> >     }
> >
> > Though I'm not sure what would be best.  As things are now,
> > octave_value is probably only useful inside a C++ program, and it's
> > not clear to me how we should control Octave from another program.  In
> > some cases, parsing and evaluating strings might be OK, but in other
> > cases, you may want to build a parse tree using some function calls
> > and then evaluate that directly, skipping the lexer/parser.
> >
> > As a minimum, I think we need to write a few functions that allow us
> > to initialize Octave without starting up the interactive I/O system so
> > we can just use Octave as a compute engine.

Are there cases where we would not want to initialize everything?  E.g., the
types but not the symbol tables?  Probably not since this interface is
designed to run interpreted code, so the whole interpreter needs to be
initialized.

>
> This is exactly the functionality I need to write a proper
> Inline::Octave for Perl. Currently I'm doing it by controlling
> stdin / stdout with two pipes, but it's a real pain.

Agreed.  It is especially difficult to protect against poor code being sent
to
the interpreter.  I have much better luck in my socket listening code
because the eval statement sets a natural boundary within which all blocks
must be closed.

>
> Note: this API also needs a good way to get errors and
> warnings back from octave.

Presumably we need to turn on octave's signal handling upon entering eval
and turn it off again upon leaving.

We also need to figure out what to do with the input statement.

And capture the output so that it can be returned to the caller.

What happens when the debugger is triggered?

Another feature I would like is an "eval in" function.  I find in my code
that I have a lot of interplay between tcl and octave.  I'll intersperse a
few lines of octave with a few lines of tcl throughout a subroutine. The
problem that I'm having is that temporary variables from one subroutine are
colliding with temporary variables in other subroutines.  To avoid this, I
want to be able to create a symbol table and call eval with it a bunch of
times, then possibly empty or delete it.

>
> Andy
>