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

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

On Fri, 6 Mar 2015, Tatsuro MATSUOKA reported from gdb:

> Program received signal SIGSEGV, Segmentation fault.
> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1",
>  max_len=-1, end=0xffffffff)
>   at ../../glib-2.42.1/glib/gutf8.c:1634
> 1634     *end = p;

I wonder if this is to do with a mix-up between C and C++ compilers.

The gnuplot code passes NULL as the last argument to g_utf8_validate. 
I gather that C++ compilers often represent NULL as all-bits-one -- 
hence, perhaps, the "0xffffffff" above? But apparently glib is not 
reading 0xffffffff as NULL (probably expects NULL = all-bits-zero).

When I build current gnuplot on Linux, gp_cairo.o is compiled by gcc, 
and then g++ is used as linker in making the gnuplot binary. Could it 
be that gp_cairo.o is being compiled by g++ in Tatsuro's case?

Allin Cottrell

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

On Friday, 06 March, 2015 10:54:23 Allin Cottrell wrote:
> Probably unrelated, but in looking at the gp_cairo.c code I noticed 
> one definite bug: in an error-response path in gp_cairo_convert on 
> line 750 the empty string "" is returned. Since the callers free the 
> return from gp_cairo_convert this will surely cause a segfault if it's 
> ever triggered. The return value here should either be NULL (if the 
> callers are ready to handle that), or g_strdup("").
> 
> Allin Cottrell


Good catch.
I run valgrind regularly to find such errors, but probably my
tests never execute locale-related error paths.

	Ethan

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

On Fri, 6 Mar 2015, Tatsuro MATSUOKA wrote:

> I have executed a short test using nmh
> https://github.com/shnya/nmh
>
> Perhaps it is better to use ICU - International Components for Unicode but
> I used nmh for rough test.
>
> Applied changes:
>
> --- gp_cairo.orig.c2014-12-14 08:42:38.000000000 +0900
> +++ gp_cairo.c2015-03-06 10:04:45.142151900 +0900
> @@ -76,6 +76,7 @@
>  
>  #include <pango/pangocairo.h>
>  #include <glib.h>
> +#include <nmh.h>
>  
>  #ifdef _MSC_VER
>  #define rint(x) floor((x)+0.5L)
> @@ -732,14 +733,21 @@
>  gsize bytes_read;
>  GError *error = NULL;
>  const char *charset = NULL;
> +const unsigned char *ucharset = NULL;
>  gchar * string_utf8;
>  
> -if (g_utf8_validate(string, -1, NULL)) {
> -    string_utf8 = g_strdup(string);
> -} else {
> -    charset = gp_cairo_get_encoding(plot);
> -    string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error);
> -}
> +charset = gp_cairo_get_encoding(plot);
> +ucharset = charset;
> +fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
> +       if (nmh_is_utf8(ucharset, strlen(ucharset))) { 
> +fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
> +   string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error); 

Bug right there: according to the documentation for g_convert, it's OK 
to pass NULL in place of the "bytes_read" pointer argument, but _not_
in place of the "bytes_written" (second to last) argument. So it's
to be expected that you get a segfault here.

(BTW, I don't see the point of the nmh test on the "ucharset" string: 
surely that's just the identifier of an encoding and will always be 
ASCII -- and hence also UTF-8.)

Allin Cottrell

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

On Tue, 3 Mar 2015, sfeam wrote:

> On Wednesday, 04 March 2015 09:54:08 AM Tatsuro MATSUOKA wrote:
>> [...]
>> I copy the back trace.
>
>> For wxt terminal,
>> (gdb) bt
>> #0  0x6862318f in g_utf8_validate (str=0x2a97fc8 "-1", max_len=-1,
>>     end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
>> #1  0x00529d21 in gp_cairo_convert (plot=0x2a0e0f0, string=0x2a97fc8 "-1")
>>     at ../../src/wxterminal/gp_cairo.c:737
>
> [snip]
>
> I think this indicates a bug in glib.
> Gnuplot is prepared for an error return from the call to g_utf8_validate,
> but apparently glib faults instead of cleanly returning an error.
> The gnuplot code is:
>        if (g_utf8_validate(string, -1, NULL)) {
>            string_utf8 = g_strdup(string);
>        } else {
>            charset = gp_cairo_get_encoding(plot);
>            string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error);
>        }

I think there must be more going on here than meets the eye. 
g_utf8_validate is a very basic glib function, I use it "all the time" 
in the same form as here (with -1 and NULL for the second and third 
arguments) and I've never seen it segfault on any platform or in any 
glib version up to 2.24.2.

Probably unrelated, but in looking at the gp_cairo.c code I noticed 
one definite bug: in an error-response path in gp_cairo_convert on 
line 750 the empty string "" is returned. Since the callers free the 
return from gp_cairo_convert this will surely cause a segfault if it's 
ever triggered. The return value here should either be NULL (if the 
callers are ready to handle that), or g_strdup("").

Allin Cottrell

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: Merritt Ethan 
> Cc: gnuplot-beta
> Date: 2015/3/4, Wed 18:45
> Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> 
> 
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam 
>>  To: Tatsuro MATSUOKA 
>>  Cc: gnuplot-beta
>>  Date: 2015/3/4, Wed 12:34
>>  Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 
> (MinGW64)
>> 
>>  On Wednesday, 04 March 2015 09:54:08 AM Tatsuro MATSUOKA wrote:
>>> 
>>>   ----- Original Message -----
>>>   >From: Ethan A Merritt 
>>>   >To: gnuplot-beta@ Tatsuro MATSUOKA 
>>>   >Date: 2015/3/4, Wed 05:29
>>>   >Subject: Re: Some observations building gnuplot for win by 
> gcc-4.9.2 
>>  (MinGW64)
>>>   >[snip]
>>>   > 
>>>   >> 32 bit
>>>   >> ******
>>>   >> gnuplot crashes by segmentation fault when one use cairo 
> based 
>>  terminals.
>>>   >> 
>>>   >> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 
> 32 
>>  bit gcc-4.9.2
>>>   >> 
>>>   >> I have met a  Segmentation fault at using gnuplot-5.1 built 
> by 
>>  myself on windows.
>>>   >> The Segmentation fault seems to be related with the cairo 
> based 
>>  terminals.
>>>   >> (The cairo based terminals use libglib.)
>>>   >> 
>>>   >> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
>>>   >> Glib version : 2.42.1. Build from source.
>>>   >> 
>>>   >> gdb message:
>>>   >> 
>>>   >> Program received signal SIGSEGV, Segmentation fault.
>>>   >> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", 
>>  max_len=-1, end=0xffffffff)
>>>   >>     at ../../glib-2.42.1/glib/gutf8.c:1634
>>>   >> 1634        *end = p;
>>>   >> 
>>>   >> Program received signal SIGSEGV, Segmentation fault.
>>>   >> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", 
>>  max_len=-1, end=0xffffffff)
>>>   >>     at ../../glib-2.42.1/glib/gutf8.c:1634
>>>   >> 1634        *end = p;
>>>   >> 
>>>   >> 
>>>   >> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
>>>   >> 
>>>   >> I have filed the issue to  the bug tracker of Gnome.
>>>   >>  
>>>   >> https://bugzilla.gnome.org/show_bug.cgi?id=745485
>>>   >> 
>>>   >> At this moment, I abandon the complier update. However, is 
> the 
>>  trouble 2 for 64 bit case not a issue of gnuplot code?
>>>   > 
>>>   >That is possible.
>>>   >Can you provide a more complete trace of the segfault that
>>>   >shows where in the gnuplot code this failure happened?
>>>   > 
>>>   >Ethan
>>>   > 
>>> 
>>> 
>>>   Thank you for your response:
>>> 
>>>   I copy the back trace.
>> 
>>>   For wxt terminal,
>>>   (gdb) bt
>>>   #0  0x6862318f in g_utf8_validate (str=0x2a97fc8 "-1", 
>>  max_len=-1,
>>>       end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
>>>   #1  0x00529d21 in gp_cairo_convert (plot=0x2a0e0f0, string=0x2a97fc8 
>>  "-1")
>>>       at ../../src/wxterminal/gp_cairo.c:737
>> 
>>  [snip]
>> 
>>  I think this indicates a bug in glib.
>>  Gnuplot is prepared for an error return from the call to g_utf8_validate,
>>  but apparently glib faults instead of cleanly returning an error.
>>  The gnuplot code is:
>>          if (g_utf8_validate(string, -1, NULL)) {
>>              string_utf8 = g_strdup(string);
>>          } else {
>>              charset = gp_cairo_get_encoding(plot);
>>              string_utf8 = g_convert(string, -1, "UTF-8", charset, 
> 
>>  &bytes_read, NULL, &error);
>>          }
>> 
>>  The strange thing is that the string being converted seems totally
>>  harmless: "-1".   I could more easily understand if the failure
>>  occurred for a string in, for example, SHIFT_JIS encoding since 
>>  I imagine the glib people have not tested that extensively.
>> 
>>  The only thing I can think of to try in the gnuplot code is to invert
>>  the order of the tests.  Something like
>> 
>>          charset = gp_cairo_get_encoding(plot);
>>          if (<some test on charset != UTF8>) {
>>              string_utf8 = g_convert(string, -1, "UTF-8", charset, 
> 
>>  &bytes_read, NULL, &error);
>>          } else if (g_utf8_validate(string, -1, NULL)) {
>>              string_utf8 = g_strdup(string);
>>          } else {
>>              more serious error code or failure
>>          }
>> 
>>  I am not sure what are the proper test in the pseudo-code above
>>  when run on Windows.
>> 
>>      Ethan
> 
> 
>  Thank you for your reply. I will consider <some test on charset != UTF8>.
> 
> Tatsuro


I have executed a short test using nmh
https://github.com/shnya/nmh

Perhaps it is better to use ICU - International Components for Unicode but
I used nmh for rough test.

Applied changes:

--- gp_cairo.orig.c2014-12-14 08:42:38.000000000 +0900
+++ gp_cairo.c2015-03-06 10:04:45.142151900 +0900
@@ -76,6 +76,7 @@
 
 #include <pango/pangocairo.h>
 #include <glib.h>
+#include <nmh.h>
 
 #ifdef _MSC_VER
 #define rint(x) floor((x)+0.5L)
@@ -732,14 +733,21 @@
 gsize bytes_read;
 GError *error = NULL;
 const char *charset = NULL;
+const unsigned char *ucharset = NULL;
 gchar * string_utf8;
 
-if (g_utf8_validate(string, -1, NULL)) {
-    string_utf8 = g_strdup(string);
-} else {
-    charset = gp_cairo_get_encoding(plot);
-    string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error);
-}
+charset = gp_cairo_get_encoding(plot);
+ucharset = charset;
+fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
+       if (nmh_is_utf8(ucharset, strlen(ucharset))) { 
+fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
+   string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error); 
+fprintf(stderr, "%f\n", nmh_is_utf8(ucharset, strlen(ucharset)));
+   } else if (g_utf8_validate(string, -1, NULL)) { 
+            string_utf8 = g_strdup(string); 
+        } else { 
+            fprintf(stderr, "more serious error code or failure \n");
+        } 
 
 /* handle error case */
 if (error != NULL) {


float nmh_is_utf8(const unsigned char *str, int size);
   argument:  str  input strings
              size size of input strings without NULL character. (wequals to strlen(str))
   retern value: 
            value=> 0 possibility of utf-8 is high; 
            value=< 0 possibility of utf-8 is low;
            value=> 1 possibility of utf-8n is high;

*****************************************
The results are:

Terminal type set to 'wxt'
gnuplot> plot sin(x)
[New Thread 21120.0x52b4]
[New Thread 21120.0x5228]
[New Thread 21120.0x4c80]
[New Thread 21120.0x4bdc]
[New Thread 21120.0x5148]
[New Thread 21120.0x52f8]
[New Thread 21120.0x3088]
[New Thread 21120.0x4ef8]
0.500000
0.500000

Program received signal SIGSEGV, Segmentation fault.
0x75d608ca in strncpy () from C:\Windows\syswow64\msvcrt.dll
(gdb) bt
#0  0x75d608ca in strncpy () from C:\Windows\syswow64\msvcrt.dll
#1  0x009e67f0 in ?? ()
#2  0x00000038 in ?? ()
#3  0x00000000 in ?? ()
(gdb)
**********************************
The first and second fprintf(stderr) are excuted but third one are not executed.
Therefore the segmentation fault is related to :
string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error);


Regards

Tatsuro

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

----- Original Message -----
> From: sfeam 
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-beta
> Date: 2015/3/4, Wed 12:34
> Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> 
> On Wednesday, 04 March 2015 09:54:08 AM Tatsuro MATSUOKA wrote:
>> 
>>  ----- Original Message -----
>>  >From: Ethan A Merritt 
>>  >To: gnuplot-beta@ Tatsuro MATSUOKA 
>>  >Date: 2015/3/4, Wed 05:29
>>  >Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 
> (MinGW64)
>>  >[snip]
>>  > 
>>  >> 32 bit
>>  >> ******
>>  >> gnuplot crashes by segmentation fault when one use cairo based 
> terminals.
>>  >> 
>>  >> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 
> bit gcc-4.9.2
>>  >> 
>>  >> I have met a  Segmentation fault at using gnuplot-5.1 built by 
> myself on windows.
>>  >> The Segmentation fault seems to be related with the cairo based 
> terminals.
>>  >> (The cairo based terminals use libglib.)
>>  >> 
>>  >> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
>>  >> Glib version : 2.42.1. Build from source.
>>  >> 
>>  >> gdb message:
>>  >> 
>>  >> Program received signal SIGSEGV, Segmentation fault.
>>  >> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", 
> max_len=-1, end=0xffffffff)
>>  >>     at ../../glib-2.42.1/glib/gutf8.c:1634
>>  >> 1634        *end = p;
>>  >> 
>>  >> Program received signal SIGSEGV, Segmentation fault.
>>  >> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", 
> max_len=-1, end=0xffffffff)
>>  >>     at ../../glib-2.42.1/glib/gutf8.c:1634
>>  >> 1634        *end = p;
>>  >> 
>>  >> 
>>  >> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
>>  >> 
>>  >> I have filed the issue to  the bug tracker of Gnome.
>>  >>  
>>  >> https://bugzilla.gnome.org/show_bug.cgi?id=745485
>>  >> 
>>  >> At this moment, I abandon the complier update. However, is the 
> trouble 2 for 64 bit case not a issue of gnuplot code?
>>  > 
>>  >That is possible.
>>  >Can you provide a more complete trace of the segfault that
>>  >shows where in the gnuplot code this failure happened?
>>  > 
>>  >Ethan
>>  > 
>> 
>> 
>>  Thank you for your response:
>> 
>>  I copy the back trace.
> 
>>  For wxt terminal,
>>  (gdb) bt
>>  #0  0x6862318f in g_utf8_validate (str=0x2a97fc8 "-1", 
> max_len=-1,
>>      end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
>>  #1  0x00529d21 in gp_cairo_convert (plot=0x2a0e0f0, string=0x2a97fc8 
> "-1")
>>      at ../../src/wxterminal/gp_cairo.c:737
> 
> [snip]
> 
> I think this indicates a bug in glib.
> Gnuplot is prepared for an error return from the call to g_utf8_validate,
> but apparently glib faults instead of cleanly returning an error.
> The gnuplot code is:
>         if (g_utf8_validate(string, -1, NULL)) {
>             string_utf8 = g_strdup(string);
>         } else {
>             charset = gp_cairo_get_encoding(plot);
>             string_utf8 = g_convert(string, -1, "UTF-8", charset, 
> &bytes_read, NULL, &error);
>         }
> 
> The strange thing is that the string being converted seems totally
> harmless: "-1".   I could more easily understand if the failure
> occurred for a string in, for example, SHIFT_JIS encoding since 
> I imagine the glib people have not tested that extensively.
> 
> The only thing I can think of to try in the gnuplot code is to invert
> the order of the tests.  Something like
> 
>         charset = gp_cairo_get_encoding(plot);
>         if (<some test on charset != UTF8>) {
>             string_utf8 = g_convert(string, -1, "UTF-8", charset, 
> &bytes_read, NULL, &error);
>         } else if (g_utf8_validate(string, -1, NULL)) {
>             string_utf8 = g_strdup(string);
>         } else {
>             more serious error code or failure
>         }
> 
> I am not sure what are the proper test in the pseudo-code above
> when run on Windows.
> 
>     Ethan


 Thank you for your reply. I will consider <some test on charset != UTF8>.

Tatsuro

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

On Wednesday, 04 March 2015 09:54:08 AM Tatsuro MATSUOKA wrote:
> 
> ----- Original Message -----
> >From: Ethan A Merritt 
> >To: gnuplot-beta@ Tatsuro MATSUOKA 
> >Date: 2015/3/4, Wed 05:29
> >Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> > 
> >
> > 
> >On Tuesday, 03 March, 2015 16:16:01 Tatsuro MATSUOKA wrote:
> >> Hello
> >> 
> >> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
> >> Some observations happened for both 64 bit and 32 bit build.
> >> 
> >> 
> >> Complier gcc-4.9.2-2 from MinGW-64 project
> >> 64 bit : exception:seh, thread:win32 
> >> 32 bit : exception:dwarf2, thread:win32 
> >> 
> >> Good point
> >> 
> >>  I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
> >> 
> >> 
> >> Troubles ?
> >> **********
> >> 64 bit
> >> **********
> >[snip]
> > 
> >> 32 bit
> >> ******
> >> gnuplot crashes by segmentation fault when one use cairo based terminals.
> >> 
> >> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 bit gcc-4.9.2
> >> 
> >> I have met a  Segmentation fault at using gnuplot-5.1 built by myself on windows.
> >> The Segmentation fault seems to be related with the cairo based terminals.
> >> (The cairo based terminals use libglib.)
> >> 
> >> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
> >> Glib version : 2.42.1. Build from source.
> >> 
> >> gdb message:
> >> 
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", max_len=-1, end=0xffffffff)
> >>     at ../../glib-2.42.1/glib/gutf8.c:1634
> >> 1634        *end = p;
> >> 
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", max_len=-1, end=0xffffffff)
> >>     at ../../glib-2.42.1/glib/gutf8.c:1634
> >> 1634        *end = p;
> >> 
> >> 
> >> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
> >> 
> >> I have filed the issue to  the bug tracker of Gnome.
> >>  
> >> https://bugzilla.gnome.org/show_bug.cgi?id=745485
> >> 
> >> At this moment, I abandon the complier update. However, is the trouble 2 for 64 bit case not a issue of gnuplot code?
> > 
> >That is possible.
> >Can you provide a more complete trace of the segfault that
> >shows where in the gnuplot code this failure happened?
> > 
> >Ethan
> > 
> 
> 
> Thank you for your response:
> 
> I copy the back trace.

> For wxt terminal,
> (gdb) bt
> #0  0x6862318f in g_utf8_validate (str=0x2a97fc8 "-1", max_len=-1,
>     end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
> #1  0x00529d21 in gp_cairo_convert (plot=0x2a0e0f0, string=0x2a97fc8 "-1")
>     at ../../src/wxterminal/gp_cairo.c:737

[snip]

I think this indicates a bug in glib.
Gnuplot is prepared for an error return from the call to g_utf8_validate,
but apparently glib faults instead of cleanly returning an error.
The gnuplot code is:
        if (g_utf8_validate(string, -1, NULL)) {
            string_utf8 = g_strdup(string);
        } else {
            charset = gp_cairo_get_encoding(plot);
            string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error);
        }

The strange thing is that the string being converted seems totally
harmless: "-1".   I could more easily understand if the failure
occurred for a string in, for example, SHIFT_JIS encoding since 
I imagine the glib people have not tested that extensively.

The only thing I can think of to try in the gnuplot code is to invert
the order of the tests.  Something like

        charset = gp_cairo_get_encoding(plot);
        if (<some test on charset != UTF8>) {
            string_utf8 = g_convert(string, -1, "UTF-8", charset, &bytes_read, NULL, &error);
        } else if (g_utf8_validate(string, -1, NULL)) {
            string_utf8 = g_strdup(string);
        } else {
            more serious error code or failure
        }

I am not sure what are the proper test in the pseudo-code above
when run on Windows.

	Ethan




> #2  0x0052b6bc in gp_cairo_enhanced_flush (plot=0x2a0e0f0)
>     at ../../src/wxterminal/gp_cairo.c:1311
> #3  0x00525eb9 in wxtPanel::wxt_cairo_exec_command (this=0x2a0df40,
>     command=...) at ../../src/wxterminal/wxt_gui.cpp:2964
> #4  0x005257a9 in wxtPanel::wxt_cairo_refresh (this=0x2a0df40)
>     at ../../src/wxterminal/wxt_gui.cpp:2850
> #5  0x00523e67 in wxt_text () at ../../src/wxterminal/wxt_gui.cpp:2047
> #6  0x0045d368 in wxt_text_wrapper () at ../../term/wxt.trm:460
> #7  0x0040e560 in term_end_plot () at ../../src/term.c:544
> #8  0x004f2f8f in do_plot (plots=0x29f8520, pcount=1)
>     at ../../src/graphics.c:912
> #9  0x004c324e in eval_plots () at ../../src/plot2d.c:3333
> #10 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
> #11 0x004acb3d in plot_command () at ../../src/command.c:1535
> #12 0x004aacb8 in command () at ../../src/command.c:621
> #13 0x004aa58d in do_line () at ../../src/command.c:418
> #14 0x004aa2cd in com_line () at ../../src/command.c:322
> #15 0x004b1518 in gnu_main (argc=0, argv=0x29e5818) at ../../src/plot.c:660
> #16 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
>     lpszCmdLine=0xa959c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
> #17 0x0057a31d in main ()
> 
> 
> For pngcairo terminal
> (gdb) bt
> #0  0x6862318f in g_utf8_validate (str=0x28f596 "-1", max_len=-1,
>     end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
> #1  0x00529d21 in gp_cairo_convert (plot=0x6088c0 <plot>,
>     string=0x28f596 "-1") at ../../src/wxterminal/gp_cairo.c:737
> #2  0x00529fbd in gp_cairo_draw_text (plot=0x6088c0 <plot>, x1=1100, y1=8842,
>     string=0x28f596 "-1", width=0x0, height=0x0)
>     at ../../src/wxterminal/gp_cairo.c:850
> #3  0x0045f1ab in cairotrm_put_text (x=1100, y=758, string=0x28f596 "-1")
>     at ../../term/cairo.trm:989
> #4  0x0040e9fc in write_multiline (x=1100, y=758, text=0x28f596 "-1",
>     hor=RIGHT, vert=JUST_CENTRE, angle=0, font=0x0) at ../../src/term.c:781
> #5  0x004fd5d5 in ytick2d_callback (axis=FIRST_Y_AXIS, place=-1,
>     text=0x28f596 "-1", ticlevel=0, grid=..., userlabels=0x0)
>     at ../../src/graphics.c:3446
> #6  0x0047fb09 in gen_tics (axis=FIRST_Y_AXIS,
>     callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1274
> #7  0x00480603 in axis_output_tics (axis=FIRST_Y_AXIS,
>     ticlabel_position=0x60bbac <ytic_x>, zeroaxis_basis=FIRST_X_AXIS,
>     callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1484
> #8  0x004f11c4 in place_grid () at ../../src/graphics.c:217
> #9  0x004f21a1 in do_plot (plots=0xde86f0, pcount=1)
>     at ../../src/graphics.c:551
> #10 0x004c324e in eval_plots () at ../../src/plot2d.c:3333
> #11 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
> #12 0x004acb3d in plot_command () at ../../src/command.c:1535
> #13 0x004aacb8 in command () at ../../src/command.c:621
> #14 0x004aa58d in do_line () at ../../src/command.c:418
> #15 0x004aa2cd in com_line () at ../../src/command.c:322
> #16 0x004b1518 in gnu_main (argc=0, argv=0xdd5818) at ../../src/plot.c:660
> #17 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
>     lpszCmdLine=0x8a59c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
> #18 0x0057a31d in main ()
> (gdb)
> 

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

----- Original Message -----
>From: Ethan A Merritt 
>To: gnuplot-beta@ Tatsuro MATSUOKA 
>Date: 2015/3/4, Wed 05:29
>Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> 
>
> 
>On Tuesday, 03 March, 2015 16:16:01 Tatsuro MATSUOKA wrote:
>> Hello
>> 
>> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
>> Some observations happened for both 64 bit and 32 bit build.
>> 
>> 
>> Complier gcc-4.9.2-2 from MinGW-64 project
>> 64 bit : exception:seh, thread:win32 
>> 32 bit : exception:dwarf2, thread:win32 
>> 
>> Good point
>> 
>>  I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
>> 
>> 
>> Troubles ?
>> **********
>> 64 bit
>> **********
>[snip]
> 
>> 32 bit
>> ******
>> gnuplot crashes by segmentation fault when one use cairo based terminals.
>> 
>> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 bit gcc-4.9.2
>> 
>> I have met a  Segmentation fault at using gnuplot-5.1 built by myself on windows.
>> The Segmentation fault seems to be related with the cairo based terminals.
>> (The cairo based terminals use libglib.)
>> 
>> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
>> Glib version : 2.42.1. Build from source.
>> 
>> gdb message:
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", max_len=-1, end=0xffffffff)
>>     at ../../glib-2.42.1/glib/gutf8.c:1634
>> 1634        *end = p;
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", max_len=-1, end=0xffffffff)
>>     at ../../glib-2.42.1/glib/gutf8.c:1634
>> 1634        *end = p;
>> 
>> 
>> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
>> 
>> I have filed the issue to  the bug tracker of Gnome.
>>  
>> https://bugzilla.gnome.org/show_bug.cgi?id=745485
>> 
>> At this moment, I abandon the complier update. However, is the trouble 2 for 64 bit case not a issue of gnuplot code?
> 
>That is possible.
>Can you provide a more complete trace of the segfault that
>shows where in the gnuplot code this failure happened?
> 
>Ethan
> 


Thank you for your response:

I copy the back trace.

For wxt terminal,
(gdb) bt
#0  0x6862318f in g_utf8_validate (str=0x2a97fc8 "-1", max_len=-1,
    end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
#1  0x00529d21 in gp_cairo_convert (plot=0x2a0e0f0, string=0x2a97fc8 "-1")
    at ../../src/wxterminal/gp_cairo.c:737
#2  0x0052b6bc in gp_cairo_enhanced_flush (plot=0x2a0e0f0)
    at ../../src/wxterminal/gp_cairo.c:1311
#3  0x00525eb9 in wxtPanel::wxt_cairo_exec_command (this=0x2a0df40,
    command=...) at ../../src/wxterminal/wxt_gui.cpp:2964
#4  0x005257a9 in wxtPanel::wxt_cairo_refresh (this=0x2a0df40)
    at ../../src/wxterminal/wxt_gui.cpp:2850
#5  0x00523e67 in wxt_text () at ../../src/wxterminal/wxt_gui.cpp:2047
#6  0x0045d368 in wxt_text_wrapper () at ../../term/wxt.trm:460
#7  0x0040e560 in term_end_plot () at ../../src/term.c:544
#8  0x004f2f8f in do_plot (plots=0x29f8520, pcount=1)
    at ../../src/graphics.c:912
#9  0x004c324e in eval_plots () at ../../src/plot2d.c:3333
#10 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
#11 0x004acb3d in plot_command () at ../../src/command.c:1535
#12 0x004aacb8 in command () at ../../src/command.c:621
#13 0x004aa58d in do_line () at ../../src/command.c:418
#14 0x004aa2cd in com_line () at ../../src/command.c:322
#15 0x004b1518 in gnu_main (argc=0, argv=0x29e5818) at ../../src/plot.c:660
#16 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
    lpszCmdLine=0xa959c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
#17 0x0057a31d in main ()


For pngcairo terminal
(gdb) bt
#0  0x6862318f in g_utf8_validate (str=0x28f596 "-1", max_len=-1,
    end=0xffffffff) at ../../glib-2.42.1/glib/gutf8.c:1634
#1  0x00529d21 in gp_cairo_convert (plot=0x6088c0 <plot>,
    string=0x28f596 "-1") at ../../src/wxterminal/gp_cairo.c:737
#2  0x00529fbd in gp_cairo_draw_text (plot=0x6088c0 <plot>, x1=1100, y1=8842,
    string=0x28f596 "-1", width=0x0, height=0x0)
    at ../../src/wxterminal/gp_cairo.c:850
#3  0x0045f1ab in cairotrm_put_text (x=1100, y=758, string=0x28f596 "-1")
    at ../../term/cairo.trm:989
#4  0x0040e9fc in write_multiline (x=1100, y=758, text=0x28f596 "-1",
    hor=RIGHT, vert=JUST_CENTRE, angle=0, font=0x0) at ../../src/term.c:781
#5  0x004fd5d5 in ytick2d_callback (axis=FIRST_Y_AXIS, place=-1,
    text=0x28f596 "-1", ticlevel=0, grid=..., userlabels=0x0)
    at ../../src/graphics.c:3446
#6  0x0047fb09 in gen_tics (axis=FIRST_Y_AXIS,
    callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1274
#7  0x00480603 in axis_output_tics (axis=FIRST_Y_AXIS,
    ticlabel_position=0x60bbac <ytic_x>, zeroaxis_basis=FIRST_X_AXIS,
    callback=0x4fcff4 <ytick2d_callback>) at ../../src/axis.c:1484
#8  0x004f11c4 in place_grid () at ../../src/graphics.c:217
#9  0x004f21a1 in do_plot (plots=0xde86f0, pcount=1)
    at ../../src/graphics.c:551
#10 0x004c324e in eval_plots () at ../../src/plot2d.c:3333
#11 0x004b4ac5 in plotrequest () at ../../src/plot2d.c:271
#12 0x004acb3d in plot_command () at ../../src/command.c:1535
#13 0x004aacb8 in command () at ../../src/command.c:621
#14 0x004aa58d in do_line () at ../../src/command.c:418
#15 0x004aa2cd in com_line () at ../../src/command.c:322
#16 0x004b1518 in gnu_main (argc=0, argv=0xdd5818) at ../../src/plot.c:660
#17 0x0053545b in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0,
    lpszCmdLine=0x8a59c9 "", nCmdShow=10) at ../../src/win/winmain.c:593
#18 0x0057a31d in main ()
(gdb)

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

On Tuesday, 03 March, 2015 16:16:01 Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
> Some observations happened for both 64 bit and 32 bit build.
> 
> 
> Complier gcc-4.9.2-2 from MinGW-64 project
> 64 bit : exception:seh, thread:win32 
> 32 bit : exception:dwarf2, thread:win32 
> 
> Good point
> 
>  I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
> 
> 
> Troubles ?
> **********
> 64 bit
> **********
[snip]

> 32 bit
> ******
> gnuplot crashes by segmentation fault when one use cairo based terminals.
> 
> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 bit gcc-4.9.2
> 
> I have met a  Segmentation fault at using gnuplot-5.1 built by myself on windows.
> The Segmentation fault seems to be related with the cairo based terminals.
> (The cairo based terminals use libglib.)
> 
> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
> Glib version : 2.42.1. Build from source.
> 
> gdb message:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", max_len=-1, end=0xffffffff)
>     at ../../glib-2.42.1/glib/gutf8.c:1634
> 1634        *end = p;
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", max_len=-1, end=0xffffffff)
>     at ../../glib-2.42.1/glib/gutf8.c:1634
> 1634        *end = p;
> 
> 
> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
> 
> I have filed the issue to  the bug tracker of Gnome.
>  
> https://bugzilla.gnome.org/show_bug.cgi?id=745485
> 
> At this moment, I abandon the complier update. However, is the trouble 2 for 64 bit case not a issue of gnuplot code?

That is possible.
Can you provide a more complete trace of the segfault that
shows where in the gnuplot code this failure happened?

	Ethan


 
> Regards
> 
> Tatsuro 

Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

Hello

I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 4.9.2.
Some observations happened for both 64 bit and 32 bit build.


Complier gcc-4.9.2-2 from MinGW-64 project
64 bit : exception:seh, thread:win32 
32 bit : exception:dwarf2, thread:win32 

Good point

 I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.


Troubles ?
**********
64 bit
**********
1. I have met an error in compiling qt_conversion.cpp.


../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was not declared in this scope

The error above can be avoided using the following patch:

--- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000 +0900
+++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
@@ -126,7 +126,7 @@
 QRgb* line = (QRgb*)(qimage.scanLine(n));
 for (int m = 0; m < M; m++)
 {
-if (isnan(*image))
+if (std::isnan(*image))
 {
 image++;
 *line++ = 0x00000000;


2. For first plotting in wxt terminal, I see a waring message like an attached file.
Here I write the text:

 You probably called setlocale() directly instead
 of using wxLocale and now there is a
 mismatch between C/C++ and Windows locale.
 Things are going to break, please only change
 locale by creating wxLocale objects to avoid this!

The above message is written in wxWidgets-3.0.2/src/common/intl.cpp

wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
{
    const wxLanguageInfo * const
        info = wxGetLocale() ? GetLanguageInfo(wxGetLocale()->GetLanguage())
                             : NULL;
    if ( !info )
    {
        // wxSetLocale() hadn't been called yet of failed, hence CRT must be
        // using "C" locale -- but check it to detect bugs that would happen if
        // this were not the case.
       wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
                      wxS("You probably called setlocale() directly instead ")
                      wxS("of using wxLocale and now there is a ")
                      wxS("mismatch between C/C++ and Windows locale.\n")
                      wxS("Things are going to break, please only change ")
                      wxS("locale by creating wxLocale objects to avoid this!") );


        // Return the hard coded values for C locale. This is really the right
        // thing to do as there is no LCID we can use in the code below in this
        // case, even LOCALE_INVARIANT is not quite the same as C locale (the
        // only difference is that it uses %Y instead of %y in the date format
        // but this difference is significant enough).

The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
However, I do not see the message building wxWidgets-3 by gcc-4.9.0.

Any ideas to avoid the message? Otherwise, is the above problem of complier?

******
32 bit
******
gnuplot crashes by segmentation fault when one use cairo based terminals.

Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 bit gcc-4.9.2

I have met a  Segmentation fault at using gnuplot-5.1 built by myself on windows.
The Segmentation fault seems to be related with the cairo based terminals.
(The cairo based terminals use libglib.)

Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
Glib version : 2.42.1. Build from source.

gdb message:

Program received signal SIGSEGV, Segmentation fault.
0x6862318f in g_utf8_validate (str=0x2888a68 "-1", max_len=-1, end=0xffffffff)
    at ../../glib-2.42.1/glib/gutf8.c:1634
1634        *end = p;

Program received signal SIGSEGV, Segmentation fault.
0x6862318f in g_utf8_validate (str=0xb28a68 "-1", max_len=-1, end=0xffffffff)
    at ../../glib-2.42.1/glib/gutf8.c:1634
1634        *end = p;


Perhaps this is a bug of glib (2.42.1 and 2.33.14).

I have filed the issue to  the bug tracker of Gnome.
 
https://bugzilla.gnome.org/show_bug.cgi?id=745485



At this moment, I abandon the complier update. However, is the trouble 2 for 64 bit case not a issue of gnuplot code?

Regards

Tatsuro 

Does "linetype" get written with save?

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

I just noticed that the settings for "linetype"
do not seem to be included in the information
persisted with "save". Is that correct, or am
I overlooking something?

Best,

		Ph.

Re: Multiplot margins and spacing options 5.0-branch vs 5.1

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

Am 21.02.2015 um 23:46 schrieb sfeam:
> On Saturday, 21 February 2015 10:53:53 AM Christoph Bersch wrote:
>>
>> Seems, like you committed your updated patch only to CVS, but applied my
>> old patch to the 5.0 branch.
>>
>> Check the following script, which behaves as expected with 5.1 CVS, but
>> not with the stable branch.
>
> The idea is to not break anything in 5.0.

Yes, that's why I asked. Because the current status of `set multiplot 
layout margins` behavior in the 5.0 branch breaks with the behavior of 
the 5.0 release version as it assumes different default units for the 
values given to this option. But as long as you still have it in your 
queue, it's fine :)

Another thing related to this is:

`set margin` and `set [lrbt]margin` use `char` as default unit, whereas 
`set multiplot layout margins` uses `screen` as default unit. That was 
the reason why I proposed to use the same behavior for all those commands.

And, the revised patch for `set multiplot layout margins` uses a sticky 
`screen` or `char` keyword, so

     set multiplot margins screen 0.1, 0.9, 0.9, 0.1

would use `screen` for all values, whereas

     set margin screen 0.1, 0.9, 0.9, 0.1

uses `screen` only for the first value. Should we adapt the behavior of 
`set multiplot margins`, so that we are consistent?
I had chosen the sticky variant, because in my use cases I always used 
the same units for all values, and I didn't want to repeat the same 
keyword four time (also like the coordinate parsing in `set object 
polygon` does).

Best,
Christoph

Re: Multiplot margins and spacing options 5.0-branch vs 5.1

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

On Saturday, 21 February 2015 10:53:53 AM Christoph Bersch wrote:
> Hi Ethan,
> 
> I had submitted a patch to update and fix the behavior of multiplot's 
> margins and spacing option, http://sourceforge.net/p/gnuplot/patches/713/
> 
> You had improved the patch, so that
> 
> * the default units are `screen`, and not `char` (as I had):
> * the ordering of <top> and <bottom> doesn't matter and is swapped 
> internally if required.
> 
> Seems, like you committed your updated patch only to CVS, but applied my 
> old patch to the 5.0 branch.
> 
> Check the following script, which behaves as expected with 5.1 CVS, but 
> not with the stable branch. 

The idea is to not break anything in 5.0.
Bugfixes and minor changes that seem fool-proof can go directly into
both 5.0 and 5.1.

My preference is that patches that are not convincingly fool-proof 
should get a testing period in 5.1 first.  If no problems turn up,
then they can bee applied to 5.0 before the next patchlevel release.
If problems or objections do turn up, they can be repaired or reverted
without affecting 5.0 at any point.

I keep a queue of patches that are in testing in 5.1 waiting for
backporting (or whatever you like to call it) into 5.0

Currently the queue contains 5 patches:

sample_interval		plot sample [a=min:max:interval] using ...
toggle_command		"toggle" from console command rather than mouse click
set_margins_order	to left, right, bottom, top
multiplot_spacing	(the patch you are referring to)
times_sign_for_iso8859	'×' rather than 'x' in "%h" format

The last 2 or 3 of those have probably had sufficient time in 5.1
with no reported complaint or problem.  The first two I'm not so sure about. 

	Ethan

> All three plots should be identical:
> 
> set multiplot layout 2,2 \
>      margins screen 0.1,0.9,0.9,0.1 spacing screen 0.1 \
>      title 'Margins order <top>,<bottom>'
> do for [i=1:4] {plot i*x }
> unset multiplot
> pause -1
> 
> set multiplot layout 2,2 \
>      margins screen 0.1,0.9,0.1,0.9 spacing screen 0.1 \
>      title 'Margins order <bottom>, <top>'
> do for [i=1:4] {plot i*x }
> unset multiplot
> pause -1
> 
> set multiplot layout 2,2 \
>      margins 0.1,0.9,0.1,0.9 spacing 0.1 \
>      title 'No explicit units, should default to "screen"'
> do for [i=1:4] {plot i*x }
> unset multiplot
> 
> Thank you,
> Christoph

Re: Any utility to adding grayscale/greyscale to terminal options

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

On Saturday, 21 February 2015 02:05:38 AM Daniel J Sebald wrote:
> The other day I pointed out the behavior of the "monochrome" option that 
> the majority of terminals have in a bug report.  Ethan pointed out the 
> legacy nature of it and not knowing how to handle rgb objects under the 
> "mono" option.  Right now, it looks like most terminals treat "mono" as 
> being a binary color, or single pen color (black).
> 
> I'm wondering if it would make sense to add a third option here, 
> grayscale.  So most terminals would have:
> 
> {color | colour | grayscale | greyscale | monochrome}
> 
> Color is obvious, I guess.  Grayscale would map colors to grayscale. 

IMHO this is the job of the viewer/printer/image-editer rather
than gnuplot. 

> Monochrome would map colors and grayscale palette to either white or 
> black, say a formula for which white is the top "half" of the range and 
> black is the bottom half.  E.g.,
> 
> rgb 0xff9f00 -> gray 0x8a -> mono 0x1
> rgb 0xff6f00 -> gray 0x7a -> mono 0x0
> 
> It might be nice having the grayscale option.
> 
> The reason that grayscale and monochrome seem useful is that internally 
> the terminal may be able to do things to customize the output.  For 
> example, postscript might be able to reduce the size of the file if 
> grayscale is used as opposed to color.

The PostScript terminal already does this.  Palette colors are represented
by a single scalar value.  In "mono" mode this is executed as a greyscale
command, in "color" mode it is executed via a PostScript routine that 
reproduces the palette color mapping.

	Ethan

Multiplot margins and spacing options 5.0-branch vs 5.1

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

Hi Ethan,

I had submitted a patch to update and fix the behavior of multiplot's 
margins and spacing option, http://sourceforge.net/p/gnuplot/patches/713/

You had improved the patch, so that

* the default units are `screen`, and not `char` (as I had):
* the ordering of <top> and <bottom> doesn't matter and is swapped 
internally if required.

Seems, like you committed your updated patch only to CVS, but applied my 
old patch to the 5.0 branch.

Check the following script, which behaves as expected with 5.1 CVS, but 
not with the stable branch. All three plots should be identical:

set multiplot layout 2,2 \
     margins screen 0.1,0.9,0.9,0.1 spacing screen 0.1 \
     title 'Margins order <top>,<bottom>'
do for [i=1:4] {plot i*x }
unset multiplot
pause -1

set multiplot layout 2,2 \
     margins screen 0.1,0.9,0.1,0.9 spacing screen 0.1 \
     title 'Margins order <bottom>, <top>'
do for [i=1:4] {plot i*x }
unset multiplot
pause -1

set multiplot layout 2,2 \
     margins 0.1,0.9,0.1,0.9 spacing 0.1 \
     title 'No explicit units, should default to "screen"'
do for [i=1:4] {plot i*x }
unset multiplot

Thank you,
Christoph

Any utility to adding grayscale/greyscale to terminal options

[Daniel J S. <dan...@ie...>]

The other day I pointed out the behavior of the "monochrome" option that 
the majority of terminals have in a bug report.  Ethan pointed out the 
legacy nature of it and not knowing how to handle rgb objects under the 
"mono" option.  Right now, it looks like most terminals treat "mono" as 
being a binary color, or single pen color (black).

I'm wondering if it would make sense to add a third option here, 
grayscale.  So most terminals would have:

{color | colour | grayscale | greyscale | monochrome}

Color is obvious, I guess.  Grayscale would map colors to grayscale. 
Monochrome would map colors and grayscale palette to either white or 
black, say a formula for which white is the top "half" of the range and 
black is the bottom half.  E.g.,

rgb 0xff9f00 -> gray 0x8a -> mono 0x1
rgb 0xff6f00 -> gray 0x7a -> mono 0x0

It might be nice having the grayscale option.

The reason that grayscale and monochrome seem useful is that internally 
the terminal may be able to do things to customize the output.  For 
example, postscript might be able to reduce the size of the file if 
grayscale is used as opposed to color.

Dan

Re: cvs(5.1) binaries for windows and Cygwin are updated

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

Hello

I have forgotten to write the url of the web site.

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (Native windows)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/ (Cygwin) 


Tatsuro


----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2015/2/19, Thu 16:43
> Subject: cvs(5.1) binaries for windows and Cygwin are updated
> 
> Hello
> 
> Since October 2014, I have not updated cvs(5.1) binaries for windows and Cygwin.
> Today I have updated them.
> 
> Please enjoy the latest features of gnuplot.
> 
> Tasuro
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

cvs(5.1) binaries for windows and Cygwin are updated

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

Hello

Since October 2014, I have not updated cvs(5.1) binaries for windows and Cygwin.
Today I have updated them.

Please enjoy the latest features of gnuplot.

Tasuro

Re: gnuplot version update on sf.net

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

Hello

I have prepared gnuplot-5.0.0 binaries using the MinGW 64bit complier and 
uploaded them on my web site.

http://www.tatsuromatsuoka.com/gnuplot/Eng/gp500/


It will be grateful if you will upload them to the SourceForge site.

This time I have not prepared the cygwin binaries because the official cygwin web site
prepare the 5.0.0 binaries for the cygiwin.

Regards

Tatsuro  


----- Original Message -----
> From: sfeam 
> To: gnuplot-beta
> Cc: 
> Date: 2015/2/19, Thu 01:23
> Subject: Re: gnuplot version update on sf.net
> 
> On Wednesday, 18 February 2015 10:00:07 AM Karl Ratzsch wrote:
>>  Hi,
>> 
>>  sf.net still advertises v466 as the latest version to windows users, and
>>  it´s still weekly getting twice as many downloads as v500. I hardly
>>  believe the users do this intentionally, for the source package the
>>  ratio is more like 1:10
>> 
>>  Can anyone fix it?
> 
> That is because 4.6.6 is the most recent version for which there
> is a full set of windows binary files.  But it would be a good idea
> to update the README pointer to direct people to 5.0.0 if they can
> use the files that do exist there.
> 
>     Ethan
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: gnuplot version update on sf.net

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

On Wednesday, 18 February 2015 10:00:07 AM Karl Ratzsch wrote:
> Hi,
> 
> sf.net still advertises v466 as the latest version to windows users, and
> it´s still weekly getting twice as many downloads as v500. I hardly
> believe the users do this intentionally, for the source package the
> ratio is more like 1:10
> 
> Can anyone fix it?

That is because 4.6.6 is the most recent version for which there
is a full set of windows binary files.  But it would be a good idea
to update the README pointer to direct people to 5.0.0 if they can
use the files that do exist there.

	Ethan

gnuplot version update on sf.net

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

Hi,

sf.net still advertises v466 as the latest version to windows users, and
it´s still weekly getting twice as many downloads as v500. I hardly
believe the users do this intentionally, for the source package the
ratio is more like 1:10

Can anyone fix it?

Best, Karl

Re: Problems with while/splot/wxt

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

On Friday, 13 February, 2015 13:37:40 Philipp K. Janert wrote:
> On Fri, 13 Feb 2015 12:52:50 -0800
> Ethan A Merritt <sf...@us...> wrote:
> 
> Wanting to exit a loop (whether it's technically 
> infinite or merely long running) is not a programming 
> error. 
> 
> I think what you are saying is that a user
> should not expect gnuplot to recover gracefully
> if a loop is terminated by other means than the
> loop condition, and that therefore the user
> MUST provide such an exit condition. 

No, what I said was that an external kill signal
(control-C from the terminal in this case) is not
a normal way to interact with a program, and in 
particular is not a normal way to exit a program loop.

Providing an explicit end-loop condition in the "while"
clause is certainly one very common method for normal exit.
Many languages also offer "break" or "goto" or "return".
Gnuplot doesn't currently support break or goto, but 
in a loaded script using "exit" acts as a "return to the 
caller/loader".  So another possible loop would be

  while (1) {
     if (done) exit
     plot <stuff>
  }
  
> I am not sure I follow the logic of your last
> paragraph entirely, though. Why "pause 0.01"?
> Why not "pause 0.0001"? Or "pause 1", for that
> matter?

Why not indeed?  Use whatever seems appropriate.

> How can I (as the user) know what kind 
> of delay is enough for wxt (?) to catch up with 
> gnuplot's core? If gnuplot overflows an internal
> data structure or fails to respond to keyboard
> events, then that's a programming error, not a
> user error. 

I think you misunderstand what is happening.

We're not talking about an internal gnuplot data structure.
We're talking about whatever inter-process communication
protocol is used by the local wxgtk graphics library.
On linux that happens to be libpthread, but I imagine
it's different on Windows or OSX or whatever.
The system will buffer the information sent over that
communications channel, gradually consuming system resources
if the reader doesn't keep up with the writer and the
writer doesn't block.  I suppose eventually you might run
out of memory or disk cache, but it would take a long time.
It's exactly analogous to running this loop after
"set term pdf; set output 'file.pdf'".  Eventually that
output file will use up all your allowed disk space.  
But it's your own fault, not gnuplot's.

When the stop request ('d' keyboard event in my sample script)
is delivered to gnuplot, it stops writing new commands into the
communication channel.  But the channel may still be bloated 
with previously written commands that the reader end will take
some time to process.  Stuffing yet another command into the
channel at the end of the queue to tell the reader end
"you can stop now" will not help.
To forcibly terminate processing by the reader end would require
some out-of-band signal or a more drastic action like
destroying/resetting the communication channel. 

> Or is it a fact that any loop that
> needs to respond to a user event MUST contain
> pause? 

No.  The response is [supposed to be] immediate regardless of
whether the loop contains a pause.  The purpose of the
pause is to prevent gnuplot from running faster than 
your graphics display can keep up with.

> Again: that's totally acceptable - it it's
> communicated as such. Since I did not find that
> info in the docs, I am asking here - where else?

Perhaps the key point to make clear is simply that there
are two "black boxes" involved here.  One is what we (the 
developer's mailing list) usually call the core.  The other
box is the graphics display driver, which depending on the
terminal type may be a separate thread (e.g. wxgtk on linux) or
a separate program (e.g. gnuplot_x11 or gnuplot_qt) or some
more circuitous pathway (gnuplot->[pdf file]->okular).
It is easily possible for the second black box to keep
functioning even after the first one (gnuplot core) is
finished.  That's the normal case for ps/pdf/png/svg output.
It is also possible for qt or x11 if you use the "persist"
option.  You can even reconnect a later gnuplot core session
(black box #1) to the previous but still running output
session (black box #2).

Trying to document what will happen if you use external commands
to clobber one of these boxes seems pointless to me.
If you reach a state where  "killall --signal KILL gnuplot"
is required, the bad stuff has already happened.
If that state is due to a bug then sure, let's try to identify
and fix it.  But responding to the kill signal is not itself a bug.


	Ethan


> Best,
> 
> 		Ph.
> 
> 
> > On Friday, 13 February, 2015 07:02:32 Philipp K. Janert wrote:
> > > 
> > > [snip]
> > > 
> > > > 
> > > > Well what did you expect?
> > > 
> > > I do expect that gnuplot cleans up its own
> > > messes. It is not acceptable to put a program 
> > > (any program) in a totally wedged state through
> > > a series of totally legal commands.
> > 
> > Let's be clear.
> > Control-C is not a normal way to interact with a program.
> > It is an externally-triggered kill switch that in this case
> > you are using to bail out of your own programming error - an
> > infinite loop with no clean exit path.
> > 
> > Gnuplot or indeed any program would be perfectly entitled to
> > exit entirely in response.  
> > 
> > Instead, gnuplot tries to be a little nicer and at least get you back
> > to a command prompt without losing your entire session context.
> > It may not always succeed, in which case a second externally
> > triggered kill signal may complete the job.
> > 
> > If you have suggestions how to detect the infinite loop as
> > a syntax error, that would be helpful.
> > 
> > If you have thoughts about how to design a thread synchonization
> > mutex that is more robust in response to a user killing one of
> > the two threads, that might also be helpful.
> > 
> > Complaining that your foot hurts after you have chosen to 
> > shoot it multiple times in succession is not so helpful.
> > 
> > Here is a more correct version of the loop you intended to write:
> > 
> > spin.gp:
> >   t = 0
> >   done = 0
> >   bind all 'd' "done = 1"
> >   while( !done ) {
> >     t = t + 0.1
> >     splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
> >   }
> > 
> > Now a gnuplot command "load 'spin.gp'" will terminate
> > cleanly when you type a 'd' in the plot window.
> > 
> > Of course there is still the problem that your loop contains
> > no delay, so the display command stream it generates will
> > get longer and longer as it runs. That means the lag between
> > hitting 'd' and exhaustion of the accumulated command stream
> > will increase.  Adding "pause 0.01" to the loop would address this,
> > or perhaps the "load" command could be followed by some
> > cleanup to terminate the current display window and open 
> > a new one.  It depends on what you want.
> > 
> > 	Ethan
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Problems with while/splot/wxt

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

On Fri, 13 Feb 2015 12:52:50 -0800
Ethan A Merritt <sf...@us...> wrote:

Wanting to exit a loop (whether it's technically 
infinite or merely long running) is not a programming 
error. 

I think what you are saying is that a user
should not expect gnuplot to recover gracefully
if a loop is terminated by other means than the
loop condition, and that therefore the user
MUST provide such an exit condition. 

With such a warning in place, I think that's
perfectly acceptable behavior, and could have
been said in just so many words. 

I am not sure I follow the logic of your last
paragraph entirely, though. Why "pause 0.01"?
Why not "pause 0.0001"? Or "pause 1", for that
matter? How can I (as the user) know what kind 
of delay is enough for wxt (?) to catch up with 
gnuplot's core? If gnuplot overflows an internal
data structure or fails to respond to keyboard
events, then that's a programming error, not a
user error. Or is it a fact that any loop that
needs to respond to a user event MUST contain
pause? Again: that's totally acceptable - it it's
communicated as such. Since I did not find that
info in the docs, I am asking here - where else?

Best,

		Ph.


> On Friday, 13 February, 2015 07:02:32 Philipp K. Janert wrote:
> > 
> > [snip]
> > 
> > > 
> > > Well what did you expect?
> > 
> > I do expect that gnuplot cleans up its own
> > messes. It is not acceptable to put a program 
> > (any program) in a totally wedged state through
> > a series of totally legal commands.
> 
> Let's be clear.
> Control-C is not a normal way to interact with a program.
> It is an externally-triggered kill switch that in this case
> you are using to bail out of your own programming error - an
> infinite loop with no clean exit path.
> 
> Gnuplot or indeed any program would be perfectly entitled to
> exit entirely in response.  
> 
> Instead, gnuplot tries to be a little nicer and at least get you back
> to a command prompt without losing your entire session context.
> It may not always succeed, in which case a second externally
> triggered kill signal may complete the job.
> 
> If you have suggestions how to detect the infinite loop as
> a syntax error, that would be helpful.
> 
> If you have thoughts about how to design a thread synchonization
> mutex that is more robust in response to a user killing one of
> the two threads, that might also be helpful.
> 
> Complaining that your foot hurts after you have chosen to 
> shoot it multiple times in succession is not so helpful.
> 
> Here is a more correct version of the loop you intended to write:
> 
> spin.gp:
>   t = 0
>   done = 0
>   bind all 'd' "done = 1"
>   while( !done ) {
>     t = t + 0.1
>     splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
>   }
> 
> Now a gnuplot command "load 'spin.gp'" will terminate
> cleanly when you type a 'd' in the plot window.
> 
> Of course there is still the problem that your loop contains
> no delay, so the display command stream it generates will
> get longer and longer as it runs. That means the lag between
> hitting 'd' and exhaustion of the accumulated command stream
> will increase.  Adding "pause 0.01" to the loop would address this,
> or perhaps the "load" command could be followed by some
> cleanup to terminate the current display window and open 
> a new one.  It depends on what you want.
> 
> 	Ethan

Re: Problems with while/splot/wxt

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

On Friday, 13 February, 2015 07:02:32 Philipp K. Janert wrote:
> 
> [snip]
> 
> > 
> > Well what did you expect?
> 
> I do expect that gnuplot cleans up its own
> messes. It is not acceptable to put a program 
> (any program) in a totally wedged state through
> a series of totally legal commands.

Let's be clear.
Control-C is not a normal way to interact with a program.
It is an externally-triggered kill switch that in this case
you are using to bail out of your own programming error - an
infinite loop with no clean exit path.

Gnuplot or indeed any program would be perfectly entitled to
exit entirely in response.  

Instead, gnuplot tries to be a little nicer and at least get you back
to a command prompt without losing your entire session context.
It may not always succeed, in which case a second externally
triggered kill signal may complete the job.

If you have suggestions how to detect the infinite loop as
a syntax error, that would be helpful.

If you have thoughts about how to design a thread synchonization
mutex that is more robust in response to a user killing one of
the two threads, that might also be helpful.

Complaining that your foot hurts after you have chosen to 
shoot it multiple times in succession is not so helpful.

Here is a more correct version of the loop you intended to write:

spin.gp:
  t = 0
  done = 0
  bind all 'd' "done = 1"
  while( !done ) {
    t = t + 0.1
    splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
  }

Now a gnuplot command "load 'spin.gp'" will terminate
cleanly when you type a 'd' in the plot window.

Of course there is still the problem that your loop contains
no delay, so the display command stream it generates will
get longer and longer as it runs. That means the lag between
hitting 'd' and exhaustion of the accumulated command stream
will increase.  Adding "pause 0.01" to the loop would address this,
or perhaps the "load" command could be followed by some
cleanup to terminate the current display window and open 
a new one.  It depends on what you want.

	Ethan

Re: Problems with while/splot/wxt

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

[snip]

> 
> Well what did you expect?

I do expect that gnuplot cleans up its own
messes. It is not acceptable to put a program 
(any program) in a totally wedged state through
a series of totally legal commands.

[snip]