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

Re: non-color-scaled rgbimage plots

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

On Wednesday, 16 August, 2017 10:24:16 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> >> "noautoscale" applies to the whole plot, does it not?
> >
> > It applies to only one component of the plot at a time.
> > The idea is so you can plot x, y, and z but only scale to fit y.
> > I.e. points from x and z may be outside the range defined by y.
> >
> >   plot 'x' noautoscale, 'y', 'z' noautoscale
> >
> >
> >> I think what would be most appropriate here is some sort of
> >> "origcolors" option applicable only to rgbimage/image data sources.
> >> So autoscaling would still apply, but would ignore "origcolors" data.
> >> Does that make sense?
> >
> > It makes sense for input RGB PNG images, but I am not certain it
> > generalizes.
> >
> > For that matter I'm not clear on what "autoscale" even means for
> > rgbimage data.  For image data it ends up controlling cbrange for
> > the palette mapping.  But for rgb images there is no palette, so
> > what exactly is being scaled?
> 
> I looked at the code, and have a sense of what's being done now.
> "noautoscale" currently does apply to rgbimage and image plots, but it
> only affects the spatial range, NOT the color range. For my use case
> (which is probably the most common use case), I'd want noautorange for
> the colors, but yesautorange for x,y. So how about a new option called
> "nocbautorange" to turn off just the color autoranging?
> 
> As for what's being scaled in palette-less rgbimages, it's the
> intensities of the R,G and B channels, controlled separately, I believe:
> look at the cb2gray() calls in process_image() in graphics.c. I doesn't
> obviously make sense to scale palette-based colors (from data) together
> with palett-less colors (in an rgbimage). Removing that logic entirely
> maybe makes the most sense, but I can imagine there're people out there
> that depend on this functionality, so maybe adding a "nocbautorange" is
> the right thing to do.

I agree that it makes no sense to apply the palette range (cbrange) 
to rgb data.
For example this just seems wrong to me:

    # looks nice
    plot 'nicepicture.jpeg' binary filetype=auto with rgbimage
    # messed up
    set cbrange [50:100]
    replot
    # lost altogether
    set log cb
    replot

So yes, cb2gray() should not be used for RGB data components.
Let's plan to replace it in 5.3 with a new routine rgb2gray(),
exact behaviour to be discussed.

Then the question becomes how or if to autoscale the rgb components.
And if we decide it should be under user control, should it be 
treated as an axis, 
	e.g. set rgbrange[0:255] 
or 3 or 4 separate axes
   e.g. set bluerange [0:1]; set alpharange [0:1] 
or a new set of non-axis commands
   set rgb {autoscale | 8bit_channels | grayscale}
or something else entirely.

If backward compatibility with current behaviour is a concern
(not sure it is in this case), then the default could be
to use the cbrange if the user has not set something else.

> 
> I think I want an option (or options) to
> 
> 1. Ignore rgbimage colors when finding the min/max for the autoscaling
> 
> 2. Ignore the computed cbrange scale when rendering the image: the
>    original image colors should be used instead
> 
> If "nocbautorange" works like "noautorange", it would only do #1, but
> maybe it should also do #2 as a special-case for rgbimage data.

My inclination is not to change the current commands that affect
cbrange, but instead to sever the connection between cbrange and
RGB image components.

Let's add this to the wishlist for 5.3 development.

	Ethan


> For grayscale images, we can read them in explicitly:
> 
>   plot "grayscale.png" binary filetype=auto flipy with image using 1
> 
> These DO end up using a palette, so probably "nocbautorange" should do
> #1, but not #2. If the user just wants to draw a background image, they
> should be instructed to plot this as an rgbimage:
> 
>   plot "grayscale.png" binary filetype=auto flipy with rgbimage
> 
> Makes sense? I'm out of town until next week, so the earliest I can send
> out a patch is late next week.

Re: non-color-scaled rgbimage plots

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

>> "noautoscale" applies to the whole plot, does it not?
>
> It applies to only one component of the plot at a time.
> The idea is so you can plot x, y, and z but only scale to fit y.
> I.e. points from x and z may be outside the range defined by y.
>
>   plot 'x' noautoscale, 'y', 'z' noautoscale
>
>
>> I think what would be most appropriate here is some sort of
>> "origcolors" option applicable only to rgbimage/image data sources.
>> So autoscaling would still apply, but would ignore "origcolors" data.
>> Does that make sense?
>
> It makes sense for input RGB PNG images, but I am not certain it
> generalizes.
>
> For that matter I'm not clear on what "autoscale" even means for
> rgbimage data.  For image data it ends up controlling cbrange for
> the palette mapping.  But for rgb images there is no palette, so
> what exactly is being scaled?

I looked at the code, and have a sense of what's being done now.
"noautoscale" currently does apply to rgbimage and image plots, but it
only affects the spatial range, NOT the color range. For my use case
(which is probably the most common use case), I'd want noautorange for
the colors, but yesautorange for x,y. So how about a new option called
"nocbautorange" to turn off just the color autoranging?

As for what's being scaled in palette-less rgbimages, it's the
intensities of the R,G and B channels, controlled separately, I believe:
look at the cb2gray() calls in process_image() in graphics.c. I doesn't
obviously make sense to scale palette-based colors (from data) together
with palett-less colors (in an rgbimage). Removing that logic entirely
maybe makes the most sense, but I can imagine there're people out there
that depend on this functionality, so maybe adding a "nocbautorange" is
the right thing to do.

I think I want an option (or options) to

1. Ignore rgbimage colors when finding the min/max for the autoscaling

2. Ignore the computed cbrange scale when rendering the image: the
   original image colors should be used instead

If "nocbautorange" works like "noautorange", it would only do #1, but
maybe it should also do #2 as a special-case for rgbimage data.

For grayscale images, we can read them in explicitly:

  plot "grayscale.png" binary filetype=auto flipy with image using 1

These DO end up using a palette, so probably "nocbautorange" should do
#1, but not #2. If the user just wants to draw a background image, they
should be instructed to plot this as an rgbimage:

  plot "grayscale.png" binary filetype=auto flipy with rgbimage

Makes sense? I'm out of town until next week, so the earliest I can send
out a patch is late next week.

Re: Release 5.0.7 [was: test-build tarball for gnuplot 5.0.7]

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

I executed build tests on Cygwin 32 and 64 bit.
Build tests were successful for both Cygwin 32 and 64 bit.

Tatsuro



----- Original Message -----
>From: sfeam <sf...@us...>
>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
>Date: 2017/8/16, Wed 14:00
>Subject: Release 5.0.7 [was: test-build tarball for gnuplot 5.0.7]
> 
>On Tuesday, 15 August 2017 12:22:19 Tatsuro MATSUOKA wrote:
>> I have made changes in wxt_gui.cpp that you shown in patch on the mail on Aug 15 01:24:36 2017.
>> 
>> The changes make 5.0.7 build (and make check) successful on Cygwin 64 bit.
>> 
>> I do not why build was succeeded in 5.0.7 on Cygwin 32 bit without the change.
>
>Thank you for testing.  
>Yes it is unexpected that the 32-bit build would work but not the 64-bit build.
>
>I have applied the patch to wxt_gui.cpp and uploaded the amended source tarball
>gnuplot-5.0.7.tar.gz  to SourceForge.  The only change from the testing tarball
>is the patch to wxt_gui.cpp and the "last modified" date in version.c
>
>    here's to the final release in the 5.0 series!
>
>        Ethan
>
>
>> 
>> At least the note should be added for this build trouble, I think.
>> 
>> Tatsuro
>> 
>> 
>> 
>> ----- Original Message -----
>> >From: Tatsuro MATSUOKA <tma...@ya...>
>> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>> >Date: 2017/8/15, Tue 10:18
>> >Subject: Re: test-build tarball for gnuplot 5.0.7
>> > 
>> >
>> >Perhaps my writing led to confusion.
>> >
>> >For MinGW, there was no problems for 5.0.7 as written on 2017-08-14 05:06:37
>> >FYI, for native windows including MinGW build, wxWidgets does not use GTK but use the windows api functions.
>> >Therefore, GTK problems are not relevant to gnuplot for native windows.
>> >
>> >
>> >I reported the failure for the build in Cygwin but not MinGW.
>> >
>> >
>> >I have not built 5.0.x branches until 5.0.6 although I have been trying to build on cvs branch for a long time.
>> >
>> >The version 5.0.7 is a first try to build gnuplot for 5.0.x on Cygwin.
>> >
>> >However, like unixy platform, wxWidgets depends on GTK on Cygwin.
>> >
>> >As was done in linux, change of GTK2 to GTK3 happened to on Cygwin
>> >and wxWidgets was re-built against the GTK3.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >----- Original Message -----
>> >>From: sfeam <sf...@us...>
>> >>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
>> >>Date: 2017/8/15, Tue 01:24
>> >>Subject: Re: test-build tarball for gnuplot 5.0.7
>> >> 
>> >>On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
>> >>> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.
>> >>
>> >>The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
>> >>It seemed at the time that this was not needed for 5.0 and indeed
>> >>there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.
>> >>
>> >>Do you advise using the current code to release 5.0.7 mingw 32/64 bit builds
>> >>as we did for previous 5.0 versions?
>> >>Or would you prefer to apply the patch before releasing 5.0.7?
>> >>Does the patched version interfere with the raise console operation in your tests? 
>> >>
>> >>    Ethan
>> >>
>> >>--- wxt_gui.cpp    2015/09/01 00:02:44    1.151
>> >>+++ wxt_gui.cpp  
>>  2016/01/04 22:47:18    1.152
>> >>@@ -1,5 +1,5 @@
>> >>/*
>> >>- * $Id: wxt_gui.cpp,v 1.151 2015/09/01 00:02:44 sfeam Exp $
>> >>+ * $Id: wxt_gui.cpp,v 1.152 2016/01/04 22:47:18 sfeam Exp $
>> >>  */
>> >>
>> >>/* GNUPLOT - wxt_gui.cpp */
>> >>@@ -1466,7 +1466,7 @@
>> >>  * to prevent focus stealing) and is inconsistent with global bindings mechanism ) */
>> >>void wxtPanel::RaiseConsoleWindow()
>> >>{
>> >>-#ifdef USE_GTK
>> >>+#if defined(USE_GTK) && (GTK_MAJOR_VERSION == 2)
>> >>    char *window_env;
>> >>    unsigned long windowid = 0;
>> >>    /* retrieve XID of gnuplot window */
>> >>@@ -3167,7 +3167,7 @@
>> >>         * Refresh() also must be called, otherwise
>> >>         * the raise won't happen immediately */
>> >>        window->frame->panel->Refresh(false);
>> >>-  
>>      gdk_window_raise(window->frame->GetHandle()->window);
>> >>+        gdk_window_raise(gtk_widget_get_window(window->frame->GetHandle()));
>> >>#else
>> >>        window->frame->Restore();
>> >>        window->frame->Raise();
>> >>@@ -3180,7 +3180,7 @@
>> >>{
>> >>#ifdef USE_GTK
>> >>    window->frame->panel->Refresh(false);
>> >>-    gdk_window_lower(window->frame->GetHandle()->window);
>> >>+    gdk_window_lower(gtk_widget_get_window(window->frame->GetHandle()));
>> >>#else
>> >>    window->frame->Lower();
>> >>#endif /* USE_GTK */
>> >>
>> >>> 
>> >>> Tatsuro
>> >>> 
>> >>> 
>> >>> 
>> >>> ----- Original Message -----
>> >>> >From: Tatsuro MATSUOKA <tma...@ya...>
>> >>> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>> >>> >Date: 2017/8/14, Mon 19:07
>> >>> >Subject: Re: test-build tarball for gnuplot 5.0.7
>> >>> > 
>> >>> >
>> >>> >I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
>> >>> >For 32 bit, build was in successful.
>> >>> >For 64 bit, build was in failure.
>> >>> >
>> >>> >
>> >>> >gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o
>>  gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
>> >>> >  
>> >>>  gdk_window_raise(gdk_window_foreign_new(windowid));
>> >>> >                                                   ^
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>> >>> >  
>>  gdk_window_raise(window->frame->GetHandle()->window);
>> >>> >                                              
>> >>>  ^
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>> >>> >  gdk_window_lower(window->frame->GetHandle()->window);
>> >>> >                                               ^
>> >>> >make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
>> >>> >make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >>> >make[3]:
>>  *** [Makefile:1027: all-recursive] Error 1
>> >>> >make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >>> >make[2]: *** [Makefile:644: all] Error 2
>> >>> >make[2]:
>> >>>  Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >>> >make[1]: *** [Makefile:419: all-recursive] Error 1
>> >>> >make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
>> >>> >make: *** [Makefile:357: all] Error 2
>> >>> >
>> >>> >
>> >>> >gnuplot.exe was not  built.
>> >>> >
>> >>> >
>> >>> >
>> >>> >Tatsuro
>> >>> >
>> >>> >
>> >>> >----- Original Message -----
>> >>> >>From: sfeam via gnuplot-beta <gnu...@li...>
>> >>>
>>  >>To: gnuplot-beta <gnu...@li...> 
>> >>> >>Date: 2017/8/14, Mon 07:25
>> >>> >>Subject: test-build tarball for gnuplot 5.0.7
>> >>> >> 
>> >>> >>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
>> >>> >>area on SourceForge.
>> >>> >>
>> >>> >>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
>> >>> >>    gp507-buildtestonly.tar.gz
>> >>> >>
>> >>> >>Please use this only to test building and packaging on Windows
>> >>> >>or other platforms.     I will wait for reports of success or problems
>> >>> >>before uploading an official
>>  release of the 5.0.7 source tarball to
>> >>> >>its own separate release directory on
>> >>>  SourceForge.
>> >>> >>
>> >>> >>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
>> >>> >>After this we can concentrate attention on releasing 5.2 and
>> >>> >>continued development in 5.3.
>> >>> >>
>> >>> >>    thanks for testing when you have time (there is no hurry)
>> >>> >>
>> >>> >>        Ethan
>> >>> >>
>> >>> >>
>> >>> >>------------------------------------------------------------------------------
>> >>> >>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
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>
>> >>
>> >>
>> >
>> >
>
>
>
>

Re: Release 5.0.7 [was: test-build tarball for gnuplot 5.0.7]

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

I have built windows binary packages on MinGW platform and uploaded
to the SourceForge site.

Tatsuro



----- Original Message -----
>From: sfeam <sf...@us...>
>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
>Date: 2017/8/16, Wed 14:00
>Subject: Release 5.0.7 [was: test-build tarball for gnuplot 5.0.7]
> 
>On Tuesday, 15 August 2017 12:22:19 Tatsuro MATSUOKA wrote:
>> I have made changes in wxt_gui.cpp that you shown in patch on the mail on Aug 15 01:24:36 2017.
>> 
>> The changes make 5.0.7 build (and make check) successful on Cygwin 64 bit.
>> 
>> I do not why build was succeeded in 5.0.7 on Cygwin 32 bit without the change.
>
>Thank you for testing.  
>Yes it is unexpected that the 32-bit build would work but not the 64-bit build.
>
>I have applied the patch to wxt_gui.cpp and uploaded the amended source tarball
>gnuplot-5.0.7.tar.gz  to SourceForge.  The only change from the testing tarball
>is the patch to wxt_gui.cpp and the "last modified" date in version.c
>
>    here's to the final release in the 5.0 series!
>
>        Ethan
>
>
>> 
>> At least the note should be added for this build trouble, I think.
>> 
>> Tatsuro
>> 
>> 
>> 
>> ----- Original Message -----
>> >From: Tatsuro MATSUOKA <tma...@ya...>
>> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>> >Date: 2017/8/15, Tue 10:18
>> >Subject: Re: test-build tarball for gnuplot 5.0.7
>> > 
>> >
>> >Perhaps my writing led to confusion.
>> >
>> >For MinGW, there was no problems for 5.0.7 as written on 2017-08-14 05:06:37
>> >FYI, for native windows including MinGW build, wxWidgets does not use GTK but use the windows api functions.
>> >Therefore, GTK problems are not relevant to gnuplot for native windows.
>> >
>> >
>> >I reported the failure for the build in Cygwin but not MinGW.
>> >
>> >
>> >I have not built 5.0.x branches until 5.0.6 although I have been trying to build on cvs branch for a long time.
>> >
>> >The version 5.0.7 is a first try to build gnuplot for 5.0.x on Cygwin.
>> >
>> >However, like unixy platform, wxWidgets depends on GTK on Cygwin.
>> >
>> >As was done in linux, change of GTK2 to GTK3 happened to on Cygwin
>> >and wxWidgets was re-built against the GTK3.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >----- Original Message -----
>> >>From: sfeam <sf...@us...>
>> >>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
>> >>Date: 2017/8/15, Tue 01:24
>> >>Subject: Re: test-build tarball for gnuplot 5.0.7
>> >> 
>> >>On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
>> >>> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.
>> >>
>> >>The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
>> >>It seemed at the time that this was not needed for 5.0 and indeed
>> >>there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.
>> >>
>> >>Do you advise using the current code to release 5.0.7 mingw 32/64 bit builds
>> >>as we did for previous 5.0 versions?
>> >>Or would you prefer to apply the patch before releasing 5.0.7?
>> >>Does the patched version interfere with the raise console operation in your tests? 
>> >>
>> >>    Ethan
>> >>
>> >>--- wxt_gui.cpp    2015/09/01 00:02:44    1.151
>> >>+++ wxt_gui.cpp  
>>  2016/01/04 22:47:18    1.152
>> >>@@ -1,5 +1,5 @@
>> >>/*
>> >>- * $Id: wxt_gui.cpp,v 1.151 2015/09/01 00:02:44 sfeam Exp $
>> >>+ * $Id: wxt_gui.cpp,v 1.152 2016/01/04 22:47:18 sfeam Exp $
>> >>  */
>> >>
>> >>/* GNUPLOT - wxt_gui.cpp */
>> >>@@ -1466,7 +1466,7 @@
>> >>  * to prevent focus stealing) and is inconsistent with global bindings mechanism ) */
>> >>void wxtPanel::RaiseConsoleWindow()
>> >>{
>> >>-#ifdef USE_GTK
>> >>+#if defined(USE_GTK) && (GTK_MAJOR_VERSION == 2)
>> >>    char *window_env;
>> >>    unsigned long windowid = 0;
>> >>    /* retrieve XID of gnuplot window */
>> >>@@ -3167,7 +3167,7 @@
>> >>         * Refresh() also must be called, otherwise
>> >>         * the raise won't happen immediately */
>> >>        window->frame->panel->Refresh(false);
>> >>-  
>>      gdk_window_raise(window->frame->GetHandle()->window);
>> >>+        gdk_window_raise(gtk_widget_get_window(window->frame->GetHandle()));
>> >>#else
>> >>        window->frame->Restore();
>> >>        window->frame->Raise();
>> >>@@ -3180,7 +3180,7 @@
>> >>{
>> >>#ifdef USE_GTK
>> >>    window->frame->panel->Refresh(false);
>> >>-    gdk_window_lower(window->frame->GetHandle()->window);
>> >>+    gdk_window_lower(gtk_widget_get_window(window->frame->GetHandle()));
>> >>#else
>> >>    window->frame->Lower();
>> >>#endif /* USE_GTK */
>> >>
>> >>> 
>> >>> Tatsuro
>> >>> 
>> >>> 
>> >>> 
>> >>> ----- Original Message -----
>> >>> >From: Tatsuro MATSUOKA <tma...@ya...>
>> >>> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>> >>> >Date: 2017/8/14, Mon 19:07
>> >>> >Subject: Re: test-build tarball for gnuplot 5.0.7
>> >>> > 
>> >>> >
>> >>> >I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
>> >>> >For 32 bit, build was in successful.
>> >>> >For 64 bit, build was in failure.
>> >>> >
>> >>> >
>> >>> >gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o
>>  gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
>> >>> >  
>> >>>  gdk_window_raise(gdk_window_foreign_new(windowid));
>> >>> >                                                   ^
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>> >>> >  
>>  gdk_window_raise(window->frame->GetHandle()->window);
>> >>> >                                              
>> >>>  ^
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
>> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>> >>> >  gdk_window_lower(window->frame->GetHandle()->window);
>> >>> >                                               ^
>> >>> >make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
>> >>> >make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >>> >make[3]:
>>  *** [Makefile:1027: all-recursive] Error 1
>> >>> >make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >>> >make[2]: *** [Makefile:644: all] Error 2
>> >>> >make[2]:
>> >>>  Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >>> >make[1]: *** [Makefile:419: all-recursive] Error 1
>> >>> >make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
>> >>> >make: *** [Makefile:357: all] Error 2
>> >>> >
>> >>> >
>> >>> >gnuplot.exe was not  built.
>> >>> >
>> >>> >
>> >>> >
>> >>> >Tatsuro
>> >>> >
>> >>> >
>> >>> >----- Original Message -----
>> >>> >>From: sfeam via gnuplot-beta <gnu...@li...>
>> >>>
>>  >>To: gnuplot-beta <gnu...@li...> 
>> >>> >>Date: 2017/8/14, Mon 07:25
>> >>> >>Subject: test-build tarball for gnuplot 5.0.7
>> >>> >> 
>> >>> >>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
>> >>> >>area on SourceForge.
>> >>> >>
>> >>> >>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
>> >>> >>    gp507-buildtestonly.tar.gz
>> >>> >>
>> >>> >>Please use this only to test building and packaging on Windows
>> >>> >>or other platforms.     I will wait for reports of success or problems
>> >>> >>before uploading an official
>>  release of the 5.0.7 source tarball to
>> >>> >>its own separate release directory on
>> >>>  SourceForge.
>> >>> >>
>> >>> >>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
>> >>> >>After this we can concentrate attention on releasing 5.2 and
>> >>> >>continued development in 5.3.
>> >>> >>
>> >>> >>    thanks for testing when you have time (there is no hurry)
>> >>> >>
>> >>> >>        Ethan
>> >>> >>
>> >>> >>
>> >>> >>------------------------------------------------------------------------------
>> >>> >>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
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>
>> >>
>> >>
>> >
>> >
>
>
>
>

Release 5.0.7 [was: test-build tarball for gnuplot 5.0.7]

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

On Tuesday, 15 August 2017 12:22:19 Tatsuro MATSUOKA wrote:
> I have made changes in wxt_gui.cpp that you shown in patch on the mail on Aug 15 01:24:36 2017.
> 
> The changes make 5.0.7 build (and make check) successful on Cygwin 64 bit.
> 
> I do not why build was succeeded in 5.0.7 on Cygwin 32 bit without the change.

Thank you for testing.   
Yes it is unexpected that the 32-bit build would work but not the 64-bit build.

I have applied the patch to wxt_gui.cpp and uploaded the amended source tarball
gnuplot-5.0.7.tar.gz  to SourceForge.  The only change from the testing tarball
is the patch to wxt_gui.cpp and the "last modified" date in version.c

	here's to the final release in the 5.0 series!

		Ethan


> 
> At least the note should be added for this build trouble, I think.
> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
> >From: Tatsuro MATSUOKA <tma...@ya...>
> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
> >Date: 2017/8/15, Tue 10:18
> >Subject: Re: test-build tarball for gnuplot 5.0.7
> > 
> >
> >Perhaps my writing led to confusion.
> >
> >For MinGW, there was no problems for 5.0.7 as written on 2017-08-14 05:06:37
> >FYI, for native windows including MinGW build, wxWidgets does not use GTK but use the windows api functions.
> >Therefore, GTK problems are not relevant to gnuplot for native windows.
> >
> >
> >I reported the failure for the build in Cygwin but not MinGW.
> >
> >
> >I have not built 5.0.x branches until 5.0.6 although I have been trying to build on cvs branch for a long time.
> >
> >The version 5.0.7 is a first try to build gnuplot for 5.0.x on Cygwin.
> >
> >However, like unixy platform, wxWidgets depends on GTK on Cygwin.
> >
> >As was done in linux, change of GTK2 to GTK3 happened to on Cygwin
> >and wxWidgets was re-built against the GTK3.
> >
> >
> >
> >
> >
> >
> >
> >----- Original Message -----
> >>From: sfeam <sf...@us...>
> >>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
> >>Date: 2017/8/15, Tue 01:24
> >>Subject: Re: test-build tarball for gnuplot 5.0.7
> >> 
> >>On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
> >>> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.
> >>
> >>The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
> >>It seemed at the time that this was not needed for 5.0 and indeed
> >>there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.
> >>
> >>Do you advise using the current code to release 5.0.7 mingw 32/64 bit builds
> >>as we did for previous 5.0 versions?
> >>Or would you prefer to apply the patch before releasing 5.0.7?
> >>Does the patched version interfere with the raise console operation in your tests? 
> >>
> >>    Ethan
> >>
> >>--- wxt_gui.cpp    2015/09/01 00:02:44    1.151
> >>+++ wxt_gui.cpp   
>  2016/01/04 22:47:18    1.152
> >>@@ -1,5 +1,5 @@
> >>/*
> >>- * $Id: wxt_gui.cpp,v 1.151 2015/09/01 00:02:44 sfeam Exp $
> >>+ * $Id: wxt_gui.cpp,v 1.152 2016/01/04 22:47:18 sfeam Exp $
> >>  */
> >>
> >>/* GNUPLOT - wxt_gui.cpp */
> >>@@ -1466,7 +1466,7 @@
> >>  * to prevent focus stealing) and is inconsistent with global bindings mechanism ) */
> >>void wxtPanel::RaiseConsoleWindow()
> >>{
> >>-#ifdef USE_GTK
> >>+#if defined(USE_GTK) && (GTK_MAJOR_VERSION == 2)
> >>    char *window_env;
> >>    unsigned long windowid = 0;
> >>    /* retrieve XID of gnuplot window */
> >>@@ -3167,7 +3167,7 @@
> >>         * Refresh() also must be called, otherwise
> >>         * the raise won't happen immediately */
> >>        window->frame->panel->Refresh(false);
> >>-   
>      gdk_window_raise(window->frame->GetHandle()->window);
> >>+        gdk_window_raise(gtk_widget_get_window(window->frame->GetHandle()));
> >>#else
> >>        window->frame->Restore();
> >>        window->frame->Raise();
> >>@@ -3180,7 +3180,7 @@
> >>{
> >>#ifdef USE_GTK
> >>    window->frame->panel->Refresh(false);
> >>-    gdk_window_lower(window->frame->GetHandle()->window);
> >>+    gdk_window_lower(gtk_widget_get_window(window->frame->GetHandle()));
> >>#else
> >>    window->frame->Lower();
> >>#endif /* USE_GTK */
> >>
> >>> 
> >>> Tatsuro
> >>> 
> >>> 
> >>> 
> >>> ----- Original Message -----
> >>> >From: Tatsuro MATSUOKA <tma...@ya...>
> >>> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
> >>> >Date: 2017/8/14, Mon 19:07
> >>> >Subject: Re: test-build tarball for gnuplot 5.0.7
> >>> > 
> >>> >
> >>> >I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
> >>> >For 32 bit, build was in successful.
> >>> >For 64 bit, build was in failure.
> >>> >
> >>> >
> >>> >gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o
>  gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
> >>> >  
> >>>  gdk_window_raise(gdk_window_foreign_new(windowid));
> >>> >                                                   ^
> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
> >>> >  
>  gdk_window_raise(window->frame->GetHandle()->window);
> >>> >                                              
> >>>  ^
> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
> >>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
> >>> >  gdk_window_lower(window->frame->GetHandle()->window);
> >>> >                                               ^
> >>> >make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
> >>> >make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
> >>> >make[3]:
>  *** [Makefile:1027: all-recursive] Error 1
> >>> >make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
> >>> >make[2]: *** [Makefile:644: all] Error 2
> >>> >make[2]:
> >>>  Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
> >>> >make[1]: *** [Makefile:419: all-recursive] Error 1
> >>> >make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
> >>> >make: *** [Makefile:357: all] Error 2
> >>> >
> >>> >
> >>> >gnuplot.exe was not  built.
> >>> >
> >>> >
> >>> >
> >>> >Tatsuro
> >>> >
> >>> >
> >>> >----- Original Message -----
> >>> >>From: sfeam via gnuplot-beta <gnu...@li...>
> >>>
>  >>To: gnuplot-beta <gnu...@li...> 
> >>> >>Date: 2017/8/14, Mon 07:25
> >>> >>Subject: test-build tarball for gnuplot 5.0.7
> >>> >> 
> >>> >>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
> >>> >>area on SourceForge.
> >>> >>
> >>> >>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
> >>> >>    gp507-buildtestonly.tar.gz
> >>> >>
> >>> >>Please use this only to test building and packaging on Windows
> >>> >>or other platforms.     I will wait for reports of success or problems
> >>> >>before uploading an official
>  release of the 5.0.7 source tarball to
> >>> >>its own separate release directory on
> >>>  SourceForge.
> >>> >>
> >>> >>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
> >>> >>After this we can concentrate attention on releasing 5.2 and
> >>> >>continued development in 5.3.
> >>> >>
> >>> >>    thanks for testing when you have time (there is no hurry)
> >>> >>
> >>> >>        Ethan
> >>> >>
> >>> >>
> >>> >>------------------------------------------------------------------------------
> >>> >>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
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>
> >>
> >>
> >
> >

Re: non-color-scaled rgbimage plots

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

>> > Right now the program ignores the "noautoscale" keyword for image plots.
>> > I'm not sure what would happen if that were to change.
>> > If you experiment with the code, that's where I suggest starting.
>>
>> "noautoscale" applies to the whole plot, does it not?
>
> It applies to only one component of the plot at a time.
> The idea is so you can plot x, y, and z but only scale to fit y.
> I.e. points from x and z may be outside the range defined by y.
>
>   plot 'x' noautoscale, 'y', 'z' noautoscale

Interesting. The documentation describes the per-axis usage, but not the
per-data usage that you mention here. This is clearly the appropriate
option to hook into.


> It makes sense for input RGB PNG images, but I am not certain it
> generalizes.
>
> For that matter I'm not clear on what "autoscale" even means for
> rgbimage data.  For image data it ends up controlling cbrange for
> the palette mapping.  But for rgb images there is no palette, so
> what exactly is being scaled?
>
> This is not a part of the code that I know very well.
> Right now I don't have any opinion on it because I don't really
> understand what it does now or what the other options might be.

OK. I'll take a look. For what it's worth, my images actually ARE
grayscale, but plotting them "with rgbimage" works while "with image"
does not. I'll look.

Thanks for the pointers.

Re: non-color-scaled rgbimage plots

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

On Tuesday, 15 August, 2017 12:39:23 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > On Monday, 14 August 2017 21:13:00 Dima Kogan wrote:
> >> Hi. These days a common plotting use case for me is to draw an image
> >> from a file, with some data plotted on top of it. I do something like
> >> this:
> >>
> >>   plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...
> >>
> >> This works OK. There's an annoyance however: the points in "yyy" have a
> >> 3rd column, rendered as a color, and I want gnuplot to autoscale these
> >> colors. But the pixels in "xxx.png" also have colors and gnuplot
> >> interprets these colors as data too, and these 0-255 color values are
> >> included in the autoscaling along with the 3rd column in "yyy". So for
> >> instance, if the 3rd column in "yyy" is in [0-1], then the image is
> >> plotted normally, but the "yyy" points all look black. Conversely, if
> >> the points in "yyy" are in [10000-20000], then the points all look
> >> yellow and the image is all black.
> >>
> >> Is there a way to instruct gnuplot to just plot the image as is, without
> >> trying to interpret the pixel colors as data? If not, can we add such an
> >> option? The current behavior is definitely good for some use cases, but
> >> not for all of them.
> >
> > Right now the program ignores the "noautoscale" keyword for image plots.
> > I'm not sure what would happen if that were to change.
> > If you experiment with the code, that's where I suggest starting.
> 
> "noautoscale" applies to the whole plot, does it not? 

It applies to only one component of the plot at a time.
The idea is so you can plot x, y, and z but only scale to fit y.
I.e. points from x and z may be outside the range defined by y.

  plot 'x' noautoscale, 'y', 'z' noautoscale 


> I think what would
> be most appropriate here is some sort of "origcolors" option applicable
> only to rgbimage/image data sources. So autoscaling would still apply,
> but would ignore "origcolors" data. Does that make sense?

It makes sense for input RGB PNG images, but I am not certain it generalizes.

For that matter I'm not clear on what "autoscale" even means for
rgbimage data.  For image data it ends up controlling cbrange for
the palette mapping.  But for rgb images there is no palette, so
what exactly is being scaled?

This is not a part of the code that I know very well.
Right now I don't have any opinion on it because I don't really
understand what it does now or what the other options might be.


	Ethan

Re: non-color-scaled rgbimage plots

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> On Monday, 14 August 2017 21:13:00 Dima Kogan wrote:
>> Hi. These days a common plotting use case for me is to draw an image
>> from a file, with some data plotted on top of it. I do something like
>> this:
>>
>>   plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...
>>
>> This works OK. There's an annoyance however: the points in "yyy" have a
>> 3rd column, rendered as a color, and I want gnuplot to autoscale these
>> colors. But the pixels in "xxx.png" also have colors and gnuplot
>> interprets these colors as data too, and these 0-255 color values are
>> included in the autoscaling along with the 3rd column in "yyy". So for
>> instance, if the 3rd column in "yyy" is in [0-1], then the image is
>> plotted normally, but the "yyy" points all look black. Conversely, if
>> the points in "yyy" are in [10000-20000], then the points all look
>> yellow and the image is all black.
>>
>> Is there a way to instruct gnuplot to just plot the image as is, without
>> trying to interpret the pixel colors as data? If not, can we add such an
>> option? The current behavior is definitely good for some use cases, but
>> not for all of them.
>
> Right now the program ignores the "noautoscale" keyword for image plots.
> I'm not sure what would happen if that were to change.
> If you experiment with the code, that's where I suggest starting.

"noautoscale" applies to the whole plot, does it not? I think what would
be most appropriate here is some sort of "origcolors" option applicable
only to rgbimage/image data sources. So autoscaling would still apply,
but would ignore "origcolors" data. Does that make sense?

Re: non-color-scaled rgbimage plots

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

On Monday, 14 August 2017 21:13:00 Dima Kogan wrote:
> Hi. These days a common plotting use case for me is to draw an image
> from a file, with some data plotted on top of it. I do something like
> this:
> 
>   plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...
> 
> This works OK. There's an annoyance however: the points in "yyy" have a
> 3rd column, rendered as a color, and I want gnuplot to autoscale these
> colors. But the pixels in "xxx.png" also have colors and gnuplot
> interprets these colors as data too, and these 0-255 color values are
> included in the autoscaling along with the 3rd column in "yyy". So for
> instance, if the 3rd column in "yyy" is in [0-1], then the image is
> plotted normally, but the "yyy" points all look black. Conversely, if
> the points in "yyy" are in [10000-20000], then the points all look
> yellow and the image is all black.
> 
> Is there a way to instruct gnuplot to just plot the image as is, without
> trying to interpret the pixel colors as data? If not, can we add such an
> option? The current behavior is definitely good for some use cases, but
> not for all of them.

gnuplot> stats 'yyy' using 3 prefix "COLOR"
gnuplot> plot 'xxx.png' binary filetype=auto with rgbimage, \
                'yyy' using 1:2:($3 * 255./COLOR_max) with points


This is not ideal since the color axis is still labeled [0:255]


Right now the program ignores the "noautoscale" keyword for image plots.
I'm not sure what would happen if that were to change.
If you experiment with the code, that's where I suggest starting.

	Ethan

non-color-scaled rgbimage plots

[Dima K. <gn...@di...>]

Hi. These days a common plotting use case for me is to draw an image
from a file, with some data plotted on top of it. I do something like
this:

  plot "xxx.png" binary filetype=auto flipy with rgbimage, "yyy" with points palette, ...

This works OK. There's an annoyance however: the points in "yyy" have a
3rd column, rendered as a color, and I want gnuplot to autoscale these
colors. But the pixels in "xxx.png" also have colors and gnuplot
interprets these colors as data too, and these 0-255 color values are
included in the autoscaling along with the 3rd column in "yyy". So for
instance, if the 3rd column in "yyy" is in [0-1], then the image is
plotted normally, but the "yyy" points all look black. Conversely, if
the points in "yyy" are in [10000-20000], then the points all look
yellow and the image is all black.

Is there a way to instruct gnuplot to just plot the image as is, without
trying to interpret the pixel colors as data? If not, can we add such an
option? The current behavior is definitely good for some use cases, but
not for all of them.

Re: test-build tarball for gnuplot 5.0.7

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

I have made changes in wxt_gui.cpp that you shown in patch on the mail on Aug 15 01:24:36 2017.

The changes make 5.0.7 build (and make check) successful on Cygwin 64 bit.

I do not why build was succeeded in 5.0.7 on Cygwin 32 bit without the change.

At least the note should be added for this build trouble, I think.

Tatsuro



----- Original Message -----
>From: Tatsuro MATSUOKA <tma...@ya...>
>To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>Date: 2017/8/15, Tue 10:18
>Subject: Re: test-build tarball for gnuplot 5.0.7
> 
>
>Perhaps my writing led to confusion.
>
>For MinGW, there was no problems for 5.0.7 as written on 2017-08-14 05:06:37
>FYI, for native windows including MinGW build, wxWidgets does not use GTK but use the windows api functions.
>Therefore, GTK problems are not relevant to gnuplot for native windows.
>
>
>I reported the failure for the build in Cygwin but not MinGW.
>
>
>I have not built 5.0.x branches until 5.0.6 although I have been trying to build on cvs branch for a long time.
>
>The version 5.0.7 is a first try to build gnuplot for 5.0.x on Cygwin.
>
>However, like unixy platform, wxWidgets depends on GTK on Cygwin.
>
>As was done in linux, change of GTK2 to GTK3 happened to on Cygwin
>and wxWidgets was re-built against the GTK3.
>
>
>
>
>
>
>
>----- Original Message -----
>>From: sfeam <sf...@us...>
>>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
>>Date: 2017/8/15, Tue 01:24
>>Subject: Re: test-build tarball for gnuplot 5.0.7
>> 
>>On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
>>> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.
>>
>>The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
>>It seemed at the time that this was not needed for 5.0 and indeed
>>there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.
>>
>>Do you advise using the current code to release 5.0.7 mingw 32/64 bit builds
>>as we did for previous 5.0 versions?
>>Or would you prefer to apply the patch before releasing 5.0.7?
>>Does the patched version interfere with the raise console operation in your tests? 
>>
>>    Ethan
>>
>>--- wxt_gui.cpp    2015/09/01 00:02:44    1.151
>>+++ wxt_gui.cpp   
 2016/01/04 22:47:18    1.152
>>@@ -1,5 +1,5 @@
>>/*
>>- * $Id: wxt_gui.cpp,v 1.151 2015/09/01 00:02:44 sfeam Exp $
>>+ * $Id: wxt_gui.cpp,v 1.152 2016/01/04 22:47:18 sfeam Exp $
>>  */
>>
>>/* GNUPLOT - wxt_gui.cpp */
>>@@ -1466,7 +1466,7 @@
>>  * to prevent focus stealing) and is inconsistent with global bindings mechanism ) */
>>void wxtPanel::RaiseConsoleWindow()
>>{
>>-#ifdef USE_GTK
>>+#if defined(USE_GTK) && (GTK_MAJOR_VERSION == 2)
>>    char *window_env;
>>    unsigned long windowid = 0;
>>    /* retrieve XID of gnuplot window */
>>@@ -3167,7 +3167,7 @@
>>         * Refresh() also must be called, otherwise
>>         * the raise won't happen immediately */
>>        window->frame->panel->Refresh(false);
>>-   
     gdk_window_raise(window->frame->GetHandle()->window);
>>+        gdk_window_raise(gtk_widget_get_window(window->frame->GetHandle()));
>>#else
>>        window->frame->Restore();
>>        window->frame->Raise();
>>@@ -3180,7 +3180,7 @@
>>{
>>#ifdef USE_GTK
>>    window->frame->panel->Refresh(false);
>>-    gdk_window_lower(window->frame->GetHandle()->window);
>>+    gdk_window_lower(gtk_widget_get_window(window->frame->GetHandle()));
>>#else
>>    window->frame->Lower();
>>#endif /* USE_GTK */
>>
>>> 
>>> Tatsuro
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> >From: Tatsuro MATSUOKA <tma...@ya...>
>>> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>>> >Date: 2017/8/14, Mon 19:07
>>> >Subject: Re: test-build tarball for gnuplot 5.0.7
>>> > 
>>> >
>>> >I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
>>> >For 32 bit, build was in successful.
>>> >For 64 bit, build was in failure.
>>> >
>>> >
>>> >gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o
 gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
>>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
>>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
>>> >  
>>>  gdk_window_raise(gdk_window_foreign_new(windowid));
>>> >                                                   ^
>>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
>>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>>> >  
 gdk_window_raise(window->frame->GetHandle()->window);
>>> >                                              
>>>  ^
>>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
>>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>>> >  gdk_window_lower(window->frame->GetHandle()->window);
>>> >                                               ^
>>> >make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
>>> >make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>>> >make[3]:
 *** [Makefile:1027: all-recursive] Error 1
>>> >make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>>> >make[2]: *** [Makefile:644: all] Error 2
>>> >make[2]:
>>>  Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>>> >make[1]: *** [Makefile:419: all-recursive] Error 1
>>> >make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
>>> >make: *** [Makefile:357: all] Error 2
>>> >
>>> >
>>> >gnuplot.exe was not  built.
>>> >
>>> >
>>> >
>>> >Tatsuro
>>> >
>>> >
>>> >----- Original Message -----
>>> >>From: sfeam via gnuplot-beta <gnu...@li...>
>>>
 >>To: gnuplot-beta <gnu...@li...> 
>>> >>Date: 2017/8/14, Mon 07:25
>>> >>Subject: test-build tarball for gnuplot 5.0.7
>>> >> 
>>> >>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
>>> >>area on SourceForge.
>>> >>
>>> >>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
>>> >>    gp507-buildtestonly.tar.gz
>>> >>
>>> >>Please use this only to test building and packaging on Windows
>>> >>or other platforms.     I will wait for reports of success or problems
>>> >>before uploading an official
 release of the 5.0.7 source tarball to
>>> >>its own separate release directory on
>>>  SourceForge.
>>> >>
>>> >>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
>>> >>After this we can concentrate attention on releasing 5.2 and
>>> >>continued development in 5.3.
>>> >>
>>> >>    thanks for testing when you have time (there is no hurry)
>>> >>
>>> >>        Ethan
>>> >>
>>> >>
>>> >>------------------------------------------------------------------------------
>>> >>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
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>
>>
>>
>
>

Re: test-build tarball for gnuplot 5.0.7

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

Perhaps my writing led to confusion.

For MinGW, there was no problems for 5.0.7 as written on 2017-08-14 05:06:37
FYI, for native windows including MinGW build, wxWidgets does not use GTK but use the windows api functions.
Therefore, GTK problems are not relevant to gnuplot for native windows.

I reported the failure for the build in Cygwin but not MinGW.

I have not built 5.0.x branches until 5.0.6 although I have been trying to build on cvs branch for a long time.

The version 5.0.7 is a first try to build gnuplot for 5.0.x on Cygwin.
However, like unixy platform, wxWidgets depends on GTK on Cygwin.

As was done in linux, change of GTK2 to GTK3 happened to on Cygwin
and wxWidgets was re-built against the GTK3.





----- Original Message -----
>From: sfeam <sf...@us...>
>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
>Date: 2017/8/15, Tue 01:24
>Subject: Re: test-build tarball for gnuplot 5.0.7
> 
>On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
>> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.
>
>The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
>It seemed at the time that this was not needed for 5.0 and indeed
>there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.
>
>Do you advise using the current code to release 5.0.7 mingw 32/64 bit builds
>as we did for previous 5.0 versions?
>Or would you prefer to apply the patch before releasing 5.0.7?
>Does the patched version interfere with the raise console operation in your tests? 
>
>    Ethan
>
>--- wxt_gui.cpp    2015/09/01 00:02:44    1.151
>+++ wxt_gui.cpp    2016/01/04 22:47:18    1.152
>@@ -1,5 +1,5 @@
>/*
>- * $Id: wxt_gui.cpp,v 1.151 2015/09/01 00:02:44 sfeam Exp $
>+ * $Id: wxt_gui.cpp,v 1.152 2016/01/04 22:47:18 sfeam Exp $
>  */
>
>/* GNUPLOT - wxt_gui.cpp */
>@@ -1466,7 +1466,7 @@
>  * to prevent focus stealing) and is inconsistent with global bindings mechanism ) */
>void wxtPanel::RaiseConsoleWindow()
>{
>-#ifdef USE_GTK
>+#if defined(USE_GTK) && (GTK_MAJOR_VERSION == 2)
>    char *window_env;
>    unsigned long windowid = 0;
>    /* retrieve XID of gnuplot window */
>@@ -3167,7 +3167,7 @@
>         * Refresh() also must be called, otherwise
>         * the raise won't happen immediately */
>        window->frame->panel->Refresh(false);
>-        gdk_window_raise(window->frame->GetHandle()->window);
>+        gdk_window_raise(gtk_widget_get_window(window->frame->GetHandle()));
>#else
>        window->frame->Restore();
>        window->frame->Raise();
>@@ -3180,7 +3180,7 @@
>{
>#ifdef USE_GTK
>    window->frame->panel->Refresh(false);
>-    gdk_window_lower(window->frame->GetHandle()->window);
>+    gdk_window_lower(gtk_widget_get_window(window->frame->GetHandle()));
>#else
>    window->frame->Lower();
>#endif /* USE_GTK */
>
>> 
>> Tatsuro
>> 
>> 
>> 
>> ----- Original Message -----
>> >From: Tatsuro MATSUOKA <tma...@ya...>
>> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>> >Date: 2017/8/14, Mon 19:07
>> >Subject: Re: test-build tarball for gnuplot 5.0.7
>> > 
>> >
>> >I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
>> >For 32 bit, build was in successful.
>> >For 64 bit, build was in failure.
>> >
>> >
>> >gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
>> >  
>>  gdk_window_raise(gdk_window_foreign_new(windowid));
>> >                                                   ^
>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>> >   gdk_window_raise(window->frame->GetHandle()->window);
>> >                                              
>>  ^
>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
>> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>> >  gdk_window_lower(window->frame->GetHandle()->window);
>> >                                               ^
>> >make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
>> >make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >make[3]: *** [Makefile:1027: all-recursive] Error 1
>> >make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >make[2]: *** [Makefile:644: all] Error 2
>> >make[2]:
>>  Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>> >make[1]: *** [Makefile:419: all-recursive] Error 1
>> >make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
>> >make: *** [Makefile:357: all] Error 2
>> >
>> >
>> >gnuplot.exe was not  built.
>> >
>> >
>> >
>> >Tatsuro
>> >
>> >
>> >----- Original Message -----
>> >>From: sfeam via gnuplot-beta <gnu...@li...>
>> >>To: gnuplot-beta <gnu...@li...> 
>> >>Date: 2017/8/14, Mon 07:25
>> >>Subject: test-build tarball for gnuplot 5.0.7
>> >> 
>> >>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
>> >>area on SourceForge.
>> >>
>> >>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
>> >>    gp507-buildtestonly.tar.gz
>> >>
>> >>Please use this only to test building and packaging on Windows
>> >>or other platforms.     I will wait for reports of success or problems
>> >>before uploading an official release of the 5.0.7 source tarball to
>> >>its own separate release directory on
>>  SourceForge.
>> >>
>> >>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
>> >>After this we can concentrate attention on releasing 5.2 and
>> >>continued development in 5.3.
>> >>
>> >>    thanks for testing when you have time (there is no hurry)
>> >>
>> >>        Ethan
>> >>
>> >>
>> >>------------------------------------------------------------------------------
>> >>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
>> >>
>> >>
>> >>
>> >
>> >
>
>
>

Re: test-build tarball for gnuplot 5.0.7

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

On Monday, 14 August 2017 18:38:26 Mojca Miklavec wrote:
> On 14 August 2017 at 18:24, sfeam via gnuplot-beta wrote:
> > On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
> >> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.
> >
> > The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
> > It seemed at the time that this was not needed for 5.0 and indeed
> > there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.
> 
> It could be that cygwin upgraded GTK in the meantime and none of the
> users of gnuplot 5.0 actually tested it against GTK 3. It's just
> speculation though, I didn't run any tests.
> 
> I don't see why that patch would be any less useful for 5.0 than it is for 5.2.
> 
> Mojca

I could be wrong since I'm only looking at the code rather than actually
running it, but it appears to me that after applying the patch anyone
using GTK3 will lose the "raise console" functionality.   Is that not true
for the mingw build, or is it just that the mingw build is still using GTK2?

I'm OK with that but people keep telling me it is need for Windows.

	Ethan

Re: test-build tarball for gnuplot 5.0.7

[Mojca M. <moj...@gm...>]

On 14 August 2017 at 18:24, sfeam via gnuplot-beta wrote:
> On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
>> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.
>
> The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
> It seemed at the time that this was not needed for 5.0 and indeed
> there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.

It could be that cygwin upgraded GTK in the meantime and none of the
users of gnuplot 5.0 actually tested it against GTK 3. It's just
speculation though, I didn't run any tests.

I don't see why that patch would be any less useful for 5.0 than it is for 5.2.

Mojca

Re: test-build tarball for gnuplot 5.0.7

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

On Monday, 14 August 2017 19:22:44 Tatsuro MATSUOKA wrote:
> I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.

The patch below was applied to 5.2/5.3 in January 2016 to address this issue.
It seemed at the time that this was not needed for 5.0 and indeed
there have been 4 releases 5.0.3 5.0.4 5.0.5 and 5.0.6 since then without it.

Do you advise using the current code to release 5.0.7 mingw 32/64 bit builds
as we did for previous 5.0 versions?
Or would you prefer to apply the patch before releasing 5.0.7?
Does the patched version interfere with the raise console operation in your tests? 

	Ethan

--- wxt_gui.cpp	2015/09/01 00:02:44	1.151
+++ wxt_gui.cpp	2016/01/04 22:47:18	1.152
@@ -1,5 +1,5 @@
 /*
- * $Id: wxt_gui.cpp,v 1.151 2015/09/01 00:02:44 sfeam Exp $
+ * $Id: wxt_gui.cpp,v 1.152 2016/01/04 22:47:18 sfeam Exp $
  */
 
 /* GNUPLOT - wxt_gui.cpp */
@@ -1466,7 +1466,7 @@
  * to prevent focus stealing) and is inconsistent with global bindings mechanism ) */
 void wxtPanel::RaiseConsoleWindow()
 {
-#ifdef USE_GTK
+#if defined(USE_GTK) && (GTK_MAJOR_VERSION == 2)
 	char *window_env;
 	unsigned long windowid = 0;
 	/* retrieve XID of gnuplot window */
@@ -3167,7 +3167,7 @@
 		 * Refresh() also must be called, otherwise
 		 * the raise won't happen immediately */
 		window->frame->panel->Refresh(false);
-		gdk_window_raise(window->frame->GetHandle()->window);
+		gdk_window_raise(gtk_widget_get_window(window->frame->GetHandle()));
 #else
 		window->frame->Restore();
 		window->frame->Raise();
@@ -3180,7 +3180,7 @@
 {
 #ifdef USE_GTK
 	window->frame->panel->Refresh(false);
-	gdk_window_lower(window->frame->GetHandle()->window);
+	gdk_window_lower(gtk_widget_get_window(window->frame->GetHandle()));
 #else
 	window->frame->Lower();
 #endif /* USE_GTK */

> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
> >From: Tatsuro MATSUOKA <tma...@ya...>
> >To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
> >Date: 2017/8/14, Mon 19:07
> >Subject: Re: test-build tarball for gnuplot 5.0.7
> > 
> >
> >I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
> >For 32 bit, build was in successful.
> >For 64 bit, build was in failure.
> >
> >
> >gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
> >  
>  gdk_window_raise(gdk_window_foreign_new(windowid));
> >                                                   ^
> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
> >   gdk_window_raise(window->frame->GetHandle()->window);
> >                                               
>  ^
> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
> >../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
> >  gdk_window_lower(window->frame->GetHandle()->window);
> >                                               ^
> >make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
> >make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
> >make[3]: *** [Makefile:1027: all-recursive] Error 1
> >make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
> >make[2]: *** [Makefile:644: all] Error 2
> >make[2]:
>  Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
> >make[1]: *** [Makefile:419: all-recursive] Error 1
> >make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
> >make: *** [Makefile:357: all] Error 2
> >
> >
> >gnuplot.exe was not  built.
> >
> >
> >
> >Tatsuro
> >
> >
> >----- Original Message -----
> >>From: sfeam via gnuplot-beta <gnu...@li...>
> >>To: gnuplot-beta <gnu...@li...> 
> >>Date: 2017/8/14, Mon 07:25
> >>Subject: test-build tarball for gnuplot 5.0.7
> >> 
> >>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
> >>area on SourceForge.
> >>
> >>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
> >>    gp507-buildtestonly.tar.gz
> >>
> >>Please use this only to test building and packaging on Windows
> >>or other platforms.     I will wait for reports of success or problems
> >>before uploading an official release of the 5.0.7 source tarball to
> >>its own separate release directory on
>  SourceForge.
> >>
> >>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
> >>After this we can concentrate attention on releasing 5.2 and
> >>continued development in 5.3.
> >>
> >>    thanks for testing when you have time (there is no hurry)
> >>
> >>        Ethan
> >>
> >>
> >>------------------------------------------------------------------------------
> >>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
> >>
> >>
> >>
> >
> >

Re: test-build tarball for gnuplot 5.0.7

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

I note that I can build gnuplot 5.3 on cygwin 32 and 64 bit.

Tatsuro



----- Original Message -----
>From: Tatsuro MATSUOKA <tma...@ya...>
>To: Merritt Ethan <sf...@us...>; gnu...@li...; tma...@ya... 
>Date: 2017/8/14, Mon 19:07
>Subject: Re: test-build tarball for gnuplot 5.0.7
> 
>
>I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
>For 32 bit, build was in successful.
>For 64 bit, build was in failure.
>
>
>gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
>../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
>../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
>  
 gdk_window_raise(gdk_window_foreign_new(windowid));
>                                                   ^
>../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
>../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>   gdk_window_raise(window->frame->GetHandle()->window);
>                                               
 ^
>../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
>../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
>  gdk_window_lower(window->frame->GetHandle()->window);
>                                               ^
>make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
>make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>make[3]: *** [Makefile:1027: all-recursive] Error 1
>make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>make[2]: *** [Makefile:644: all] Error 2
>make[2]:
 Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
>make[1]: *** [Makefile:419: all-recursive] Error 1
>make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
>make: *** [Makefile:357: all] Error 2
>
>
>gnuplot.exe was not  built.
>
>
>
>Tatsuro
>
>
>----- Original Message -----
>>From: sfeam via gnuplot-beta <gnu...@li...>
>>To: gnuplot-beta <gnu...@li...> 
>>Date: 2017/8/14, Mon 07:25
>>Subject: test-build tarball for gnuplot 5.0.7
>> 
>>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
>>area on SourceForge.
>>
>>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
>>    gp507-buildtestonly.tar.gz
>>
>>Please use this only to test building and packaging on Windows
>>or other platforms.     I will wait for reports of success or problems
>>before uploading an official release of the 5.0.7 source tarball to
>>its own separate release directory on
 SourceForge.
>>
>>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
>>After this we can concentrate attention on releasing 5.2 and
>>continued development in 5.3.
>>
>>    thanks for testing when you have time (there is no hurry)
>>
>>        Ethan
>>
>>
>>------------------------------------------------------------------------------
>>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
>>
>>
>>
>
>

Re: test-build tarball for gnuplot 5.0.7

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

I tried to build 5.0.7 on the Cygwin 32 and 64 bits.
For 32 bit, build was in successful.
For 64 bit, build was in failure.

gcc  -g -O2  -L/usr/local/lib -lcerf -o gnuplot_x11.exe gnuplot_x11-gplt_x11.o gnuplot_x11-gpexecute.o gnuplot_x11-getcolor.o gnuplot_x11-version.o -lX11  -lcaca -lcerf  -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 -lintl
../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In member function 'void wxtPanel::RaiseConsoleWindow()':
../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:1552:51: error: 'gdk_window_foreign_new' was not declared in this scope
   gdk_window_raise(gdk_window_foreign_new(windowid));
                                                   ^
../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_raise_window(wxt_window_t*, bool)':
../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3123:48: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
   gdk_window_raise(window->frame->GetHandle()->window);
                                                ^
../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp: In function 'void wxt_lower_window(wxt_window_t*)':
../../gnuplot-5.0.7/src/wxterminal/wxt_gui.cpp:3141:47: error: 'GtkWidget {aka struct _GtkWidget}' has no member named 'window'
  gdk_window_lower(window->frame->GetHandle()->window);
                                               ^
make[4]: *** [Makefile:984: wxterminal/wxt_gui.o] Error 1
make[4]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
make[3]: *** [Makefile:1027: all-recursive] Error 1
make[3]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
make[2]: *** [Makefile:644: all] Error 2
make[2]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release/src'
make[1]: *** [Makefile:419: all-recursive] Error 1
make[1]: Leaving directory '/cygdrive/d/usr/Tatsu/cyg64work/gnuplot/5.0.7-test/build-release'
make: *** [Makefile:357: all] Error 2


gnuplot.exe was not  built.


Tatsuro


----- Original Message -----
>From: sfeam via gnuplot-beta <gnu...@li...>
>To: gnuplot-beta <gnu...@li...> 
>Date: 2017/8/14, Mon 07:25
>Subject: test-build tarball for gnuplot 5.0.7
> 
>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
>area on SourceForge.
>
>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
>    gp507-buildtestonly.tar.gz
>
>Please use this only to test building and packaging on Windows
>or other platforms.     I will wait for reports of success or problems
>before uploading an official release of the 5.0.7 source tarball to
>its own separate release directory on SourceForge.
>
>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
>After this we can concentrate attention on releasing 5.2 and
>continued development in 5.3.
>
>    thanks for testing when you have time (there is no hurry)
>
>        Ethan
>
>
>------------------------------------------------------------------------------
>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
>
>
>

Re: test-build tarball for gnuplot 5.0.7

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

I have built windows binary packages using the source tar ball.
Build, packaging, all.dem processes were fine for both 32 and 64 bit.

Tatsuro



----- Original Message -----
>From: sfeam via gnuplot-beta <gnu...@li...>
>To: gnuplot-beta <gnu...@li...> 
>Date: 2017/8/14, Mon 07:25
>Subject: test-build tarball for gnuplot 5.0.7
> 
>I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
>area on SourceForge.
>
>https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
>    gp507-buildtestonly.tar.gz
>
>Please use this only to test building and packaging on Windows
>or other platforms.     I will wait for reports of success or problems
>before uploading an official release of the 5.0.7 source tarball to
>its own separate release directory on SourceForge.
>
>gnuplot 5.0.7 will probably be the last release in the 5.0 series.
>After this we can concentrate attention on releasing 5.2 and
>continued development in 5.3.
>
>    thanks for testing when you have time (there is no hurry)
>
>        Ethan
>
>
>------------------------------------------------------------------------------
>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
>
>
>

test-build tarball for gnuplot 5.0.7

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

I have uploaded a tarball for 5.0.7 to the "5.0 Release Candidates" 
area on SourceForge.

https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
	gp507-buildtestonly.tar.gz

Please use this only to test building and packaging on Windows
or other platforms.     I will wait for reports of success or problems
before uploading an official release of the 5.0.7 source tarball to
its own separate release directory on SourceForge.

gnuplot 5.0.7 will probably be the last release in the 5.0 series.
After this we can concentrate attention on releasing 5.2 and
continued development in 5.3.

	thanks for testing when you have time (there is no hurry)

		Ethan

Re: Version 5.2 release candidate -rc3

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

On Saturday, 05 August 2017 00:24:37 Petr Mikulik wrote:
> > On Friday, 04 August 2017 17:12:47 Petr Mikulik wrote:
> >>> Source tarball for -rc3 in now in the "Release Candidates" folder on SourceForge.
> >>
> >> When testing the obsolete pm3d contrib awk scripts on my demo data, I have
> >> found a bug in 5.2 vs 5.0 and 4.*. Try this:
> >>
> >> set pm3d map; splot x*x-y*y
> >>
> >> In 5.2, the key "x*x-y*y" is shown above the map.
> >> In 4.* and 5.0, the key "x*x-y*y" is not shown (actually, it is drawn
> >> below the plot).
> >> The key makes no sense for the plot (there is no colour line there), so it is
> >> recommended to hide the key.
> >>
> >> The problem is due to:
> >> current:
> >>      key is ON, position: top right vertical fixed
> >> 5.2:
> >>      key is ON, position: top right vertical inside
> >>
> >> Note that the key positioning is bad (overlaped with plot) also
> >> for the use of the contour map:
> >>      set view map; set contour; splot x*x-y*y
> >> so that "key fixed" does not help.
> >>
> >>
> >> I think the "inside" should mean "inside" for "plot" as well
> >> as for "splot map". Otherwise "mapped splots" are not compatible
> >> with current gnuplot neither with
> >>      plot '3d.dat' with image
> >>
> >>
> >> Is it possible to fix the meaning of the new "fixed" keyword?
> >
> > I do not know where such a title should be placed by default, but
> > for both 5.0 and 5.2
> >    set key inside opaque box
> > will display the key embedded in the pm3d or contour surface.
> 
> The title should not be visible by default, it must stay inside for maps,
> otherwise we break compatibility (there would be an unwanted text in maps 
> produced by new gnuplot).
> 
> I think that in 5.2
>      if ("key_fixed") ...
> should be changed to
>      if ("key_fixed" AND !splot_map) ...

Yes, you are right.

> Is such a fix possible?

Sure. I think it is only one place.

	Ethan

Re: Version 5.2 release candidate -rc3

[Petr M. <mi...@ph...>]

> On Friday, 04 August 2017 17:12:47 Petr Mikulik wrote:
>>> Source tarball for -rc3 in now in the "Release Candidates" folder on SourceForge.
>>
>> When testing the obsolete pm3d contrib awk scripts on my demo data, I have
>> found a bug in 5.2 vs 5.0 and 4.*. Try this:
>>
>> set pm3d map; splot x*x-y*y
>>
>> In 5.2, the key "x*x-y*y" is shown above the map.
>> In 4.* and 5.0, the key "x*x-y*y" is not shown (actually, it is drawn
>> below the plot).
>> The key makes no sense for the plot (there is no colour line there), so it is
>> recommended to hide the key.
>>
>> The problem is due to:
>> current:
>>      key is ON, position: top right vertical fixed
>> 5.2:
>>      key is ON, position: top right vertical inside
>>
>> Note that the key positioning is bad (overlaped with plot) also
>> for the use of the contour map:
>>      set view map; set contour; splot x*x-y*y
>> so that "key fixed" does not help.
>>
>>
>> I think the "inside" should mean "inside" for "plot" as well
>> as for "splot map". Otherwise "mapped splots" are not compatible
>> with current gnuplot neither with
>>      plot '3d.dat' with image
>>
>>
>> Is it possible to fix the meaning of the new "fixed" keyword?
>
> I do not know where such a title should be placed by default, but
> for both 5.0 and 5.2
>    set key inside opaque box
> will display the key embedded in the pm3d or contour surface.

The title should not be visible by default, it must stay inside for maps,
otherwise we break compatibility (there would be an unwanted text in maps 
produced by new gnuplot).

I think that in 5.2
     if ("key_fixed") ...
should be changed to
     if ("key_fixed" AND !splot_map) ...

Is such a fix possible?

---
Petr

Re: Version 5.2 release candidate -rc3

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

On Friday, 04 August 2017 17:12:47 Petr Mikulik wrote:
> > Source tarball for -rc3 in now in the "Release Candidates" folder on SourceForge.
> 
> When testing the obsolete pm3d contrib awk scripts on my demo data, I have 
> found a bug in 5.2 vs 5.0 and 4.*. Try this:
> 
> set pm3d map; splot x*x-y*y
> 
> In 5.2, the key "x*x-y*y" is shown above the map.
> In 4.* and 5.0, the key "x*x-y*y" is not shown (actually, it is drawn
> below the plot).
> The key makes no sense for the plot (there is no colour line there), so it is 
> recommended to hide the key.
> 
> The problem is due to:
> current:
>      key is ON, position: top right vertical fixed
> 5.2:
>      key is ON, position: top right vertical inside
> 
> Note that the key positioning is bad (overlaped with plot) also
> for the use of the contour map:
>      set view map; set contour; splot x*x-y*y
> so that "key fixed" does not help.
> 
> 
> I think the "inside" should mean "inside" for "plot" as well
> as for "splot map". Otherwise "mapped splots" are not compatible
> with current gnuplot neither with
>      plot '3d.dat' with image
> 
> 
> Is it possible to fix the meaning of the new "fixed" keyword?

I do not know where such a title should be placed by default, but
for both 5.0 and 5.2
    set key inside opaque box 
will display the key embedded in the pm3d or contour surface.

	Ethan

Re: Version 5.2 release candidate -rc3

[Petr M. <mi...@ph...>]

> Source tarball for -rc3 in now in the "Release Candidates" folder on SourceForge.

When testing the obsolete pm3d contrib awk scripts on my demo data, I have 
found a bug in 5.2 vs 5.0 and 4.*. Try this:

set pm3d map; splot x*x-y*y

In 5.2, the key "x*x-y*y" is shown above the map.
In 4.* and 5.0, the key "x*x-y*y" is not shown (actually, it is drawn
below the plot).
The key makes no sense for the plot (there is no colour line there), so it is 
recommended to hide the key.

The problem is due to:
current:
     key is ON, position: top right vertical fixed
5.2:
     key is ON, position: top right vertical inside

Note that the key positioning is bad (overlaped with plot) also
for the use of the contour map:
     set view map; set contour; splot x*x-y*y
so that "key fixed" does not help.


I think the "inside" should mean "inside" for "plot" as well
as for "splot map". Otherwise "mapped splots" are not compatible
with current gnuplot neither with
     plot '3d.dat' with image


Is it possible to fix the meaning of the new "fixed" keyword?

---
Petr

Re: Version 5.2 release candidate -rc3

[Petr M. <mi...@ph...>]

>> Directory pm3d is missing in 5.2-rc tar ball
>
> That is intentional.  So far as I know the scripts in the pm3d subdirectory are
> no longer needed because the operations they perform are now part of the main program.
> The scripts can still be obtained from the SourceForge site if someone wants them.

Yes, these scripts are no longer needed. They were written around year 2000, 
but nowadays gnuplot has this functionality built-in (what a nice progress 
over ages!):

    plot ... with image
    (s)plot ... with point lc variable


BTW, I have just tested them - so if you still want to try 
pm3dConvertToImage.awk, then in the postscript file you have to move

%pm3d_map_begin

just above the image data, as there are currently these lines:

   1.000 UL
   LT0
   LC0 setrgbcolor

blocking between %pm3d_map_begin and the image data.

---
Petr

Re: Re: Version 5.2 release candidate -rc3

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

Similar changes can be applied to 5.3

Tatsuro

--- Tatsuro MATSUOKA wrote:
> Thank you for the change.
> I was able to build rc4 source on rc4 without treatments.
> Now corresponding binary packages are uploaded.
> 
> Tatsuro
> 
> 
> 
> 
> ----- Original Message -----
> > From: sfeam 
> > To: gnuplot-beta
> > Cc: 
> > Date: 2017/7/31, Mon 12:25
> > Subject: Re: Version 5.2 release candidate -rc3
> > 
> > OK.
> > tarball for -rc4 is uploaded.
> > All source files are identical to -rc3.
> > The only change is to the inventory of subdirectories for Windows packages
> > as discussed below.
> > 
> >     Ethan
> > 
> > On Monday, 31 July 2017 10:44:57 Tatsuro MATSUOKA wrote:
> >>  ----- Original Message -----
> >> 
> >>  > From: sfeam 
> >>  > To: gnuplot-beta Tatsuro MATSUOKA > Cc: 
> >>  > Date: 2017/7/31, Mon 10:10
> >>  > Subject: Re: Version 5.2 release candidate -rc3
> >>  > 
> >>   
> >>  > That is intentional.  So far as I know the scripts in the pm3d 
> > subdirectory are 
> >>  > no longer needed because the operations they perform are now part of 
> > the main 
> >>  > program.
> >>  > The scripts can still be obtained from the SourceForge site if someone 
> > wants 
> >>  > them.
> >>  > 
> >>  >>  and make installer on windows build fails.
> >>  > 
> >>  > Can you figure out why it fails?  Is it because of these files
> >>  > 
> >>  > .../config/mingw/Makefile
> >>  > .../config/msvc/Makefile
> >>  > 
> >>  > Does this patch fix it?
> >>  > 
> >>  > --- gnuplot52/config/mingw/Makefile    2017-07-30 09:44:01.450442197 
> > -0700
> >>  > +++ test52/config/mingw/Makefile    2017-07-30 18:01:58.078032167 
> > -0700
> >>  > @@ -1029,8 +1029,8 @@
> >>  >     -cp -p $(M)* $(DESTDIR)/demo/
> >>  >     mkdir -p $(DESTDIR)/demo/games
> >>  >     -cp -p $(M)/games/* $(DESTDIR)/demo/games/
> >>  > -    mkdir -p $(DESTDIR)/contrib/pm3d/
> >>  > -    -cp -p $(TOP)/pm3d/contrib/* $(DESTDIR)/contrib/pm3d/
> >>  > +#    mkdir -p $(DESTDIR)/contrib/pm3d/
> >>  > +#    -cp -p $(TOP)/pm3d/contrib/* $(DESTDIR)/contrib/pm3d/
> >>  > # docs
> >>  >     mkdir -p $(DESTDIR)/docs
> >>  >     -cp -p gnuplot.pdf $(DESTDIR)/docs/
> >>  > --- gnuplot52/config/msvc/Makefile    2017-07-30 09:44:01.458441784 
> > -0700
> >>  > +++ test52/config/msvc/Makefile    2017-07-30 18:06:33.926299097 -0700
> >>  > @@ -550,8 +550,8 @@
> >>  >     xcopy /Y $(TOP)\demo $(DESTDIR)\demo
> >>  >     if not exist $(DESTDIR)\demo\games mkdir 
> >>  > $(DESTDIR)\demo\games
> >>  >     xcopy /Y $(TOP)\demo\games $(DESTDIR)\demo\games
> >>  > -    if not exist $(DESTDIR)\contrib\pm3d mkdir 
> >>  > $(DESTDIR)\contrib\pm3d
> >>  > -    xcopy /Y $(TOP)\pm3d\contrib\*.* 
> >>  > $(DESTDIR)\contrib\pm3d
> >>  > +#    if not exist $(DESTDIR)\contrib\pm3d mkdir 
> >>  > $(DESTDIR)\contrib\pm3d
> >>  > +#    xcopy /Y $(TOP)\pm3d\contrib\*.* 
> >>  > $(DESTDIR)\contrib\pm3d
> >>  > 
> >>  > zip:
> >>  >     $(MAKE) DESTDIR=.\gnuplot install
> >>  > 
> >> 
> >>  For zip and 7zip archives, the above is enough.
> >>  For installer additional change is required
> >> 
> >>  # ***************************
> >>  --- a/win/gnuplot.iss    2017-07-31 10:21:32.139777700 +0900
> >>  +++ b/win/gnuplot.iss    2016-08-10 01:23:27.000000000 +0900
> >>  @@ -260,7 +260,7 @@
> >>   
> >>   ; demo files / contrib
> >>   
> >>  -;Source: "contrib\*"; DestDir: {app}\contrib\; 
> > Flags: recursesubdirs; Components: demo
> >>  +Source: "contrib\*"; DestDir: {app}\contrib\; Flags: 
> > recursesubdirs; Components: demo
> >>   
> >>   Source: "demo\*"; DestDir: {app}\demo\; Flags: 
> > recursesubdirs; Components: demo
> >>   
> >>  # ***************************
> >> 
> >> 
> >> 
> >>  In the iss file (Setting file for Inno Setup Compiler), ";"  is a 
> > comment mark.
> >>  I did not test on MSVC because I do not have build environments of gnuplot 
> > using MSVC.
> >> 
> >> 
> >> 
> >>  > 
> >>  >>  In 5.2 cvs source tree, directory pm3d exist and I copy it to the 
> > 5.2-rc 
> >>  > source tree and execute make installer.
> >>  >> 
> >>  >>  Please correct the 5.2-rc package.
> >>  > 
> >>  > If it is really needed for the program itself then I will restore the 
> > pm3d 
> >>  > subdirectory.
> >>  > But if the problem is only that the subdirectly is incorrectly listed 
> > in the 
> >>  > Makefile
> >>  > then let's fix that instead.
> >>  > 
> >>  >     thanks for testing
> >>  > 
> >>  >         Ethan
> >> 
> >>  I deleted contrib directory and executed all.dem.
> >>  all.dem worked fine without the pm3d subdirectory.
> >> 
> >>  Please fix Makefile and gnuplot.iss.
> >> 
> >>  Tatsuro
> >> 
> >> 
> >>  >>  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
> > 
> 
> ------------------------------------------------------------------------------
> 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
>