octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gui/pager problem on MacOSX


From: Ben Abbott
Subject: Re: gui/pager problem on MacOSX
Date: Thu, 24 Oct 2013 08:56:29 -0400

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 via email to

[Prev in Thread] Current Thread [Next in Thread]