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

Re: encoding question

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

On Fri, 24 Mar 2017, Allin Cottrell wrote:

> On Fri, 24 Mar 2017, Ethan A Merritt wrote:
>
>> On Friday, 24 March, 2017 14:57:11 Allin Cottrell wrote:
>>> 
>>> I ran an experiment to try to assess this. Booted Windows 8 (ugh) and
>>> created a directory named Beauté (that's with an e-acute) on my
>>> Desktop. I then created two copies of a simple gnuplot script to
>>> produce a PNG file. Each included the line
>>> 
>>> set output 'c:/users/cottrell/desktop/Beauté/test.png'
>>> 
>>> (encoded in cp1251). The two files were identical except that one of
>>> them included the line
>>> 
>>> set encoding utf8
>>> 
>>> before the "set output" line. (And the accented character in the
>>> output filename was the only non-ASCII character in the files.)
>>> 
>>> I then called wgnuplot.exe on the two scripts from the command line in
>>> a cmd.exe window. The one without "set encoding utf8" worked to
>>> produce the PNG, the other didn't. To see what was happening I then
>>> tried opening wgnuplot interactively and using the "load" command to
>>> run the scripts. The variant without "set encoding" again worked fine;
>>> the other one gave:
>>> 
>>> set output 'c:/users/cottrell/desktop/Beaut?/test.png'
>>>   cannot open file; output not changed
>>> 
>>> (note that in gnuplot's error message echoing the "set output" line
>>> the e-acute has been changed to a question mark, actually not an
>>> ASCII question mark but an "unrecognized glyph" symbol).
>>> 
>>> It therefore seems that "set encoding" has somehow altered gnuplot's
>>> reading of the bytes in the output filename.
>> 
>> No, I don't think that is what is happening.
>> 
>>> (Once again, those bytes
>>> are identical in the two files.) If gnuplot had simply passed the
>>> incoming cp1251 bytes to the OS, surely the output file would have
>>> been opened OK in both cases.
>> 
>> What seems to be happening is that in syscfg.h on Windows it says
>> /* The unicode/encoding support requires translation of file names */
>>    #define fopen win_fopen
>> 
>> and wmain.c:win_fopen() indeed tries to translate the name from the
>> current gnuplot encoding into Windows Unicode text.
>> I think the comment is wrong. File names should *not* be translated,
>> as you are finding out.  The current gnuplot encoding is a separate
>> thing from the encoding used in the sourcecode of the script.
>> 
>> I only see this code in the development version, not in the source
>> for 5.0.5 or 5.0.6.  So I guess your bug report is specifically for
>> the development version?
>> 
>> I'll defer to the Windows crowd here, but my tentative diagnosis
>> is that addition of a win_fopen() wrapper for fopen() in 5.1 should
>> be reverted.
>
> Aha, this is very interesting! Yes, I'm using the development 
> version on Windows so your diagnosis seems very plausible. But 
> actually, now I (think) I understand what's going on, I _like_ the 
> idea behind win_fopen.
>
> If I've got this right, it would let me standardize on 
> consistently UTF-8 gnuplot script files (including representing 
> Windows paths in UTF-8), and let gnuplot take care of recoding 
> paths on the fly as needed for interaction with the OS.
>
> It's ugly and error-prone to mix text encodings in a single file, 
> but I guess that's what you have to do with gnuplot 5.0 if you 
> want (a) to represent titles, labels and so on in UTF-8, but (b) 
> to include Windows filenames that contain non-ASCII characters. It 
> sounds like gnuplot 5.1 could improve on that. I can now try the 
> experiment of keeping "set encoding utf8" but recoding Windows 
> paths to UTF-8 when writing them into a gnuplot script. If that 
> works, I'm happy!

The experiment was successful. I could create a clean UTF-8 encoded 
gnuplot script (including a non-ASCII Windows path for "set 
output"), and gnuplot's win_fopen handled interaction with the OS 
correctly in the background. So I would definitely be in favor of 
keeping win_fopen.

(Reminder for anyone trying to follow this: win_fopen is a special 
facility in the development version of gnuplot. It has the effect of 
recoding filenames in a gnuplot script from whatever is set via "set 
encoding" to Windows-compatible 16-bit Unicode before they are 
passed to the C-library function fopen().)

Allin Cottrell

Re: encoding question

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

On Fri, 24 Mar 2017, Ethan A Merritt wrote:

> On Friday, 24 March, 2017 14:57:11 Allin Cottrell wrote:
>>
>> I ran an experiment to try to assess this. Booted Windows 8 (ugh) and
>> created a directory named Beauté (that's with an e-acute) on my
>> Desktop. I then created two copies of a simple gnuplot script to
>> produce a PNG file. Each included the line
>>
>> set output 'c:/users/cottrell/desktop/Beauté/test.png'
>>
>> (encoded in cp1251). The two files were identical except that one of
>> them included the line
>>
>> set encoding utf8
>>
>> before the "set output" line. (And the accented character in the
>> output filename was the only non-ASCII character in the files.)
>>
>> I then called wgnuplot.exe on the two scripts from the command line in
>> a cmd.exe window. The one without "set encoding utf8" worked to
>> produce the PNG, the other didn't. To see what was happening I then
>> tried opening wgnuplot interactively and using the "load" command to
>> run the scripts. The variant without "set encoding" again worked fine;
>> the other one gave:
>>
>> set output 'c:/users/cottrell/desktop/Beaut?/test.png'
>>   cannot open file; output not changed
>>
>> (note that in gnuplot's error message echoing the "set output" line
>> the e-acute has been changed to a question mark, actually not an
>> ASCII question mark but an "unrecognized glyph" symbol).
>>
>> It therefore seems that "set encoding" has somehow altered gnuplot's
>> reading of the bytes in the output filename.
>
> No, I don't think that is what is happening.
>
>> (Once again, those bytes
>> are identical in the two files.) If gnuplot had simply passed the
>> incoming cp1251 bytes to the OS, surely the output file would have
>> been opened OK in both cases.
>
> What seems to be happening is that in syscfg.h on Windows it says
> /* The unicode/encoding support requires translation of file names */
>    #define fopen win_fopen
>
> and wmain.c:win_fopen() indeed tries to translate the name from the
> current gnuplot encoding into Windows Unicode text.
> I think the comment is wrong. File names should *not* be translated,
> as you are finding out.  The current gnuplot encoding is a separate
> thing from the encoding used in the sourcecode of the script.
>
> I only see this code in the development version, not in the source
> for 5.0.5 or 5.0.6.  So I guess your bug report is specifically for
> the development version?
>
> I'll defer to the Windows crowd here, but my tentative diagnosis
> is that addition of a win_fopen() wrapper for fopen() in 5.1 should
> be reverted.

Aha, this is very interesting! Yes, I'm using the development 
version on Windows so your diagnosis seems very plausible. But 
actually, now I (think) I understand what's going on, I _like_ the 
idea behind win_fopen.

If I've got this right, it would let me standardize on consistently 
UTF-8 gnuplot script files (including representing Windows paths in 
UTF-8), and let gnuplot take care of recoding paths on the fly as 
needed for interaction with the OS.

It's ugly and error-prone to mix text encodings in a single file, 
but I guess that's what you have to do with gnuplot 5.0 if you want 
(a) to represent titles, labels and so on in UTF-8, but (b) to 
include Windows filenames that contain non-ASCII characters. It 
sounds like gnuplot 5.1 could improve on that. I can now try the 
experiment of keeping "set encoding utf8" but recoding Windows paths 
to UTF-8 when writing them into a gnuplot script. If that works, I'm 
happy!

(But of course if the win_fopen wrapper is preserved the backward 
incompatibility needs to be made clear -- though it probably affects 
rather few people.)

Allin Cottrell

Re: encoding question

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

On Friday, 24 March, 2017 14:57:11 Allin Cottrell wrote:
> On Thu, 23 Mar 2017, sfeam wrote:
>  
> >> So here's the question: given that the output filename is in CP1251,
> >> is my "set encoding" line liable to interfere with gnuplot's output
> >> routine (for example, such that output cannot be written because
> >> some non-ASCII component of the path is non-existent, if the bytes
> >> are interpreted as UTF-8), or is gnuplot's I/O mechanism separate
> >> and insulated from "set encoding"?
> >
> > Gnuplot does not care what is in the string used as a file name.
> > Linux/unix also does not care what is in the string used as a file name.
> > Any sequence of bytes is a legal filename even if is not printable.
> > Windows - I'm not so sure.  There are two ways that it might go wrong
> > on windows that I have heard of, and I suppose they might interact
> > badly.
> > Caveat: I don't use Windows myself, so I'm only repeating what I have
> > seen mentioned elsewhere.
> >
> > (1) Windows filesystems only allow certain encodings for file
> > names, and UTF-8 is not one of the allowed encodings.
> > https://msdn.microsoft.com/en-us/library/windows/desktop/dd317748(v=vs.85).aspx
> >
> > (2) At least some incarnations of Windows used a magic byte sequence
> > known as BOM to indicate the encoding used by a text file.  If your gnuplot
> > script file contains UTF-8 anything, some Windows machines are unhappy
> > if it does not start with BOM.  On the other hand if it _does_ start with BOM
> > then strings in the script file that are really CP1251 rather than UTF-8
> > might (I am guessing) be converted inappropriately.
> >
> > So I think your question is actually a Windows + script file format question
> > rather than anything specific to gnuplot.  I doubt that "set encoding"
> > matters, but mixing UTF-8 and CP1251 in the same script file may
> > be intrinsically problematic on Windows.
> 
> I ran an experiment to try to assess this. Booted Windows 8 (ugh) and 
> created a directory named Beauté (that's with an e-acute) on my 
> Desktop. I then created two copies of a simple gnuplot script to 
> produce a PNG file. Each included the line
> 
> set output 'c:/users/cottrell/desktop/Beauté/test.png'
> 
> (encoded in cp1251). The two files were identical except that one of 
> them included the line
> 
> set encoding utf8
> 
> before the "set output" line. (And the accented character in the 
> output filename was the only non-ASCII character in the files.)
> 
> I then called wgnuplot.exe on the two scripts from the command line in 
> a cmd.exe window. The one without "set encoding utf8" worked to 
> produce the PNG, the other didn't. To see what was happening I then 
> tried opening wgnuplot interactively and using the "load" command to 
> run the scripts. The variant without "set encoding" again worked fine; 
> the other one gave:
> 
> set output 'c:/users/cottrell/desktop/Beaut?/test.png'
>   cannot open file; output not changed
> 
> (note that in gnuplot's error message echoing the "set output" line 
> the e-acute has been changed to a question mark, actually not an 
> ASCII question mark but an "unrecognized glyph" symbol).
> 
> It therefore seems that "set encoding" has somehow altered gnuplot's 
> reading of the bytes in the output filename. 

No, I don't think that is what is happening.

> (Once again, those bytes 
> are identical in the two files.) If gnuplot had simply passed the 
> incoming cp1251 bytes to the OS, surely the output file would have 
> been opened OK in both cases.

What seems to be happening is that in syscfg.h on Windows it says
/* The unicode/encoding support requires translation of file names */
    #define fopen win_fopen

and wmain.c:win_fopen() indeed tries to translate the name from the
current gnuplot encoding into Windows Unicode text.
I think the comment is wrong. File names should *not* be translated,
as you are finding out.  The current gnuplot encoding is a separate
thing from the encoding used in the sourcecode of the script.

I only see this code in the development version, not in the source
for 5.0.5 or 5.0.6.  So I guess your bug report is specifically for
the development version?

I'll defer to the Windows crowd here, but my tentative diagnosis
is that addition of a win_fopen() wrapper for fopen() in 5.1 should
be reverted.

Of course if you are seeing this same problem with 5.0 then my
diagnosis is wrong :-/   

	Ethan

Re: encoding question

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

On Thu, 23 Mar 2017, sfeam wrote:

> On Thursday, 23 March 2017 08:09:14 PM Allin Cottrell wrote:
>> Sorry, this is quite ticklish but I'll try to explain it as best I
>> can.
>>
>> I'm not sure, from reading the gnuplot help on "encoding", of the
>> exact scope and effect of giving a "set encoding XXX" command in a
>> plot file.
>>
>> Here's the context: my program writes a gnuplot command file,
>> designed to produce PNG output via the pngcairo "terminal", and
>> among the users of the program are people working on Windows in
>> Russian. There are two possible non-ASCII elements in the plot file:
>>
>> 1) the name of the output file (as in "set output 'OOO'"), which for
>> MS Windows in Russian will be encoded in CP1251; and
>>
>> 2) strings occurring in titles, labels or whatever in the body of
>> the plot: by default these will be in UTF-8, which is what pngcairo
>> expects.
>>
>> At present I'm sticking a line into the plot file:
>>
>> set encoding utf8
>>
>> which I hope is going to tell gnuplot, "Whatever you might think
>> based on the fact that you're working on Windows in Russian, please
>> interpret titles/labels as being in UTF-8."
>
> That much is fine.  It also has the effect, for the png terminal and
> some others, that when you specify a font by name it will try to find
> a version of it that uses your specified encoding.

OK so far!

>> So here's the question: given that the output filename is in CP1251,
>> is my "set encoding" line liable to interfere with gnuplot's output
>> routine (for example, such that output cannot be written because
>> some non-ASCII component of the path is non-existent, if the bytes
>> are interpreted as UTF-8), or is gnuplot's I/O mechanism separate
>> and insulated from "set encoding"?
>
> Gnuplot does not care what is in the string used as a file name.
> Linux/unix also does not care what is in the string used as a file name.
> Any sequence of bytes is a legal filename even if is not printable.
> Windows - I'm not so sure.  There are two ways that it might go wrong
> on windows that I have heard of, and I suppose they might interact
> badly.
> Caveat: I don't use Windows myself, so I'm only repeating what I have
> seen mentioned elsewhere.
>
> (1) Windows filesystems only allow certain encodings for file
> names, and UTF-8 is not one of the allowed encodings.
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd317748(v=vs.85).aspx
>
> (2) At least some incarnations of Windows used a magic byte sequence
> known as BOM to indicate the encoding used by a text file.  If your gnuplot
> script file contains UTF-8 anything, some Windows machines are unhappy
> if it does not start with BOM.  On the other hand if it _does_ start with BOM
> then strings in the script file that are really CP1251 rather than UTF-8
> might (I am guessing) be converted inappropriately.
>
> So I think your question is actually a Windows + script file format question
> rather than anything specific to gnuplot.  I doubt that "set encoding"
> matters, but mixing UTF-8 and CP1251 in the same script file may
> be intrinsically problematic on Windows.

I ran an experiment to try to assess this. Booted Windows 8 (ugh) and 
created a directory named Beauté (that's with an e-acute) on my 
Desktop. I then created two copies of a simple gnuplot script to 
produce a PNG file. Each included the line

set output 'c:/users/cottrell/desktop/Beauté/test.png'

(encoded in cp1251). The two files were identical except that one of 
them included the line

set encoding utf8

before the "set output" line. (And the accented character in the 
output filename was the only non-ASCII character in the files.)

I then called wgnuplot.exe on the two scripts from the command line in 
a cmd.exe window. The one without "set encoding utf8" worked to 
produce the PNG, the other didn't. To see what was happening I then 
tried opening wgnuplot interactively and using the "load" command to 
run the scripts. The variant without "set encoding" again worked fine; 
the other one gave:

set output 'c:/users/cottrell/desktop/Beaut?/test.png'
  cannot open file; output not changed

(note that in gnuplot's error message echoing the "set output" line 
the e-acute has been changed to a question mark, actually not an 
ASCII question mark but an "unrecognized glyph" symbol).

It therefore seems that "set encoding" has somehow altered gnuplot's 
reading of the bytes in the output filename. (Once again, those bytes 
are identical in the two files.) If gnuplot had simply passed the 
incoming cp1251 bytes to the OS, surely the output file would have 
been opened OK in both cases.

Allin Cottrell

Re: encoding question

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

On Thursday, 23 March 2017 08:09:14 PM Allin Cottrell wrote:
> Sorry, this is quite ticklish but I'll try to explain it as best I 
> can.
> 
> I'm not sure, from reading the gnuplot help on "encoding", of the 
> exact scope and effect of giving a "set encoding XXX" command in a 
> plot file.
> 
> Here's the context: my program writes a gnuplot command file, 
> designed to produce PNG output via the pngcairo "terminal", and 
> among the users of the program are people working on Windows in 
> Russian. There are two possible non-ASCII elements in the plot file:
> 
> 1) the name of the output file (as in "set output 'OOO'"), which for 
> MS Windows in Russian will be encoded in CP1251; and
> 
> 2) strings occurring in titles, labels or whatever in the body of 
> the plot: by default these will be in UTF-8, which is what pngcairo 
> expects.
> 
> At present I'm sticking a line into the plot file:
> 
> set encoding utf8
> 
> which I hope is going to tell gnuplot, "Whatever you might think 
> based on the fact that you're working on Windows in Russian, please 
> interpret titles/labels as being in UTF-8."

That much is fine.  It also has the effect, for the png terminal and
some others, that when you specify a font by name it will try to find
a version of it that uses your specified encoding.

> So here's the question: given that the output filename is in CP1251, 
> is my "set encoding" line liable to interfere with gnuplot's output 
> routine (for example, such that output cannot be written because 
> some non-ASCII component of the path is non-existent, if the bytes 
> are interpreted as UTF-8), or is gnuplot's I/O mechanism separate 
> and insulated from "set encoding"?

Gnuplot does not care what is in the string used as a file name.
Linux/unix also does not care what is in the string used as a file name.
Any sequence of bytes is a legal filename even if is not printable.
Windows - I'm not so sure.  There are two ways that it might go wrong
on windows that I have heard of, and I suppose they might interact
badly. 
Caveat: I don't use Windows myself, so I'm only repeating what I have
seen mentioned elsewhere.
   
(1) Windows filesystems only allow certain encodings for file
names, and UTF-8 is not one of the allowed encodings.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317748(v=vs.85).aspx

(2) At least some incarnations of Windows used a magic byte sequence 
known as BOM to indicate the encoding used by a text file.  If your gnuplot
script file contains UTF-8 anything, some Windows machines are unhappy
if it does not start with BOM.  On the other hand if it _does_ start with BOM
then strings in the script file that are really CP1251 rather than UTF-8 
might (I am guessing) be converted inappropriately.

So I think your question is actually a Windows + script file format question
rather than anything specific to gnuplot.  I doubt that "set encoding"
matters, but mixing UTF-8 and CP1251 in the same script file may
be intrinsically problematic on Windows.

> As you might expect, this is not merely hypothetical: I'm getting an 
> error report from a Russian Windows user, and I wonder if the fact 
> that wgnuplot.exe is exiting with a non-zero code when trying to 
> process a command file written by my program might have something to 
> do with a text encoding issue.

Does the same script work if the file names it refers to are strictly ascii?

	Ethan

encoding question

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

Sorry, this is quite ticklish but I'll try to explain it as best I 
can.

I'm not sure, from reading the gnuplot help on "encoding", of the 
exact scope and effect of giving a "set encoding XXX" command in a 
plot file.

Here's the context: my program writes a gnuplot command file, 
designed to produce PNG output via the pngcairo "terminal", and 
among the users of the program are people working on Windows in 
Russian. There are two possible non-ASCII elements in the plot file:

1) the name of the output file (as in "set output 'OOO'"), which for 
MS Windows in Russian will be encoded in CP1251; and

2) strings occurring in titles, labels or whatever in the body of 
the plot: by default these will be in UTF-8, which is what pngcairo 
expects.

At present I'm sticking a line into the plot file:

set encoding utf8

which I hope is going to tell gnuplot, "Whatever you might think 
based on the fact that you're working on Windows in Russian, please 
interpret titles/labels as being in UTF-8."

So here's the question: given that the output filename is in CP1251, 
is my "set encoding" line liable to interfere with gnuplot's output 
routine (for example, such that output cannot be written because 
some non-ASCII component of the path is non-existent, if the bytes 
are interpreted as UTF-8), or is gnuplot's I/O mechanism separate 
and insulated from "set encoding"?

As you might expect, this is not merely hypothetical: I'm getting an 
error report from a Russian Windows user, and I wonder if the fact 
that wgnuplot.exe is exiting with a non-zero code when trying to 
process a command file written by my program might have something to 
do with a text encoding issue.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Aw: Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

[Bastian M. <bma...@we...>]

> Gesendet: Donnerstag, 23. März 2017 um 02:58 Uhr
> Von: sfeam <sf...@us...>
>
> Aha!
> 
> Finally I understand how the position of GEPID in the enum could make a difference.
> It is because of these lines here:
> 
> QtGnuplotEvent.cpp: 123
> 
>              if ((type < 1000) || (type > GEDone))
>                         {
>                         // FIXME EAM - At this point the program cannot recover and
>                         // if we try to continue it will eventually become a zombie.
>                         // Better to just exit explicitly right now.
>                                 qDebug() << "qt_gnuplot exiting on read error";
>                                 exit(0);
>                                 // return;
>                         }
> 
> So it really does treat the event differently if the code comes after GEDone.
> Sigh.
> 
> OK, please revert my change to place GEPID at the end so that the
> Windows executables work properly.  That would break my debugging things
> on linux, but the windows code won't be run on linux anyhow.
> 
> I will think about how to make this more fool-proof and make sure that it
> does not break either linux or Windows in the future.
> 
> 
> Maybe it is a bit late to ask, but is the raise-console option really necessary
> on Windows?   In truth my preferred option would be to get rid of it, in which
> case GEPID is not needed anyhow.
> 
> 	Ethan
> 

Yes. raise-console is a must-have in my opinion. Personally, I use it all the time.
Also it works flawlessly on Windows for wgnuplot and console mode gnuplot in a cmd 
shell - at least for windows and wxt terminal, but also for qt on the systems I
tested it. But I am not opposed to allow "space" to be bound via "bind".

As I currently cannot reproduce the problem Tatsuro is seeing, it is a bit
more difficult to debug.  In particular, changing the order of definitions for
QEPID does not change anything here.  Weird.

  Bastian

5.0.6 windows binary packages are uploaded

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

The windows binary packages for gnuplot release 5.0.6 are now available on SourceForge.

https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.6/

From this distribution, 7-zip archived packages are added. 


Note:

The packages were prepared using a source tar ball 5.0.6 but
src/qtterminal/QtGnuplotEvent.h was used in  5.0.6pre source tarball.

See the discussion in the below thread:
http://gnuplot.10905.n7.nabble.com/Release-5-0-6-td20570.html

Regards

Tatsuro

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

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

> From: sfeam 
> To: gnuplot-beta
> Cc: Tatsuro MATSUOKA <tmacchant3; bmaerkisch
> Date: 2017/3/23, Thu 10:58
> Subject: Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)
> 
> Aha!
> 
> Finally I understand how the position of GEPID in the enum could make a 
> difference.
> It is because of these lines here:
> 
> QtGnuplotEvent.cpp: 123
> 
>              if ((type < 1000) || (type > GEDone))
>                         {
>                         // FIXME EAM - At this point the program cannot recover 
> and
>                         // if we try to continue it will eventually become a 
> zombie.
>                         // Better to just exit explicitly right now.
>                                 qDebug() << "qt_gnuplot exiting on 
> read error";
>                                 exit(0);
>                                 // return;
>                         }
> 
> So it really does treat the event differently if the code comes after GEDone.
> Sigh.
> 
> OK, please revert my change to place GEPID at the end so that the
> Windows executables work properly.  That would break my debugging things
> on linux, but the windows code won't be run on linux anyhow.
> 
> I will think about how to make this more fool-proof and make sure that it
> does not break either linux or Windows in the future.
> 
> 
> Maybe it is a bit late to ask, but is the raise-console option really necessary
> on Windows?   In truth my preferred option would be to get rid of it, in which
> case GEPID is not needed anyhow.
> 
>     Ethan

Excuse me I have posted reply to the previous post before seeing this post.

> Maybe it is a bit late to ask, but is the raise-console option really necessary
> on Windows?   In truth my preferred option would be to get rid of it, in which
> case GEPID is not needed anyhow.

The raise-console option for qt for windows is implemented by Bastain.
Perhaps he will give you reply for this matter.

If I build binary using revert changes for QtGnuplotEvent.h, should I do the following
in Copyright?

 *   1. distribute the corresponding source modifications from the
 *    released version in the form of a patch file along with the binaries,
 *   2. add special version identification to distinguish your version
 *    in addition to the base release version number,
 *   3. provide your name and address as the primary contact for the
 *    support of your modified version, and
 *   4. retain our contact information in regard to use of the base
 *    software.

Tatsuro

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

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

> From: Ethan A Merritt <sf...@us...>
> To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...>
> Cc: bma...@we...
> Date: 2017/3/23, Thu 09:18
> Subject: Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)
> 
> On Thursday, 23 March, 2017 08:41:28 Tatsuro MATSUOKA wrote:
> 
>>  >> 
>>  >>  > Does commenting out this one line in qt_term.cpp make it 
> work again?
>>  >>  > 
>>  >>  > diff -urp gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 
>>  >>  > gnuplot-5.0.6/src/qtterminal/qt_term.cpp
>>  >>  > --- gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 2017-02-25 
>>  > 14:18:30.000000000 
>>  >>  > -0800
>>  >>  > +++ gnuplot-5.0.6/src/qtterminal/qt_term.cpp    2017-03-21 
>>  > 19:49:24.159719912 
>>  >>  > -0700
>>  >>  > @@ -537,7 +537,7 @@ void qt_graphics()
>>  >>  >         qt->out << GEInitWindow;
>>  >>  > #ifdef _WIN32
>>  >>  >         // Let the terminal window know our PID
>>  >>  > -       qt->out << GEPID << 
>>  > quint32(GetCurrentProcessId());
>>  >>  > +       // qt->out << GEPID << 
>>  > quint32(GetCurrentProcessId());
>>  >>  > #endif
>>  >>  >         qt->out << GEActivate;
>>  >>  >         qt->out << GETitle << 
> qt_option->Title;
>>  >> 
>>  >> 
>>  >> 
>>  >>  Yes! 
>>  >> 
>>  >>  > +       // qt->out << GEPID << 
>>  > quint32(GetCurrentProcessId());
>>  >> 
>>  >>  The comment out the above makes gnuplot_qt work. 
>>  >> 
>>  >>  Tatsuro
>>  > 
>>  > That demonstrates the problem is not due to changing the order of
>>  > symbols in enum QtGnuplotEventType.
>>  > 
>>  > There may be something wrong in the communication of pid information
>>  > between processes or possibly an error from the call to
>>  > AllowSetForegroundWindow(m_pid).  Maybe it needs error-checking?
>>  > Or sanity checking of the m_pid value?
>>  > Anyhow it seems from the symptoms you report that the error comes
>>  > from the code added to allow '--enable-raise-console'.  So I 
> expect
>>  > that the cleanest option for building from unmodified source is to
>>  > configure with 
>>  > 
>>  >    --disable-raise-console
>>  > 
>>  > or (same thing) add a line to config.h
>>  > 
>>  >     #define DISABLE_SPACE_RAISES_CONSOLE 
>>  > 
>>  > 
>>  >         Ethan
>> 
>>  Windows build does not use configure but use the special makefile.
>>  I add -DDISABLE_SPACE_RAISES_CONSOLE to CFLAGS and build 5.0.6 unmodified 
> source.
>>  However, the qt does not work even if this option is added.
>> 
>>  As I showed gdb trace previously
>>  http://gnuplot.10905.n7.nabble.com/Release-5-0-6-td20570.html#a20573
>>  gnuplot_qt seems to close at the point before DISABLE_SPACE_RAISES_CONSOLE 
> check in qt code.
>>  (QtGnuplotWindow.cpp).
> 
> Perhaps this patch will help.
> It adds GEPID to the list of events that should be ignored if they arrive
> before gnuplot_qt is ready to handle them.  
> 
> --- gnuplot50/src/qtterminal/QtGnuplotEvent.cpp    2015-08-20 10:24:39.000000000 
> -0700
> +++ gnuplot-5.0.6/src/qtterminal/QtGnuplotEvent.cpp    2017-03-22 
> 17:10:13.004011326 -0700
> @@ -183,5 +183,6 @@ void QtGnuplotEventReceiver::swallowEven
>     else if (type == GERaise)            ;               // 1034
>     else if (type == GEDesactivate)      ;               // 1038
>     else if (type == GESetPosition)      in >> point;
> +    else if (type == GEPID)              in >> i;
>     else qDebug() << "Event not swallowed !" << type;
> }
> 
> This patch looks correct to me even if it does not fix your problem,
> so I will add it to CVS.  But if it does fix your problem you should
> add it to 5.0.6 also in order to get a working Windows build.
> 
>     Ethan

Thank for your kind reply.

Unfortunately the patch above gave the same result.

I traced code with gdb gnuplot_qt terminates at the same line as posted previously in qt_term.cpp

(gdb) n
550             qt_sendFont();
(gdb) n

Here gnuplot_qt terminates again.

I should do child process debug but I do not have enough knowledge to do that
at this moment.

Tatsuro

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

Aha!

Finally I understand how the position of GEPID in the enum could make a difference.
It is because of these lines here:

QtGnuplotEvent.cpp: 123

             if ((type < 1000) || (type > GEDone))
                        {
                        // FIXME EAM - At this point the program cannot recover and
                        // if we try to continue it will eventually become a zombie.
                        // Better to just exit explicitly right now.
                                qDebug() << "qt_gnuplot exiting on read error";
                                exit(0);
                                // return;
                        }

So it really does treat the event differently if the code comes after GEDone.
Sigh.

OK, please revert my change to place GEPID at the end so that the
Windows executables work properly.  That would break my debugging things
on linux, but the windows code won't be run on linux anyhow.

I will think about how to make this more fool-proof and make sure that it
does not break either linux or Windows in the future.


Maybe it is a bit late to ask, but is the raise-console option really necessary
on Windows?   In truth my preferred option would be to get rid of it, in which
case GEPID is not needed anyhow.

	Ethan

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

On Thursday, 23 March, 2017 08:41:28 Tatsuro MATSUOKA wrote:
 
> >> 
> >>  > Does commenting out this one line in qt_term.cpp make it work again?
> >>  > 
> >>  > diff -urp gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 
> >>  > gnuplot-5.0.6/src/qtterminal/qt_term.cpp
> >>  > --- gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 2017-02-25 
> > 14:18:30.000000000 
> >>  > -0800
> >>  > +++ gnuplot-5.0.6/src/qtterminal/qt_term.cpp    2017-03-21 
> > 19:49:24.159719912 
> >>  > -0700
> >>  > @@ -537,7 +537,7 @@ void qt_graphics()
> >>  >         qt->out << GEInitWindow;
> >>  > #ifdef _WIN32
> >>  >         // Let the terminal window know our PID
> >>  > -       qt->out << GEPID << 
> > quint32(GetCurrentProcessId());
> >>  > +       // qt->out << GEPID << 
> > quint32(GetCurrentProcessId());
> >>  > #endif
> >>  >         qt->out << GEActivate;
> >>  >         qt->out << GETitle << qt_option->Title;
> >> 
> >> 
> >> 
> >>  Yes! 
> >> 
> >>  > +       // qt->out << GEPID << 
> > quint32(GetCurrentProcessId());
> >> 
> >>  The comment out the above makes gnuplot_qt work. 
> >> 
> >>  Tatsuro
> > 
> > That demonstrates the problem is not due to changing the order of
> > symbols in enum QtGnuplotEventType.
> > 
> > There may be something wrong in the communication of pid information
> > between processes or possibly an error from the call to
> > AllowSetForegroundWindow(m_pid).  Maybe it needs error-checking?
> > Or sanity checking of the m_pid value?
> > Anyhow it seems from the symptoms you report that the error comes
> > from the code added to allow '--enable-raise-console'.  So I expect
> > that the cleanest option for building from unmodified source is to
> > configure with 
> > 
> >    --disable-raise-console
> > 
> > or (same thing) add a line to config.h
> > 
> >     #define DISABLE_SPACE_RAISES_CONSOLE 
> > 
> > 
> >         Ethan
> 
> Windows build does not use configure but use the special makefile.
> I add -DDISABLE_SPACE_RAISES_CONSOLE to CFLAGS and build 5.0.6 unmodified source.
> However, the qt does not work even if this option is added.
> 
> As I showed gdb trace previously
> http://gnuplot.10905.n7.nabble.com/Release-5-0-6-td20570.html#a20573
> gnuplot_qt seems to close at the point before DISABLE_SPACE_RAISES_CONSOLE check in qt code.
> (QtGnuplotWindow.cpp).

Perhaps this patch will help.
It adds GEPID to the list of events that should be ignored if they arrive
before gnuplot_qt is ready to handle them.  

--- gnuplot50/src/qtterminal/QtGnuplotEvent.cpp	2015-08-20 10:24:39.000000000 -0700
+++ gnuplot-5.0.6/src/qtterminal/QtGnuplotEvent.cpp	2017-03-22 17:10:13.004011326 -0700
@@ -183,5 +183,6 @@ void QtGnuplotEventReceiver::swallowEven
 	else if (type == GERaise)            ;               // 1034
 	else if (type == GEDesactivate)      ;               // 1038
 	else if (type == GESetPosition)      in >> point;
+	else if (type == GEPID)              in >> i;
 	else qDebug() << "Event not swallowed !" << type;
 }

This patch looks correct to me even if it does not fix your problem,
so I will add it to CVS.  But if it does fix your problem you should
add it to 5.0.6 also in order to get a working Windows build.

	Ethan

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

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

> From: Ethan A Merritt <sf...@us...>
> To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...>
> Cc: bma...@we...
> Date: 2017/3/23, Thu 04:00
> Subject: Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)
> 
> On Wednesday, 22 March, 2017 12:40:59 Tatsuro MATSUOKA wrote:
>>  ----- Original Message -----
>> 
>>  > From: sfeam 
>>  > To: Tatsuro MATSUOKA 
>>  > Cc: gnuplot-beta bmaerkisch
>>  > Date: 2017/3/22, Wed 11:54
>>  > Subject: Re: qt terminal trouble 5.0.6 source on windows build (was 
> Re: Release 5.0.6)
>>  > 
>>  > On Tuesday, 21 March 2017 01:08:48 PM Tatsuro MATSUOKA wrote:
>>  >>  I checked changes after pre-release of 5.0.6 and found that
>>  >>  the change
>>  >> 
>>  >> 
>>  >>  2017-03-08  Ethan A Merritt  <merritt@u.washington.edu>
>>  >> 
>>  >>      * src/qtterminal/QtGnuplotEvent.h: Move new enum GEPID 
> (2017-02-25) to
>>  >>      end of enum list rather than in the middle.  Otherwise the 
> gnuplot_qt
>>  >>      built for 5.0.6 is incompatible with gnuplot executables 
> 5.0.0-5, which
>>  >>      makes comparison of multiple versions to debug things harder 
> than it
>>  >>      needs to be.  If the new event is at the end, all earlier 
> gnuplot 5.0.x
>>  >>      versions can share gnuplot_qt 5.0.6.
>>  >> 
>>  >>  prevents gnuplot_qt.exe to start on windows.
>>  >> 
>>  >>  I do not have enough knowledge so that I do not know why this 
> change causes 
>>  > 
>>  >>  trouble on qt terminal for windows.
>> 
>>  > 
>>  > Have you confirmed that it really is that one change?
>> 
>>  Yes. 
>>  I modified only  QtGnuplotEvent.h to before this change.
>> 
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/qtterminal/QtGnuplotEvent.h?r1=1.13.2.1&r2=1.13.2.2
>>  and gnuplot_qt works without problem
>> 
>> 
>>  > Does commenting out this one line in qt_term.cpp make it work again?
>>  > 
>>  > diff -urp gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 
>>  > gnuplot-5.0.6/src/qtterminal/qt_term.cpp
>>  > --- gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 2017-02-25 
> 14:18:30.000000000 
>>  > -0800
>>  > +++ gnuplot-5.0.6/src/qtterminal/qt_term.cpp    2017-03-21 
> 19:49:24.159719912 
>>  > -0700
>>  > @@ -537,7 +537,7 @@ void qt_graphics()
>>  >         qt->out << GEInitWindow;
>>  > #ifdef _WIN32
>>  >         // Let the terminal window know our PID
>>  > -       qt->out << GEPID << 
> quint32(GetCurrentProcessId());
>>  > +       // qt->out << GEPID << 
> quint32(GetCurrentProcessId());
>>  > #endif
>>  >         qt->out << GEActivate;
>>  >         qt->out << GETitle << qt_option->Title;
>> 
>> 
>> 
>>  Yes! 
>> 
>>  > +       // qt->out << GEPID << 
> quint32(GetCurrentProcessId());
>> 
>>  The comment out the above makes gnuplot_qt work. 
>> 
>>  Tatsuro
> 
> That demonstrates the problem is not due to changing the order of
> symbols in enum QtGnuplotEventType.
> 
> There may be something wrong in the communication of pid information
> between processes or possibly an error from the call to
> AllowSetForegroundWindow(m_pid).  Maybe it needs error-checking?
> Or sanity checking of the m_pid value?
> Anyhow it seems from the symptoms you report that the error comes
> from the code added to allow '--enable-raise-console'.  So I expect
> that the cleanest option for building from unmodified source is to
> configure with 
> 
>    --disable-raise-console
> 
> or (same thing) add a line to config.h
> 
>     #define DISABLE_SPACE_RAISES_CONSOLE 
> 
> 
>         Ethan

Windows build does not use configure but use the special makefile.
I add -DDISABLE_SPACE_RAISES_CONSOLE to CFLAGS and build 5.0.6 unmodified source.
However, the qt does not work even if this option is added.

As I showed gdb trace previously
http://gnuplot.10905.n7.nabble.com/Release-5-0-6-td20570.html#a20573
gnuplot_qt seems to close at the point before DISABLE_SPACE_RAISES_CONSOLE check in qt code.
(QtGnuplotWindow.cpp).

Tatsuro

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

On Wednesday, 22 March, 2017 12:40:59 Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: sfeam 
> > To: Tatsuro MATSUOKA 
> > Cc: gnuplot-beta bmaerkisch
> > Date: 2017/3/22, Wed 11:54
> > Subject: Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)
> > 
> > On Tuesday, 21 March 2017 01:08:48 PM Tatsuro MATSUOKA wrote:
> >>  I checked changes after pre-release of 5.0.6 and found that
> >>  the change
> >> 
> >> 
> >>  2017-03-08  Ethan A Merritt  <merritt@u.washington.edu>
> >> 
> >>      * src/qtterminal/QtGnuplotEvent.h: Move new enum GEPID (2017-02-25) to
> >>      end of enum list rather than in the middle.  Otherwise the gnuplot_qt
> >>      built for 5.0.6 is incompatible with gnuplot executables 5.0.0-5, which
> >>      makes comparison of multiple versions to debug things harder than it
> >>      needs to be.  If the new event is at the end, all earlier gnuplot 5.0.x
> >>      versions can share gnuplot_qt 5.0.6.
> >> 
> >>  prevents gnuplot_qt.exe to start on windows.
> >> 
> >>  I do not have enough knowledge so that I do not know why this change causes 
> > 
> >>  trouble on qt terminal for windows.
> 
> > 
> > Have you confirmed that it really is that one change?
> 
> Yes. 
> I modified only  QtGnuplotEvent.h to before this change.
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/qtterminal/QtGnuplotEvent.h?r1=1.13.2.1&r2=1.13.2.2
> and gnuplot_qt works without problem
> 
> 
> > Does commenting out this one line in qt_term.cpp make it work again?
> > 
> > diff -urp gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 
> > gnuplot-5.0.6/src/qtterminal/qt_term.cpp
> > --- gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 2017-02-25 14:18:30.000000000 
> > -0800
> > +++ gnuplot-5.0.6/src/qtterminal/qt_term.cpp    2017-03-21 19:49:24.159719912 
> > -0700
> > @@ -537,7 +537,7 @@ void qt_graphics()
> >         qt->out << GEInitWindow;
> > #ifdef _WIN32
> >         // Let the terminal window know our PID
> > -       qt->out << GEPID << quint32(GetCurrentProcessId());
> > +       // qt->out << GEPID << quint32(GetCurrentProcessId());
> > #endif
> >         qt->out << GEActivate;
> >         qt->out << GETitle << qt_option->Title;
> 
> 
> 
> Yes! 
> 
> > +       // qt->out << GEPID << quint32(GetCurrentProcessId());
> 
> The comment out the above makes gnuplot_qt work. 
> 
> Tatsuro

That demonstrates the problem is not due to changing the order of
symbols in enum QtGnuplotEventType.

There may be something wrong in the communication of pid information
between processes or possibly an error from the call to
AllowSetForegroundWindow(m_pid).  Maybe it needs error-checking?
Or sanity checking of the m_pid value?

Anyhow it seems from the symptoms you report that the error comes
from the code added to allow '--enable-raise-console'.  So I expect
that the cleanest option for building from unmodified source is to
configure with 

   --disable-raise-console

or (same thing) add a line to config.h

    #define DISABLE_SPACE_RAISES_CONSOLE 


		Ethan

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

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

> From: sfeam 
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-beta bmaerkisch
> Date: 2017/3/22, Wed 11:54
> Subject: Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)
> 
> On Tuesday, 21 March 2017 01:08:48 PM Tatsuro MATSUOKA wrote:
>>  I checked changes after pre-release of 5.0.6 and found that
>>  the change
>> 
>> 
>>  2017-03-08  Ethan A Merritt  <merritt@u.washington.edu>
>> 
>>      * src/qtterminal/QtGnuplotEvent.h: Move new enum GEPID (2017-02-25) to
>>      end of enum list rather than in the middle.  Otherwise the gnuplot_qt
>>      built for 5.0.6 is incompatible with gnuplot executables 5.0.0-5, which
>>      makes comparison of multiple versions to debug things harder than it
>>      needs to be.  If the new event is at the end, all earlier gnuplot 5.0.x
>>      versions can share gnuplot_qt 5.0.6.
>> 
>>  prevents gnuplot_qt.exe to start on windows.
>> 
>>  I do not have enough knowledge so that I do not know why this change causes 
> 
>>  trouble on qt terminal for windows.

> 
> Have you confirmed that it really is that one change?

Yes. 
I modified only  QtGnuplotEvent.h to before this change.
http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/qtterminal/QtGnuplotEvent.h?r1=1.13.2.1&r2=1.13.2.2
and gnuplot_qt works without problem


> Does commenting out this one line in qt_term.cpp make it work again?
> 
> diff -urp gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 
> gnuplot-5.0.6/src/qtterminal/qt_term.cpp
> --- gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 2017-02-25 14:18:30.000000000 
> -0800
> +++ gnuplot-5.0.6/src/qtterminal/qt_term.cpp    2017-03-21 19:49:24.159719912 
> -0700
> @@ -537,7 +537,7 @@ void qt_graphics()
>         qt->out << GEInitWindow;
> #ifdef _WIN32
>         // Let the terminal window know our PID
> -       qt->out << GEPID << quint32(GetCurrentProcessId());
> +       // qt->out << GEPID << quint32(GetCurrentProcessId());
> #endif
>         qt->out << GEActivate;
>         qt->out << GETitle << qt_option->Title;



Yes! 

> +       // qt->out << GEPID << quint32(GetCurrentProcessId());

The comment out the above makes gnuplot_qt work. 

Tatsuro

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

On Tuesday, 21 March 2017 01:08:48 PM Tatsuro MATSUOKA wrote:
> I checked changes after pre-release of 5.0.6 and found that
> the change
> 
> 
> 2017-03-08  Ethan A Merritt  <merritt@u.washington.edu>
> 
>     * src/qtterminal/QtGnuplotEvent.h: Move new enum GEPID (2017-02-25) to
>     end of enum list rather than in the middle.  Otherwise the gnuplot_qt
>     built for 5.0.6 is incompatible with gnuplot executables 5.0.0-5, which
>     makes comparison of multiple versions to debug things harder than it
>     needs to be.  If the new event is at the end, all earlier gnuplot 5.0.x
>     versions can share gnuplot_qt 5.0.6.
> 
> prevents gnuplot_qt.exe to start on windows.
> 
> I do not have enough knowledge so that I do not know why this change causes 
> trouble on qt terminal for windows.

Have you confirmed that it really is that one change?
Does commenting out this one line in qt_term.cpp make it work again?

diff -urp gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp gnuplot-5.0.6/src/qtterminal/qt_term.cpp
--- gnuplot-5.0.6pre/src/qtterminal/qt_term.cpp 2017-02-25 14:18:30.000000000 -0800
+++ gnuplot-5.0.6/src/qtterminal/qt_term.cpp    2017-03-21 19:49:24.159719912 -0700
@@ -537,7 +537,7 @@ void qt_graphics()
        qt->out << GEInitWindow;
 #ifdef _WIN32
        // Let the terminal window know our PID
-       qt->out << GEPID << quint32(GetCurrentProcessId());
+       // qt->out << GEPID << quint32(GetCurrentProcessId());
 #endif
        qt->out << GEActivate;
        qt->out << GETitle << qt_option->Title;


> Tatsuro
> 

Re: Aw: Re: Release 5.0.6

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

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

> From: sfeam 
> To: gnuplot-beta
> Cc: Bastian Märkisch ; tmacchant3
> Date: 2017/3/22, Wed 00:37
> Subject: Re: Aw: Re: Release 5.0.6
> 
> On Tuesday, 21 March 2017 10:19:59 AM Bastian Märkisch wrote:
>>  Dear Tatsuro,
>> 
>>  Indeed I experienced the same problem on my system. At least at first. I am 
> now unable to reproduce the problem with an unmodified 5.0.6 source tree (except 
> for the Makefile options). After many test builds, it seems that the only source 
> of for that error left that I could think is a race condition during build. In 
> particular changing the definitions of QEPID does not make a difference. So I 
> suggest you do a "make veryclean && make windows" and try 
> again.
> 
> Could it be that the OS caches a previously-used copy of gnuplot_qt, so that 
> even when
> you build a new one in practice it uses the old one?  That would explain 
> everything.
> 
> The problem you are now seeing sounds exactly like the problem I saw when the
> new QEPID was originally added in the middle of the definition list.  It made 
> the new
> gnuplot executable incompatible with my old gnuplot_qt, and vice versa it made 
> the
> new gnuplot_qt incompatible with the gnuplot executables previously built for
> 5.0.0 5.0.1 5.0.2 etc.  
> 
>     Ethan
> 
> 
>> 
>>    Bastian

Dear Bastian and Ethan

Thanks for replies.

I rebooted PC and deleted the previous source tress and extract freshly.
And I tried to build again.

However, I cannot get successful results 
I tried on both gcc-5.3.0 and gcc-6.3.0 on64 bits, gcc-5.3.0 on 32 bit.

It seems that the issue depends on my local environments and is is not a bug.
Anyway I cannot provide windows binaries for 5.0.6 at the moment.

Tatsuro

Re: Aw: Re: Release 5.0.6

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

On Tuesday, 21 March 2017 10:19:59 AM Bastian Märkisch wrote:
> Dear Tatsuro,
> 
> Indeed I experienced the same problem on my system. At least at first. I am now unable to reproduce the problem with an unmodified 5.0.6 source tree (except for the Makefile options). After many test builds, it seems that the only source of for that error left that I could think is a race condition during build. In particular changing the definitions of QEPID does not make a difference. So I suggest you do a "make veryclean && make windows" and try again.

Could it be that the OS caches a previously-used copy of gnuplot_qt, so that even when
you build a new one in practice it uses the old one?  That would explain everything.

The problem you are now seeing sounds exactly like the problem I saw when the
new QEPID was originally added in the middle of the definition list.  It made the new
gnuplot executable incompatible with my old gnuplot_qt, and vice versa it made the
new gnuplot_qt incompatible with the gnuplot executables previously built for
5.0.0 5.0.1 5.0.2 etc.  

	Ethan


> 
>   Bastian
> 
> > Gesendet: Dienstag, 21. März 2017 um 03:16 Uhr
> > Von: "Tatsuro MATSUOKA" <tma...@ya...>
> > An: "Merritt Ethan" <sf...@us...>, gnu...@li..., bma...@we..., tma...@ya...
> > Betreff: Re: Release 5.0.6
> >
> > ----- Original Message -----
> > 
> > > From: sfeam 
> > > To: gnuplot-beta
> > > Cc: 
> > > Date: 2017/3/18, Sat 13:08
> > > Subject: Release 5.0.6
> > > 
> > >T he source tarball for gnuplot release 5.0.6 is now available on SourceForge.
> > > 
> > > Changes in 5.0.6
> > > ================
> > > * NEW command 'set micro' enables encoding-specific char for gprintf %c 
> > > format
> > > * NEW command 'set datafile missing NaN' treats invalid data as if it 
> > > were missing
> > > * NEW backport updated svg/domterm terminal from development version
> > > * CHANGE - start/end limits in nested iterations are reevaluated dynamically
> > > * CHANGE - revised adjustment of x2label and plot title when x2tics are present
> > > * CHANGE - mark non-free pdf terminal DEPRECATED (to be removed in release 5.2)
> > > * CHANGE - allow fractional font sizes for gdlib terminals
> > > * CHANGE - do not allow inverted R axis (requires support not backported from 
> > > 5.1)
> > > * CHANGE - allow pointinterval property in 'with lp' for splot as well 
> > > as for plot
> > > * CHANGE - "linewidth <lw>" is accepted as a terminal option for 
> > > aquaterm, qt, wxt
> > > * CHANGE - spline segments outside xrange are ignored rather than treated as 
> > > errors
> > > * FIX assignment of x/y dimensions in "binary record=(a,b) ... with 
> > > image"
> > > * FIX wxt - multithreaded wxt was faulting during resize (mutex lock failure)
> > > * FIX windows - timed pause only worked for intervals < 1 second
> > > * FIX Front/back layering of border+grid lines was not always correct in 
> > > hidden3d
> > > * FIX "set pm3d depthorder interpolate N,M" memory allocation failure
> > > * FIX aquaterm failed to honor request to disable enhanced text markup
> > > * FIX save and show commands failed to list linecolor for lines with "lt 
> > > -1"
> > > * FIX the "missing" data flag is honored by "using ($n)" as 
> > > it is for "using n"
> > > * FIX error reporting of line number inside a bracketed clause
> > > * FIX gnuplot_x11: possible fix for sporadic use-after-free error
> > > * FIX initialization of hidden3d structures for splot with dots
> > > * FIX track arrowhead properties in hidden3d mode
> > > * FIX tracking of NaN values from function evaluated during binary data input
> > > * FIX 3D rotation does not clobber hidden/visible status of plots
> > > 
> > > 
> > >     happy gnuplotting
> > > 
> > >         Ethan
> > > 
> > 
> > I have tried to build gnuplot 5.0.6 on windows.
> > However, gnuplot_qt process fails to start
> > 
> > For starting qt terminal
> > 
> > gnuplot> set term qt
> > gnuplot> plot x
> > 
> > Warning: slow font initializationgnuplot>
> > 
> > Seeing task (process) manager on windows 10, I cannot see gnuplot_qt.exe.
> > This does not happens on gnuplot-5.0.6pre and 5.1 (2017-03-19).
> > 
> > I have tried both my original build dependency and msys2 dependency.
> > But results are the same
> > 
> > @Bastian
> > 
> > Did you see the similar phenomenon?
> > 
> > Tatsuro
> > 
> >
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Aw: Re: Release 5.0.6

[Bastian M. <bma...@we...>]

Dear Tatsuro,

Indeed I experienced the same problem on my system. At least at first. I am now unable to reproduce the problem with an unmodified 5.0.6 source tree (except for the Makefile options). After many test builds, it seems that the only source of for that error left that I could think is a race condition during build. In particular changing the definitions of QEPID does not make a difference. So I suggest you do a "make veryclean && make windows" and try again.

  Bastian

> Gesendet: Dienstag, 21. März 2017 um 03:16 Uhr
> Von: "Tatsuro MATSUOKA" <tma...@ya...>
> An: "Merritt Ethan" <sf...@us...>, gnu...@li..., bma...@we..., tma...@ya...
> Betreff: Re: Release 5.0.6
>
> ----- Original Message -----
> 
> > From: sfeam 
> > To: gnuplot-beta
> > Cc: 
> > Date: 2017/3/18, Sat 13:08
> > Subject: Release 5.0.6
> > 
> >T he source tarball for gnuplot release 5.0.6 is now available on SourceForge.
> > 
> > Changes in 5.0.6
> > ================
> > * NEW command 'set micro' enables encoding-specific char for gprintf %c 
> > format
> > * NEW command 'set datafile missing NaN' treats invalid data as if it 
> > were missing
> > * NEW backport updated svg/domterm terminal from development version
> > * CHANGE - start/end limits in nested iterations are reevaluated dynamically
> > * CHANGE - revised adjustment of x2label and plot title when x2tics are present
> > * CHANGE - mark non-free pdf terminal DEPRECATED (to be removed in release 5.2)
> > * CHANGE - allow fractional font sizes for gdlib terminals
> > * CHANGE - do not allow inverted R axis (requires support not backported from 
> > 5.1)
> > * CHANGE - allow pointinterval property in 'with lp' for splot as well 
> > as for plot
> > * CHANGE - "linewidth <lw>" is accepted as a terminal option for 
> > aquaterm, qt, wxt
> > * CHANGE - spline segments outside xrange are ignored rather than treated as 
> > errors
> > * FIX assignment of x/y dimensions in "binary record=(a,b) ... with 
> > image"
> > * FIX wxt - multithreaded wxt was faulting during resize (mutex lock failure)
> > * FIX windows - timed pause only worked for intervals < 1 second
> > * FIX Front/back layering of border+grid lines was not always correct in 
> > hidden3d
> > * FIX "set pm3d depthorder interpolate N,M" memory allocation failure
> > * FIX aquaterm failed to honor request to disable enhanced text markup
> > * FIX save and show commands failed to list linecolor for lines with "lt 
> > -1"
> > * FIX the "missing" data flag is honored by "using ($n)" as 
> > it is for "using n"
> > * FIX error reporting of line number inside a bracketed clause
> > * FIX gnuplot_x11: possible fix for sporadic use-after-free error
> > * FIX initialization of hidden3d structures for splot with dots
> > * FIX track arrowhead properties in hidden3d mode
> > * FIX tracking of NaN values from function evaluated during binary data input
> > * FIX 3D rotation does not clobber hidden/visible status of plots
> > 
> > 
> >     happy gnuplotting
> > 
> >         Ethan
> > 
> 
> I have tried to build gnuplot 5.0.6 on windows.
> However, gnuplot_qt process fails to start
> 
> For starting qt terminal
> 
> gnuplot> set term qt
> gnuplot> plot x
> 
> Warning: slow font initializationgnuplot>
> 
> Seeing task (process) manager on windows 10, I cannot see gnuplot_qt.exe.
> This does not happens on gnuplot-5.0.6pre and 5.1 (2017-03-19).
> 
> I have tried both my original build dependency and msys2 dependency.
> But results are the same
> 
> @Bastian
> 
> Did you see the similar phenomenon?
> 
> Tatsuro
> 
>

Re: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

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

> From: Tatsuro MATSUOKA > 
To: tmacchant3 Merritt Ethan ; gnuplot-beta bmaerkisch
> Cc: 
> Date: 2017/3/21, Tue 13:08
> Subject: qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)
> 
> 
> 
[snip]

>>  I have tried to build gnuplot 5.0.6 on windows.
>>  However, gnuplot_qt process fails to start
>> 
>>  For starting qt terminal
>> 
>>  gnuplot> set term qt
>>  gnuplot> plot x
>> 
>>  Warning: slow font initializationgnuplot>
>> 
>>  Seeing task (process) manager on windows 10, I cannot see gnuplot_qt.exe.
>>  This does not happens on gnuplot-5.0.6pre and 5.1 (2017-03-19).
>> 
>>  I have tried both my original build dependency and msys2 dependency.
>>  But results are the same
>> 
>>  @Bastian
>> 
>>  Did you see the similar phenomenon?
>> 
>>  Tatsuro
> 
> I checked changes after pre-release of 5.0.6 and found that
> the change
> 
> 
> 2017-03-08  Ethan A Merritt  <merritt@u.washington.edu>
> 
>     * src/qtterminal/QtGnuplotEvent.h: Move new enum GEPID (2017-02-25) to
>     end of enum list rather than in the middle.  Otherwise the gnuplot_qt
>     built for 5.0.6 is incompatible with gnuplot executables 5.0.0-5, which
>     makes comparison of multiple versions to debug things harder than it
>     needs to be.  If the new event is at the end, all earlier gnuplot 5.0.x
>     versions can share gnuplot_qt 5.0.6.
> 
> prevents gnuplot_qt.exe to start on windows.
> 
> I do not have enough knowledge so that I do not know why this change causes 
> trouble on qt terminal for windows.
> 
> Tatsuro

I have executed gdb trace.

gnuplot_qt starts but terminates at start_plot



Thread 1 hit Breakpoint 1, execGnuplotQt ()
    at ../../src/qtterminal/qt_term.cpp:229
229             QString filename;
(gdb) n
230             char* path = getenv("GNUPLOT_DRIVER_DIR");
(gdb) n
231             if (path)
(gdb) n
233             if (filename.isEmpty()) {
(gdb) n
235                     filename = QCoreApplication::applicationDirPath();
(gdb) n
241             filename += "/";
(gdb) n
242             filename += GNUPLOT_QT;
(gdb) n
245             qt->gnuplot_qtStarted = QProcess::startDetached(filename, QStringList(), QString(), &pid);
(gdb) n
246             if (qt->gnuplot_qtStarted) {  
Here gnuplot_qt started

(gdb) n
247                     qt->localServerName = "qtgnuplot" + QString::number(pid);
(gdb) n
250                     qt->pid = pid;
(gdb) n
229             QString filename;
(gdb) n
255     }
(gdb) n
qt_init () at ../../src/qtterminal/qt_term.cpp:440
440             setlocale(LC_NUMERIC, "C");
(gdb) n
441             setlocale(LC_TIME, current_locale);
(gdb) n
444             qt->out.setVersion(QDataStream::Qt_4_4);
(gdb) n
445             term_interlock = (void *)qt_init;
(gdb) n
446             gp_atexit(qt_atexit);
(gdb) n
447     }
(gdb) n
term_initialise () at ../../src/term.c:502
502             term_initialised = TRUE;
(gdb) n
504     }
(gdb) n
[New Thread 8800.0x10f4]
do_plot (plots=0x4ca54b0, pcount=1) at ../../src/graphics.c:523
523         term_start_plot();
(gdb) n
Here gnuplot_qt terminates.

I dig into term_start_plot(); by step command.

523         term_start_plot();
(gdb) s
term_start_plot () at ../../src/term.c:512
512         if (!term_initialised)
(gdb) s
515         if (!term_graphics) {
(gdb) s
517             (*term->graphics) ();
(gdb) s
qt_graphics () at ../../src/qtterminal/qt_term.cpp:514
514             ensureOptionsCreated();
(gdb) n
515             qt->out << GEDesactivate;
(gdb) n
516             qt_flushOutBuffer();
(gdb) n
517             qt_connectToServer();
(gdb) n
520             if (!(qt->codec = qt_encodingToCodec(encoding)))
(gdb) n
524             qt->currentFontSize = qt_optionFontSize;
(gdb) n
525             qt->currentFontName = qt_option->FontName;
(gdb) n
528             if (qt_setSize)
(gdb) n
530                     term->xmax = qt_oversampling*qt_setWidth;
(gdb) n
531                     term->ymax = qt_oversampling*qt_setHeight;
(gdb) n
532                     qt_setSize = false;
(gdb) n
536             qt->out << GESetCurrentWindow << qt_optionWindowId;
(gdb) n
537             qt->out << GEInitWindow;
(gdb) n
540             qt->out << GEPID << quint32(GetCurrentProcessId());
(gdb) n
542             qt->out << GEActivate;
(gdb) n
543             qt->out << GETitle << qt_option->Title;
(gdb) n
544             qt->out << GESetCtrl << qt_optionCtrl;
(gdb) n
545             qt->out << GESetWidgetSize << QSize(term->xmax, term->ymax)/qt_oversampling;
(gdb) n
547             qt->out << GESetSceneSize << QSize(term->xmax, term->ymax)/qt_oversampling;
(gdb) n
548             qt->out << GEClear;
(gdb) n
550             qt_sendFont();
(gdb) n

Here gnuplot_qt terminates.

Perhaps 
"Move new enum GEPID (2017-02-25) to end of enum list rather than in the middle"
affects the gnuplot_qt execution on windows but I cannot give fix for this issue.

But this is a serious bug of gnuplot for windows and should be corrected.

Tatsuro

qt terminal trouble 5.0.6 source on windows build (was Re: Release 5.0.6)

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

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

> From: Tatsuro MATSUOKA 
> To: Merritt Ethan  gnuplot-beta bmaerkisch tmacchant3
> Cc: 
> Date: 2017/3/21, Tue 11:16
> Subject: Re: Release 5.0.6
> 
> ----- Original Message -----
> 
>>  From: sfeam 
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2017/3/18, Sat 13:08
>>  Subject: Release 5.0.6
>> 
>> T he source tarball for gnuplot release 5.0.6 is now available on 
> SourceForge.
>> 
>>  Changes in 5.0.6
>>  ================
>>  * NEW command 'set micro' enables encoding-specific char for 
> gprintf %c 
>>  format
>>  * NEW command 'set datafile missing NaN' treats invalid data as if 
> it 
>>  were missing
>>  * NEW backport updated svg/domterm terminal from development version
>>  * CHANGE - start/end limits in nested iterations are reevaluated 
> dynamically
>>  * CHANGE - revised adjustment of x2label and plot title when x2tics are 
> present
>>  * CHANGE - mark non-free pdf terminal DEPRECATED (to be removed in release 
> 5.2)
>>  * CHANGE - allow fractional font sizes for gdlib terminals
>>  * CHANGE - do not allow inverted R axis (requires support not backported 
> from 
>>  5.1)
>>  * CHANGE - allow pointinterval property in 'with lp' for splot as 
> well 
>>  as for plot
>>  * CHANGE - "linewidth <lw>" is accepted as a terminal 
> option for 
>>  aquaterm, qt, wxt
>>  * CHANGE - spline segments outside xrange are ignored rather than treated 
> as 
>>  errors
>>  * FIX assignment of x/y dimensions in "binary record=(a,b) ... with 
>>  image"
>>  * FIX wxt - multithreaded wxt was faulting during resize (mutex lock 
> failure)
>>  * FIX windows - timed pause only worked for intervals < 1 second
>>  * FIX Front/back layering of border+grid lines was not always correct in 
>>  hidden3d
>>  * FIX "set pm3d depthorder interpolate N,M" memory allocation 
> failure
>>  * FIX aquaterm failed to honor request to disable enhanced text markup
>>  * FIX save and show commands failed to list linecolor for lines with 
> "lt 
>>  -1"
>>  * FIX the "missing" data flag is honored by "using 
> ($n)" as 
>>  it is for "using n"
>>  * FIX error reporting of line number inside a bracketed clause
>>  * FIX gnuplot_x11: possible fix for sporadic use-after-free error
>>  * FIX initialization of hidden3d structures for splot with dots
>>  * FIX track arrowhead properties in hidden3d mode
>>  * FIX tracking of NaN values from function evaluated during binary data 
> input
>>  * FIX 3D rotation does not clobber hidden/visible status of plots
>> 
>> 
>>      happy gnuplotting
>> 
>>          Ethan
>> 
> 
> I have tried to build gnuplot 5.0.6 on windows.
> However, gnuplot_qt process fails to start
> 
> For starting qt terminal
> 
> gnuplot> set term qt
> gnuplot> plot x
> 
> Warning: slow font initializationgnuplot>
> 
> Seeing task (process) manager on windows 10, I cannot see gnuplot_qt.exe.
> This does not happens on gnuplot-5.0.6pre and 5.1 (2017-03-19).
> 
> I have tried both my original build dependency and msys2 dependency.
> But results are the same
> 
> @Bastian
> 
> Did you see the similar phenomenon?
> 
> Tatsuro

I checked changes after pre-release of 5.0.6 and found that
the change


2017-03-08  Ethan A Merritt  <merritt@u.washington.edu>

    * src/qtterminal/QtGnuplotEvent.h: Move new enum GEPID (2017-02-25) to
    end of enum list rather than in the middle.  Otherwise the gnuplot_qt
    built for 5.0.6 is incompatible with gnuplot executables 5.0.0-5, which
    makes comparison of multiple versions to debug things harder than it
    needs to be.  If the new event is at the end, all earlier gnuplot 5.0.x
    versions can share gnuplot_qt 5.0.6.

prevents gnuplot_qt.exe to start on windows.

I do not have enough knowledge so that I do not know why this change causes 
trouble on qt terminal for windows.

Tatsuro

 


Tatsuro

Re: Release 5.0.6

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

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

> From: sfeam 
> To: gnuplot-beta
> Cc: 
> Date: 2017/3/18, Sat 13:08
> Subject: Release 5.0.6
> 
>T he source tarball for gnuplot release 5.0.6 is now available on SourceForge.
> 
> Changes in 5.0.6
> ================
> * NEW command 'set micro' enables encoding-specific char for gprintf %c 
> format
> * NEW command 'set datafile missing NaN' treats invalid data as if it 
> were missing
> * NEW backport updated svg/domterm terminal from development version
> * CHANGE - start/end limits in nested iterations are reevaluated dynamically
> * CHANGE - revised adjustment of x2label and plot title when x2tics are present
> * CHANGE - mark non-free pdf terminal DEPRECATED (to be removed in release 5.2)
> * CHANGE - allow fractional font sizes for gdlib terminals
> * CHANGE - do not allow inverted R axis (requires support not backported from 
> 5.1)
> * CHANGE - allow pointinterval property in 'with lp' for splot as well 
> as for plot
> * CHANGE - "linewidth <lw>" is accepted as a terminal option for 
> aquaterm, qt, wxt
> * CHANGE - spline segments outside xrange are ignored rather than treated as 
> errors
> * FIX assignment of x/y dimensions in "binary record=(a,b) ... with 
> image"
> * FIX wxt - multithreaded wxt was faulting during resize (mutex lock failure)
> * FIX windows - timed pause only worked for intervals < 1 second
> * FIX Front/back layering of border+grid lines was not always correct in 
> hidden3d
> * FIX "set pm3d depthorder interpolate N,M" memory allocation failure
> * FIX aquaterm failed to honor request to disable enhanced text markup
> * FIX save and show commands failed to list linecolor for lines with "lt 
> -1"
> * FIX the "missing" data flag is honored by "using ($n)" as 
> it is for "using n"
> * FIX error reporting of line number inside a bracketed clause
> * FIX gnuplot_x11: possible fix for sporadic use-after-free error
> * FIX initialization of hidden3d structures for splot with dots
> * FIX track arrowhead properties in hidden3d mode
> * FIX tracking of NaN values from function evaluated during binary data input
> * FIX 3D rotation does not clobber hidden/visible status of plots
> 
> 
>     happy gnuplotting
> 
>         Ethan
> 

I have tried to build gnuplot 5.0.6 on windows.
However, gnuplot_qt process fails to start

For starting qt terminal

gnuplot> set term qt
gnuplot> plot x

Warning: slow font initializationgnuplot>

Seeing task (process) manager on windows 10, I cannot see gnuplot_qt.exe.
This does not happens on gnuplot-5.0.6pre and 5.1 (2017-03-19).

I have tried both my original build dependency and msys2 dependency.
But results are the same

@Bastian

Did you see the similar phenomenon?

Tatsuro

Release 5.0.6

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

The source tarball for gnuplot release 5.0.6 is now available on SourceForge.

Changes in 5.0.6
================
* NEW command 'set micro' enables encoding-specific char for gprintf %c format
* NEW command 'set datafile missing NaN' treats invalid data as if it were missing
* NEW backport updated svg/domterm terminal from development version
* CHANGE - start/end limits in nested iterations are reevaluated dynamically
* CHANGE - revised adjustment of x2label and plot title when x2tics are present
* CHANGE - mark non-free pdf terminal DEPRECATED (to be removed in release 5.2)
* CHANGE - allow fractional font sizes for gdlib terminals
* CHANGE - do not allow inverted R axis (requires support not backported from 5.1)
* CHANGE - allow pointinterval property in 'with lp' for splot as well as for plot
* CHANGE - "linewidth <lw>" is accepted as a terminal option for aquaterm, qt, wxt
* CHANGE - spline segments outside xrange are ignored rather than treated as errors
* FIX assignment of x/y dimensions in "binary record=(a,b) ... with image"
* FIX wxt - multithreaded wxt was faulting during resize (mutex lock failure)
* FIX windows - timed pause only worked for intervals < 1 second
* FIX Front/back layering of border+grid lines was not always correct in hidden3d
* FIX "set pm3d depthorder interpolate N,M" memory allocation failure
* FIX aquaterm failed to honor request to disable enhanced text markup
* FIX save and show commands failed to list linecolor for lines with "lt -1"
* FIX the "missing" data flag is honored by "using ($n)" as it is for "using n"
* FIX error reporting of line number inside a bracketed clause
* FIX gnuplot_x11: possible fix for sporadic use-after-free error
* FIX initialization of hidden3d structures for splot with dots
* FIX track arrowhead properties in hidden3d mode
* FIX tracking of NaN values from function evaluated during binary data input
* FIX 3D rotation does not clobber hidden/visible status of plots


	happy gnuplotting

		Ethan

   

Re: Regression when using gnuplot and loops?

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

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

> From: Philipp K. Janert 
 To: gnuplot-beta
> Cc: 
> Date: 2017/3/7, Tue 10:24
> Subject: Re: Regression when using gnuplot and loops?
> 
> 
> [snip]
> 
>>  If you have a chance to build gnuplot by yourself,
>>  --with-wx-single-threaded 
>>  at configure sometimes changes the situation.
>>  (However, it may reduce the speed.)
> 
> Thanks for the hint! I'll give it a shot.
> 
> (But it may be a while before I get around to it!)
> 
The below is also similar to your case.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834396

In the above, as workaround, build gnuplot with --with-wx-single-threaded option is described.

Tatsuro

Re: Regression when using gnuplot and loops?

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

[snip]

> 
> As you wrote in the first post
> 
> > They may be due to some form of library version skew 
> > (I updated myLinux install in the meantime).    
> 
> Perhaps this is an issue of some form of library version skew.
> There seems to be difficulty in libraries of GTK+2, wxGTK and gnuplot.
> 
> If you have a chance to build gnuplot by yourself,
> --with-wx-single-threaded 
> at configure sometimes changes the situation.
> (However, it may reduce the speed.)

Thanks for the hint! I'll give it a shot.

(But it may be a while before I get around to it!)