Graphical octave frontend

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

Graphical octave frontend

Ulrich Kuettler-2

Hi octave developers:

At first, let me say thank you. Octave is not only a very valuable
piece of software but also a very interesting one. I really enjoyed
looking at the source. It is surprisingly clear and understandable.

The reason I looked at octave is that I wanted to empower kformula
with a numerical engine. kformula is the formula editor of the koffice
suite. (www.koffice.org) My intention is to build a MathCAD like
interactive koffice application. A very first prove-of-concept
implementation is now available at
http://rcswww.urz.tu-dresden.de/~uk327083/kengineer.tar.bz2 It needs
the current cvs versions of both octave and koffice. Build
instructions are included.

There are also a few screenshots:
http://rcswww.urz.tu-dresden.de/~uk327083/kengineer-matrix.png
http://rcswww.urz.tu-dresden.de/~uk327083/kengineer-pyth.png

I hope you share my enthusiasm about it because to go further I need
your kind help and support. My aim is to link against out of the box
octave libraries. But there might be a few changes necessary. For
example could the build process be much smoother if octave's config.h
had another name. (I'm also very much in favour of John Eaton's
suggestion to introduce an "octave" namespace.) Another issue I
haven't solved yet is how a library's user finds the error messages
when error_state != 0.

But there will be many more problems and questions. For this project
to succeed I'll definitely need your support and advice. The result on
the other hand would be quite an amazing tool.

Regards,
Uli


Reply | Threaded
Open this post in threaded view
|

Re: Graphical octave frontend

Paul Kienzle
Ulrich Kuettler wrote:

>I hope you share my enthusiasm about it because to go further I need
>your kind help and support. My aim is to link against out of the box
>octave libraries. But there might be a few changes necessary. For
>
There are a number of projects which want a
'headless' octave, such as a windows port,
a tcl extension, a perl extension, an R extension,
and various parallel octave implementations which
need to take over from the read-eval-print loop.
Lots of ambition but not much time.

An alternative approach is to run octave in a
separate process and use pipes (e.g., octave-forge
extra/engine) or TCP/IP sockets (e.g., octave-forge
main/miscellaneous/listen.cc).  Neither interface is
complete, but both have been used successfully in
some projects.

>example could the build process be much smoother if octave's config.h
>had another name. (I'm also very much in favour of John Eaton's
>suggestion to introduce an "octave" namespace.) Another issue I
>haven't solved yet is how a library's user finds the error messages
>when error_state != 0.
>
Look in listen.cc:

    bind_global_error_variable();
    octave_value def = get_builtin_value("__error_text__");
    std::string str = def.string_value();

I also have:

    clear_gloabl_error_variable(NULL);

but I don't think it is needed.

The function get_builtin_value is not (yet) in
variables.cc.  It is defined as follows:

octave_value
get_builtin_value (const std::string& nm)
{
  octave_value retval;
  symbol_record *sr = fbi_sym_tab->lookup (nm);
  if (sr) {
    octave_value sr_def = sr->def ();
    if (sr_def.is_undefined())
      error ("get_builtin_value: undefined symbol `%s'", nm.c_str ());
    else
      retval = sr_def;
  } else error("get_builtin_value: unkonwn_symbol %s",nm.c_str());
}

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Graphical octave frontend

Ulrich Kuettler-2
On Tuesday 11 March 2003 03:01, Paul Kienzle wrote:

> Ulrich Kuettler wrote:
> >I hope you share my enthusiasm about it because to go further I need
> >your kind help and support. My aim is to link against out of the box
> >octave libraries. But there might be a few changes necessary. For
>
> An alternative approach is to run octave in a
> separate process and use pipes (e.g., octave-forge
> extra/engine) or TCP/IP sockets (e.g., octave-forge
> main/miscellaneous/listen.cc).  Neither interface is
> complete, but both have been used successfully in
> some projects.

This surely is an idea. But on the other hand would it force me to implement
my own parse tree and value classes. That is why linking against octave libs
seems more reasonable to me.

>
> >example could the build process be much smoother if octave's config.h
> >had another name. (I'm also very much in favour of John Eaton's
> >suggestion to introduce an "octave" namespace.) Another issue I
> >haven't solved yet is how a library's user finds the error messages
> >when error_state != 0.
>
> Look in listen.cc:
>
>     bind_global_error_variable();
>     octave_value def = get_builtin_value("__error_text__");
>     std::string str = def.string_value();
>

Thank you very much. This solves it! Now it's merely a question of the user
interface to present the message in a sensible way. (But why don't I find the
file listen.cc?)

To me it's really amazing how well octave fits, how easy it is to use it. The
only difficulty I see now is the file config.h as there is a file of the same
name inside koffice. And would it be possible to add "--cflags" and "--libs"
options to octave-config? This would make the build process a lot easier.

Thanks again,
Uli


Reply | Threaded
Open this post in threaded view
|

Re: Graphical octave frontend

Paul Kienzle
Ulrich Kuettler wrote:
On Tuesday 11 March 2003 03:01, Paul Kienzle wrote:
  
Ulrich Kuettler wrote:
    
I hope you share my enthusiasm about it because to go further I need
your kind help and support. My aim is to link against out of the box
octave libraries. But there might be a few changes necessary. For
      
An alternative approach is to run octave in a
separate process and use pipes (e.g., octave-forge
extra/engine) or TCP/IP sockets (e.g., octave-forge
main/miscellaneous/listen.cc).  Neither interface is
complete, but both have been used successfully in
some projects.
    

This surely is an idea. But on the other hand would it force me to implement 
my own parse tree and value classes. That is why linking against octave libs 
seems more reasonable to me. 
No, you can send commands to evaluate through
the link, whatever it is, and just pick up the results.
example could the build process be much smoother if octave's config.h
had another name. (I'm also very much in favour of John Eaton's
suggestion to introduce an "octave" namespace.) Another issue I
haven't solved yet is how a library's user finds the error messages
when error_state != 0.
      
Look in listen.cc:

    bind_global_error_variable();
    octave_value def = get_builtin_value("__error_text__");
    <a class="moz-txt-link-freetext" href="std::string">std::string str = def.string_value();

    

Thank you very much. This solves it! Now it's merely a question of the user 
interface to present the message in a sensible way. (But why don't I find the 
file listen.cc?)
http://octave.sf.net
To me it's really amazing how well octave fits, how easy it is to use it. The 
only difficulty I see now is the file config.h as there is a file of the same 
name inside koffice. And would it be possible to add "--cflags" and "--libs" 
options to octave-config? This would make the build process a lot easier.
Do you mean:

    CFLAGS=... LIBS=... ./configure

Or do you mean:

    mkoctfile -p CFLAGS
    mkoctfile -p LIBS

Paul Kienzle
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Graphical octave frontend

John W. Eaton-6
On 11-Mar-2003, Paul Kienzle <[hidden email]> wrote:

| Ulrich Kuettler wrote:
|
| >To me it's really amazing how well octave fits, how easy it is to
| >use it. The only difficulty I see now is the file config.h as there
| >is a file of the same name inside koffice. And would it be possible
| >to add "--cflags" and "--libs" options to octave-config? This would
| >make the build process a lot easier.
|
| Do you mean:
|
|     CFLAGS=... LIBS=... ./configure
|
| Or do you mean:
|
|     mkoctfile -p CFLAGS
|     mkoctfile -p LIBS

No, I think he means the octave-config script that we generate.  The
intent is for it to be used by people who want to find out things
about Octave's configuration.  But currently it can only tell a few
things.

Also, the problem about config.h eventually needs to be fixed as
well.  We should not install config.h.  If we need to install a
similar file, it should be given a different name and probably only
contain symbols that are specific to Octave, that we would want to
export.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Graphical octave frontend

Paul Kienzle
John W. Eaton wrote:

>On 11-Mar-2003, Paul Kienzle <[hidden email]> wrote:
>
>| Ulrich Kuettler wrote:
>|
>| >To me it's really amazing how well octave fits, how easy it is to
>| >use it. The only difficulty I see now is the file config.h as there
>| >is a file of the same name inside koffice. And would it be possible
>| >to add "--cflags" and "--libs" options to octave-config? This would
>| >make the build process a lot easier.
>|
>| Do you mean:
>|
>|     CFLAGS=... LIBS=... ./configure
>|
>| Or do you mean:
>|
>|     mkoctfile -p CFLAGS
>|     mkoctfile -p LIBS
>
>No, I think he means the octave-config script that we generate.  The
>intent is for it to be used by people who want to find out things
>about Octave's configuration.  But currently it can only tell a few
>things.
>
He is trying to compile and link a standalone app
against liboctave/liboctinterp.  That's what mkoctfile
is for.  If he doesn't want to use mkoctfile, then he
can query mkoctfile for the compiler flags that it
would use.  octave-config doesn't need to be extended
to handle this.

For the rest, one can always do as I'm doing in the
most recent octave-forge:

  dnl grab canonical_host_type from octave
  canonical_host_type=`echo
"disp(octave_config_info('canonical_host_type'))"\
     | $OCTAVE -q`

This won't support cross-compiling an octave-extension
though.  For that, I guess you need to dump all these
flags into octave-config.

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Graphical octave frontend

Ulrich Kuettler-2
On Wednesday 12 March 2003 13:07, Paul Kienzle wrote:

> John W. Eaton wrote:
> >On 11-Mar-2003, Paul Kienzle <[hidden email]> wrote:
> >| Ulrich Kuettler wrote:
> >| >To me it's really amazing how well octave fits, how easy it is to
> >| >use it. The only difficulty I see now is the file config.h as there
> >| >is a file of the same name inside koffice. And would it be possible
> >| >to add "--cflags" and "--libs" options to octave-config? This would
> >| >make the build process a lot easier.
> >|
> >| Do you mean:
> >|
> >|     CFLAGS=... LIBS=... ./configure
> >|
> >| Or do you mean:
> >|
> >|     mkoctfile -p CFLAGS
> >|     mkoctfile -p LIBS
> >
> >No, I think he means the octave-config script that we generate.  The
> >intent is for it to be used by people who want to find out things
> >about Octave's configuration.  But currently it can only tell a few
> >things.

That's exactly what I meant.

>
> He is trying to compile and link a standalone app
> against liboctave/liboctinterp.  That's what mkoctfile
> is for.  If he doesn't want to use mkoctfile, then he
> can query mkoctfile for the compiler flags that it
> would use.  octave-config doesn't need to be extended
> to handle this.

Hmm. It seems you can get all the required information out of mkoctfile. Fine!
I won't complain anymore then. ;)

>
> For the rest, one can always do as I'm doing in the
> most recent octave-forge:
>
>   dnl grab canonical_host_type from octave
>   canonical_host_type=`echo
> "disp(octave_config_info('canonical_host_type'))"\
>      | $OCTAVE -q`
>

That's another very interesting option. Thanks.

Uli


Reply | Threaded
Open this post in threaded view
|

Re: Graphical octave frontend

Dirk Eddelbuettel
In reply to this post by Paul Kienzle
On Wed, Mar 12, 2003 at 07:07:27AM -0500, Paul Kienzle wrote:

> He is trying to compile and link a standalone app
> against liboctave/liboctinterp.  That's what mkoctfile
> is for.  If he doesn't want to use mkoctfile, then he
> can query mkoctfile for the compiler flags that it
> would use.  octave-config doesn't need to be extended
> to handle this.
>
> For the rest, one can always do as I'm doing in the
> most recent octave-forge:
>
>  dnl grab canonical_host_type from octave
>  canonical_host_type=`echo
> "disp(octave_config_info('canonical_host_type'))"\
>     | $OCTAVE -q`
>

I did / do similar things in the debian/rules for octave-forge.
This got a little easier thanks to octave-config, but I still need

octbin          := $(shell echo 'printf("%s", \
                        octave_config_info ("localverarchlibdir"));' | \
                        octave2.1 -q | cut -d: -f1 | sed -e 's/\\t//g')

It would be nice to collect all switches we all need within octave-config.

Dirk

--
Prediction is very difficult, especially about the future.
                                             -- Niels Bohr