Creating a standalone executable

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating a standalone executable

JD Cole-2
I am trying to write a standalone application using the Octave API and
am running into some trouble when I actually run the application. Here's
what I did:

source code (a.cc)
=========
#include <octave/oct.h>

#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
  octave_value a(10.0),b(20.0),c;

  c = a + b;

  c.print(cout);
 
  return (0);
}

how I compiled it
=============
Initially I tried using the "--link-stand-alone" argument to mkoctfile,
but it seemed to be missing the library arguments "-lkpathsea
-loctinterp" or else I get missing symbols related to these two libraries.

So I used "mkoctfile -c a.cc -o a.o" to copile the object file and then
added the above libraries to the output of "mkoctfile --verbose -o a
a.o". Which seems to compile just fine.

when I ran it
=========
Running "./a" yields the following output:

fatal: range error in Array3

This error comes from "checkelem" in Arrray3.h. Of course, to my
knowledge, I'm only using scalars. I tried changing my source to just "c
= a" rather than "c = a +b" and it performed as expected. I investigated
the operator instantiations of "+" in ov.h and was a bit confused.

Another note: I did try putting the above code into a DLD_FUNTION and it
performed as expected.

I guess my question here is, "Has anyone done this before?"

Best,

JD



Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

Paul Kienzle-2
JD,

The '+' operator is looked up in a three dimensional array of op x type x type.

You will want to go into octave.cc and look at the octave_main function.

Depending on what you are doing, you will need to include various pieces from
there, in this case install_ops().

Doug, are you adding this to your help document?

Paul Kienzle
[hidden email]

On Fri, Dec 13, 2002 at 12:37:46PM -0800, JD Cole wrote:

> I am trying to write a standalone application using the Octave API and
> am running into some trouble when I actually run the application. Here's
> what I did:
>
> source code (a.cc)
> =========
> #include <octave/oct.h>
>
> #include <iostream>
>
> using namespace std;
>
> int main(int argc, char *argv[])
> {
>   octave_value a(10.0),b(20.0),c;
>
>   c = a + b;
>
>   c.print(cout);
>  
>   return (0);
> }
>
> how I compiled it
> =============
> Initially I tried using the "--link-stand-alone" argument to mkoctfile,
> but it seemed to be missing the library arguments "-lkpathsea
> -loctinterp" or else I get missing symbols related to these two libraries.
>
> So I used "mkoctfile -c a.cc -o a.o" to copile the object file and then
> added the above libraries to the output of "mkoctfile --verbose -o a
> a.o". Which seems to compile just fine.
>
> when I ran it
> =========
> Running "./a" yields the following output:
>
> fatal: range error in Array3
>
> This error comes from "checkelem" in Arrray3.h. Of course, to my
> knowledge, I'm only using scalars. I tried changing my source to just "c
> = a" rather than "c = a +b" and it performed as expected. I investigated
> the operator instantiations of "+" in ov.h and was a bit confused.
>
> Another note: I did try putting the above code into a DLD_FUNTION and it
> performed as expected.
>
> I guess my question here is, "Has anyone done this before?"
>
> Best,
>
> JD
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

JD Cole-2
In reply to this post by JD Cole-2
Thanks Paul, worked like a charm. (Code included below for those
on-lookers.) As for the compilation steps, should "-lkpathsea
-loctinterp" be default linker arguments to "mkoctfile
--link-stand-alone"? If so I will create a patch.

-JD

the code
========================
#include <octave/oct.h>
#include <octave/ops.h> // added this include for install_ops definition

#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
  install_types ();

  // Important that types are installed before ops
  install_ops ();

  octave_value a(10.0),b(20.0),c;

  c = a + b;

  c.print(cout);
 
  return (0);
}
===================


Paul Kienzle wrote:

>And you probably want install_types () as well.  I'm surprised it gets to
>the operator lookup without it.
>
>- Paul
>  
>



Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

Paul Kienzle-2
Can you include -lkpathsea on the mkoctfile line?  Those libs
should be passed directly through to the linker unless there
is a bug in mkoctfile.

The reason not to include -loctinterp is that liboctave can
be used without liboctinterp.  On the other hand, it doesn't
hurt to specify -loctinterp even if nothing uses it, does it?

I didn't realize kpathsea was a separate library.  I thought
it was statically linked into liboctave.

On Fri, Dec 13, 2002 at 02:17:50PM -0800, JD Cole wrote:

> Thanks Paul, worked like a charm. (Code included below for those
> on-lookers.) As for the compilation steps, should "-lkpathsea
> -loctinterp" be default linker arguments to "mkoctfile
> --link-stand-alone"? If so I will create a patch.
>
> -JD
>
> the code
> ========================
> #include <octave/oct.h>
> #include <octave/ops.h> // added this include for install_ops definition
>
> #include <iostream>
>
> using namespace std;
>
> int main(int argc, char *argv[])
> {
>   install_types ();
>
>   // Important that types are installed before ops
>   install_ops ();
>
>   octave_value a(10.0),b(20.0),c;
>
>   c = a + b;
>
>   c.print(cout);
>  
>   return (0);
> }
> ===================
>
>
> Paul Kienzle wrote:
>
> >And you probably want install_types () as well.  I'm surprised it gets to
> >the operator lookup without it.
> >
> >- Paul
> >  
> >
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

JD Cole-2
Paul,
   My mistake. I went back and checked the need for -loctinterp, and it
isn't. It didn't make sense to me either. (This was a figment of me
trying to get mode stand-alone app to work. But now I can't repeat the
problem.) As for -lkpathsea, I have compiled octave with the
--enable-shared --enable-dl. Perhaps when these switches are marked,
kpathsea is not being linked in statically. I verified that it is not a
shared library of my stand-alone app using ldd:

ldd ./a

    liboctave.so => /video_tmp/build/lib/octave-2.1.40/liboctave.so
(0x40018000)
    liboctinterp.so =>
/video_tmp/build/lib/octave-2.1.40/liboctinterp.so (0x40157000)
    libcruft.so => /video_tmp/build/lib/octave-2.1.40/libcruft.so
(0x403c2000)
    liblapack.so.3 => /usr/lib/liblapack.so.3 (0x4042e000)
    libblas.so.3 => /usr/lib/libblas.so.3 (0x40871000)
    libreadline.so.4 => /video_tmp/build_tools/lib/libreadline.so.4
(0x408bc000)
    libncurses.so.5 => /usr/lib/libncurses.so.5 (0x408e7000)
    libdl.so.2 => /lib/libdl.so.2 (0x40929000)
    libg2c.so.0 => /video_tmp/build_tools/lib/libg2c.so.0 (0x4092d000)
    libm.so.6 => /lib/i686/libm.so.6 (0x4094c000)
    libgcc_s.so.1 => /video_tmp/build_tools/lib/libgcc_s.so.1 (0x40970000)
    libstdc++.so.5 => /video_tmp/build_tools/lib/libstdc++.so.5 (0x40978000)
    libc.so.6 => /lib/i686/libc.so.6 (0x40a2d000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


Please note that this compilation only used an extra "-lkpathsea" and NO
"-loctinterp". Which leads me to ask, why liboctinterp is still a
dynamic library dependency.

-JD

Paul Kienzle wrote:

>Can you include -lkpathsea on the mkoctfile line?  Those libs
>should be passed directly through to the linker unless there
>is a bug in mkoctfile.
>
>The reason not to include -loctinterp is that liboctave can
>be used without liboctinterp.  On the other hand, it doesn't
>hurt to specify -loctinterp even if nothing uses it, does it?
>
>I didn't realize kpathsea was a separate library.  I thought
>it was statically linked into liboctave.
>
>  
>




Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

Andy Adler
I just tried your test code under cygwin (with 2.1.40)
and liboctinterp _is_ a dependency

$ mkoctfile --link-stand-alone -loctinterp test.cc
g++: unrecognized option `-rdynamic'

$ ./a.exe
3.000000e+01

$ mkoctfile --link-stand-alone  test.cc
g++: unrecognized option `-rdynamic'
test.o(.text+0x95): In function `main':
/home/adler/test.cc:7: undefined reference to `install_types()'

Andy


On Fri, 13 Dec 2002, JD Cole wrote:

> Paul,
>    My mistake. I went back and checked the need for -loctinterp, and it
> isn't. It didn't make sense to me either. (This was a figment of me
> trying to get mode stand-alone app to work. But now I can't repeat the
> problem.) As for -lkpathsea, I have compiled octave with the
> --enable-shared --enable-dl. Perhaps when these switches are marked,
> kpathsea is not being linked in statically. I verified that it is not a
> shared library of my stand-alone app using ldd:
>
> ldd ./a
>
>     liboctave.so => /video_tmp/build/lib/octave-2.1.40/liboctave.so
> (0x40018000)
>     liboctinterp.so =>
> /video_tmp/build/lib/octave-2.1.40/liboctinterp.so (0x40157000)
>     libcruft.so => /video_tmp/build/lib/octave-2.1.40/libcruft.so
> (0x403c2000)
>     liblapack.so.3 => /usr/lib/liblapack.so.3 (0x4042e000)
>     libblas.so.3 => /usr/lib/libblas.so.3 (0x40871000)
>     libreadline.so.4 => /video_tmp/build_tools/lib/libreadline.so.4
> (0x408bc000)
>     libncurses.so.5 => /usr/lib/libncurses.so.5 (0x408e7000)
>     libdl.so.2 => /lib/libdl.so.2 (0x40929000)
>     libg2c.so.0 => /video_tmp/build_tools/lib/libg2c.so.0 (0x4092d000)
>     libm.so.6 => /lib/i686/libm.so.6 (0x4094c000)
>     libgcc_s.so.1 => /video_tmp/build_tools/lib/libgcc_s.so.1 (0x40970000)
>     libstdc++.so.5 => /video_tmp/build_tools/lib/libstdc++.so.5 (0x40978000)
>     libc.so.6 => /lib/i686/libc.so.6 (0x40a2d000)
>     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
>
> Please note that this compilation only used an extra "-lkpathsea" and NO
> "-loctinterp". Which leads me to ask, why liboctinterp is still a
> dynamic library dependency.
>
> -JD
>
> Paul Kienzle wrote:
>
> >Can you include -lkpathsea on the mkoctfile line?  Those libs
> >should be passed directly through to the linker unless there
> >is a bug in mkoctfile.
> >
> >The reason not to include -loctinterp is that liboctave can
> >be used without liboctinterp.  On the other hand, it doesn't
> >hurt to specify -loctinterp even if nothing uses it, does it?
> >
> >I didn't realize kpathsea was a separate library.  I thought
> >it was statically linked into liboctave.
> >
> >
> >
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Creating a standalone executable

John W. Eaton-6
In reply to this post by JD Cole-2
On 13-Dec-2002, JD Cole <[hidden email]> wrote:

| I am trying to write a standalone application using the Octave API and
| am running into some trouble when I actually run the application. Here's
| what I did:
|
| source code (a.cc)
| =========
| #include <octave/oct.h>
|
| #include <iostream>
|
| using namespace std;
|
| int main(int argc, char *argv[])
| {
|   octave_value a(10.0),b(20.0),c;
|
|   c = a + b;
|
|   c.print(cout);
|  
|   return (0);
| }
|
| how I compiled it
| =============
| Initially I tried using the "--link-stand-alone" argument to mkoctfile,
| but it seemed to be missing the library arguments "-lkpathsea
| -loctinterp" or else I get missing symbols related to these two libraries.

I've modified mkoctfile so that it will include these libraries when
linking stand alone executables.

But there is another problem in that the kpathsearch library is not
installed when Octave is installed.

Eventually, I'd like to remove kpathsearch from the Octave sources,
but we can't do that quite yet.  Some changes were needed to make
kpathsearch work with Octave, and I'm not sure those changes are in
any released version of kpathsearch yet, though I believe the changes
have been accepted by the kpathsearch maintainer.

I'm not sure whether it is a good idea to just install the
libkpathsea.a from Octave's sources, since that may wipe out some
other version of the library that is installed, depending on how
libdir is set when building Octave.  So maybe we should rename
Octave's libkpathsea.a to be liboctkpathsea.a and install that
instead?

Other suggestions?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

John W. Eaton-6
In reply to this post by Paul Kienzle-2
On 13-Dec-2002, Paul Kienzle <[hidden email]> wrote:

| The '+' operator is looked up in a three dimensional array of op x
| type x type.
|
| You will want to go into octave.cc and look at the octave_main function.
|
| Depending on what you are doing, you will need to include various pieces from
| there, in this case install_ops().

Maybe we should try to fix this so the operator installation happens
automatically?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

Paul Kienzle-2
On Wed, Dec 18, 2002 at 12:12:22PM -0600, John W. Eaton wrote:

> On 13-Dec-2002, Paul Kienzle <[hidden email]> wrote:
>
> | The '+' operator is looked up in a three dimensional array of op x
> | type x type.
> |
> | You will want to go into octave.cc and look at the octave_main function.
> |
> | Depending on what you are doing, you will need to include various pieces from
> | there, in this case install_ops().
>
> Maybe we should try to fix this so the operator installation happens
> automatically?

There are several different levels of support that people may want:

        liboctave support
        octave_value support
        symbol_table support
        interpreter support

The octave_value and symbol_table support is needed so that people can call
Fload/Fsave from a standalone application.  They do not need octave_value
operators.

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

Paul Kienzle-2
In reply to this post by John W. Eaton-6
On Wed, Dec 18, 2002 at 12:09:55PM -0600, John W. Eaton wrote:

> On 13-Dec-2002, JD Cole <[hidden email]> wrote:
>
> | I am trying to write a standalone application using the Octave API and
> | am running into some trouble when I actually run the application. Here's
> | what I did:
> |
> | source code (a.cc)
> | =========
> | #include <octave/oct.h>
> |
> | #include <iostream>
> |
> | using namespace std;
> |
> | int main(int argc, char *argv[])
> | {
> |   octave_value a(10.0),b(20.0),c;
> |
> |   c = a + b;
> |
> |   c.print(cout);
> |  
> |   return (0);
> | }
> |
> | how I compiled it
> | =============
> | Initially I tried using the "--link-stand-alone" argument to mkoctfile,
> | but it seemed to be missing the library arguments "-lkpathsea
> | -loctinterp" or else I get missing symbols related to these two libraries.
>
> I've modified mkoctfile so that it will include these libraries when
> linking stand alone executables.
>
> But there is another problem in that the kpathsearch library is not
> installed when Octave is installed.
>
> Eventually, I'd like to remove kpathsearch from the Octave sources,
> but we can't do that quite yet.  Some changes were needed to make
> kpathsearch work with Octave, and I'm not sure those changes are in
> any released version of kpathsearch yet, though I believe the changes
> have been accepted by the kpathsearch maintainer.
>
> I'm not sure whether it is a good idea to just install the
> libkpathsea.a from Octave's sources, since that may wipe out some
> other version of the library that is installed, depending on how
> libdir is set when building Octave.  So maybe we should rename
> Octave's libkpathsea.a to be liboctkpathsea.a and install that
> instead?
>
> Other suggestions?

Is there some way to force liboctave or liboctinterp to include all
the symbols from libkpathsea.a that it needs so that you do not
have to subsequently link against libkpathsea?  I thought it did this
already.

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

John W. Eaton-6
On 18-Dec-2002, Paul Kienzle <[hidden email]> wrote:

| Is there some way to force liboctave or liboctinterp to include all
| the symbols from libkpathsea.a that it needs so that you do not
| have to subsequently link against libkpathsea?  I thought it did this
| already.

No, it was just linked in to the final octave executable.

I've just made some changes to do what you suggest.  Now there is no
need for Octave to link with kpathsea, because all of the kpathsea
objects are now included in both the static and shared versions of
liboctave.  We'll see whether that change causes any trouble.
I still want to remove kpathsearch from Octave at some point, but that
will have to wait a while.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

JD Cole-2
In reply to this post by John W. Eaton-6
This may be a C++ ignorant question, but, what was the motivation behind
installing operators/types "manually" rather than having them
instantiated in the type class?

JD

John W. Eaton wrote:

>On 13-Dec-2002, Paul Kienzle <[hidden email]> wrote:
>
>| The '+' operator is looked up in a three dimensional array of op x
>| type x type.
>|
>| You will want to go into octave.cc and look at the octave_main function.
>|
>| Depending on what you are doing, you will need to include various pieces from
>| there, in this case install_ops().
>
>Maybe we should try to fix this so the operator installation happens
>automatically?
>
>jwe
>  
>


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

John W. Eaton-6
On 18-Dec-2002, JD Cole <[hidden email]> wrote:

| This may be a C++ ignorant question, but, what was the motivation behind
| installing operators/types "manually" rather than having them
| instantiated in the type class?

Mixed-type operations, I think.

But I think it would still be possible to have them installed
automatically, using some static object -- the constructor of the
object would call the appropriate function for installing the
operators defined in the file where the static object appears.  The
constructor for the static object would be called automatically when
the object is loaded.  That only leaves the question of ensuring that
everything is initialized in the proper order (probably not too hard
to do, but would require some care).  But as Paul points out, maybe
you don't want to initialize all of this every time you use
liboctinterp?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

JD Cole-2
Yes, that is why I was curious about the history of install_ops/_types.

Just to clear something up, when I'm performing octave_value addition,
as in the code snippet below, this uses liboctinterp operators, not
liboctave operators?

The way I "understand" now I thought that ov operators were all defined
in liboctave, so in the following code I shouldn't need functionality
from liboctinterp, right? (I admit I'm a bit confused at this point.)

JD

| source code (a.cc)

> | =========
> | #include <octave/oct.h>
> | #include <octave/ops.h>
> | #include <iostream>
> |
> | using namespace std;
> |
> | int main(int argc, char *argv[])
> | {
> |   install_types ();
> |   install_ops ();
> |   octave_value a(10.0),b(20.0),c;
> |
> |   c = a + b;
> |
> |   c.print(cout);
> |  
> |   return (0);
> | }


John W. Eaton wrote:

>On 18-Dec-2002, JD Cole <[hidden email]> wrote:
>
>| This may be a C++ ignorant question, but, what was the motivation behind
>| installing operators/types "manually" rather than having them
>| instantiated in the type class?
>
>Mixed-type operations, I think.
>
>But I think it would still be possible to have them installed
>automatically, using some static object -- the constructor of the
>object would call the appropriate function for installing the
>operators defined in the file where the static object appears.  The
>constructor for the static object would be called automatically when
>the object is loaded.  That only leaves the question of ensuring that
>everything is initialized in the proper order (probably not too hard
>to do, but would require some care).  But as Paul points out, maybe
>you don't want to initialize all of this every time you use
>liboctinterp?
>
>jwe
>
>  
>


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

Paul Kienzle-2
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.

Paul Kienzle
[hidden email]


On Wed, Dec 18, 2002 at 11:50:41AM -0800, JD Cole wrote:

> Yes, that is why I was curious about the history of install_ops/_types.
>
> Just to clear something up, when I'm performing octave_value addition,
> as in the code snippet below, this uses liboctinterp operators, not
> liboctave operators?
>
> The way I "understand" now I thought that ov operators were all defined
> in liboctave, so in the following code I shouldn't need functionality
> from liboctinterp, right? (I admit I'm a bit confused at this point.)
>
> JD
>
> | source code (a.cc)
> > | =========
> > | #include <octave/oct.h>
> > | #include <octave/ops.h>
> > | #include <iostream>
> > |
> > | using namespace std;
> > |
> > | int main(int argc, char *argv[])
> > | {
> > |   install_types ();
> > |   install_ops ();
> > |   octave_value a(10.0),b(20.0),c;
> > |
> > |   c = a + b;
> > |
> > |   c.print(cout);
> > |  
> > |   return (0);
> > | }
>
>
> John W. Eaton wrote:
>
> >On 18-Dec-2002, JD Cole <[hidden email]> wrote:
> >
> >| This may be a C++ ignorant question, but, what was the motivation behind
> >| installing operators/types "manually" rather than having them
> >| instantiated in the type class?
> >
> >Mixed-type operations, I think.
> >
> >But I think it would still be possible to have them installed
> >automatically, using some static object -- the constructor of the
> >object would call the appropriate function for installing the
> >operators defined in the file where the static object appears.  The
> >constructor for the static object would be called automatically when
> >the object is loaded.  That only leaves the question of ensuring that
> >everything is initialized in the proper order (probably not too hard
> >to do, but would require some care).  But as Paul points out, maybe
> >you don't want to initialize all of this every time you use
> >liboctinterp?
> >
> >jwe
> >
> >  
> >
>


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

John W. Eaton-6
On 18-Dec-2002, Paul Kienzle <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Creating a standalone executable

JD Cole-2
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 <[hidden email]> 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
>
>  
>


Reply | Threaded
Open this post in threaded view
|

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
[hidden email]

----- Original Message -----
From: "JD Cole" <[hidden email]>
To: "John W. Eaton" <[hidden email]>
Cc: <[hidden email]>; "Randy Gober"
<[hidden email]>
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 <[hidden email]> 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
> >
> >
> >
>