Re: Creating a standalone executable

[Paul Kienzle]

The trick I've used elsewhere is to pre-allocate the storage using Matrix,
get a pointer to the data using fortran_vec(), then fill that pointer, e.g.,
by reading the data directly from a socket into the pointer.  This very
efficient for initializing matrices with constants in C++, but it might be
good enough.

The other case it doesn't handle is when the data is coming from elsewhere.
E.g.,
it would be nice in what I'm doing to be able to directly share BLT vectors
in Tcl with Matrix values in octave.  However, to do that the matrix class
would need to allow initialization from a pointer and changing the
length/pointer when the BLT vector is updated.  I haven't looked too closely
at this lately since I'm currently using sockets rather than shared memory
to communicate.  I don't know if direct sharing of data is such a wise thing
to do.

Paul Kienzle
address@hidden

----- Original Message -----
From: "JD Cole" <address@hidden>
To: "John W. Eaton" <address@hidden>
Cc: <address@hidden>; "Randy Gober"
<address@hidden>
Sent: Wednesday, December 18, 2002 5:29 PM
Subject: Re: Creating a standalone executable


> Thanks Paul and John,
>   That tied some things together for me. And to answer question John,
> yes, I've been doing a little work on a Octave to C++ translator. I
> don't have much to show yet, so I haven't been very vocal about it. As
> Paul and I had previously discussed, I am attempting to use the
> tree_walker interface to emit code (I called it tree_emit_cplusplus). My
> inquiry, and patches, for tree_checker were are related to this effort.
> I would like to run tree_checker prior to emitting code so I don't have
> to worry about bad trees when I go to emit code. For testing right now I
> am implementing tree_emit_cplusplus in an oct-file because  the compile
> overhead is so much less, however, if proven useful, we may want to
> integrate the functionality into Octave itself, similar to the way GNU
> Emacs has a built-in Lisp compiler.
>
> Some of the issues/ideas I have been kicking around:
> 1. This is a function compiler.
> 2. I have implemented a function interface, right now the following
> function script:
> ------------ mysum.m -------------------
> function [a,this,b] = mysum (this, that, those)
>   a=[1 2 3 4 5];
>
>   res= 0;
>
>   for i=1:5
>     res= res + a(i);
>   end
>   b
>   res
> endfunction
> ----------------------------------------
> tranlates to this:
> ---------------- mysum.cc ----------------
> #include <octave/oct.h>
>
> extern void
> mysum (octave_value& this, const octave_value& that, const octave_value&
> those,
>        octave_value& a, octave_value& b)
> {
> .......
> }
> where input only parameters are marked as const and input/output pairs
> are used to alter return values.
> 3. I am currently educating myself about range values so I can implement
> simple looping.
> 4. One major sticking point right now is the setting of constant
> vector/matrix values. I noticed that the constructors which use
> pointer-based initialization are private. Still not sure on a "clean"
> method of doing this. I would like to do something like this:
> ------------
> double init_data[10]={1,2,3,4,5,6,7,8,9,0};
>
> octave_matrix m(init_data,2,5);
> ------------
> to try to keep things clean.
> 5. I'm using a simple hash table to keep track of valid symbol/variable
> names.
> 6. Perhaps after single functions can be translated, a recursive
> translator can be created which will produce a directory containing all
> the code, .oct and tranlated C++, to created a complete working
executable.
>
> JD
>
> John W. Eaton wrote:
>
> >On 18-Dec-2002, Paul Kienzle <address@hidden> wrote:
> >
> >| octave_value is part of liboctinterp.  Many of the classes on which the
> >| octave_value types are based are defined in liboctave.  E.g., liboctave
> >| defines Matrix, which is wrapped by octave_matrix.
> >|
> >| octave_value implements dynamic typing, so all operations must be
looked
> >| up at run time every time they are invoked.
> >|
> >| Things like the * operator for the Matrix class, however, are
resolvable
> >| at compile time.
> >|
> >| Most of the code in e.g., src/DLD-FUNCTIONS, operates directly on
values
> >| of the underlying type rather than on the octave_value item.
> >
> >Right.  I'm not sure why you would want to operate directly on
> >octave_value objects unless you were working on a simple Octave to C++
> >translator or if you are trying to write some generic functions in C++.
> >(For example, C++ code that can do the equivalent of something like:
> >
> >  function result = add (a, b)
> >    result = a + b;
> >
> >and not have to do any type checking/value extraction before
> >attempting the addition.)
> >
> >If you are writing generic functions, why not just write them in the
> >scripting language?
> >
> >If you are working on a translator, then it might be useful to share
> >some of your ideas on the list.
> >
> >Thanks,
> >
> >jwe
> >
> >
> >
>