About
GNU Octave is a
high-level language for numerical computation with a syntax
very similar to Mathworks' Matlab. The
interaction between Octave's plots and the interpreter are
currently very limited and there is no possibility to create
graphical widget that could be used to create user-friendly
interfaces. Octave being expandable, there exist several
packages (provide links) that improve this situation.While
most of the graphics related projects for Octave target an
improved plotting capability, few provide the creation of
GUIs. One prerequesite to support the creation and the use
of graphical widgets is to make Octave handle user triggered
"asynchronous" events.
Concurrent Modules for Octave, or CMO for short, is a
GPL'ed project that aims to provide a framework to
develope external modules that will:
- run concurrently with Octave in separate threads
without blocking Octave's input loop;
- listen to Octave and respond to some
module-defined commands (e.g. create a plot);
- send events to Octave. Octave will check for events
on its internal input loop or when it executes some
specific commands (e.g. while pausing).
True asynchroneous event handling is not implemented, but
it is believed that polling for the events while waiting
for a user input or while processing some specific
commands is sufficient.
Details
Architecture
CMO consist of three main parts:
- a common set of functions to handle library
initialization, modules handling and event processing
(
cmo.cc);
- a
cmo_module_interface class that is
responsible to communicate with the module and to
manage the registered events specific to the
module (cmo-module-interface.cc);
- a
cmo_module abstract class that is to
be used as the base class to derive specific modules
(like a GUI module). The user must implement a small
set of virtual functions to be able to communicate
with Octave. The to be implemented functions concerns
the initialization of the module (starting its main
loop), exiting the module (quitting its main loop),
enabling and disabling events and executing
module-specific commands (cmo-module.h)
Other helper classes are obviously used, such the
cmo_event class that identifies an event and
its associated cmo_callback class, and the
cmo_command_interface responsible for the
command transfer between Octave and the module.
Initialization and events polling
When initialized, CMO adds a private hook function to the
input loop (currently only if readline library is used).
The hook function is called every 1/100s and polls for
events. Whenever events are pending, it executes the user
defined callback associated with the event. In case where
the event check occured while Octave is already executing
a callback, then depending of the interruptibility
propriety of this running callback, the current event
callback is called or not. If not, it will be discarded
or kept for later handling, depending on the discardability
propriety of the event.
Sending commands and receiving results
Octave interpreter can request the module to execute some
module-specific commands. These commands depend on the
implementation of the module. But independently on the
module implementation, Octave stores the command type
and its argument in a slot, then it notifies the module by
writing in an anonymous socket, and then it blocks waiting for a
response from this same socket. Meanwhile, the module
receives the signal on its socket, retrieves the command
type and its argument and executes it. The execution code
depends on the module implementation. The commands are
identified by a simple integer. The first few integers
are not to be used by the module implementator, because
they are used to do specific functions: enabling/disabling
events and exiting the module. The user-types are to be
handled by a specific function implemented by the module.
Events and callbacks
Events are currently identified by the triplet
(module_name, object_name, event_name). To
an event is associated a single callback. The callback
can be defined by an expression to evaluate (currently
buggy) or by a function handler. When enabled, the
module receives an instance of cmo_event
object that identifies the event and contains its
callback. The module shall enable the event and shall send
this same instance back to Octave whenever the event
occurs. The module shall just stop sending events when
the disable command is received. Octave events handling
loop will poll for the events and will call the
associated callback unless the interpreter is currently
running a non-interruptible callback, in which case the
event may be discarded or delayed.
Examples
The source code contains a test module
tmod_module in the
./src/tests. It is a timer that, when
enabled, sends periodically an event. Check the
test_*.m examples for how to use it.
API
A Doxygen documentation with source is provided in the following package: cmo-0.0.1-doxygen.tar.gz.
Untar and use any browser to read the index.html file therein.
Status
After a proof of concept, CMO is evolving to a usable
project. Current stage is debugging the code.
Subsequent step is to provide an Octave GUI Module based
on it. This may result in implementing a new Octave
data type taylored for CMO and representing abstract objects.
Download
A preliminary package useful only for developers is to be downloaded from this cmo-0.0.1.tar.gz, it is distributed under the GPL v2 or later licence.
Last modified: Mon Feb 2 07:32:29 CET 2004
|