Re: [RFC] External control of Octave via IPC

[Michael Goffioul]

On Mon, Jan 19, 2009 at 9:12 PM, Søren Hauberg <address@hidden> wrote:
> Hi All
>
> Once in a while there are discussions about creating a graphical user
> interface for interacting with Octave. Basically such an interface
> consists of
>
>  1) A "fancy" terminal that graphically shows your history, your
>     current variables, etc...
>
>  2) An editor that integrates with the current Octave process, such
>     that the user can set breakpoints, step through programs, ...
>
> This mail is about the second point. One way of doing this is to create
> out own editor and run this in the Octave process. The good thing about
> such an idea is that the interaction with Octave is fairly easy to
> program. The downside is, however, that many users already have a
> prefered editor, and really don't want to switch to a new one.
>
> I think the best solution is to provide some framework for different
> processes to interact with Octave, and use this framework to extend
> different editors. Basically, I suggest we incorporate some means of
> interprocess communication (IPC) inside of Octave.
>
> I've been playing a bit around with DBus [1] (this is the IPC framework
> that Gnome and KDE uses) for this task, and it seems to be fairly easy
> to work with. I've extended the 'gnu_readline' function in
> 'src/input.cc' to include the following lines
>
>  bool ipc_has_commands = false;
>  ipc_server.handle_requests (retval, ipc_has_commands);
>  if (ipc_has_commands)
>    return retval;
>
> where 'ipc_server' handles communication via DBus (quick'n'dirty code
> for this is attached in case you're interested). What this does is that
> external processes can send commands to Octave via DBus, which Octave
> will execute the next time it's idle. What this means is that an editor
> can be extended to send commands (such as 'dbstep') to an Octave
> process. As a proof-of-concepts I've extended Gedit (the Gnome text
> editor) such that you can do simple things such as setting breakpoints
> and stepping, and it seems like it should work (it's still quite early
> though). This seems like a fairly easy task, and I assume it would also
> be fairly easy for other editors (Emacs, Vim, ...).
>
> Anyway, this mail is getting too long... Does anybody have any thoughts
> on the subject?

This sounds interesting, although somehow redundant with John's
(Swensen) proposal to allow interaction between octave and an editor
running in another thread (or another process?, I'm not sure). However,
your idea is more generic, using DBus, so it's probably a better way
to go.

I just have 2 concerns:
1) portability: it seems DBus exist under Windows (MinGW and MSVC)
under the name winDBus. Any idea about potential portability issues?
Is winDBus in sync with reference implementation?
2) does DBus allow in-process communication, between threads for instance?
(sorry for possible stupid question, I know nothing about DBus, except that
it implements IPC).

Michael.



>
> Søren
>
> [1] http://dbus.freedesktop.org/
>