From octave-maintainers-request at bevo dot che dot wisc dot edu Mon Nov 10 13:37:02 2003
Subject: Re: Shared memory interface to Octave
From: "" <jswensen at intergate dot com>
To: "" <octave-maintainers at bevo dot che dot wisc dot edu>
Date: Mon, 10 Nov 2003 12:40:09 -0700

Nick,
   My thoughts were to use a plain QT implementation.  This way, it would port 
to most *nixes and windows.  I don't think the KDE API has a whole lot more to 
offer in terms of what I would like to do.

The GUI I am proposing would initially be very simple and would contain the 
following feature (most of these are things I liked from Matlab R12):
1) command history in a window
2) currently defined variables with their type and size.  If it is not an 
array, the value would also be displayed.  (As a future feature, arrays could 
be view using a treeview with +/- boxes.)
3) window for input/output
4) tree view containing a list of all the functions listed by the 'help' 
command.  Clicking on the function would open a dialog containing the text 
return by 'help name_of_the_command'

These would be the initial features.  After this is done, I would be open to 
any other requests.

To tell you the truth, the method of communication between the GUI and the 
octave core is of secondary importance.  A well defined interface will allow 
future implementers to do it however they would like.  It would also allow me 
to experiment/implement all the options to see which is the fastest.

Just to summarize the options that have been presented so far as to the 
communications between the GUI and the octave core (in a simple 'trade study' 
manner):

Sockets
Pros: 1)Every platform known to man supports sockets
2) Existing code supports socket for use in distributed environments
Cons: May not be as fast as some other kernel level methods

Shared memory
Pros: Very fast. Portable support for most OSs (Even windows with Cygwin).
Cons: Harder to redirect stdout and stdin to a simple memory location

Named pipes(FIFOs)
Pros: 1) Fairly seamless interface to the octave core(simple IO redirection)
2) Faster than sockets (most likely, I haven't experimented)
Cons: Slower than shared memory (most likely, I haven't experimented)

Any additions to these lists would be greatly appreciated.  I haven't used perl 
much, so it is going to take me a day or two to wade through the Inline::Octave 
perl module and determine the nuances of communicating with Octave via named 
pipes.  I will be doing the implementation in C/C++.  This will probably be the 
first communication method I implement.  I will also be doing up some use case 
diagrams to delineate the capabilities of the GUI and the comm interface.  I 
would be interested in having someone else look them over and comment before I 
begin more detailed UML diagrams and implementation.  

John Swensen

Quoting N Smethurst <nick dot smethurst at free dot fr>:

> Hi John
> 
> I've been using sockets in my application (kvisualiser.free.fr). I've found
> it 
> generally takes only about 10-15ms to base64 encode in XML, transfer, and 
> then decode a 150x150 point polydata surface (703KB including base64 
> encoding). Admitedly this is on an Athlon 1400. However, the amount of data 
> for a GUI would generally be far less than this, so I would imagine that the
> 
> resulting time lag would be negligible.
> 
> Out of interest, what kind of application are you aiming to write? I was 
> invisaging starting at some point a front end to Octave as a companion to 
> KVisualiser. If our ideas were similar, perhaps there could be a 
> collaboration.
> 
> Nick
> 



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