Re: ROctave

[Duncan Temple Lang]

Hi John.

I finally got a chance to get to this and put Octave inside R.  Thanks
for making those changes. It is a great start and I made some trivial
additions to conditionally activate different parts of the code. I've
attached the patch file for the 3 files that were modified.  With
those changes compiled into liboctave and calling octave_main() with
the new 3rd argument - embedded - as 1, I get the Octave engine
without the octave event/input loop.

We could, of course, also split the octave_main into more pieces, some
common and some specific to interactive use, and have main() be
slightly more complex. Either works well for me; more routines gives
greater customizability at the expense of complexity. So sticking with
arguments to octave_main() might be simplest, and that is what I was
going for.  If we also want to allow conditional startup of the I/O
system, etc.  then we may want a general options object or
split the material into multiple routines.

Regarding whether one wants to parse and evaluate strings or build
parse trees, all our inter-system interfaces typically work by calling
regular functions in the embedded system.  So for Octave in R, the
primary function is .Octave which takes the name of the Octave
function to call and an arbitrary number of arguments.  I convert
those R values to Octave objects (octave_values) and call feval() and
convert the result back to R.  We try to dissuade people from using
commands passed as strings as then they have to know two languages.
And one cannot express all types of expressions, e.g. when one needs a
reference to an object in one system.

Cheers,
 D.


John W. Eaton wrote:
> [I'm copying this to the octave-maintainers mailing list so that we
> can maybe start a discussion of this there as well.  --jwe]
> 
> On  7-Dec-2002, Duncan Temple Lang <address@hidden> wrote:
> 
> | The only difficulty that might arise in the longer term is what I
> | would ideally like to have: an Octave embedded in R.
> 
> OK, I've been thinking about how to do something similar (allow people
> to load Octave in other programs) and it is currently possible to load
> all of Octave as a shared library.  The main Octave program is now
> just
> 
>   #ifdef HAVE_CONFIG_H
>   #include <config.h>
>   #endif
> 
>   #include "f77-fcn.h"
>   #include "lo-ieee.h"
> 
>   #include "octave.h"
> 
>   int
>   main (int argc, char **argv)
>   {
>     return octave_main (argc, argv);
>   }
> 
> and octave_main and everything else is in a set of shared libraries,
> so you can load them and call octave_main in your own application.
> The problem is that this also starts up the interactive command loop.
> So we really need an interface that looks something like
> 
>   // load shared libraries...
> 
>   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.
> 
> jwe

PATCHES
Description: Text document