gui/pager problem on MacOSX

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

gui/pager problem on MacOSX

bpabbott
Administrator
I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.

Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)

Ben


Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

Thorsten Liebig
Am 11.10.2013 15:47, schrieb Ben Abbott:
> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
>
> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
>
> Ben
>
>
>
I think this is related to this bug report:
https://savannah.gnu.org/bugs/index.php?37672#comment14

It seems that if a system command is active, the terminal does not receive any keys any more...

The bug is in the list 3.8 bug fix list as well.

Thorsten
Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John W. Eaton
Administrator
In reply to this post by bpabbott
On 10/11/2013 09:47 AM, Ben Abbott wrote:
> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
>
> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)

How are you starting Octave?  If it is from a terminal, does it work to
type the commands for less in the terminal window?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

bpabbott
Administrator
On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:

> On 10/11/2013 09:47 AM, Ben Abbott wrote:
>> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
>>
>> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
>
> How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?
>
> jwe

I run the gui using run-octave.

From the terminal the pager works correctly.

Ben

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John Swensen-3
On Fri, Oct 11, 2013 at 10:32 AM, Ben Abbott <[hidden email]> wrote:
On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:

> On 10/11/2013 09:47 AM, Ben Abbott wrote:
>> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
>>
>> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
>
> How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?
>
> jwe

I run the gui using run-octave.

From the terminal the pager works correctly.

Ben


Way back when I was actively working on OctaveDE in GTK and later the QT version of it, JWE helped me get some PTY magic working so that the gui terminal was the controlling terminal.

You can see the code that had to happen at startup to fork and make it work at 
I don't understand this code completely, but without it the pager would not work in the gui. Before this fix, if I launched the gui from a terminal, I was able to go back to the terminal from which it was started and control the pager that was in the QT gui terminal. I'm not sure if this is still a good/right solution, but thought I would chime in nonetheless.

John Swensen
Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John Swensen-3
On Fri, Oct 11, 2013 at 10:54 AM, John Swensen <[hidden email]> wrote:
On Fri, Oct 11, 2013 at 10:32 AM, Ben Abbott <[hidden email]> wrote:
On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:

> On 10/11/2013 09:47 AM, Ben Abbott wrote:
>> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
>>
>> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
>
> How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?
>
> jwe

I run the gui using run-octave.

From the terminal the pager works correctly.

Ben


Way back when I was actively working on OctaveDE in GTK and later the QT version of it, JWE helped me get some PTY magic working so that the gui terminal was the controlling terminal.

You can see the code that had to happen at startup to fork and make it work at 
I don't understand this code completely, but without it the pager would not work in the gui. Before this fix, if I launched the gui from a terminal, I was able to go back to the terminal from which it was started and control the pager that was in the QT gui terminal. I'm not sure if this is still a good/right solution, but thought I would chime in nonetheless.

John Swensen

Oops! I now see that this same functionality was rolled into octave_start_gui and dissociate_terminal in octave-gui.cc. So, disregard my blatherings, though the problem still may be in that the QT terminal is not becoming the controlling terminal for some reason and would be debugged in these locations.

John Swensen
Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

bpabbott
Administrator
In reply to this post by John Swensen-3

On Oct 11, 2013, at 10:54 AM, John Swensen wrote:

> On Fri, Oct 11, 2013 at 10:32 AM, Ben Abbott <[hidden email]> wrote:
> On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:
>
> > On 10/11/2013 09:47 AM, Ben Abbott wrote:
> >> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
> >>
> >> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
> >
> > How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?
> >
> > jwe
>
> I run the gui using run-octave.
>
> From the terminal the pager works correctly.
>
> Ben
>
>
> Way back when I was actively working on OctaveDE in GTK and later the QT version of it, JWE helped me get some PTY magic working so that the gui terminal was the controlling terminal.
>
> You can see the code that had to happen at startup to fork and make it work at
> http://sourceforge.net/p/octavede/code/HEAD/tree/branches/OctaveDE_QT/src/main.cpp
> I don't understand this code completely, but without it the pager would not work in the gui. Before this fix, if I launched the gui from a terminal, I was able to go back to the terminal from which it was started and control the pager that was in the QT gui terminal. I'm not sure if this is still a good/right solution, but thought I would chime in nonetheless.
>
> John Swensen

Thanks John! ! !

Your suggestion worked. The pager is connected to the original terminal window.

Ben

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

Michael Goffioul
In reply to this post by John Swensen-3
On Fri, Oct 11, 2013 at 10:54 AM, John Swensen <[hidden email]> wrote:
On Fri, Oct 11, 2013 at 10:32 AM, Ben Abbott <[hidden email]> wrote:
On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:

> On 10/11/2013 09:47 AM, Ben Abbott wrote:
>> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
>>
>> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
>
> How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?
>
> jwe

I run the gui using run-octave.

From the terminal the pager works correctly.

Ben


Way back when I was actively working on OctaveDE in GTK and later the QT version of it, JWE helped me get some PTY magic working so that the gui terminal was the controlling terminal.

You can see the code that had to happen at startup to fork and make it work at 
I don't understand this code completely, but without it the pager would not work in the gui. Before this fix, if I launched the gui from a terminal, I was able to go back to the terminal from which it was started and control the pager that was in the QT gui terminal. I'm not sure if this is still a good/right solution, but thought I would chime in nonetheless.

The reason is that "less" reads commands directly from /dev/tty, and not from stdin (otherwise you wouldn't be able to "pipe" to "less"). So if you start octave from a terminal, the controlling terminal stays the one you started octave from. To switch to another controlling TTY (in this case, the PTY that is created to run the embedded terminal widget), you need to dissociate the octave process from its controlling terminal, in order to re-associate it with another one. But to be able to dissociate from the controlling TTY, you need to be a process group leader/owner. And so far, the only way we've found to be such a process group owner is to fork.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John W. Eaton
Administrator
In reply to this post by bpabbott
On 10/11/2013 11:01 AM, Ben Abbott wrote:

>
> On Oct 11, 2013, at 10:54 AM, John Swensen wrote:
>
>> On Fri, Oct 11, 2013 at 10:32 AM, Ben Abbott<[hidden email]>  wrote:
>> On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:
>>
>>> On 10/11/2013 09:47 AM, Ben Abbott wrote:
>>>> I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.
>>>>
>>>> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
>>>
>>> How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?
>>>
>>> jwe
>>
>> I run the gui using run-octave.
>>
>>  From the terminal the pager works correctly.
>>
>> Ben
>>
>>
>> Way back when I was actively working on OctaveDE in GTK and later the QT version of it, JWE helped me get some PTY magic working so that the gui terminal was the controlling terminal.
>>
>> You can see the code that had to happen at startup to fork and make it work at
>> http://sourceforge.net/p/octavede/code/HEAD/tree/branches/OctaveDE_QT/src/main.cpp
>> I don't understand this code completely, but without it the pager would not work in the gui. Before this fix, if I launched the gui from a terminal, I was able to go back to the terminal from which it was started and control the pager that was in the QT gui terminal. I'm not sure if this is still a good/right solution, but thought I would chime in nonetheless.
>>
>> John Swensen
>
> Thanks John! ! !
>
> Your suggestion worked. The pager is connected to the original terminal window.

Yes, but it should not be.  It should work inside the GUI terminal.

The problem is that on OS X we don't execute the code that forks because
OS X won't let us do that and then set up the Qt event loop.  So this
problem is still not solved for OS X.

Perhaps the solution is to fork and exec to give up the controlling tty,
and have the parent process wait on the child and send any signals it
receives to the child.  We are almost doing that now, we're just not
following through with the exec.  I'll see what I can do.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John W. Eaton
Administrator
In reply to this post by Michael Goffioul
On 10/11/2013 11:12 AM, Michael Goffioul wrote:

> The reason is that "less" reads commands directly from /dev/tty, and not
> from stdin (otherwise you wouldn't be able to "pipe" to "less").

Looking at the comments in ttyin.c the less sources it appears that it
can still work even without /dev/tty by using file descriptor 2
(stderr):

  /*
   * Try /dev/tty.
   * If that doesn't work, use file descriptor 2,
   * which in Unix is usually attached to the screen,
   * but also usually lets you read from the keyboard.
   */

jwe
Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

Michael Goffioul
In reply to this post by John W. Eaton
On Fri, Oct 11, 2013 at 11:14 AM, John W. Eaton <[hidden email]> wrote:
On 10/11/2013 11:01 AM, Ben Abbott wrote:

On Oct 11, 2013, at 10:54 AM, John Swensen wrote:

On Fri, Oct 11, 2013 at 10:32 AM, Ben Abbott<[hidden email]>  wrote:
On Oct 11, 2013, at 9:58 AM, John W. Eaton wrote:

On 10/11/2013 09:47 AM, Ben Abbott wrote:
I just noticed that when running the gui on MacOSX the pager isn't working. When less is waiting on input, typing at the keyboard has no effect.  The only way to recover is to pull up the task manager and kill Octave.

Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)

How are you starting Octave?  If it is from a terminal, does it work to type the commands for less in the terminal window?

jwe

I run the gui using run-octave.

 From the terminal the pager works correctly.

Ben


Way back when I was actively working on OctaveDE in GTK and later the QT version of it, JWE helped me get some PTY magic working so that the gui terminal was the controlling terminal.

You can see the code that had to happen at startup to fork and make it work at
http://sourceforge.net/p/octavede/code/HEAD/tree/branches/OctaveDE_QT/src/main.cpp
I don't understand this code completely, but without it the pager would not work in the gui. Before this fix, if I launched the gui from a terminal, I was able to go back to the terminal from which it was started and control the pager that was in the QT gui terminal. I'm not sure if this is still a good/right solution, but thought I would chime in nonetheless.

John Swensen

Thanks John! ! !

Your suggestion worked. The pager is connected to the original terminal window.

Yes, but it should not be.  It should work inside the GUI terminal.

The problem is that on OS X we don't execute the code that forks because OS X won't let us do that and then set up the Qt event loop.  So this problem is still not solved for OS X.

I'm not entirely sure, but wasn't the problem the fact that OS X refused to fork/exec if the base process had already accessed the cocoa framework, which we do (or used to do) through the display_info class?

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John W. Eaton
Administrator
On 10/11/2013 12:16 PM, Michael Goffioul wrote:

> I'm not entirely sure, but wasn't the problem the fact that OS X refused
> to fork/exec if the base process had already accessed the cocoa
> framework, which we do (or used to do) through the display_info class?

My idea was to have a simple main program that would give up the
controlling tty and then exec the real Octave.  To preserve the illusion
of having one program that is running in the terminal, the simple main
program would wait for the child and pass signals to the child.  That
way you could still control it from the terminal (at least in the sense
of C-z working to stop the process, for example).  Would that work?  I'm
not sure, I haven't tried it.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

Carlo de Falco-2
In reply to this post by bpabbott

On 11 Oct 2013, at 15:47, Ben Abbott <[hidden email]> wrote:

> Carlo, can you verify that this isn't a problem local to my build (or maybe MacOSX 10.7?)
Ben,
Yes I can confirm his happens on 10.8.5 as well.
c.

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

Carlo de Falco-2
In reply to this post by bpabbott

On 11 Oct 2013, at 16:32, Ben Abbott <[hidden email]> wrote:

> I run the gui using run-octave.
I also tried installing and the behaviour is still the same.
c.
Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John W. Eaton
Administrator
In reply to this post by John W. Eaton
On 10/11/2013 12:51 PM, John W. Eaton wrote:

> On 10/11/2013 12:16 PM, Michael Goffioul wrote:
>
>> I'm not entirely sure, but wasn't the problem the fact that OS X refused
>> to fork/exec if the base process had already accessed the cocoa
>> framework, which we do (or used to do) through the display_info class?
>
> My idea was to have a simple main program that would give up the
> controlling tty and then exec the real Octave. To preserve the illusion
> of having one program that is running in the terminal, the simple main
> program would wait for the child and pass signals to the child. That way
> you could still control it from the terminal (at least in the sense of
> C-z working to stop the process, for example). Would that work? I'm not
> sure, I haven't tried it.
If the problem is that we can't fork after checking to see whether
there is a graphical display, then I don't know how to solve the
problem of falling back to the command-line interface if the graphical
display is not available.  But judging from the error messages that
Ben posted here:

 
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-August/029721.html

   "The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec()."

I think we can get away with doing an exec to start the GUI program
after the fork, even if we have already called some GUI functions in
the main program.

So instead of forking without exec, I propose that we create a small
driver program that will

   1. Check to see whether there is a graphical display available.  If
      not, start the command-line version of the program.

   2. Check the command line arguments for --no-gui.  If it is present,
      start the command-line version of the program.

   3. Fork.  In the parent, set up signal handling to pass any signals
      to the child process and wait for the child.  In the child, exec
      the GUI version of the program.

A simple prototype of this idea is attached.

Ben, can you try this and see whether it works?  You'll need to edit
the file to define OCTAVE_INSTALL_DIR to point to the location where
you have a copy of Octave with the GUI installed.  You'll also need to
link with the Carbon libraries.

If this approach works on OS X, then I can work on integrating it with
the Octave sources.  It will still need a more work to also avoid
starting the GUI if a filename has been provided on the command line,
either with a command like "octave foo.m" or "octave < foo.m".  That
logic is already in octave.cc, so it should not be too hard to make
this work.  But it will take some time to get it fully working and
merged with the Octave build system.

jwe

driver.c (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

bpabbott
Administrator

On Oct 24, 2013, at 3:32 AM, John W. Eaton wrote:

> On 10/11/2013 12:51 PM, John W. Eaton wrote:
>> On 10/11/2013 12:16 PM, Michael Goffioul wrote:
>>
>>> I'm not entirely sure, but wasn't the problem the fact that OS X refused
>>> to fork/exec if the base process had already accessed the cocoa
>>> framework, which we do (or used to do) through the display_info class?
>>
>> My idea was to have a simple main program that would give up the
>> controlling tty and then exec the real Octave. To preserve the illusion
>> of having one program that is running in the terminal, the simple main
>> program would wait for the child and pass signals to the child. That way
>> you could still control it from the terminal (at least in the sense of
>> C-z working to stop the process, for example). Would that work? I'm not
>> sure, I haven't tried it.
>
> If the problem is that we can't fork after checking to see whether
> there is a graphical display, then I don't know how to solve the
> problem of falling back to the command-line interface if the graphical
> display is not available.  But judging from the error messages that
> Ben posted here:
>
> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-August/029721.html
>
>  "The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec()."
>
> I think we can get away with doing an exec to start the GUI program
> after the fork, even if we have already called some GUI functions in
> the main program.
>
> So instead of forking without exec, I propose that we create a small
> driver program that will
>
>  1. Check to see whether there is a graphical display available.  If
>     not, start the command-line version of the program.
>
>  2. Check the command line arguments for --no-gui.  If it is present,
>     start the command-line version of the program.
>
>  3. Fork.  In the parent, set up signal handling to pass any signals
>     to the child process and wait for the child.  In the child, exec
>     the GUI version of the program.
>
> A simple prototype of this idea is attached.
>
> Ben, can you try this and see whether it works?  You'll need to edit
> the file to define OCTAVE_INSTALL_DIR to point to the location where
> you have a copy of Octave with the GUI installed.  You'll also need to
> link with the Carbon libraries.
>
> If this approach works on OS X, then I can work on integrating it with
> the Octave sources.  It will still need a more work to also avoid
> starting the GUI if a filename has been provided on the command line,
> either with a command like "octave foo.m" or "octave < foo.m".  That
> logic is already in octave.cc, so it should not be too hard to make
> this work.  But it will take some time to get it fully working and
> merged with the Octave build system.
>
> jwe
> <driver.c>

Carlo,

You mentioned you've installed a developer's version of Octave (I have not).  Can you test jwe's driver?

Ben

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

bpabbott
Administrator
On Oct 24, 2013, at 7:58 AM, Ben Abbott wrote:

> On Oct 24, 2013, at 3:32 AM, John W. Eaton wrote:
>
>> On 10/11/2013 12:51 PM, John W. Eaton wrote:
>>> On 10/11/2013 12:16 PM, Michael Goffioul wrote:
>>>
>>>> I'm not entirely sure, but wasn't the problem the fact that OS X refused
>>>> to fork/exec if the base process had already accessed the cocoa
>>>> framework, which we do (or used to do) through the display_info class?
>>>
>>> My idea was to have a simple main program that would give up the
>>> controlling tty and then exec the real Octave. To preserve the illusion
>>> of having one program that is running in the terminal, the simple main
>>> program would wait for the child and pass signals to the child. That way
>>> you could still control it from the terminal (at least in the sense of
>>> C-z working to stop the process, for example). Would that work? I'm not
>>> sure, I haven't tried it.
>>
>> If the problem is that we can't fork after checking to see whether
>> there is a graphical display, then I don't know how to solve the
>> problem of falling back to the command-line interface if the graphical
>> display is not available.  But judging from the error messages that
>> Ben posted here:
>>
>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-August/029721.html
>>
>> "The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec()."
>>
>> I think we can get away with doing an exec to start the GUI program
>> after the fork, even if we have already called some GUI functions in
>> the main program.
>>
>> So instead of forking without exec, I propose that we create a small
>> driver program that will
>>
>> 1. Check to see whether there is a graphical display available.  If
>>    not, start the command-line version of the program.
>>
>> 2. Check the command line arguments for --no-gui.  If it is present,
>>    start the command-line version of the program.
>>
>> 3. Fork.  In the parent, set up signal handling to pass any signals
>>    to the child process and wait for the child.  In the child, exec
>>    the GUI version of the program.
>>
>> A simple prototype of this idea is attached.
>>
>> Ben, can you try this and see whether it works?  You'll need to edit
>> the file to define OCTAVE_INSTALL_DIR to point to the location where
>> you have a copy of Octave with the GUI installed.  You'll also need to
>> link with the Carbon libraries.
>>
>> If this approach works on OS X, then I can work on integrating it with
>> the Octave sources.  It will still need a more work to also avoid
>> starting the GUI if a filename has been provided on the command line,
>> either with a command like "octave foo.m" or "octave < foo.m".  That
>> logic is already in octave.cc, so it should not be too hard to make
>> this work.  But it will take some time to get it fully working and
>> merged with the Octave build system.
>>
>> jwe
>> <driver.c>
>
> Carlo,
>
> You mentioned you've installed a developer's version of Octave (I have not).  Can you test jwe's driver?
>
> Ben


Carlo, I had a few minutes to try out the driver.  I built it using a script containing ...

#! /bin/sh -e
CC=/opt/local/bin/gcc-mp-4.7
CFLAGS="-pipe -O2 -m64 -D_THREAD_SAFE -pthread"
CARBON_LIBS="-Wl,-framework -Wl,Carbon"
$CC driver.c -o driver $CFLAGS $CARBON_LIBS

jwe, Using your driver, the pager works for me.  Thanks!

Ben

Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

John W. Eaton
Administrator
On 10/24/2013 08:56 AM, Ben Abbott wrote:

> On Oct 24, 2013, at 7:58 AM, Ben Abbott wrote:
>
>> On 10/11/2013 12:51 PM, John W. Eaton wrote:
>>
>> I think we can get away with doing an exec to start the GUI program
>> after the fork, even if we have already called some GUI functions in
>> the main program.
>>
>> So instead of forking without exec, I propose that we create a small
>> driver program that will
>>
>> 1. Check to see whether there is a graphical display available.  If
>>     not, start the command-line version of the program.
>>
>> 2. Check the command line arguments for --no-gui.  If it is present,
>>     start the command-line version of the program.
>>
>> 3. Fork.  In the parent, set up signal handling to pass any signals
>>     to the child process and wait for the child.  In the child, exec
>>     the GUI version of the program.
>>
>> A simple prototype of this idea is attached.
>>
>> Ben, can you try this and see whether it works?  You'll need to edit
>> the file to define OCTAVE_INSTALL_DIR to point to the location where
>> you have a copy of Octave with the GUI installed.  You'll also need to
>> link with the Carbon libraries.
>>
>> If this approach works on OS X, then I can work on integrating it with
>> the Octave sources.  It will still need a more work to also avoid
>> starting the GUI if a filename has been provided on the command line,
>> either with a command like "octave foo.m" or "octave<  foo.m".  That
>> logic is already in octave.cc, so it should not be too hard to make
>> this work.  But it will take some time to get it fully working and
>> merged with the Octave build system.
>
> Carlo, I had a few minutes to try out the driver.  I built it using a script containing ...
>
> #! /bin/sh -e
> CC=/opt/local/bin/gcc-mp-4.7
> CFLAGS="-pipe -O2 -m64 -D_THREAD_SAFE -pthread"
> CARBON_LIBS="-Wl,-framework -Wl,Carbon"
> $CC driver.c -o driver $CFLAGS $CARBON_LIBS
>
> jwe, Using your driver, the pager works for me.  Thanks!

OK, I checked in a changeset with a more complete program based on
this idea.

We now generate three binaries:

   * octave-cli.  Same as before.

   * octave-gui.  This is what the "octave" binary was previously, but
                  now it never forks and so no longer recognizes the
                  --no-fork option.  If you want to debug the gui, it
                  is probably easiest to run this under gdb.  However,
                  because of the way libtool works, octave-gui in the
                  build tree is a shell script, so a little more work
                  needs to be done to make this convenient again.

   * octave.      A new wrapper program that invokes either octave-cli
                  or octave-gui.

The "octave" binary now does the following things to decide whether to
start the GUI:

   1. Check the command line arguments for --no-gui-libs.  If present,
      it execs "octave-cli".  This option is not passed on to the
      "octave-cli" process.

   2. Check the comand line arguments for --no-gui.  If present, it
      execs the "octave-gui" binary with the --no-gui option.  In this
      case, we want to start the binary that was linked with the GUI
      libraries so that we can do plotting (in the future with Qt
      widgets) but we start in the command-line mode so we don't give
      up the controlling tty.  When given --no-gui, the "octave-gui"
      binary also starts a QApplication context before launching the
      command-line interpreter.

   3. If neither of these arguments are present and there is no
      controlling tty, exec "octave-gui" directly as there is no need
      to give up the controlling terminal.

   4. If neither of these arguments are present, then set up signal
      handling in the parent to pass any signals to the child process
      then fork and

        * in the child, give up the controlling terminal and exec
          "octave-gui" to start the GUI.

        * in the parent, wait for the child, passing signals to the
          child.

Finally, on Windows and Cygwin, where fork was apparently never
needed, octave always execs "octave-cli" or "octave-gui" instead of
forking to give up the controlling tty.  Otherwise, the same rules
apply: --no-gui-libs starts "octave-cli" and --no-gui starts
"octave-gui" in command-line mode.

The "octave" main program looks for "octave-gui" and "octave-cli" in
$bindir as set by configure and Make during the build (after
substituting OCTAVE_HOME), or by looking at the environment variable
OCTAVE_BINDIR.  The run-octave script uses OCTAVE_BINDIR to run the
programs from the src directory in the build tree.

To exec Octave from a Desktop launcher that starts process without a
controlling terminal, you could just run the "octave-gui" binary
directly.  Or, if you want to use the command-line version directly,
you can invoke "octave-cli".  The wrapper is really only needed if you
want to run the GUI from a terminal where the process will inherit a
controlling tty.  But it makes sense to me to have one binary that can
be given options to do all these things.

I thought about putting "octave-gui" and "octave-cli" in the $libexec
directory as a way to try to avoid confusion (I'm thinking that people
will see the "octave-gui" binary and run it from the command line then
wonder why the pager doesn't work properly).  But there are cases
where running "octave-gui" or "octave-cli" directly makes sense, so
maybe they do belong in $bindir?  I'm not sure what is best here.

Comments?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

bpabbott
Administrator
On Oct 27, 2013, at 7:49 PM, John W. Eaton wrote:

> On 10/24/2013 08:56 AM, Ben Abbott wrote:
>> On Oct 24, 2013, at 7:58 AM, Ben Abbott wrote:
>>
>>> On 10/11/2013 12:51 PM, John W. Eaton wrote:
>>>
>>> I think we can get away with doing an exec to start the GUI program
>>> after the fork, even if we have already called some GUI functions in
>>> the main program.
>>>
>>> So instead of forking without exec, I propose that we create a small
>>> driver program that will
>>>
>>> 1. Check to see whether there is a graphical display available.  If
>>>    not, start the command-line version of the program.
>>>
>>> 2. Check the command line arguments for --no-gui.  If it is present,
>>>    start the command-line version of the program.
>>>
>>> 3. Fork.  In the parent, set up signal handling to pass any signals
>>>    to the child process and wait for the child.  In the child, exec
>>>    the GUI version of the program.
>>>
>>> A simple prototype of this idea is attached.
>>>
>>> Ben, can you try this and see whether it works?  You'll need to edit
>>> the file to define OCTAVE_INSTALL_DIR to point to the location where
>>> you have a copy of Octave with the GUI installed.  You'll also need to
>>> link with the Carbon libraries.
>>>
>>> If this approach works on OS X, then I can work on integrating it with
>>> the Octave sources.  It will still need a more work to also avoid
>>> starting the GUI if a filename has been provided on the command line,
>>> either with a command like "octave foo.m" or "octave<  foo.m".  That
>>> logic is already in octave.cc, so it should not be too hard to make
>>> this work.  But it will take some time to get it fully working and
>>> merged with the Octave build system.
>>
>> Carlo, I had a few minutes to try out the driver.  I built it using a script containing ...
>>
>> #! /bin/sh -e
>> CC=/opt/local/bin/gcc-mp-4.7
>> CFLAGS="-pipe -O2 -m64 -D_THREAD_SAFE -pthread"
>> CARBON_LIBS="-Wl,-framework -Wl,Carbon"
>> $CC driver.c -o driver $CFLAGS $CARBON_LIBS
>>
>> jwe, Using your driver, the pager works for me.  Thanks!
>
> OK, I checked in a changeset with a more complete program based on
> this idea.


The pager now works for me.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: gui/pager problem on MacOSX

bpabbott
Administrator
In reply to this post by John W. Eaton

On Oct 27, 2013, at 7:49 PM, John W. Eaton wrote:

> On 10/24/2013 08:56 AM, Ben Abbott wrote:
>> On Oct 24, 2013, at 7:58 AM, Ben Abbott wrote:
>>
>>> On 10/11/2013 12:51 PM, John W. Eaton wrote:
>>>
>>> I think we can get away with doing an exec to start the GUI program
>>> after the fork, even if we have already called some GUI functions in
>>> the main program.
>>>
>>> So instead of forking without exec, I propose that we create a small
>>> driver program that will
>>>
>>> 1. Check to see whether there is a graphical display available.  If
>>>    not, start the command-line version of the program.
>>>
>>> 2. Check the command line arguments for --no-gui.  If it is present,
>>>    start the command-line version of the program.
>>>
>>> 3. Fork.  In the parent, set up signal handling to pass any signals
>>>    to the child process and wait for the child.  In the child, exec
>>>    the GUI version of the program.
>>>
>>> A simple prototype of this idea is attached.
>>>
>>> Ben, can you try this and see whether it works?  You'll need to edit
>>> the file to define OCTAVE_INSTALL_DIR to point to the location where
>>> you have a copy of Octave with the GUI installed.  You'll also need to
>>> link with the Carbon libraries.
>>>
>>> If this approach works on OS X, then I can work on integrating it with
>>> the Octave sources.  It will still need a more work to also avoid
>>> starting the GUI if a filename has been provided on the command line,
>>> either with a command like "octave foo.m" or "octave<  foo.m".  That
>>> logic is already in octave.cc, so it should not be too hard to make
>>> this work.  But it will take some time to get it fully working and
>>> merged with the Octave build system.
>>
>> Carlo, I had a few minutes to try out the driver.  I built it using a script containing ...
>>
>> #! /bin/sh -e
>> CC=/opt/local/bin/gcc-mp-4.7
>> CFLAGS="-pipe -O2 -m64 -D_THREAD_SAFE -pthread"
>> CARBON_LIBS="-Wl,-framework -Wl,Carbon"
>> $CC driver.c -o driver $CFLAGS $CARBON_LIBS
>>
>> jwe, Using your driver, the pager works for me.  Thanks!
>
> OK, I checked in a changeset with a more complete program based on
> this idea.
>
> We now generate three binaries:
>
>  * octave-cli.  Same as before.
>
>  * octave-gui.  This is what the "octave" binary was previously, but
>                 now it never forks and so no longer recognizes the
>                 --no-fork option.  If you want to debug the gui, it
>                 is probably easiest to run this under gdb.  However,
>                 because of the way libtool works, octave-gui in the
>                 build tree is a shell script, so a little more work
>                 needs to be done to make this convenient again.
>
>  * octave.      A new wrapper program that invokes either octave-cli
>                 or octave-gui.
>
> The "octave" binary now does the following things to decide whether to
> start the GUI:
>
>  1. Check the command line arguments for --no-gui-libs.  If present,
>     it execs "octave-cli".  This option is not passed on to the
>     "octave-cli" process.
>
>  2. Check the comand line arguments for --no-gui.  If present, it
>     execs the "octave-gui" binary with the --no-gui option.  In this
>     case, we want to start the binary that was linked with the GUI
>     libraries so that we can do plotting (in the future with Qt
>     widgets) but we start in the command-line mode so we don't give
>     up the controlling tty.  When given --no-gui, the "octave-gui"
>     binary also starts a QApplication context before launching the
>     command-line interpreter.
>
>  3. If neither of these arguments are present and there is no
>     controlling tty, exec "octave-gui" directly as there is no need
>     to give up the controlling terminal.
>
>  4. If neither of these arguments are present, then set up signal
>     handling in the parent to pass any signals to the child process
>     then fork and
>
>       * in the child, give up the controlling terminal and exec
>         "octave-gui" to start the GUI.
>
>       * in the parent, wait for the child, passing signals to the
>         child.
>
> Finally, on Windows and Cygwin, where fork was apparently never
> needed, octave always execs "octave-cli" or "octave-gui" instead of
> forking to give up the controlling tty.  Otherwise, the same rules
> apply: --no-gui-libs starts "octave-cli" and --no-gui starts
> "octave-gui" in command-line mode.
>
> The "octave" main program looks for "octave-gui" and "octave-cli" in
> $bindir as set by configure and Make during the build (after
> substituting OCTAVE_HOME), or by looking at the environment variable
> OCTAVE_BINDIR.  The run-octave script uses OCTAVE_BINDIR to run the
> programs from the src directory in the build tree.
>
> To exec Octave from a Desktop launcher that starts process without a
> controlling terminal, you could just run the "octave-gui" binary
> directly.  Or, if you want to use the command-line version directly,
> you can invoke "octave-cli".  The wrapper is really only needed if you
> want to run the GUI from a terminal where the process will inherit a
> controlling tty.  But it makes sense to me to have one binary that can
> be given options to do all these things.
>
> I thought about putting "octave-gui" and "octave-cli" in the $libexec
> directory as a way to try to avoid confusion (I'm thinking that people
> will see the "octave-gui" binary and run it from the command line then
> wonder why the pager doesn't work properly).  But there are cases
> where running "octave-gui" or "octave-cli" directly makes sense, so
> maybe they do belong in $bindir?  I'm not sure what is best here.
>
> Comments?
>
> jwe

I just noticed that when building the docs, octave-gui is being run.  I assume this isn't intended?

Ben