octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Octave and IDE communication


From: Michael Goffioul
Subject: Octave and IDE communication
Date: Mon, 29 Oct 2007 14:34:55 +0100

Hi,

During a discussion I had with a guy iinterested in IDE stuffs for octave,
the discussion went about how octave and the IDE should communicate.
John Swensen already made a proposal for this, in the form of an
octave_server class that collects informations from octave when it is
idle and allow the IDE to access them in a thread-safe way. This of
course assumes that the IDE and octave runs in the same process,
but in separate threads.

When octave runs in its own process, you need some additional
communication channel between octave and the IDE. This is the
reason of this mail. Provided that the IDE sets up a terminal
emulation where octave runs in, I thought it could be doable to
reuse the terminal channel to implement IDE/octave communication.

In practice, what I had in mind would look like this:
1) when the IDE wants to send something to octave, it uses the
terminal emulation to send the data using some pre-defined (unbound)
key sequence; this command is then only read by octave when the
readline code is active, in idle state; by definition, this is synchronous
with octave thread
2) when octave wants to send something to the IDE, it uses its stdout
to send a pre-defined (unbound) escape sequence to the terminal
emulation (which is then responsible to interpret it).

This scheme does not need to set up an additional communication
channel and is only active when octave is idle. OTOH, this also
imply code overhead in octave (to catch and interpret the commands)
and the terminal emulation. This also imply the definition of a kind of
protocol for the IDE communication. This also would work whether
octave runs in its own thread of in its own process.

What do you think about this? Does this sound stupid?

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]