Yet another GUI releated thought

[Søren Hauberg]

Hi All,
  I'm still not convinced that it is necessary to make Octave thread
safe or similar complicated things to provide a graphical interface to
Octave. I don't really understand the input handling in Octave, so this
has been developed in a "Hmmm, I wonder what happens if I press this
button..." style.
  What I have done is the following:
In 'src/input.cc' I have added:

  // TRUE if the GUI is being used
  bool using_gui = true;

Then later (same file) I have changed the function 'gnu_readline' so it
reads

  if (!using_gui)
    retval = command_editor::readline (s, eof);
  else
    retval = GUI::readline (s, eof);

This is probably the wrong place to do this, but it seems to work
(haven't tested much, though). The function 'GUI::readline' returns when
the user pressed Return in the GUI. The GUI is being started in
'octave_main' in 'src/octave.cc' in a separate thread.
  Using this approach the GUI supports partial statements. It does not
support tab-completion and history searching, and similar. Such things
will have to be reimplemented in the GUI. I don't think that's much work
though. Are there any issues with this approach that I'm missing?

Søren

[John Swensen]

On May 7, 2008, at 3:26 PM, Søren Hauberg wrote:

> Hi All,
>  I'm still not convinced that it is necessary to make Octave thread
> safe or similar complicated things to provide a graphical interface to
> Octave. I don't really understand the input handling in Octave, so  
> this
> has been developed in a "Hmmm, I wonder what happens if I press this
> button..." style.
>  What I have done is the following:
> In 'src/input.cc' I have added:
>
>  // TRUE if the GUI is being used
>  bool using_gui = true;
>
> Then later (same file) I have changed the function 'gnu_readline' so  
> it
> reads
>
>  if (!using_gui)
>    retval = command_editor::readline (s, eof);
>  else
>    retval = GUI::readline (s, eof);
>
> This is probably the wrong place to do this, but it seems to work
> (haven't tested much, though). The function 'GUI::readline' returns  
> when
> the user pressed Return in the GUI. The GUI is being started in
> 'octave_main' in 'src/octave.cc' in a separate thread.
>  Using this approach the GUI supports partial statements. It does not
> support tab-completion and history searching, and similar. Such things
> will have to be reimplemented in the GUI. I don't think that's much  
> work
> though. Are there any issues with this approach that I'm missing?
>
> Søren
>

I don't think it is necessary to make Octave "explicitly" thread-safe  
either.  In fact, the current method in OctaveDE of registering a  
function with the Readline idle event function seems to provide all  
the thread-safety my IDE needs.  Now, when you say GUI, maybe you are  
referring to creating uicontrol objects and handling their callback  
functions.

John Swensen

[Søren Hauberg]

ons, 07 05 2008 kl. 15:44 -0400, skrev John Swensen:
> I don't think it is necessary to make Octave "explicitly"
> thread-safe  
> either.  In fact, the current method in OctaveDE of registering a  
> function with the Readline idle event function seems to provide all  
> the thread-safety my IDE needs.  Now, when you say GUI, maybe you are  
> referring to creating uicontrol objects and handling their callback  
> functions.

No, I mean a IDE similar to OctaveDE (sorry, bad choice of words on my
part). From what I understand your work uses a terminal, which has
difficulties being ported to Windows. Is this true, or did I simply
misunderstand things. But hey, if your solution works and is portable,
then that would be great.

Søren

[John Swensen]

On May 7, 2008, at 4:01 PM, Søren Hauberg wrote:

> ons, 07 05 2008 kl. 15:44 -0400, skrev John Swensen:
>> I don't think it is necessary to make Octave "explicitly"
>> thread-safe
>> either.  In fact, the current method in OctaveDE of registering a
>> function with the Readline idle event function seems to provide all
>> the thread-safety my IDE needs.  Now, when you say GUI, maybe you are
>> referring to creating uicontrol objects and handling their callback
>> functions.
>
> No, I mean a IDE similar to OctaveDE (sorry, bad choice of words on my
> part). From what I understand your work uses a terminal, which has
> difficulties being ported to Windows. Is this true, or did I simply
> misunderstand things. But hey, if your solution works and is portable,
> then that would be great.
>
> Søren
>

chael Goffioul actually included my IDE with the most recent release  
of Octave for windows, however it is an optional install that you have  
to check if you want it.  I have also compiled it for OSX and Linux.

John

[Michael Goffioul-2]

On Wed, May 7, 2008 at 10:01 PM, Søren Hauberg <soren@...> wrote:
>
>  No, I mean a IDE similar to OctaveDE (sorry, bad choice of words on my
>  part). From what I understand your work uses a terminal, which has
>  difficulties being ported to Windows. Is this true, or did I simply
>  misunderstand things. But hey, if your solution works and is portable,
>  then that would be great.

I finally decided to try to port VTE to Windows. I could reach a point where
it's usable. It's of course not a real terminal (Win32 API does not have the
concept of pseudo terminal), but a regular pipe channel that allow terminal
communication. I had to use a few hacks to make it work and also
reimplement a few things, but it works fine enough to run octave in it
(which is the goal anyway; note that the emulation is not that bad,
because I could even run vi).

The only remaining problem is about the pager: octave pipes the data
to pager's stdin, and the pager (less in this case) captures key event
by reading /dev/tty directly. I'm not sure how to translate that in
Windows world: especially in the context of OctaveDE, where the GUI,
which runs in it own thread, is capturing key events.

Michael.

[John W. Eaton]

On  7-May-2008, Søren Hauberg wrote:

|   I'm still not convinced that it is necessary to make Octave thread
| safe or similar complicated things to provide a graphical interface to
| Octave. I don't really understand the input handling in Octave, so this
| has been developed in a "Hmmm, I wonder what happens if I press this
| button..." style.
|   What I have done is the following:
| In 'src/input.cc' I have added:
|
|   // TRUE if the GUI is being used
|   bool using_gui = true;
|
| Then later (same file) I have changed the function 'gnu_readline' so it
| reads
|
|   if (!using_gui)
|     retval = command_editor::readline (s, eof);
|   else
|     retval = GUI::readline (s, eof);
|
| This is probably the wrong place to do this, but it seems to work
| (haven't tested much, though). The function 'GUI::readline' returns when
| the user pressed Return in the GUI. The GUI is being started in
| 'octave_main' in 'src/octave.cc' in a separate thread.

If the GUI runs in a separate thread and Octave is not thread safe,
then how do you make the GUI responsive while Octave is off doing some
calculation?

|   Using this approach the GUI supports partial statements. It does not
| support tab-completion and history searching, and similar. Such things
| will have to be reimplemented in the GUI. I don't think that's much work
| though. Are there any issues with this approach that I'm missing?

Right, so you want to reimplement all the features of GNU readline in
your GUI::readline function?

jwe

[c.]

On 08/mag/08, at 18:04, octave-maintainers-request@... wrote:

> Message: 3
> Date: Thu, 08 May 2008 12:15:32 -0400
> From: "John W. Eaton" <jwe@...>
> Subject: Yet another GUI releated thought
> To: S?ren Hauberg <soren@...>
> Cc: Octave Maintainers List <octave-maintainers@...>
> Message-ID: <18467.10020.887888.151492@...>
> Content-Type: text/plain; charset=iso-8859-1
>
> On  7-May-2008, S?ren Hauberg wrote:
>
> |   I'm still not convinced that it is necessary to make Octave thread
> | safe or similar complicated things to provide a graphical  
> interface to
> | Octave. I don't really understand the input handling in Octave,  
> so this
> | has been developed in a "Hmmm, I wonder what happens if I press this
> | button..." style.
> |   What I have done is the following:
> | In 'src/input.cc' I have added:
> |
> |   // TRUE if the GUI is being used
> |   bool using_gui = true;
> |
> | Then later (same file) I have changed the function 'gnu_readline'  
> so it
> | reads
> |
> |   if (!using_gui)
> |     retval = command_editor::readline (s, eof);
> |   else
> |     retval = GUI::readline (s, eof);
> |
> | This is probably the wrong place to do this, but it seems to work
> | (haven't tested much, though). The function 'GUI::readline'  
> returns when
> | the user pressed Return in the GUI. The GUI is being started in
> | 'octave_main' in 'src/octave.cc' in a separate thread.
>
> If the GUI runs in a separate thread and Octave is not thread safe,
> then how do you make the GUI responsive while Octave is off doing some
> calculation?

I never took part in the discussions about a GUI because I dont'see  
much use in it myself...
But, just out of curiosity, how much "irresponsive" would the GUI be  
in this way?
If the idea is to reproduce the functionalities of the matlab GUI, if  
I remeber well, there is not much it can do
while the kernel is evaluating a cmmand, it just shows a "busy..."  
message and dragging or resizing
the windows is essantially all that can be done until the evalution  
is over.

> jwe


  c.

[Søren Hauberg]

tor, 08 05 2008 kl. 12:15 -0400, skrev John W. Eaton:
> If the GUI runs in a separate thread and Octave is not thread safe,
> then how do you make the GUI responsive while Octave is off doing some
> calculation?

What would you want a GUI to do while Octave is calculating? Start
another parallel calculation? The GUI just needs to know that it Octave
is busy, such that it doesn't start any new calculations.

> |   Using this approach the GUI supports partial statements. It does not
> | support tab-completion and history searching, and similar. Such things
> | will have to be reimplemented in the GUI. I don't think that's much work
> | though. Are there any issues with this approach that I'm missing?
>
> Right, so you want to reimplement all the features of GNU readline in
> your GUI::readline function?

Tab-completion is easy as that is implemented by Octave anyway. History
searching might be a bit more work. GNU readline also implements all
sorts of keyboard shortcuts (Ctrl-k deletes the rest of the current
line, etc), which all would have to be reimplemented. But thoughts on
this is simply, to not reimplement this -- people using a GUI would just
loose some functionality (the most commonly used operations could
obviously by implemented, but an entire clone of readline, would be
silly).
  The way I see it, if a GUI is simply a terminal with some extra stuff
around it (like the Matlab one), then I couldn't care less. However,
having the graphical capabilities opens up some new possibilities. Tab
completions and history searches could be displayed in drop-down menus
(is that the name?). Perhaps help texts could be displayed in HTML when
the user types 'help function_name'. But things like that really
requires that we don't use a terminal as the input -- it requires
something more general. The approach I suggested allows such things. It
would be quite some work, but at least it would be possible...

Søren

[Michael Goffioul-2]

On Thu, May 8, 2008 at 9:56 PM, Søren Hauberg <soren@...> wrote:
> tor, 08 05 2008 kl. 12:15 -0400, skrev John W. Eaton:
>
> > If the GUI runs in a separate thread and Octave is not thread safe,
>  > then how do you make the GUI responsive while Octave is off doing some
>  > calculation?
>
>  What would you want a GUI to do while Octave is calculating? Start
>  another parallel calculation? The GUI just needs to know that it Octave
>  is busy, such that it doesn't start any new calculations.

To answer John's question first, the GUI would still be responsive
as long as nothing is required from the octave kernel. For instance,
trying to execute a callback (which are executed synchronously
with octave) would just freeze. But things like editing a file would
still work.

>  > Right, so you want to reimplement all the features of GNU readline in
>  > your GUI::readline function?
>
>  Tab-completion is easy as that is implemented by Octave anyway. History
>  searching might be a bit more work. GNU readline also implements all
>  sorts of keyboard shortcuts (Ctrl-k deletes the rest of the current
>  line, etc), which all would have to be reimplemented. But thoughts on
>  this is simply, to not reimplement this -- people using a GUI would just
>  loose some functionality (the most commonly used operations could
>  obviously by implemented, but an entire clone of readline, would be
>  silly).
>   The way I see it, if a GUI is simply a terminal with some extra stuff
>  around it (like the Matlab one), then I couldn't care less. However,
>  having the graphical capabilities opens up some new possibilities. Tab
>  completions and history searches could be displayed in drop-down menus
>  (is that the name?). Perhaps help texts could be displayed in HTML when
>  the user types 'help function_name'. But things like that really
>  requires that we don't use a terminal as the input -- it requires
>  something more general. The approach I suggested allows such things. It
>  would be quite some work, but at least it would be possible...

IMO the terminal emulation is the easiest way to go, because you
don't have to re-implement readline capabilities. Everything is already
there. And you can focus on other things like file editing, debugging
capabilities or graphics backend integration (that's what I mean by
GUI). We are so missing man-power that I wouldn't go that way to
for the time being (this could be added later on).

Just for the record, I personally don't find the drop-down menu of
Matlab for tab-completion very convenient. Let's say you have
100 possibilities, the drop-down menu shows you about 5 of them,
while the readline way shows you all of them. Having clickable
item in the command window (like for the "See also" items) would
indeed be interesting, although I never use it. This is something
that (I think) is possible with VTE. For more advanced documentation,
I would go for a separate HTML-based help browser.

These are only my feelings about the subject.

Michael.

[Przemek Klosowski]

   > > If the GUI runs in a separate thread and Octave is not thread safe,
   >  > then how do you make the GUI responsive while Octave is off doing some
   >  > calculation?
   >
   >  What would you want a GUI to do while Octave is calculating? Start
   >  another parallel calculation? The GUI just needs to know that it Octave
   >  is busy, such that it doesn't start any new calculations.

One really useful function of the GUI is the variable watch window,
i.e. the ability to select ad-hoc and display the values of Octave
variables in real time during a calculation. Of course it's not a
deal-breaker, because one can always put some print statements in the
code---and even simulate the 'watch' window, e.g. via a function that
takes a bunch of variable names and prints their values in a fixed
layout so that one doesn't need to do saccades to track any specific
value.

If we agree that it's worth to have async peeking at values, I think
it already requires thread safety because octave variables don't have
to have constant memory addresses across their lifetime---right?
If so, then we might as well allow running arbitrary Octave code to
process the values for display.

Now, a somehow ugly compromise might be to introduce synchronization
points, either implicit in the octave eval loop or explicit in user
code (process_gui_callbacks())

[John W. Eaton]

On  8-May-2008, Michael Goffioul wrote:

| IMO the terminal emulation is the easiest way to go, because you
| don't have to re-implement readline capabilities. Everything is already
| there. And you can focus on other things like file editing, debugging
| capabilities or graphics backend integration (that's what I mean by
| GUI).

Likewise, there are already good editors available, so I think we
should make Octave work with one or more of them instead of
implementing a new editor.

jwe

[Michael Goffioul-2]

On Sat, May 10, 2008 at 8:32 AM, John W. Eaton <jwe@...> wrote:

> On  8-May-2008, Michael Goffioul wrote:
>
> | IMO the terminal emulation is the easiest way to go, because you
> | don't have to re-implement readline capabilities. Everything is already
> | there. And you can focus on other things like file editing, debugging
> | capabilities or graphics backend integration (that's what I mean by
> | GUI).
>
> Likewise, there are already good editors available, so I think we
> should make Octave work with one or more of them instead of
> implementing a new editor.

I guess that's what John is doing by using the gtksourceview
component (which is a GTK source editing component). Or maybe
you had something else in mind?

Michael.

[John W. Eaton]

On  9-May-2008, Michael Goffioul wrote:

| On Sat, May 10, 2008 at 8:32 AM, John W. Eaton <jwe@...> wrote:
| > On  8-May-2008, Michael Goffioul wrote:
| >
| > | IMO the terminal emulation is the easiest way to go, because you
| > | don't have to re-implement readline capabilities. Everything is already
| > | there. And you can focus on other things like file editing, debugging
| > | capabilities or graphics backend integration (that's what I mean by
| > | GUI).
| >
| > Likewise, there are already good editors available, so I think we
| > should make Octave work with one or more of them instead of
| > implementing a new editor.
|
| I guess that's what John is doing by using the gtksourceview
| component (which is a GTK source editing component). Or maybe
| you had something else in mind?

I was thinking of Emacs and other existing editors, and not trying to
write something from scratch.

jwe

[John W. Eaton]

On  9-May-2008, Przemek Klosowski wrote:

| Now, a somehow ugly compromise might be to introduce synchronization
| points, either implicit in the octave eval loop or explicit in user
| code (process_gui_callbacks())

I think that's what John Swensen's IDE does now.

jwe

[Ryan Rusaw]

On Mon, May 12, 2008 at 9:29 PM, John W. Eaton <jwe@...> wrote:

> On  9-May-2008, Przemek Klosowski wrote:
>
>  | Now, a somehow ugly compromise might be to introduce synchronization
>  | points, either implicit in the octave eval loop or explicit in user
>  | code (process_gui_callbacks())
>
>  I think that's what John Swensen's IDE does now.
>
>  jwe
>

Would it not be possible to allow the various IDE's to register code
to be called on each iteration of the octave eval loop at startup?
Then leave it to each IDE development team to determine what
functionality they need themselves ie. updating a variable watch
window in the IDE via a data socket or other IPC mechanism.

Ryan

[John Swensen]

On May 12, 2008, at 11:19 PM, Ryan Rusaw wrote:

> On Mon, May 12, 2008 at 9:29 PM, John W. Eaton  
> <jwe@...> wrote:
>> On  9-May-2008, Przemek Klosowski wrote:
>>
>> | Now, a somehow ugly compromise might be to introduce  
>> synchronization
>> | points, either implicit in the octave eval loop or explicit in user
>> | code (process_gui_callbacks())
>>
>> I think that's what John Swensen's IDE does now.
>>
>> jwe
>>
>
> Would it not be possible to allow the various IDE's to register code
> to be called on each iteration of the octave eval loop at startup?
> Then leave it to each IDE development team to determine what
> functionality they need themselves ie. updating a variable watch
> window in the IDE via a data socket or other IPC mechanism.
>
> Ryan

This mechanism is already in place.  A while back John Eaton cleaned  
up my patch to allow multiple "clients" to register for the Readline  
idle event.  I currently have a class  sources for my IDE called  
octave_server that is a singleton and registers a function with this  
idle loop.  Whenever the function is called, there is a transaction  
between the server class and octave (gets new history items, gets a  
table of whos-like variable information, processes breakpoint  
additions and hits, requests variables, etc). Then the IDE is free to  
query these values from the octave_server class whenever it feels like  
it.  Since the data in the octave_server class is mutex protected, and  
we can guarantee that the octave_server class only interacts with  
Octave while the octave interpreter is in the Readline idle loop (e.g.  
nothing is being executed), then this is as much "thread-safety" as  
most IDE's will need.

John Swensen

[Michael Goffioul-2]

On Tue, May 13, 2008 at 5:28 AM, John W. Eaton <jwe@...> wrote:
>  I was thinking of Emacs and other existing editors, and not trying to
>  write something from scratch.

I don't think you'll reach a high level of integration using an
out-of-process editor like emacs.

Michael.

[Jordi Gutiérrez Hermoso-2]

On 13/05/2008, Michael Goffioul <michael.goffioul@...> wrote:
> I don't think you'll reach a high level of integration using an
>  out-of-process editor like emacs.

No? Dem's fighting words!

     http://www.gnu.org/software/emacs/tour/images/gdb.png

- Jordi G. H.

[Ryan Rusaw]

For the record, Emacs + GEBEN (DBGP client for Emacs) + Octave DBGP
works pretty well as is. I've also tried a DBGP plugin for vi and that
mostly worked as well. Any of the minor bugs I noticed were invariably
my fault, as I'm sure I've implemented some facets of the protocol
incorrectly.

On Tue, May 13, 2008 at 6:40 PM, Jordi Gutiérrez Hermoso
<jordigh@...> wrote:

> On 13/05/2008, Michael Goffioul <michael.goffioul@...> wrote:
>  > I don't think you'll reach a high level of integration using an
>  >  out-of-process editor like emacs.
>
>  No? Dem's fighting words!
>
>      http://www.gnu.org/software/emacs/tour/images/gdb.png
>
>  - Jordi G. H.
>