[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shared memory interface to Octave
From: |
|
Subject: |
Re: Shared memory interface to Octave |
Date: |
Mon, 10 Nov 2003 12:40:09 -0700 |
User-agent: |
Internet Messaging Program (IMP) 3.1 / FreeBSD-4.8 |
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 <address@hidden>:
> 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/