gnuplot-beta — Developers and beta testers of new gnuplot code

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

[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 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

[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

[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 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 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, 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

[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, 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

[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

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: documentation format and html output

[Christoph B. <us...@be...>]

Am 18.08.2015 um 01:08 schrieb Karl-Friedrich Ratzsch:
>
> * "make html" throws a billion errors. I get an html output in the
> end, sometimes, but it looks very broken. There are errormessages
> from latex2html that options are missing from the "inputenc" and
> "hyperref" package. Only my latex2html version (2008) seems to not
> have a hyperref package. (i also tried "make html" in the 4.6 tree,
> and there it tries to call "htlatex" instead of latex2html.
> docs/README in 5.1cvs says it wants to use htlatex, too, but doesn't?)
>
> I tried searching the web a bit and found a few messages on
> gnuplot-beta and in the bug tracker, but I'm not really clear how
> the status of this is.

For this reason, that no proper LaTeX-to-HTML-converter exists, I 
proposed a standalone doc2html converter, of which I posted a first 
version as patch on sf: http://sourceforge.net/p/gnuplot/patches/683/.

Since I got no real feedback I didn't go on. But the doc format isn't so 
complicated that one cannot have an own doc2html converter.
One could use this converter to get one single-file documentation, a 
multi-file documentation and a responsive version using e.g. bootstrap 
or whatever.

Christoph

Re: documentation format and html output --

[Hans-Bernhard B. <HBB...@t-...>]

Am 20.08.2015 um 23:29 schrieb Karl-Friedrich Ratzsch:
> Ah! Still it never used, can't be, because there is a bug in
> doc2tex, the link gets two closing brackets too many. I uploaded a fix:
> https://sourceforge.net/p/gnuplot/patches/719/#646e

I think I'll do my own fix ;-)

>> Why make such a major change, when every self-respecting
>> programmers' text editor can regex-search for, e.g., /^3/ ?

> Oh, I don't have so much respect for myself as a programmer.

You misinterpreted that statement.  It's the editor that's supposed to 
be self-respecting.  "Programmers' text editor" is a somewhat 
well-established tool category.  Note how the placement of the "'" makes 
a little difference :-)

> And you said nobody had an editor with syntax highlighting for the
> gnuplot docs. ;-)

Well, you were asking about syntax highlighting, so I answered that 
question.

If you had asked about navigating from node to node right away, you 
would got the answer about regexps in editors earlier.

> Still, i see no harm in adding an empty line before every heading.

Well, empty lines may have meaning, and may be passed through to some of 
the output formats.  They might create silly blank space at the end of 
pages / paragraphs.  That doesn't feel like a risk worth taking just to 
avoid typing something as easy as <Ctrl-Meta-s> ^ 3 or <ESC> <Ctrl-s> ^ 
3 (in Emacs) or / ^ 3 (in Vi)

;-P

And who's going to be making sure that those empty lines are 
consistently maintained in the future: you?  Will you get mad at others 
if they remove them, or if they forget to add new ones when they add new 
sections?

gnuplot.doc is newline-heavy enough as it is.  We don't need to spend 
even more screen real estate for empty lines.

> Which are indented much further. Ah! So the rule might better be
> "Plaintext tables get indented so as to at least leave a space in
> column 2."

No. The blank in column two is actually an active character.  It means 
"output this entire line verbatim" (for both LaTeX and plain text output).

Re: documentation format and html output --

[Karl-Friedrich R. <ra...@un...>]

Am 20.08.2015 um 00:01 schrieb Hans-Bernhard Bröker:
> Am 19.08.2015 um 01:34 schrieb Karl-Friedrich Ratzsch:
> 
>> Trying to link to them using
>>
>> ^ <a href="#positive">positivelink</a>
>>
>> was not possible, pdflatex complains about runaway arguments and
>> unfound references. Hm. I'll look into this.
> 
> Well, maybe there's a reason all the existing links are spelled like
> this instead:
> 
> ^ <a href="#positive">
>  positivelink
> ^ </a>
> 
> ;-)

Ah! Still it never used, can't be, because there is a bug in
doc2tex, the link gets two closing brackets too many. I uploaded a fix:
https://sourceforge.net/p/gnuplot/patches/719/#646e


>> I wanted to add an empty lines before section heading, two for
>> levels 2,3, to make navigation in the source a bit easier. Any
>> objection to changing that style rule?
> 
> Why make such a major change, when every self-respecting
> programmers' text editor can regex-search for, e.g., /^3/ ?

Oh, I don't have so much respect for myself as a programmer.
And you said nobody had an editor with syntax highlighting for the
gnuplot docs. ;-)
I noticed the diff format is rather similar, and i might perhaps dig
myself into finally learning regular expressions and adjusting
gedits highlighting scheme to the gnuplot.doc format. Let's see.

Still, i see no harm in adding an empty line before every heading.
Similar looking source code still works, but gets frowned upon.

> 
>> There is one comment in docs/README, saying
>>
>>     Tables must have a space in column 2.
>>
>> Any idea what this means? It is never done.
> 
> Ah, but it is! For _plain_text_ tables, that is.

Which are indented much further. Ah! So the rule might better be
"Plaintext tables get indented so as to at least leave a space in
column 2."

But plaintext always has fixed line feed anyway. Does that rule make
any difference? (Of course it makes a lot of sense to indent tables.)

  Karl

Re: documentation format and html output --

[Hans-Bernhard B. <HBB...@t-...>]

Am 19.08.2015 um 01:34 schrieb Karl-Friedrich Ratzsch:
> Am 18.08.2015 um 02:12 schrieb Ethan A Merritt:

> Trying to link to them using
>
> ^ <a href="#positive">positivelink</a>
>
> was not possible, pdflatex complains about runaway arguments and
> unfound references. Hm. I'll look into this.

Well, maybe there's a reason all the existing links are spelled like 
this instead:

^ <a href="#positive">
  positivelink
^ </a>

;-)

> Doesn't, it does not even get boldfaced in a Table. TeX converts the
> backquotes into typographic quotation marks instead. I'll add a note
> to the README.

Note that the note is already there --- only it's just about *roff 
output, so far.  The limitation, and the reason for it, is the same for 
the other "clever" output formats, though: the doc2* tools can't 
generate correct table syntax for the various output formats as-is, much 
less if they're to mark-up parts of the tables' content, too, while 
trying to do that.

> I wanted to add an empty lines before section heading, two for
> levels 2,3, to make navigation in the source a bit easier. Any
> objection to changing that style rule?

Why make such a major change, when every self-respecting programmers' 
text editor can regex-search for, e.g., /^3/ ?

> There is one comment in docs/README, saying
>
> 	Tables must have a space in column 2.
>
> Any idea what this means? It is never done.

Ah, but it is! For _plain_text_ tables, that is.

Re: qt terminal for windows : qDebug() problems

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

----- Original Message -----
> From: sfeam 
> To: gnuplot-beta; Tatsuro MATSUOKA 
> Cc: 
> Date: 2015/8/19, Wed 13:54
> Subject: Re: qt terminal for windows : qDebug()  problems
> 
> On Wednesday, 19 August 2015 12:46:49 PM Tatsuro MATSUOKA wrote:
>>  1)************************************************
>>  >1) The messages from qt_term.cpp can be written using fprintf(stderr, 
> ...).
>>  >This would be consistent with error messages throughout the main 
> program.
>>  >I will make this change.
>> 
>> 
>>  I appreciate that you will make the change.
>>  All messages from qt_term.cpp will be represented not only gnuplot.exe but 
>>  also wgnuplot.exe and wgnuplot_pipes.exe.
> 
> This change is now in CVS.
> 
>>  2)*************************************************
>>  >2) Messages from the separate process gnuplot_qt should not try
>>  >to write directly to stderr, since this may not go anywhere useful.
>>  >qDebug() is supposed to handle this, but I can't help with how to
>>  >configure on Windows.
>> 
>> 
>> 
>>  >qDebug() is supposed to handle this, but I can't help with how to
>>  >configure on Windows.
>> 
>>  According information searched on the web, qDebug() on windows can be 
>>  output messages to the console if the application is console one
>>  otherwise message to send to the debugger if it is present.
>> 
>>  gnuplot_qt.exe does not have own console.
>>  This might be the origin represent nothing 
>>  even if gnuplot_qt.exe executed from gnuplot.exe.
>> 
>>  For gnuplot for windows, two alternative way can be considered
>>  1) make original message system with qt tools within gnuplot_qt.exe.
> 
> Maybe for Windows you could replace qDebug() with a popup message box?
> 
>   http://doc.qt.io/qt-5/qmessagebox.html
> 
Thanks! I will consider modification using the above. 

>>  2) transfer messages to the main process and represented in the main 
> process.
> 
> That could not work if the message being sent is that
> the connection to the main process has broken :-)
> 
Ah! I can only do the case 1)

Tatsuro

Re: qt terminal for windows : qDebug() problems

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

On Wednesday, 19 August 2015 12:46:49 PM Tatsuro MATSUOKA wrote:
> 1)************************************************
> >1) The messages from qt_term.cpp can be written using fprintf(stderr, ...).
> >This would be consistent with error messages throughout the main program.
> >I will make this change.
> 
> 
> I appreciate that you will make the change.
> All messages from qt_term.cpp will be represented not only gnuplot.exe but 
> also wgnuplot.exe and wgnuplot_pipes.exe.

This change is now in CVS.
 
> 2)*************************************************
> >2) Messages from the separate process gnuplot_qt should not try
> >to write directly to stderr, since this may not go anywhere useful.
> >qDebug() is supposed to handle this, but I can't help with how to
> >configure on Windows.
> 
> 
> 
> >qDebug() is supposed to handle this, but I can't help with how to
> >configure on Windows.
> 
> According information searched on the web, qDebug() on windows can be 
> output messages to the console if the application is console one
> otherwise message to send to the debugger if it is present.
> 
> gnuplot_qt.exe does not have own console.
> This might be the origin represent nothing 
> even if gnuplot_qt.exe executed from gnuplot.exe.
> 
> For gnuplot for windows, two alternative way can be considered
> 1) make original message system with qt tools within gnuplot_qt.exe.

Maybe for Windows you could replace qDebug() with a popup message box?

   http://doc.qt.io/qt-5/qmessagebox.html


> 2) transfer messages to the main process and represented in the main process.

That could not work if the message being sent is that
the connection to the main process has broken :-)


> I think that the case 1) is more practical than case 2). 
> 
> Tatsuro

Re: qt terminal for windows : qDebug() problems

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

>> Two topic
>> 1) message related to qt terminal in gnuplot main program.
>> 2) message in gnuplot_qt
> 
>I think you are correct.
> 
>1) The messages from qt_term.cpp can be written using fprintf(stderr, ...).
>This would be consistent with error messages throughout the main program.
>I will make this change.
> 
>2) Messages from the separate process gnuplot_qt should not try
>to write directly to stderr, since this may not go anywhere useful.
>qDebug() is supposed to handle this, but I can't help with how to
>configure on Windows.
> 
>Ethan


Thank you for the reply.

1)************************************************
>1) The messages from qt_term.cpp can be written using fprintf(stderr, ...).
>This would be consistent with error messages throughout the main program.
>I will make this change.


I appreciate that you will make the change.
All messages from qt_term.cpp will be represented not only gnuplot.exe but 
also wgnuplot.exe and wgnuplot_pipes.exe.

2)*************************************************
>2) Messages from the separate process gnuplot_qt should not try
>to write directly to stderr, since this may not go anywhere useful.
>qDebug() is supposed to handle this, but I can't help with how to
>configure on Windows.



>qDebug() is supposed to handle this, but I can't help with how to
>configure on Windows.

According information searched on the web, qDebug() on windows can be 
output messages to the console if the application is console one
otherwise message to send to the debugger if it is present.

gnuplot_qt.exe does not have own console.
This might be the origin represent nothing 
even if gnuplot_qt.exe executed from gnuplot.exe.

For gnuplot for windows, two alternative way can be considered
1) make original message system with qt tools within gnuplot_qt.exe.
2) transfer messages to the main process and represented in the main process.

I think that the case 1) is more practical than case 2). 

Tatsuro

Re: documentation format and html output --

[Karl-Friedrich R. <ra...@un...>]

Am 18.08.2015 um 02:12 schrieb Ethan A Merritt:
> On Tuesday, 18 August, 2015 01:08:13 Karl-Friedrich Ratzsch wrote:
>> I was trying to work on the documentation a bit, but got quite
>> confused. ;-) Perhaps someone here can enlighten me.
>>
>> * I found that all tables appear twice in docs/gnupot.doc, only i've
>> got not idea where the one that is readymade html code (with "^" in
>> the first column) goes, and why there are two redundant versions.
>> Stuff with "^" in the first column should (says docs/README) go to
>> doc2{tex,html}, only i don't see it in the output of "make html" or
>> "make pdf". (waiiit, it's in the wxhelp html output! So is stuff
>> with "^" in fact only for doc2html, not doc2tex?)
> 
> Lines starting with ^ generate hyperlinks in the pdf documentation also,
> created via the *.tex file.
> 

Ah, I see. Lines beginning with "^ <a href" or "^ <a name" are
inserted as a hyperlink target or label by doc2tex:217 following,
other lines with first character "^" are ignored, and used by
doc2html only.

There are currently only two hyperlink labels in the whole text,
which are only referenced by using backquotes (in the "rgbformulae"
chapter).

Trying to link to them using

^ <a href="#positive">positivelink</a>

was not possible, pdflatex complains about runaway arguments and
unfound references. Hm. I'll look into this.


> 
>> * docs/README says that text between backquotes is set to boldface.
>> Is it correct that this also automatically creates a link (in html,
>> pdf), if there is an interactive "?help keyword" with the same name?
> 
> Yes.
> 
>> And this does not work inside tables. (OK, im sure about this. I'll
>> add a note to the README)
> 
> I have never tried to do that, so I don't know.

Doesn't, it does not even get boldfaced in a Table. TeX converts the
backquotes into typographic quotation marks instead. I'll add a note
to the README.


>> * I've tried adding a few extra empty lines and comments (with "C"
>> in the first column) here and there, to make the doc source a bit
>> more structured. I saw no problems, but do empty lines have any
>> significance except forcing a line break in continuous text?
> 
> The README discourages blank lines as a matter of style, but I think
> this has not been uniformly applied in practice.

I wanted to add an empty lines before section heading, two for
levels 2,3, to make navigation in the source a bit easier. Any
objection to changing that style rule?


>> * "make html" throws a billion errors. I get an html output in the
>> ...  
> 
> "make html" has not worked usably for many years. It used to
> invoke latex2html, but that package is no longer supplied or supported
> by current TeX bundles. I've had somewhat better luck with htlatex,
> but not enough luck to consider it a real option IMHO.
> In particular I could never get it to include figures correctly.

I know, I've used htlatex for another project. Some things go quite
well, others not. And it's mostly unmaintained, too. I guess I don't
need to test against the html target anway, as it doesn't work on
gnuplot.doc directly but on the .tex file.


As for tips&tricks, I found the program docs/checkdoc, which does at
least some very basic syntax checking on gnuplot.doc. It is called
by "make check-local". And for syntax highlighting, i tried gedit
with the "diff" format, which is a bit similar. I think that could
be adapted without too much work. Already looks not bad now.


There is one comment in docs/README, saying

	Tables must have a space in column 2.

Any idea what this means? It is never done.


I've set up a patch to docs/README on sf.net, comments are of course
welcome. https://sourceforge.net/p/gnuplot/patches/719/


  Karl

Re: documentation format and html output

[Hans-Bernhard B. <HBB...@t-...>]

Am 18.08.2015 um 01:08 schrieb Karl-Friedrich Ratzsch:
> * I found that all tables appear twice in docs/gnupot.doc,

Actually, make that _four_times_ ;-)

$ grep 'back a single' gnuplot.doc
        ^B    moves back a single character.
#\verb~^B~ & move back a single character.\\
%^B@move back a single character.
^<tr>    <td><tt>^B</tt></td>    <td>move back a single character.</td></tr>

 > only i've
> got not idea where the one that is readymade html code (with "^" in
> the first column) goes, and why there are two redundant versions.

I think it's because it would be quite hopeless to extract usable table 
content for four different from the same input.  Making the doc2*** 
programs clever enough to do that would be more work than doing all the 
tables multiple times.

> Stuff with "^" in the first column should (says docs/README) go to
> doc2{tex,html}, only i don't see it in the output of "make html" or
> "make pdf". (waiiit, it's in the wxhelp html output! So is stuff
> with "^" in fact only for doc2html, not doc2tex?)

Some of it is.  doc2tex only picks up the hyperlinks.  All other HTML is 
for doc2html only.

> * "make html" throws a billion errors. I get an html output in the
> end, sometimes, but it looks very broken.

Latex2html _is_, for all intents and purposes, broken. It just doesn't 
want to work with current-day Perl any more.  And none of the 
alternatives really work, either, for what we want to do.  We may have 
to consider that type of HTML generate a dead parrot.

> * docs/README mentions a make target "pdffigures" that's gone, but
> there is one "pdf_figures" that imo does the job advertised.

Not really.  That target really just makes the figures, but not the pdf 
with the included.  You want "make pdf".

> * lastly, does anyone have some hints/tricks for working with the
> gnuplot.doc file? Some editor that is able to do a bit of syntax
> highlighting, perchance?

I'm quite sure there isn't.  A total of about 5 people in the world ever 
work on that document.  That's just not enough of a user base for anyone 
to create an Emacs mode or whatever for this really rather tricky file 
format.

Re: qt terminal for windows : qDebug() problems

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

On Tuesday, 18 August, 2015 19:09:20 Tatsuro MATSUOKA wrote:
> Hello
> 
> This topic originally from the bug tracker.
> https://sourceforge.net/p/gnuplot/bugs/1554/
> 
> 
> Two topic
> 1) message related to qt terminal in gnuplot main program.
> 2) message in gnuplot_qt

I think you are correct.

1) The messages from qt_term.cpp can be written using fprintf(stderr, ...).
This would be consistent with error messages throughout the main program.
I will make this change.

2) Messages from the separate process gnuplot_qt should not try
to write directly to stderr, since this may not go anywhere useful.
qDebug() is supposed to handle this, but I can't help with how to
configure on Windows.

	Ethan

> 
> 1)*********************************************
> For qt terminal, some messages are represented by qDebug() in qt libraries.
> 
> However, using qDebug(), any message cannot be represented in wgnuplot.
> In gnuplot main program for windows (gnuplot.exe, wgnuplot.exe and wgnuplot_pipes.exe),
> fprintf is redefined and can be used to represent in stderr.
> (Of course, printf )
> 
> In main program qt related routine is mainly described in qt_term.cpp.
> In qt_term.cpp, qDebug() function is used in 7 times.
> 
> fprintf(stderr,"") ... is also used in qt_term.cpp.
> 
> For exapmle
> 
> 973: fprintf(stderr, "Qt terminal communication error: select() error %i %s\n", errno, strerror(errno));
> 
> I cannot find the reason why both qDebug() and fprintf(stderr,"") are used.
> 
> Can qDebug() replaced by fprintf(stderr,"") in qt_term.cpp?
> 
> ****************************************************** end of 1)
> 
> 
> 2) *********************************************************************
> BTW, for gnuplot_qt.exe situation is different.
> qDebug seems not to represent anything on gnuplot.exe, wgnuplot.exe nor wgnuplot_pipes.exe.
> 
> gnuplot_qt.exe works in another process so that it is difficult represent qDebug message to 
> wgnuplot command windows.  
> 
> Special treatment might be required to represent message from gnuplot_qt on windows.
> 
> Does anyone have good idea?
> ********************************************************** end of 2)
> 
> Tatsuro 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: "bins filter" and "set fit nolog option"

[Philipp K. J. <ja...@ie...>]

[snip]

> > Thanks, very helpful.
> > 
> > I couldn't find either of them in the CVS-PDF
> > at http://gnuplot.info/gnuplot_cvs.pdf
> > 
> > Best,
> > 
> 
> 
> The pdf document of cvs version in the above are not update
> frequently. Please go to 
> http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/
> 
> There is a new gnuplot.pdf in which document for bin is included.

Terrific - many thanks.

> 
> Tatsuro