Re: [RFC] External control of Octave via IPC

[Michael Goffioul]

On Tue, Jan 20, 2009 at 6:52 AM, Søren Hauberg <address@hidden> wrote:
> man, 19 01 2009 kl. 21:49 +0000, skrev Michael Goffioul:
>> 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.
>
> John, please correct me if I'm wrong.
>
> >From what I understand John's work allows you to run an editor in the
> Octave thread. So, if you want to integrate the Octave debugger in, say,
> Emacs, you'd have to embed Emacs in the Octave thread (using Xembed?).
> This is non-trivial and non-portable. What John's done is to create a
> new editor (based on gtksourceview, so it's not very much work)
> specifically for Octave, that run's in the Octave thread.
>
> This makes very good sense, but it does not allow users to use their
> editor of choice. This basically means that us old farts that aren't
> going to changing editor won't have access to debugging facilities in
> the editor.

I was actually referring to something else. To enable his editor to interact
with octave, John wrote a small class (I think it was called octave_server)
to allow an external component (like an editor, running in another thread)
to communicate and exchange data with octave. The idea was the same:
hook an input event into the readline loop and process events from there.

>> 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).
>
> I guess you could use DBus to communicate between threads, but it would
> a fairly complicated way of doing that, and it would be quite
> inefficient. So, if the general opinion is that we should be running the
> editor in the Octave process, then I don't think DBus would be the right
> solution.

I don't agree. My point was that a good solution would allow communication
with octave from another thread (even if it's not that efficient) or
another process,
using the same consistent interface. If DBus can do that, then I think
it's a good
candidate. We don't need high efficiency here. But a unique interface would
make life easier.

Michael.