From octave-maintainers-request at bevo dot che dot wisc dot edu Sat Nov 15 00:50:08 2003 Subject: Re: mx and C enigne API From: "" To: Octave Maintainer Date: Fri, 14 Nov 2003 23:53:40 -0700 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 : > 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 > pkienzle at users dot sf dot net > > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/