Re: mx and C enigne API

First and foremost, I have to say thanks to Paul.  This little example of
"embedded Octave" was exactly what I needed.  It was easy to adapt his project
and use the QT QProcess class (with great IO redirection capabilities) to start
up pretty much a full fledged Octave session.  I have included a link to where
it can be downloaded if anyone wants to see how it works.  The modifications to
Paul's project were minimal (~40 lines of code) and the QT code to run it came
in at a whopping 80 lines.  Of course it is nothing fancy and needs a lot more
work, but pretty much was a proof of concept for me.  Just untar/un-gzip the
file and the readme has build instructions.  I am not guaranteeing it will build
on all systems.  I explained in the README what I am running.

http://www.intergate.com/~jswensen/octave_qt.tar.gz

John

Quoting Paul Kienzle <address@hidden>:

> On Tue, Nov 11, 2003 at 10:15:23AM +0100, Bernd Kalbfuss wrote:
> > Hi John,
> > 
> > after so many postings about interprocess communication I am just 
> > puzzled. Simple question: is there any standard method available at the 
> > moment that allows to control octave from a different process? If yes: 
> > where is the documentation for it or where can I find some examples?
> > Since nobody responded to my last message I will just ask again: what 
> > about implementing the matlab mx and C engine API in octave? This would 
> > help in two ways: 1st it would make external matlab functions portable, 
> > 2nd this could provide an easy interface for any application that wants 
> > to exchange data with octave. I would volunteer to do this. But I 
> > definitely need more information about the current status of the project.
> 
> The place for this information is:
> 
> http://wiki.octave.org/wiki.pl?CategoryExternal
> 
> The quick answer is that many mx, mex and eng routines are available
> from octave-forge.  You are more than welcome to extend them in
> whichever way you need.
> 
> mat routines would be very convenient so that people can read octave files
> from other applications without loading the octave interpreter.  Doing this
> properly will require a reorganization of load-save so that it is
> independent of liboctave and liboctinterp.
> 
> A while back I posted some code which extracts the bits of
> octave out of toplevel.cc so that the read-eval loop can be 
> in your own application.  I've modified it to make use of
> octave's initialization code directly, but I didn't push it 
> far enough to separate out the printing since it is just a 
> proof of concept. 
> 
> You can find it here:
> 
>       http://octave.sf.net/octave_embed.tar.gz
> 
> As for the relative merits of sockets, pipes, threads and shared memory,
> you are on your own.  All are possible in each operating system.
> 
> Paul Kienzle
> address@hidden
> 
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/