[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] External control of Octave via IPC
From: |
Søren Hauberg |
Subject: |
Re: [RFC] External control of Octave via IPC |
Date: |
Tue, 20 Jan 2009 11:15:15 +0100 |
tir, 20 01 2009 kl. 09:40 +0000, skrev Michael Goffioul:
> > >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.
I think we're misunderstanding each other. What I've done is very
similar to the octave_server class that John has written. The, IMHO,
problem with the octave_server class is that it is designed for
interacting with editors that are running in the same process as Octave.
I think that limits its usefulness, as many people (myself included)
will prefer to run their favourite editor in a different process. The
octave_server class will then not allow my editor to communicate with
Octave, as they are not running in the same thread.
> >> 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.
Yeah I guess you have a point.
Soren