From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Mar 11 09:25:32 2003
Subject: Re: Graphical octave frontend
From: Ulrich Kuettler <ulrich dot kuettler at mailbox dot tu-dresden dot de>
To: octave-maintainers at bevo dot che dot wisc dot edu
Date: Tue, 11 Mar 2003 16:25:10 +0100

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