gnuplot-beta

wxt term + osx

[Allin C. <cot...@wf...>]

I've built current CVS gnuplot and wxWidgets 3.0.2 for OS X and most 
things are working fine, but with one puzzling anomaly and I wonder 
if anyone has some insight.

Calling gnuplot with a script argument: the script sets term = wxt, 
puts up a 3D plot, and ends with "pause mouse close". If I do this 
directly from a Terminal window it works fine, and I get to 
manipulate the plot with the mouse.

But if I do the same thing programmatically (using the GLib function 
g_spawn_async) the wxt window appears momentarily, with the plot 
looking OK so far as I can tell, then disappears right away. The 
GLib call seems to be correct; it works as intended on Linux. 
Somehow on OS X the "pause mouse close" isn't preventing the 
termination of the gnuplot process. (No complaints on stderr.)

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: wxt term + osx

[Jun T. <tak...@kb...>]

2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote:

> But if I do the same thing programmatically (using the GLib function 
> g_spawn_async) the wxt window appears momentarily, with the plot 
> looking OK so far as I can tell, then disappears right away. The 
> GLib call seems to be correct; it works as intended on Linux. 
> Somehow on OS X the "pause mouse close" isn't preventing the 
> termination of the gnuplot process.

I have no experience with glib, but I guess the stdin of the
spawned gnuplot is set to /dev/null, so the gnuplot thinks it
should quit (as if you typed ctrl-D in the terminal = EOF).

On Linux, wxt window is managed by a separate process from the main
gnuplot process. But on Mac, gnuplot+wxt is a single process, and if
the main gnuplot quits then the plot window will go away.

You may try setting the G_SPAWN_CHILD_INHERITS_STDIN bit in the
'flags' (the 4th arg of g_spawn_async()), so that the gnuplot will
inherit the stdin from the parent.

Jun

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, Jun T. wrote:

> 2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote:
>
>> But if I do the same thing programmatically (using the GLib function
>> g_spawn_async) the wxt window appears momentarily, with the plot
>> looking OK so far as I can tell, then disappears right away. The
>> GLib call seems to be correct; it works as intended on Linux.
>> Somehow on OS X the "pause mouse close" isn't preventing the
>> termination of the gnuplot process.
>
> I have no experience with glib, but I guess the stdin of the
> spawned gnuplot is set to /dev/null, so the gnuplot thinks it
> should quit (as if you typed ctrl-D in the terminal = EOF).
>
> On Linux, wxt window is managed by a separate process from the main
> gnuplot process. But on Mac, gnuplot+wxt is a single process, and if
> the main gnuplot quits then the plot window will go away.
>
> You may try setting the G_SPAWN_CHILD_INHERITS_STDIN bit in the
> 'flags' (the 4th arg of g_spawn_async()), so that the gnuplot will
> inherit the stdin from the parent.

Thanks, your diagnosis seems to be accurate. Unfortunately the program 
from which I'm calling gnuplot is a GUI program so it doesn't have a 
STDIN that gnuplot can inherit.

I have found one way to get gnuplot/wxt to stay open in this context 
bit it's seriously clunky: write out a shell script that calls gnuplot 
with the plot-script argument, then use system() to call Terminal.app 
to execute the shell script. The Terminal.app window is just in the 
way and doesn't close itself on exit.

One thing I'm still not getting: you're right that g_spawn sets the 
child's stdin to /dev/null by default, but then I wonder how gnuplot 
stays open on Linux? As I understand it, gnuplot itself must still be 
running if the 3D plot can be manipulated with the mouse.

Allin Cottrell

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, Allin Cottrell wrote:

> On Tue, 25 Aug 2015, Jun T. wrote:
>
>> 2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote:
>> 
>>> But if I do the same thing programmatically (using the GLib function
>>> g_spawn_async) the wxt window appears momentarily, with the plot
>>> looking OK so far as I can tell, then disappears right away. The
>>> GLib call seems to be correct; it works as intended on Linux.
>>> Somehow on OS X the "pause mouse close" isn't preventing the
>>> termination of the gnuplot process.
>> 
>> I have no experience with glib, but I guess the stdin of the
>> spawned gnuplot is set to /dev/null, so the gnuplot thinks it
>> should quit (as if you typed ctrl-D in the terminal = EOF).
>> 
>> On Linux, wxt window is managed by a separate process from the main
>> gnuplot process. But on Mac, gnuplot+wxt is a single process, and if
>> the main gnuplot quits then the plot window will go away.
>> 
>> You may try setting the G_SPAWN_CHILD_INHERITS_STDIN bit in the
>> 'flags' (the 4th arg of g_spawn_async()), so that the gnuplot will
>> inherit the stdin from the parent.
>
> Thanks, your diagnosis seems to be accurate. Unfortunately the program from 
> which I'm calling gnuplot is a GUI program so it doesn't have a STDIN that 
> gnuplot can inherit.
>
> I have found one way to get gnuplot/wxt to stay open in this context bit it's 
> seriously clunky: write out a shell script that calls gnuplot with the 
> plot-script argument, then use system() to call Terminal.app to execute the 
> shell script. The Terminal.app window is just in the way and doesn't close 
> itself on exit.
>
> One thing I'm still not getting: you're right that g_spawn sets the child's 
> stdin to /dev/null by default, but then I wonder how gnuplot stays open on 
> Linux? As I understand it, gnuplot itself must still be running if the 3D 
> plot can be manipulated with the mouse.

Thinking some more about what you said, I think I'm closer to a 
workable solution: use g_spawn_async_with_pipes, which enables you to 
grab a file descriptor for the child's (i.e. gnuplot's) stdin; then 
pipe the script through that instead of supplying its name as a 
command-line argument. But now the problem is that gnuplot doesn't 
quit when the wxt window is closed, it continues running in the 
background. Urgh!

Allin Cottrell

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, Allin Cottrell wrote:

> On Tue, 25 Aug 2015, Jun T. wrote:
>
>> 2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote:
>> 
>>> But if I do the same thing programmatically (using the GLib function
>>> g_spawn_async) the wxt window appears momentarily, with the plot
>>> looking OK so far as I can tell, then disappears right away. The
>>> GLib call seems to be correct; it works as intended on Linux.
>>> Somehow on OS X the "pause mouse close" isn't preventing the
>>> termination of the gnuplot process.
>> 
>> I have no experience with glib, but I guess the stdin of the
>> spawned gnuplot is set to /dev/null, so the gnuplot thinks it
>> should quit (as if you typed ctrl-D in the terminal = EOF).
>> 
>> On Linux, wxt window is managed by a separate process from the main
>> gnuplot process. But on Mac, gnuplot+wxt is a single process, and if
>> the main gnuplot quits then the plot window will go away.
>> 
>> You may try setting the G_SPAWN_CHILD_INHERITS_STDIN bit in the
>> 'flags' (the 4th arg of g_spawn_async()), so that the gnuplot will
>> inherit the stdin from the parent.
>
> Thanks, your diagnosis seems to be accurate. Unfortunately the program from 
> which I'm calling gnuplot is a GUI program so it doesn't have a STDIN that 
> gnuplot can inherit.
>
> I have found one way to get gnuplot/wxt to stay open in this context bit it's 
> seriously clunky: write out a shell script that calls gnuplot with the 
> plot-script argument, then use system() to call Terminal.app to execute the 
> shell script. The Terminal.app window is just in the way and doesn't close 
> itself on exit.
>
> One thing I'm still not getting: you're right that g_spawn sets the child's 
> stdin to /dev/null by default, but then I wonder how gnuplot stays open on 
> Linux? As I understand it, gnuplot itself must still be running if the 3D 
> plot can be manipulated with the mouse.

Thinking some more about what you said, I think I'm closer to a 
workable solution: use g_spawn_async_with_pipes, which enables you to 
grab a file descriptor for the child's (i.e. gnuplot's) stdin; then 
pipe the script through that instead of supplying its name as a 
command-line argument. But now the problem is that gnuplot doesn't 
quit when the wxt window is closed, it continues running in the 
background. Urgh!

Allin Cottrell

Re: wxt term + osx

[sfeam <sf...@us...>]

On Tuesday, 25 August 2015 11:00:42 AM Allin Cottrell wrote:
> On Tue, 25 Aug 2015, Jun T. wrote:
> 
> > 2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote:
> >
> >> But if I do the same thing programmatically (using the GLib function
> >> g_spawn_async) the wxt window appears momentarily, with the plot
> >> looking OK so far as I can tell, then disappears right away. The
> >> GLib call seems to be correct; it works as intended on Linux.
> >> Somehow on OS X the "pause mouse close" isn't preventing the
> >> termination of the gnuplot process.
> >
> > I have no experience with glib, but I guess the stdin of the
> > spawned gnuplot is set to /dev/null, so the gnuplot thinks it
> > should quit (as if you typed ctrl-D in the terminal = EOF).
> >
> > On Linux, wxt window is managed by a separate process from the main
> > gnuplot process. But on Mac, gnuplot+wxt is a single process, and if
> > the main gnuplot quits then the plot window will go away.
> Thanks, your diagnosis seems to be accurate. Unfortunately the program 
> from which I'm calling gnuplot is a GUI program so it doesn't have a 
> STDIN that gnuplot can inherit.

That is true for the x11 and qt terminal drivers, which are managed
by the separate processes gnuplot_x11 and gnuplot_qt respectively.
Your description is not quite correct for wxt.  Rather than two
entirely separate processes, the wxt terminal uses either a single
thread (OSX) or two threads (linux) by default.  Some people have
reported that they have better luck running a single thread on linux
also, but that may be due to early/buggy versions of wxgtk3.

> One thing I'm still not getting: you're right that g_spawn sets the 
> child's stdin to /dev/null by default, but then I wonder how gnuplot 
> stays open on Linux? As I understand it, gnuplot itself must still be 
> running if the 3D plot can be manipulated with the mouse.

Yes.  Because it is not a separate process, the main gnuplot thread
stays around when the wxt terminal is in persist mode.  This is unlike
other terminals.

The single- and multi- threaded versions use a different section of
code in the routine wxt_gui.cpp: wxt_waitforinput()
It sounds like there is some tweak needed for the single-threaded
code block so that it doesn't exit if "pause mouse close" is active.

You could try adding a check for
  if (!paused_for_mouse)
or maybe it would need to be
  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)

before breaking from the loop that starts at line 3869.
But I'm not sure... that might cause it to hang in other 
circumstances.

	Ethan



> I have found one way to get gnuplot/wxt to stay open in this context 
> bit it's seriously clunky: write out a shell script that calls gnuplot 
> with the plot-script argument, then use system() to call Terminal.app 
> to execute the shell script. The Terminal.app window is just in the 
> way and doesn't close itself on exit.
>
> >
> > You may try setting the G_SPAWN_CHILD_INHERITS_STDIN bit in the
> > 'flags' (the 4th arg of g_spawn_async()), so that the gnuplot will
> > inherit the stdin from the parent.
> 
 
> 
> Allin Cottrell
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, sfeam wrote:

> On Tuesday, 25 August 2015 11:00:42 AM Allin Cottrell wrote:
>> On Tue, 25 Aug 2015, Jun T. wrote:
>>
>>> 2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote:
>>>
>>>> But if I do the same thing programmatically (using the GLib function
>>>> g_spawn_async) the wxt window appears momentarily, with the plot
>>>> looking OK so far as I can tell, then disappears right away. The
>>>> GLib call seems to be correct; it works as intended on Linux.
>>>> Somehow on OS X the "pause mouse close" isn't preventing the
>>>> termination of the gnuplot process.
>>>
>>> I have no experience with glib, but I guess the stdin of the
>>> spawned gnuplot is set to /dev/null, so the gnuplot thinks it
>>> should quit (as if you typed ctrl-D in the terminal = EOF).
>>>
>>> On Linux, wxt window is managed by a separate process from the main
>>> gnuplot process. But on Mac, gnuplot+wxt is a single process, and if
>>> the main gnuplot quits then the plot window will go away.
>> Thanks, your diagnosis seems to be accurate. Unfortunately the program
>> from which I'm calling gnuplot is a GUI program so it doesn't have a
>> STDIN that gnuplot can inherit.
>
> That is true for the x11 and qt terminal drivers, which are managed
> by the separate processes gnuplot_x11 and gnuplot_qt respectively.
> Your description is not quite correct for wxt.  Rather than two
> entirely separate processes, the wxt terminal uses either a single
> thread (OSX) or two threads (linux) by default.  Some people have
> reported that they have better luck running a single thread on linux
> also, but that may be due to early/buggy versions of wxgtk3.
>
>> One thing I'm still not getting: you're right that g_spawn sets the
>> child's stdin to /dev/null by default, but then I wonder how gnuplot
>> stays open on Linux? As I understand it, gnuplot itself must still be
>> running if the 3D plot can be manipulated with the mouse.
>
> Yes.  Because it is not a separate process, the main gnuplot thread
> stays around when the wxt terminal is in persist mode.  This is unlike
> other terminals.
>
> The single- and multi- threaded versions use a different section of
> code in the routine wxt_gui.cpp: wxt_waitforinput()
> It sounds like there is some tweak needed for the single-threaded
> code block so that it doesn't exit if "pause mouse close" is active.
>
> You could try adding a check for
>  if (!paused_for_mouse)
> or maybe it would need to be
>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
>
> before breaking from the loop that starts at line 3869.
> But I'm not sure... that might cause it to hang in other
> circumstances.

Thanks for the hint, I'll give it a try.

In the meantime, something related: I tried hooking up all relevant 
pipes via g_spawn (gnuplot's stdin to pipe in the script, and 
gnuplot's stdout to read messages). My idea was, after "pause mouse 
close" get gnuplot to print "done" (with print set to "-"). So when we 
read "done", close all pipes and gnuplot should shut down.

This works fine on Linux, but not on OS X: "done" never gets printed, 
or in other words closing the wxt window does not trigger "close" so 
far as pause mouse is concerned. The pause is either non-existent or 
permanent 8-/

Allin Cottrell

Re: wxt term + osx

[Ethan A M. <sf...@us...>]

On Tuesday, 25 August, 2015 14:22:05 Allin Cottrell wrote:
> On Tue, 25 Aug 2015, sfeam wrote:

> > The single- and multi- threaded versions use a different section of
> > code in the routine wxt_gui.cpp: wxt_waitforinput()
> > It sounds like there is some tweak needed for the single-threaded
> > code block so that it doesn't exit if "pause mouse close" is active.
> >
> > You could try adding a check for
> >  if (!paused_for_mouse)
> > or maybe it would need to be
> >  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
> >
> > before breaking from the loop that starts at line 3869.
> > But I'm not sure... that might cause it to hang in other
> > circumstances.
> 
> Thanks for the hint, I'll give it a try.
> 
> In the meantime, something related: I tried hooking up all relevant 
> pipes via g_spawn (gnuplot's stdin to pipe in the script, and 
> gnuplot's stdout to read messages). My idea was, after "pause mouse 
> close" get gnuplot to print "done" (with print set to "-"). So when we 
> read "done", close all pipes and gnuplot should shut down.
> 
> This works fine on Linux, but not on OS X: "done" never gets printed, 
> or in other words closing the wxt window does not trigger "close" so 
> far as pause mouse is concerned. The pause is either non-existent or 
> permanent 8-/

Does it make any persist/nopersist make any difference?
Try activating the FPRINTF in wxt_gui.cpp

    void wxtFrame::OnClose( wxCloseEvent& event )
    {
        FPRINTF((stderr,"OnClose\n"));

to monitor whether the window close event is being delivered to
the program.

	Ethan

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, Ethan A Merritt wrote:

> On Tuesday, 25 August, 2015 14:22:05 Allin Cottrell wrote:
>> On Tue, 25 Aug 2015, sfeam wrote:
>
>>> The single- and multi- threaded versions use a different section of
>>> code in the routine wxt_gui.cpp: wxt_waitforinput()
>>> It sounds like there is some tweak needed for the single-threaded
>>> code block so that it doesn't exit if "pause mouse close" is active.
>>>
>>> You could try adding a check for
>>>  if (!paused_for_mouse)
>>> or maybe it would need to be
>>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
>>>
>>> before breaking from the loop that starts at line 3869.
>>> But I'm not sure... that might cause it to hang in other
>>> circumstances.
>>
>> Thanks for the hint, I'll give it a try.
>>
>> In the meantime, something related: I tried hooking up all relevant
>> pipes via g_spawn (gnuplot's stdin to pipe in the script, and
>> gnuplot's stdout to read messages). My idea was, after "pause mouse
>> close" get gnuplot to print "done" (with print set to "-"). So when we
>> read "done", close all pipes and gnuplot should shut down.
>>
>> This works fine on Linux, but not on OS X: "done" never gets printed,
>> or in other words closing the wxt window does not trigger "close" so
>> far as pause mouse is concerned. The pause is either non-existent or
>> permanent 8-/
>
> Does it make any persist/nopersist make any difference?
> Try activating the FPRINTF in wxt_gui.cpp
>
>    void wxtFrame::OnClose( wxCloseEvent& event )
>    {
>        FPRINTF((stderr,"OnClose\n"));
>
> to monitor whether the window close event is being delivered to
> the program.

It was being delivered, and I was wrong above: the "done" was coming 
through on the stdout pipe, it's just that I wasn't reading from the 
pipe expertly enough. However, if I read correctly and close the pipes 
when "done" comes through I'm back with my original problem, the 
window closing right away. Context:

set print "-"
<various commands>
pause mouse close
print "done"

However... If I ignore the "done" and instead wait for "OnClose" 
coming out the stderr pipe from wxt_gui.cpp, it works right! The 
window remains open until deliberately closed, at which point I close 
the pipes and gnuplot exits.

Allin Cottrell

Re: wxt term + osx

[Ethan A M. <sf...@us...>]

On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
> 
> > On Tuesday, 25 August, 2015 14:22:05 Allin Cottrell wrote:
> >> On Tue, 25 Aug 2015, sfeam wrote:
> >
> >>> The single- and multi- threaded versions use a different section of
> >>> code in the routine wxt_gui.cpp: wxt_waitforinput()
> >>> It sounds like there is some tweak needed for the single-threaded
> >>> code block so that it doesn't exit if "pause mouse close" is active.
> >>>
> >>> You could try adding a check for
> >>>  if (!paused_for_mouse)
> >>> or maybe it would need to be
> >>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
> >>>
> >>> before breaking from the loop that starts at line 3869.
> >>> But I'm not sure... that might cause it to hang in other
> >>> circumstances.
> >>
> >> Thanks for the hint, I'll give it a try.
> >>
> >> In the meantime, something related: I tried hooking up all relevant
> >> pipes via g_spawn (gnuplot's stdin to pipe in the script, and
> >> gnuplot's stdout to read messages). My idea was, after "pause mouse
> >> close" get gnuplot to print "done" (with print set to "-"). So when we
> >> read "done", close all pipes and gnuplot should shut down.
> >>
> >> This works fine on Linux, but not on OS X: "done" never gets printed,
> >> or in other words closing the wxt window does not trigger "close" so
> >> far as pause mouse is concerned. The pause is either non-existent or
> >> permanent 8-/
> >
> > Does it make any persist/nopersist make any difference?
> > Try activating the FPRINTF in wxt_gui.cpp
> >
> >    void wxtFrame::OnClose( wxCloseEvent& event )
> >    {
> >        FPRINTF((stderr,"OnClose\n"));
> >
> > to monitor whether the window close event is being delivered to
> > the program.
> 
> It was being delivered, and I was wrong above: the "done" was coming 
> through on the stdout pipe, it's just that I wasn't reading from the 
> pipe expertly enough. However, if I read correctly and close the pipes 
> when "done" comes through I'm back with my original problem, the 
> window closing right away. Context:
> 
> set print "-"
> <various commands>
> pause mouse close
> print "done"
> 
> However... If I ignore the "done" and instead wait for "OnClose" 
> coming out the stderr pipe from wxt_gui.cpp, it works right! The 
> window remains open until deliberately closed, at which point I close 
> the pipes and gnuplot exits.

Okaaay.... but what you are describing is exactly what "pause mouse close"
is supposed to be doing all by itself - wait in the main thread for the
OnClose event and not proceed until it arrives.  In other words, if the
program were executing as intended your test script above could never
send "done" before sending "OnClose".  So I'm back to thinking that
the single-threaded version of the pause code is not really waiting for
the OnClose event as it should.

	Ethan

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, Ethan A Merritt wrote:

> On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
>> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
>>
>>> On Tuesday, 25 August, 2015 14:22:05 Allin Cottrell wrote:
>>>> On Tue, 25 Aug 2015, sfeam wrote:
>>>
>>>>> The single- and multi- threaded versions use a different section of
>>>>> code in the routine wxt_gui.cpp: wxt_waitforinput()
>>>>> It sounds like there is some tweak needed for the single-threaded
>>>>> code block so that it doesn't exit if "pause mouse close" is active.
>>>>>
>>>>> You could try adding a check for
>>>>>  if (!paused_for_mouse)
>>>>> or maybe it would need to be
>>>>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
>>>>>
>>>>> before breaking from the loop that starts at line 3869.
>>>>> But I'm not sure... that might cause it to hang in other
>>>>> circumstances.
>>>>
>>>> Thanks for the hint, I'll give it a try.
>>>>
>>>> In the meantime, something related: I tried hooking up all relevant
>>>> pipes via g_spawn (gnuplot's stdin to pipe in the script, and
>>>> gnuplot's stdout to read messages). My idea was, after "pause mouse
>>>> close" get gnuplot to print "done" (with print set to "-"). So when we
>>>> read "done", close all pipes and gnuplot should shut down.
>>>>
>>>> This works fine on Linux, but not on OS X: "done" never gets printed,
>>>> or in other words closing the wxt window does not trigger "close" so
>>>> far as pause mouse is concerned. The pause is either non-existent or
>>>> permanent 8-/
>>>
>>> Does it make any persist/nopersist make any difference?
>>> Try activating the FPRINTF in wxt_gui.cpp
>>>
>>>    void wxtFrame::OnClose( wxCloseEvent& event )
>>>    {
>>>        FPRINTF((stderr,"OnClose\n"));
>>>
>>> to monitor whether the window close event is being delivered to
>>> the program.
>>
>> It was being delivered, and I was wrong above: the "done" was coming
>> through on the stdout pipe, it's just that I wasn't reading from the
>> pipe expertly enough. However, if I read correctly and close the pipes
>> when "done" comes through I'm back with my original problem, the
>> window closing right away. Context:
>>
>> set print "-"
>> <various commands>
>> pause mouse close
>> print "done"
>>
>> However... If I ignore the "done" and instead wait for "OnClose"
>> coming out the stderr pipe from wxt_gui.cpp, it works right! The
>> window remains open until deliberately closed, at which point I close
>> the pipes and gnuplot exits.
>
> Okaaay.... but what you are describing is exactly what "pause mouse close"
> is supposed to be doing all by itself - wait in the main thread for the
> OnClose event and not proceed until it arrives.  In other words, if the
> program were executing as intended your test script above could never
> send "done" before sending "OnClose".  So I'm back to thinking that
> the single-threaded version of the pause code is not really waiting for
> the OnClose event as it should.

Yes, waiting for a magic marker on (hacked) stderr is obviously a 
half-assed way of doing things. Tomorrow, if I can find time, I'll 
try your first suggestion: modifying the relevant event-loop code in 
wxt_gui.cpp.

Allin Cottrell

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Tue, 25 Aug 2015, Ethan A Merritt wrote:

> On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
>> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
>>
>>> On Tuesday, 25 August, 2015 14:22:05 Allin Cottrell wrote:
>>>> On Tue, 25 Aug 2015, sfeam wrote:
>>>
>>>>> The single- and multi- threaded versions use a different section of
>>>>> code in the routine wxt_gui.cpp: wxt_waitforinput()
>>>>> It sounds like there is some tweak needed for the single-threaded
>>>>> code block so that it doesn't exit if "pause mouse close" is active.
>>>>>
>>>>> You could try adding a check for
>>>>>  if (!paused_for_mouse)
>>>>> or maybe it would need to be
>>>>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
>>>>>
>>>>> before breaking from the loop that starts at line 3869.
>>>>> But I'm not sure... that might cause it to hang in other
>>>>> circumstances.
>>>>
>>>> Thanks for the hint, I'll give it a try.
>>>>
>>>> In the meantime, something related: I tried hooking up all relevant
>>>> pipes via g_spawn (gnuplot's stdin to pipe in the script, and
>>>> gnuplot's stdout to read messages). My idea was, after "pause mouse
>>>> close" get gnuplot to print "done" (with print set to "-"). So when we
>>>> read "done", close all pipes and gnuplot should shut down.
>>>>
>>>> This works fine on Linux, but not on OS X: "done" never gets printed,
>>>> or in other words closing the wxt window does not trigger "close" so
>>>> far as pause mouse is concerned. The pause is either non-existent or
>>>> permanent 8-/
>>>
>>> Does it make any persist/nopersist make any difference?
>>> Try activating the FPRINTF in wxt_gui.cpp
>>>
>>>    void wxtFrame::OnClose( wxCloseEvent& event )
>>>    {
>>>        FPRINTF((stderr,"OnClose\n"));
>>>
>>> to monitor whether the window close event is being delivered to
>>> the program.
>>
>> It was being delivered, and I was wrong above: the "done" was coming
>> through on the stdout pipe, it's just that I wasn't reading from the
>> pipe expertly enough. However, if I read correctly and close the pipes
>> when "done" comes through I'm back with my original problem, the
>> window closing right away. Context:
>>
>> set print "-"
>> <various commands>
>> pause mouse close
>> print "done"
>>
>> However... If I ignore the "done" and instead wait for "OnClose"
>> coming out the stderr pipe from wxt_gui.cpp, it works right! The
>> window remains open until deliberately closed, at which point I close
>> the pipes and gnuplot exits.
>
> Okaaay.... but what you are describing is exactly what "pause mouse close"
> is supposed to be doing all by itself - wait in the main thread for the
> OnClose event and not proceed until it arrives.  In other words, if the
> program were executing as intended your test script above could never
> send "done" before sending "OnClose".  So I'm back to thinking that
> the single-threaded version of the pause code is not really waiting for
> the OnClose event as it should.

I think there may be an antecedent problem here in relation to 
wxWidgets. In wxt_gui.h we have:

#ifndef WXT_MONOTHREADED
#if defined(__WXGTK__)
# define WXT_MULTITHREADED
#elif defined(__WXMSW__) || defined(__WXMAC__)
# define WXT_MONOTHREADED
#else
# error "wxt does not know if this platform has to be single- or 
multi-threaded"
#endif
#endif

Now, as I understand it, WXT_MONOTHREADED is defined when this code is 
first reached if and only if the user has deployed the configure 
option --with-wx-single-threaded (described with "do not use 
multithreaded wxgtk even if available"). In my gnuplot build I did not 
use that option; it's not applicable since my wxWidgets on OS X does 
not use GTK, it's cocoa. Therefore we proceed within the cpp block, 
and we skip 'if defined(__WXGTK__)'.

But then what happens? If __WXMAC__ is defined gnuplot then defines 
WXT_MONOTHREADED, but why? My build of wxWidgets 3.0.2 defines 
__WXMAC__, and __WXOSX_COCOA__, and wxUSE_THREADS, so it seems an 
incorrect assumption is being made here.

Allin Cottrell

Re: wxt term + osx

[Ethan A M. <sf...@us...>]

On Wednesday, 26 August, 2015 17:33:27 Allin Cottrell wrote:
> 
> I think there may be an antecedent problem here in relation to 
> wxWidgets. In wxt_gui.h we have:
> 
> #ifndef WXT_MONOTHREADED
> #if defined(__WXGTK__)
> # define WXT_MULTITHREADED
> #elif defined(__WXMSW__) || defined(__WXMAC__)
> # define WXT_MONOTHREADED
> #else
> # error "wxt does not know if this platform has to be single- or 
> multi-threaded"
> #endif
> #endif
> 
> Now, as I understand it, WXT_MONOTHREADED is defined when this code is 
> first reached if and only if the user has deployed the configure 
> option --with-wx-single-threaded (described with "do not use 
> multithreaded wxgtk even if available"). In my gnuplot build I did not 
> use that option; it's not applicable since my wxWidgets on OS X does 
> not use GTK, it's cocoa. Therefore we proceed within the cpp block, 
> and we skip 'if defined(__WXGTK__)'.
> 
> But then what happens? If __WXMAC__ is defined gnuplot then defines 
> WXT_MONOTHREADED, but why? My build of wxWidgets 3.0.2 defines 
> __WXMAC__, and __WXOSX_COCOA__, and wxUSE_THREADS, so it seems an 
> incorrect assumption is being made here.

I cannot reconstruct when/why the gnuplot code assumes that
wx on OSX must be single threaded.  
Maybe it was true for some earlier OSX versions but the restriction
was later relaxed?
Maybe it is true for wx+carbon but not for wx+cocoa?
Maybe it is not true in general, but gnuplot breaks the
threading model (event loop is in secondary not primary thread)?
Maybe it was always wrong but it was added in an attempt to
fix a problem that was ultimately due to something else?

Anyhow, if you can confirm that it works in multithread mode
also, I'd be happy to remove that assumption from wxt_gui.h.

	Ethan

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Wed, 26 Aug 2015, Ethan A Merritt wrote:

> On Wednesday, 26 August, 2015 17:33:27 Allin Cottrell wrote:
>>
>> I think there may be an antecedent problem here in relation to
>> wxWidgets. In wxt_gui.h we have:
>>
>> #ifndef WXT_MONOTHREADED
>> #if defined(__WXGTK__)
>> # define WXT_MULTITHREADED
>> #elif defined(__WXMSW__) || defined(__WXMAC__)
>> # define WXT_MONOTHREADED
>> #else
>> # error "wxt does not know if this platform has to be single- or
>> multi-threaded"
>> #endif
>> #endif
>>
>> Now, as I understand it, WXT_MONOTHREADED is defined when this code is
>> first reached if and only if the user has deployed the configure
>> option --with-wx-single-threaded (described with "do not use
>> multithreaded wxgtk even if available"). In my gnuplot build I did not
>> use that option; it's not applicable since my wxWidgets on OS X does
>> not use GTK, it's cocoa. Therefore we proceed within the cpp block,
>> and we skip 'if defined(__WXGTK__)'.
>>
>> But then what happens? If __WXMAC__ is defined gnuplot then defines
>> WXT_MONOTHREADED, but why? My build of wxWidgets 3.0.2 defines
>> __WXMAC__, and __WXOSX_COCOA__, and wxUSE_THREADS, so it seems an
>> incorrect assumption is being made here.
>
> I cannot reconstruct when/why the gnuplot code assumes that
> wx on OSX must be single threaded.
> Maybe it was true for some earlier OSX versions but the restriction
> was later relaxed?
> Maybe it is true for wx+carbon but not for wx+cocoa?
> Maybe it is not true in general, but gnuplot breaks the
> threading model (event loop is in secondary not primary thread)?
> Maybe it was always wrong but it was added in an attempt to
> fix a problem that was ultimately due to something else?
>
> Anyhow, if you can confirm that it works in multithread mode
> also, I'd be happy to remove that assumption from wxt_gui.h.

I was hoping it would be that simple -- i.e. make gnuplot define 
WXT_MULTITHREADED conditional on some feature of my case and all 
would be well -- but I'm afraid that didn't work out: when I did 
that, gnuplot crashed when I tried to activate the wxt terminal.

I'll try to get some more information about this, but gdb doesn't 
seem to be included among the OS X "command line tools".

Allin Cottrell

Re: wxt term + osx

[Jun T. <tak...@kb...>]

The reason why the current wxt on Mac is single-threaded is
documented in the following:
http://sourceforge.net/p/gnuplot/patches/544/
In short, on Mac (or at least with Cocoa), the GUI loop
need be in the main thread.

A multi-threded wxt would be better, but "single-threaded"
does not necessarily mean that it does not work.

But there seems to be another problem.
At line 4022 and below in wxt_gui.cpp (in wxt_atexit()),
gnuplot fork() and the parent exits, while the child continues
running. But "fork() without exec()" is not recommended on Mac.
See, for example,
http://stackoverflow.com/questions/18854708/why-is-it-prohivited-to-use-fork-without-exec-in-mac

If I comment out the line 4041:

       freopen("/dev/null","w",stderr);

then I get lots of the following message:

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

If I #undef HAVE_WORKING_FORK then the problem that the
wxt window is closed immediately after it is opened seeks
to be fixed. For example the followings work as expected:

$ cat test.plt | gnuplot -d
$ gnuplot -d test.plt < /dev/null
(where test.plot contains
 set term wxt; plot something; pause mouse close)

But then the plot window is not closed also at the end of

$ make check	# i.e., check-noninteractive

and I need to manually close it. So it's not the complete
solution. 

Re: wxt term + osx

[Ethan A M. <sf...@us...>]

On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
> >
> >>> The single- and multi- threaded versions use a different section of
> >>> code in the routine wxt_gui.cpp: wxt_waitforinput()
> >>> It sounds like there is some tweak needed for the single-threaded
> >>> code block so that it doesn't exit if "pause mouse close" is active.
> >>>
> >>> You could try adding a check for
> >>>  if (!paused_for_mouse)
> >>> or maybe it would need to be
> >>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
> >>>
> >>> before breaking from the loop that starts at line 3869.
> >>> But I'm not sure... that might cause it to hang in other
> >>> circumstances.
> >>
> >> Thanks for the hint, I'll give it a try.

I tried building the single-threaded option on linux.
"pause mouse" commands did not work at all; the program
resumed on the next keyboard input regardless of mousing.
The following 2 patches fixed it:

Patch 1 prevents "pause mouse" from returning prematurely

--- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
+++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
@@ -3880,6 +3881,7 @@ int wxt_waitforinput(int options)
          FD_ZERO(&read_fd);
          FD_SET(0, &read_fd);
          if (select(1, &read_fd, NULL, NULL, &tv) != -1 && FD_ISSET(0, &read_fd))
+           if (!paused_for_mouse)
                break;
        }
        return getchar();



Patch 2 prevents loss of a character from the input stream after
        waiting for a mouse click.
        I am not sure if this is needed or even safe on Windows.

--- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
+++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
@@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
        event.winid = id;
 
 #if defined(WXT_MONOTHREADED) || defined(_Windows)
-       wxt_process_one_event(&event);
+       if (wxt_process_one_event(&event))
+           ungetc('\n',stdin); /* FIXME: OK on Windows? */
        return true;
 #else
        if (!wxt_handling_persist)

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Thu, 27 Aug 2015, Ethan A Merritt wrote:

> On Tuesday, 25 August, 2015 16:17:52 Allin Cottrell wrote:
>> On Tue, 25 Aug 2015, Ethan A Merritt wrote:
>>>
>>>>> The single- and multi- threaded versions use a different section of
>>>>> code in the routine wxt_gui.cpp: wxt_waitforinput()
>>>>> It sounds like there is some tweak needed for the single-threaded
>>>>> code block so that it doesn't exit if "pause mouse close" is active.
>>>>>
>>>>> You could try adding a check for
>>>>>  if (!paused_for_mouse)
>>>>> or maybe it would need to be
>>>>>  if ((paused_for_mouse & PAUSE_WINCLOSE) != 0)
>>>>>
>>>>> before breaking from the loop that starts at line 3869.
>>>>> But I'm not sure... that might cause it to hang in other
>>>>> circumstances.
>>>>
>>>> Thanks for the hint, I'll give it a try.
>
> I tried building the single-threaded option on linux.
> "pause mouse" commands did not work at all; the program
> resumed on the next keyboard input regardless of mousing.
> The following 2 patches fixed it:
>
> Patch 1 prevents "pause mouse" from returning prematurely
>
> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
> @@ -3880,6 +3881,7 @@ int wxt_waitforinput(int options)
>          FD_ZERO(&read_fd);
>          FD_SET(0, &read_fd);
>          if (select(1, &read_fd, NULL, NULL, &tv) != -1 && FD_ISSET(0, &read_fd))
> +           if (!paused_for_mouse)
>                break;
>        }
>        return getchar();
>
>
>
> Patch 2 prevents loss of a character from the input stream after
>        waiting for a mouse click.
>        I am not sure if this is needed or even safe on Windows.
>
> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>        event.winid = id;
>
> #if defined(WXT_MONOTHREADED) || defined(_Windows)
> -       wxt_process_one_event(&event);
> +       if (wxt_process_one_event(&event))
> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>        return true;
> #else
>        if (!wxt_handling_persist)

Thanks, Ethan. I can confirm that these patches work nicely for me 
with wxWidgets 3.0.2 on OS X 10.10.

On an unrelated cosmetic point: there's some comment in the gnuplot 
wxt* sources about "blurry" icons on cocoa, with a workaround to 
make the gnuplot-specific PNG-derived icons come out better. The 
workaround is effective, but that leaves the two icons on the left 
of the wxt terminal toolbar (Copy to clipboard and Save to disk), 
which are added via the wxArtProvider API. In my build, at any rate, 
these come out horrible (I think they must be bitmaps downsized from 
the cocoa default of 32x32). They are bigger than the other icons 
and also blurry.

In my build I have added a 16x16 "Save" icon (from GTK stock) in the 
same mode as the gnuplot-specific icons in wxterminal/bitmaps/png 
and I'm using this (plus the clipboard icon that's already present 
in that directory but not used currently) to replace the wxArt icons 
-- so that all items on the toolbar are of a uniform size and 
sharpness.

If there's interest in this I could submit a patch; I guess it's 
specific to __WXOSX_COCOA__.

Allin Cottrell

Re: wxt term + osx

[Tatsuro M. <tma...@ya...>]

>Patch 2 prevents loss of a character from the input stream after
>waiting for a mouse click.
>I am not sure if this is needed or even safe on Windows.
> 
>--- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
>+++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
>@@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>event.winid = id;
>#if defined(WXT_MONOTHREADED) || defined(_Windows)
>-       wxt_process_one_event(&event);
>+       if (wxt_process_one_event(&event))
>+           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>return true;
>#else
>if (!wxt_handling_persist)
> 


 
I have complied patch 2 attached wxt_gui.cpp.
Compile itself have passed on gnuplot.exe and wgnuplot.exe.

However 

ungetc('\n',stdin);


perhaps only works on console mode (gnuplot.exe) (untested.)

The function ungetc is not redefined in wtext.h.

For wgnuplot.exe, special treatment might be required but 
I do not have ability on this matter.

Tatsuro 

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:

>> Patch 2 prevents loss of a character from the input stream after
>> waiting for a mouse click.
>> I am not sure if this is needed or even safe on Windows.
>>  
>> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
>> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
>> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>> event.winid = id;
>> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>> -       wxt_process_one_event(&event);
>> +       if (wxt_process_one_event(&event))
>> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>> return true;
>> #else
>> if (!wxt_handling_persist)
>  
> I have complied patch 2 attached wxt_gui.cpp.
> Compile itself have passed on gnuplot.exe and wgnuplot.exe.
>
> However 
>
> ungetc('\n',stdin);
>
> perhaps only works on console mode (gnuplot.exe) (untested.)
>
> The function ungetc is not redefined in wtext.h.

It's defined in stdio.h.


-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: wxt term + osx

[sfeam <sf...@us...>]

On Friday, 28 August 2015 08:07:11 AM Allin Cottrell wrote:
> On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:
> 
> >> Patch 2 prevents loss of a character from the input stream after
> >> waiting for a mouse click.
> >> I am not sure if this is needed or even safe on Windows.
> >>  
> >> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
> >> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
> >> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
> >> event.winid = id;
> >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
> >> -       wxt_process_one_event(&event);
> >> +       if (wxt_process_one_event(&event))
> >> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
> >> return true;
> >> #else
> >> if (!wxt_handling_persist)
> >  
> > I have complied patch 2 attached wxt_gui.cpp.
> > Compile itself have passed on gnuplot.exe and wgnuplot.exe.
> >
> > However 
> >
> > ungetc('\n',stdin);
> >
> > perhaps only works on console mode (gnuplot.exe) (untested.)
> >
> > The function ungetc is not redefined in wtext.h.
> 
> It's defined in stdio.h.

Does the problem exist on Windows?
Test case before patch:

gnuplot> plot sin(x)
gnuplot> pause mouse
print "type this before interacting with the plot"
<now click on the plot>
gnuplot>rint "type this before interacting with the plot"
                 ^
         invalid command
gnuplot> 

On linux + single-thread option the 'p' of the "print"
is lost. The patch fixes this.  But is it lost on OSX
and Windows also?  If not, they do not need the patch.

	Ethan

Re: wxt term + osx

[Allin C. <cot...@wf...>]

On Fri, 28 Aug 2015, sfeam wrote:

> On Friday, 28 August 2015 08:07:11 AM Allin Cottrell wrote:
>> On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:
>>
>>>> Patch 2 prevents loss of a character from the input stream after
>>>> waiting for a mouse click.
>>>> I am not sure if this is needed or even safe on Windows.
>>>>
>>>> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 -0700
>>>> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 12:26:12.000000000 -0700
>>>> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>>>> event.winid = id;
>>>> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>>>> -       wxt_process_one_event(&event);
>>>> +       if (wxt_process_one_event(&event))
>>>> +           ungetc('\n',stdin); /* FIXME: OK on Windows? */
>>>> return true;
>>>> #else
>>>> if (!wxt_handling_persist)
>>>
>>> I have complied patch 2 attached wxt_gui.cpp.
>>> Compile itself have passed on gnuplot.exe and wgnuplot.exe.
>>>
>>> However
>>>
>>> ungetc('\n',stdin);
>>>
>>> perhaps only works on console mode (gnuplot.exe) (untested.)
>>>
>>> The function ungetc is not redefined in wtext.h.
>>
>> It's defined in stdio.h.
>
> Does the problem exist on Windows?
> Test case before patch:
>
> gnuplot> plot sin(x)
> gnuplot> pause mouse
> print "type this before interacting with the plot"
> <now click on the plot>
> gnuplot>rint "type this before interacting with the plot"
>                 ^
>         invalid command
> gnuplot>
>
> On linux + single-thread option the 'p' of the "print"
> is lost. The patch fixes this.  But is it lost on OSX
> and Windows also?  If not, they do not need the patch.

I can't speak for Windows, but it is indeed lost on OS X so your patch 
is required there.

Allin Cottrell

Re: wxt term + osx

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam 
> To: gnuplot-beta
> Cc: Allin Cottrell  Tatsuro MATSUOKA 
> Date: 2015/8/29, Sat 00:34
> Subject: Re: wxt term + osx
> 
> On Friday, 28 August 2015 08:07:11 AM Allin Cottrell wrote:
>>  On Fri, 28 Aug 2015, Tatsuro MATSUOKA wrote:
>> 
>>  >> Patch 2 prevents loss of a character from the input stream after
>>  >> waiting for a mouse click.
>>  >> I am not sure if this is needed or even safe on Windows.
>>  >>  
>>  >> --- a/src/wxterminal/wxt_gui.cpp  2015-07-13 10:54:44.000000000 
> -0700
>>  >> +++ b/src/wxterminal/wxt_gui.cpp      2015-08-27 
> 12:26:12.000000000 -0700
>>  >> @@ -3716,7 +3716,8 @@ bool wxt_exec_event(int type, int mx, in
>>  >> event.winid = id;
>>  >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>>  >> -       wxt_process_one_event(&event);
>>  >> +       if (wxt_process_one_event(&event))
>>  >> +           ungetc('\n',stdin); /* FIXME: OK on 
> Windows? */
>>  >> return true;
>>  >> #else
>>  >> if (!wxt_handling_persist)
>>  >  
>>  > I have complied patch 2 attached wxt_gui.cpp.
>>  > Compile itself have passed on gnuplot.exe and wgnuplot.exe.
>>  >
>>  > However 
>>  >
>>  > ungetc('\n',stdin);
>>  >
>>  > perhaps only works on console mode (gnuplot.exe) (untested.)
>>  >
>>  > The function ungetc is not redefined in wtext.h.
>> 
>>  It's defined in stdio.h.
> 
> Does the problem exist on Windows?
> Test case before patch:
> 
> gnuplot> plot sin(x)
> gnuplot> pause mouse
> print "type this before interacting with the plot"
> <now click on the plot>
> gnuplot>rint "type this before interacting with the plot"
>                  ^
>          invalid command
> gnuplot> 
> 
> On linux + single-thread option the 'p' of the "print"
> is lost. The patch fixes this.  But is it lost on OSX
> and Windows also?  If not, they do not need the patch.
> 
I have checked out the source (ChangeLog 2015-08-28).
The second patch is not applied for windows. (ungetc)

gnuplot> plot sin(x)
gnuplot> pause mouse
print "type this before interacting with the plot"
<now click on the plot>
gnuplot>print "type this before interacting with the plot"


Therefore the second patch is not required for windows.

Tatsuro

Re: wxt term + osx

[Jun T. <tak...@kb...>]

2015/08/28 04:41, Ethan A Merritt <sf...@us...> wrote:

> Patch 1 prevents "pause mouse" from returning prematurely

With this patch "pause mouse" works now on my Mac. Thanks.

But if I hit ^C in the console before closing the wxt window
then gnuplot hangs. Is the SIGINT handler at the end of
wxt_gui.cpp also used in the mono-threaded case?


And --persist (without pause mouse) still doesn't work, for example

$ echo 'set term wxt;plot sin(x)' | gnuplot -d -p

quits immediately after opening the plot window. This may be due to
that the forked child (without exec) does not work well on Mac.
I guess supporting --persist on Mac would be rather difficult.

Re: wxt term + osx

[Ethan A M. <sf...@us...>]

On Saturday, 29 August, 2015 01:48:58 Jun T. wrote:
> 
> 2015/08/28 04:41, Ethan A Merritt <sf...@us...> wrote:
> 
> > Patch 1 prevents "pause mouse" from returning prematurely
> 
> With this patch "pause mouse" works now on my Mac. Thanks.

Thanks for confirming.  I will add the patches to CVS for 5.0 and 5.1

> But if I hit ^C in the console before closing the wxt window
> then gnuplot hangs. Is the SIGINT handler at the end of
> wxt_gui.cpp also used in the mono-threaded case?

During normal operation, yes.  
However there is some funny business at the top of the the wxt_atexit()
code that involves resetting sigint handling and is only executed in
multi-threaded mode. I do not know if this is relevant to what you are
seeing.

> And --persist (without pause mouse) still doesn't work, for example
> 
> $ echo 'set term wxt;plot sin(x)' | gnuplot -d -p
> 
> quits immediately after opening the plot window. This may be due to
> that the forked child (without exec) does not work well on Mac.
> I guess supporting --persist on Mac would be rather difficult.

I can't reproduce either of these problems on linux, so I think I
will have to leave exploration of possible fixes to someone with
an OSX system to experiment on.

	Ethan 

Re: wxt term + osx

[Jun T. <tak...@kb...>]

As I wrote before, on my Mac, If I start gnuplot by

$ echo 'set term wxt;plot sin(x);pause mouse close' | gnuplot -d

do something on the wxt plot window (by mouse or keyboard),
go back to the console and hit ^C, then the gnuplot hangs
(actually it is not a hang but an infinite loop with 100% cpu usage).

I haven't tried building a mono-threaded wxt on Linux, but at least
on Mac what happening is the following:

Lines 3870-3872 in wxt_gui.cpp:
      yield = 1;
      wxTheApp->Yield();
      yield = 0;

if ^C is hit during the gui loop Yield(), then the variable yield
remais 1 (the line 'yield = 0' is not executed). After the signal
handler returns, it seems wxt_waitforinput() is called, but 
at lines 3852-3853:
    if (yield)
        return '\0';
so it returns immediately without checking the keyboard input.
This causes that the function do_line() is called repeatedly with
a null string as an input.

The following patch seems to fix this problem, but I'm not confident
that this is the correct fix, and yes, it is rather ugly.

Jun (Jun-ichi Takimoto)

Index: src/wxterminal/wxt_gui.cpp
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/wxterminal/wxt_gui.cpp,v
retrieving revision 1.149
diff -u -r1.149 wxt_gui.cpp
--- src/wxterminal/wxt_gui.cpp	31 Aug 2015 01:47:20 -0000	1.149
+++ src/wxterminal/wxt_gui.cpp	31 Aug 2015 13:26:03 -0000
@@ -2070,11 +2070,17 @@
 	wxt_sigint_restore();
 }
 
+#if defined(WXT_MONOTHREADED) && !defined(_Windows)
+static int yield = 0;	/* used in wxt_waitforinput() */
+#endif
+
 void wxt_reset()
 {
 	/* sent when gnuplot exits and when the terminal or the output change.*/
 	FPRINTF((stderr,"wxt_reset\n"));
 
+	yield = 0;
+
 	if (wxt_status == STATUS_UNINITIALIZED)
 		return;
 
@@ -3848,7 +3854,6 @@
 #else /* !_Windows */
 	/* Generic hybrid GUI & console message loop */
 	/* (used mainly on MacOSX - still single threaded) */
-	static int yield = 0;
 	if (yield)
 		return '\0';