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

Re: rgbimage plots with linked axes

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

Forgot to attach the image

rgbimage plots with linked axes

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

Hi. I just stumbled on another bug with rgbimages. If somebody knows
what's causing it, that'd be appreciated.

I'm plotting an image showing a map composed of stitched openstreetmap
tiles (attached). The mapping between pixels in this image and lat/lon
is linear in longitude and nonlinear in latitude. I'm plotting the image
pixels onto x2y2, and using linked axes to get the latitude on y and
longitude on x. The script is this:

  set x2tics auto
  set y2tics auto

  lon0       = -123.5614
  lon_offset = 180.0 + lon0

  zoom = 4.
  px_to_lon(x) = x/(256. * 2.**4)*360. - 180. + lon_offset
  lon_to_px(x) = (x-lon_offset+180.)/360. * 2.**zoom * 256.

  lat_offset_px = 1215.969

  s1_cos(x)     = (sin(x)+1)/cos(x)
  inv_s1_cos(x) = asin( (x**2 - 1)/(x**2 + 1) )

  px_to_lat(x) = inv_s1_cos(exp((1 - (x + lat_offset_px)/(2.**zoom * 256) *2)*pi))*180./pi
  lat_to_px(x) = (1 - log( (sin(x*pi/180) + 1.)/cos(x*pi/180) )/pi)/2. * 2.**zoom * 256 - lat_offset_px


  set link x2 via lon_to_px(x) inverse px_to_lon(x)
  set link y2 via lat_to_px(y) inverse px_to_lat(y)

  plot [x=-120:-80][y=20:60] "montage_40_-99_1300miles_4.png" binary filetype=png flipy with rgbimage notitle axis x2y2, '-' with points axis x2y2
  60 419
  e


Note that the circle representing Los Angeles lies at pixel coordinates
60,419 and I'm plotting a point there. The corresponding latlon is
roughly -118,34. The pixels are on x2y2 and the point is on x2y2, so
this point should be rendered in that circle. I'm not seeing that at
all, however. The point is at y2=419 as it should be, but the Los
Angeles circle is roughly at y2=448. The x coordinates match properly.

Furthermore, zooming in makes it clear that gnuplot is confused:
interactively zooming on the plotted point shows me the zoomed LA
circle, even though visually the LA circle was elsewhere.

Any pointers?

Re: Questions about configure/building regarding Qt and Lua

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

I'm attaching a patch file with some mods that work for me.  Should I 
open a bug report and post the diff file there?  That will allow more 
organized development.

More comments below...

On 08/31/2017 07:36 PM, sfeam wrote:
> On Thursday, 31 August 2017 16:05:48 Daniel J Sebald wrote:
>> I upgraded to Mint 18.2 here, and I'm going through all the usually
>> system rebuilding...
>>
>> Why does configure report:
>>
>> checking for QT... yes
>> configure: WARNING: The Qt terminal will use Qt5.
>>
>> Is it simply because Qt5 is considered experimental support at this stage?
> 
> Just because the macro autotools provides to write something non-fatal
> during configuration is AC_MSG_WARN.  You'd think they would provide
> something blander like AC_MSG_JUST_IN_CASE_YOU_CARE, but no.
> WARN is better than the alternatives ERROR or FAILURE.

There is AC_MSG_RESULT, which is used a few other places in the 
configure.ac file.  If you want to add "checking " to the front to match 
all the other lines that's fine.


>> Also, when compiling I ran into a missing lrelease utility for Qt:
>>
>> /bin/bash: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: No such file or
>> directory
>> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
>> make[4]: *** [qtgnuplot_fr.qm] Error 127
>>
>> Should configure check for that lrelease file that is being included?
> 
> Sure.  But I don't know how to do that.  lrelease is not a library, so the
> library test macros don't help.

Asking for the version:

sebald@ ~ $ lrelease -version
lrelease version 5.5.1

should return with 0 if lrelease is present, otherwise return non-zero. 
It should be possible to run the command from configure and check the 
result.


>> It isn't too much trouble to find the package and install lrelease
>> (qttools5-dev-tools), but that package isn't automatically installed
>> with all the other Qt5 packages as a requirement.
> 
> That seems more like a failure of the mint package dependencies than
> something gnuplot's configure script is responsible for.
> FWIW on my machines lrelease does not come in a separate *-dev-*
> package.  It's in qttools5 proper.

Yes, it does seem that way.  Maybe the developers will catch this 
eventually.


>> After installing
>> qttools5-dev-tools, compilation continues with 29 translations for Qt.
>>
>> I then ran into this problem:
>>
>> make[2]: Entering directory '/usr/local/src/gnuplot/gnuplot/build1/docs'
>> lua5.2 /home/sebald/gnuplot/gnuplot/gnuplot/term/lua/gnuplot-tikz.lua
>> termhelp > gnuplot-tikz.help
>> /bin/bash: lua5.2: command not found
>> Makefile:979: recipe for target 'gnuplot-tikz.help' failed
>> make[2]: *** [gnuplot-tikz.help] Error 127
>>
>> which is of the same variety as the previous problem.  I had to install
>> lua5.2 package because it isn't a requirement for liblua5.2-dev package.
>>    Should configure check for the lua executable?
> 
> The configure script uses pkg-config to check for lua.
> It checks for "lua", and if that fails it checks for "lua5.1", "lua5.2", "lua5.3".
> So again it sounds like mint weirdness.  If pkg-config is reporting that you
> have lua installed but really you do not, I would consider that a system
> configuration error.
> 
> But also it's weird that bash is trying to run explicitly lua5.2.
> Normally it just runs "lua" and that invokes the current installed version
> whatever it is.  Can you pin down what script this is, exactly?  I don't
> see any such script in the gnuplot source.

Ah, that's probably because these are two different things.  The 
$PKG_CONFIG is checking for the associated package files in the 
directory where the pertinent library was built.  That package is 
lua5.2.  I assume this package construct is because there is some code 
compiled into gnuplot that interacts with lua libraries.

But what was failing is the executable name, "lua"...which typically 
consists of a link to the (or some) package directory, e.g.,

lrwxrwxrwx 1 root root 33 Aug 31 15:50 /usr/bin/lua -> 
/etc/alternatives/lua-interpreter

well, in this case there is an extra level of abstraction.

I suppose the idea is that the library is used to construct something 
that can input to the external "lua" app.  The configure.ac doesn't make 
any distinction between those.  I've added a LUA_CMD=lua and changed 
$(LUA) to $(LUA_CMD) in a select few locations.

As with lrelease, the LUA_CMD could be verified with

sebald@ ~ $ lua -v
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio

return 0 as opposed to -1.  I'm just assuming it is present for now.

Dan

Re: Questions about configure/building regarding Qt and Lua

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

On Thursday, 31 August 2017 16:05:48 Daniel J Sebald wrote:
> I upgraded to Mint 18.2 here, and I'm going through all the usually 
> system rebuilding...
> 
> Why does configure report:
> 
> checking for QT... yes
> configure: WARNING: The Qt terminal will use Qt5.
> 
> Is it simply because Qt5 is considered experimental support at this stage?

Just because the macro autotools provides to write something non-fatal
during configuration is AC_MSG_WARN.  You'd think they would provide
something blander like AC_MSG_JUST_IN_CASE_YOU_CARE, but no.
WARN is better than the alternatives ERROR or FAILURE.

> Also, when compiling I ran into a missing lrelease utility for Qt:
> 
> /bin/bash: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: No such file or 
> directory
> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
> make[4]: *** [qtgnuplot_fr.qm] Error 127
> 
> Should configure check for that lrelease file that is being included? 

Sure.  But I don't know how to do that.  lrelease is not a library, so the
library test macros don't help. 

> It isn't too much trouble to find the package and install lrelease 
> (qttools5-dev-tools), but that package isn't automatically installed 
> with all the other Qt5 packages as a requirement.  

That seems more like a failure of the mint package dependencies than
something gnuplot's configure script is responsible for.
FWIW on my machines lrelease does not come in a separate *-dev-*
package.  It's in qttools5 proper.

> After installing 
> qttools5-dev-tools, compilation continues with 29 translations for Qt.
> 
> I then ran into this problem:
> 
> make[2]: Entering directory '/usr/local/src/gnuplot/gnuplot/build1/docs'
> lua5.2 /home/sebald/gnuplot/gnuplot/gnuplot/term/lua/gnuplot-tikz.lua 
> termhelp > gnuplot-tikz.help
> /bin/bash: lua5.2: command not found
> Makefile:979: recipe for target 'gnuplot-tikz.help' failed
> make[2]: *** [gnuplot-tikz.help] Error 127
> 
> which is of the same variety as the previous problem.  I had to install 
> lua5.2 package because it isn't a requirement for liblua5.2-dev package. 
>   Should configure check for the lua executable?

The configure script uses pkg-config to check for lua.
It checks for "lua", and if that fails it checks for "lua5.1", "lua5.2", "lua5.3".
So again it sounds like mint weirdness.  If pkg-config is reporting that you
have lua installed but really you do not, I would consider that a system
configuration error.

But also it's weird that bash is trying to run explicitly lua5.2.
Normally it just runs "lua" and that invokes the current installed version
whatever it is.  Can you pin down what script this is, exactly?  I don't
see any such script in the gnuplot source.

	Ethan

Questions about configure/building regarding Qt and Lua

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

I upgraded to Mint 18.2 here, and I'm going through all the usually 
system rebuilding...

Why does configure report:

checking for QT... yes
configure: WARNING: The Qt terminal will use Qt5.

Is it simply because Qt5 is considered experimental support at this stage?

Also, when compiling I ran into a missing lrelease utility for Qt:

c++  -g -O2 -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-pthread -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12 -fPIC   -lcerf  -o 
gnuplot_qt qtterminal/gnuplot_qt.o qtterminal/QtGnuplotWindow.o 
qtterminal/QtGnuplotApplication.o qtterminal/QtGnuplotWidget.o 
qtterminal/QtGnuplotScene.o qtterminal/QtGnuplotItems.o 
qtterminal/QtGnuplotEvent.o qtterminal/moc_QtGnuplotWindow.o 
qtterminal/moc_QtGnuplotApplication.o qtterminal/moc_QtGnuplotWidget.o 
qtterminal/moc_QtGnuplotScene.o qtterminal/moc_QtGnuplotEvent.o 
qtterminal/qrc_QtGnuplotResource.o -lQt5Network -lQt5Svg 
-lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Core -ldl -lm -lcerf  -lz 
-lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0
/usr/lib/x86_64-linux-gnu/qt5/bin/lrelease 
/home/sebald/gnuplot/gnuplot/gnuplot/src/qtterminal/po/qtgnuplot_fr.ts 
-qm qtgnuplot_fr.qm
/bin/bash: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: No such file or 
directory
Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
make[4]: *** [qtgnuplot_fr.qm] Error 127

Should configure check for that lrelease file that is being included? 
It isn't too much trouble to find the package and install lrelease 
(qttools5-dev-tools), but that package isn't automatically installed 
with all the other Qt5 packages as a requirement.  After installing 
qttools5-dev-tools, compilation continues with 29 translations for Qt.

I then ran into this problem:

make[2]: Entering directory '/usr/local/src/gnuplot/gnuplot/build1/docs'
lua5.2 /home/sebald/gnuplot/gnuplot/gnuplot/term/lua/gnuplot-tikz.lua 
termhelp > gnuplot-tikz.help
/bin/bash: lua5.2: command not found
Makefile:979: recipe for target 'gnuplot-tikz.help' failed
make[2]: *** [gnuplot-tikz.help] Error 127

which is of the same variety as the previous problem.  I had to install 
lua5.2 package because it isn't a requirement for liblua5.2-dev package. 
  Should configure check for the lua executable?

sebald@ ~/gnuplot/gnuplot/gnuplot $ lua5.2 -v
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio

Dan

Re: Ready for final 5.2 release?

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

On 30 August 2017 at 09:20, Mojca Miklavec wrote:
>
> I tested the compilation on Mac now and I get a segmentation error
> (during compilation already). I didn't test previous RCs, so I cannot
> say since when this could be a problem.
>
> I'll try if I can figure out what causes it.

I'm sorry, this seems to be just a buggy default system compiler.
(Everything sem ok after replacing the compiler with a newer one.)

Mojca

Re: Ready for final 5.2 release?

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

Dear Ethan,

On 28 August 2017 at 18:52, sfeam via gnuplot-beta wrote:
> We've had three release candidate for version 5.2 since May 2017 [*].
> Four bugs have been found and fixed since -rc3, and a few bits of new code
> back-ported from 5.3.
>
> Does anyone see a need for an -rc5 before the final version 5.2 release?

I tested the compilation on Mac now and I get a segmentation error
(during compilation already). I didn't test previous RCs, so I cannot
say since when this could be a problem.

I'll try if I can figure out what causes it.

Mojca

Re: Ready for final 5.2 release?

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

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

> From: sfeam 
> To: gnuplot-beta; Tatsuro MATSUOKA 
> Cc: bmaerkisch
> Date: 2017/8/30, Wed 13:02
> Subject: Re: Ready for final 5.2 release?
> 
> On Wednesday, 30 August 2017 11:02:10 Tatsuro MATSUOKA wrote:
>>  > OK. I have updated that file.
>> 
>>  > Please check that I understand correctly.
>>  > There is no reason to mention wgnuplot_pipes at all, is this correct?
>> 
>> 
>>  Now the difference of wgnuplot_pipes from wgnuplot is to output stderr of 
> child process
>>  or external libraries to the additional console.
>> 
>>  I myself agree with your description 
>> 
>>  in which explanation of wgnuplot_pipes is just omitted  but binary package 
> keep to have it. 
>> 
>> 
>> 
>> 
>>  > The file now says
>>  > 
>>  > gnuplot binaries
>>  > ----------------
>>  > 
>>  > * wgnuplot.exe:  GUI version and the default gnuplot executable.
>>  > 
>>  > * gnuplot.exe:  Text (console) mode version of the gnuplot executable 
> with full
>>  >   pipe functionality as on other platforms. In contrast to 
> wgnuplot.exe, this
>>  >   program can also accept commands on stdin (standard input) and print 
> messages
>>  >   on stdout (standard output). It replaces a program pgnuplot.exe used 
> by some
>>  >   earlier gnuplot versions.  gnuplot.exe can be used as a graph engine 
> by
>>  >   3rd party applications like Octave (www.octave.org).
>>  > 
>>  > * runtime library files
>>  >   Runtime library files (e.g. freetype6.dll) that are required for 
> gnuplot
>>  >   are included in the package.  Licenses of these runtime libraries 
> can be
>>  >   found in the 'license' directory.
>>  > 
>> 
>> 
>>  > >   Runtime library files (e.g. freetype6.dll)
>>  small correction 
>> 
>>  freetype6.dll is not used binary package distribution.
>>  Now the corresponding dll is named as libfreetype-6.dll.
>> 
>>  Tatsuro
> 
> Got it. Thank you.
> 
> Can you modify the Japanese version README-Windows-ja.txt
> the same way?
> 
>     Ethan


README-Windows-ja.txt has not been revised since 2016-03-07.
I can revised it asap but it takes a bit time.

In addition, this manuscript has been revised by Shigeharu Takeno
so that the revised manuscript is better to reviewed by Shigeharu Takeno

Tatsuro

Re: Ready for final 5.2 release?

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

On Wednesday, 30 August 2017 11:02:10 Tatsuro MATSUOKA wrote:
> > OK. I have updated that file.
> 
> > Please check that I understand correctly.
> > There is no reason to mention wgnuplot_pipes at all, is this correct?
> 
> 
> Now the difference of wgnuplot_pipes from wgnuplot is to output stderr of child process
> or external libraries to the additional console.
> 
> I myself agree with your description 
> 
> in which explanation of wgnuplot_pipes is just omitted  but binary package keep to have it. 
> 
> 
> 
> 
> > The file now says
> > 
> > gnuplot binaries
> > ----------------
> > 
> > * wgnuplot.exe:  GUI version and the default gnuplot executable.
> > 
> > * gnuplot.exe:  Text (console) mode version of the gnuplot executable with full
> >   pipe functionality as on other platforms. In contrast to wgnuplot.exe, this
> >   program can also accept commands on stdin (standard input) and print messages
> >   on stdout (standard output). It replaces a program pgnuplot.exe used by some
> >   earlier gnuplot versions.  gnuplot.exe can be used as a graph engine by
> >   3rd party applications like Octave (www.octave.org).
> > 
> > * runtime library files
> >   Runtime library files (e.g. freetype6.dll) that are required for gnuplot
> >   are included in the package.  Licenses of these runtime libraries can be
> >   found in the 'license' directory.
> > 
> 
> 
> > >   Runtime library files (e.g. freetype6.dll)
> small correction 
> 
> freetype6.dll is not used binary package distribution.
> Now the corresponding dll is named as libfreetype-6.dll.
> 
> Tatsuro

Got it. Thank you.

Can you modify the Japanese version README-Windows-ja.txt
the same way?

	Ethan

Re: Ready for final 5.2 release?

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

> OK. I have updated that file.

> Please check that I understand correctly.
> There is no reason to mention wgnuplot_pipes at all, is this correct?


Now the difference of wgnuplot_pipes from wgnuplot is to output stderr of child process
or external libraries to the additional console.

I myself agree with your description 

in which explanation of wgnuplot_pipes is just omitted  but binary package keep to have it. 




> The file now says
> 
> gnuplot binaries
> ----------------
> 
> * wgnuplot.exe:  GUI version and the default gnuplot executable.
> 
> * gnuplot.exe:  Text (console) mode version of the gnuplot executable with full
>   pipe functionality as on other platforms. In contrast to wgnuplot.exe, this
>   program can also accept commands on stdin (standard input) and print messages
>   on stdout (standard output). It replaces a program pgnuplot.exe used by some
>   earlier gnuplot versions.  gnuplot.exe can be used as a graph engine by
>   3rd party applications like Octave (www.octave.org).
> 
> * runtime library files
>   Runtime library files (e.g. freetype6.dll) that are required for gnuplot
>   are included in the package.  Licenses of these runtime libraries can be
>   found in the 'license' directory.
> 


> >   Runtime library files (e.g. freetype6.dll)
small correction 

freetype6.dll is not used binary package distribution.
Now the corresponding dll is named as libfreetype-6.dll.

Tatsuro

Re: Ready for final 5.2 release?

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

On Tuesday, 29 August, 2017 14:39:48 Tatsuro MATSUOKA wrote:
> 
> In win/Readme-windows.txt, 
> 
> * wgnuplot.exe:  GUI version and the default gnuplot executable. As of version 5 
>   it emulates pipe functionality.
> 
> Now pipe works on also wgnuplot.exe, emulation is not used at present.
> The above sentence should be corrected accordingly.
> 
> Tatsuro

OK. I have updated that file.
Please check that I understand correctly.
There is no reason to mention wgnuplot_pipes at all, is this correct?
The file now says

gnuplot binaries
----------------

* wgnuplot.exe:  GUI version and the default gnuplot executable.

* gnuplot.exe:  Text (console) mode version of the gnuplot executable with full
  pipe functionality as on other platforms. In contrast to wgnuplot.exe, this
  program can also accept commands on stdin (standard input) and print messages
  on stdout (standard output). It replaces a program pgnuplot.exe used by some
  earlier gnuplot versions.  gnuplot.exe can be used as a graph engine by
  3rd party applications like Octave (www.octave.org).

* runtime library files
  Runtime library files (e.g. freetype6.dll) that are required for gnuplot
  are included in the package.  Licenses of these runtime libraries can be
  found in the 'license' directory.

	Ethan

Re: Ready for final 5.2 release?

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

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

> From: sfeam 

> To: Tatsuro MATSUOKA 

> Cc: gnu...@li...; bma...@we...
> Date: 2017/8/29, Tue 15:34
> Subject: Re: Ready for final 5.2 release?
> 
> On Tuesday, 29 August 2017 14:39:48 Tatsuro MATSUOKA wrote:
>>  > From: sfeam via gnuplot-beta 
>> 
>>  > To: gnuplot-beta
>>  > Cc: 
>>  > Date: 2017/8/29, Tue 01:52
>>  > Subject: Ready for final 5.2 release?
>>  > 
>>  > We've had three release candidate for version 5.2 since May 2017 
> [*].
>>  > Four bugs have been found and fixed since -rc3, and a few bits of new 
> code
>>  > back-ported from 5.3.
>>  > 
>>  > Does anyone see a need for an -rc5 before the final version 5.2 
> release?
>>  > 
>>  > If not, I'll plan to package up a 5.2 source tarball at the end of 
> this 
>>  > week.
>>  > 
>>  >     Ethan
>> 
>>  In win/Readme-windows.txt, 
>> 
>>  * wgnuplot.exe:  GUI version and the default gnuplot executable. As of 
> version 5 
>>    it emulates pipe functionality.
>> 
>> 
>> 
>>  As of version 5, it emulates pipe functionality.
>> 
>>  Now pipe works on also wgnuplot.exe, emulation is not used at present.
>>  The above sentence should be corrected accordingly.
>> 
>>  Tatsuro
>> 
> 
> In file   config/mingw/Makefile   I see
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> ifndef MINGW64
>         EXTRA_CPPFLAGS_PLAIN += -DUSE_FAKEPIPES
> else
>         EXTRA_CPPFLAGS_PLAIN += -DPIPES
> endif
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> Does this mean that the 64-bit Mingw executable uses real pipes
> but the 32-bit executable uses emulation?
> Is it only true for Mingw?
> 
>     Ethan 


MinGW 64 provides both 32 and 64 bit build tools.
I have used it for both 32 and 64 bit binaries since 5.0.1. 

and 32 bit executable also does not use emulation.


The pipe on  wgnuplot is also currently supported on MSVC.

See ChangeLog of 5.2-rc4


2017-07-29  Bastian Maerkisch  <bma...@we...>

    * config/mingw/Makefile config/msvc/Makefile:  Mingw-w64 and MSVC have
    working popen/pclose implementations for GUI applications.  So we use
    them instead of our own "fake" pipe emulation.
    Bug #1950


Tatsuro

Re: Ready for final 5.2 release?

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

On Tuesday, 29 August 2017 14:39:48 Tatsuro MATSUOKA wrote:
> > From: sfeam via gnuplot-beta 
> 
> > To: gnuplot-beta
> > Cc: 
> > Date: 2017/8/29, Tue 01:52
> > Subject: Ready for final 5.2 release?
> > 
> > We've had three release candidate for version 5.2 since May 2017 [*].
> > Four bugs have been found and fixed since -rc3, and a few bits of new code
> > back-ported from 5.3.
> > 
> > Does anyone see a need for an -rc5 before the final version 5.2 release?
> > 
> > If not, I'll plan to package up a 5.2 source tarball at the end of this 
> > week.
> > 
> >     Ethan
> 
> In win/Readme-windows.txt, 
> 
> * wgnuplot.exe:  GUI version and the default gnuplot executable. As of version 5 
>   it emulates pipe functionality.
> 
> 
> 
> As of version 5, it emulates pipe functionality.
> 
> Now pipe works on also wgnuplot.exe, emulation is not used at present.
> The above sentence should be corrected accordingly.
> 
> Tatsuro
> 

In file   config/mingw/Makefile   I see

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ifndef MINGW64
        EXTRA_CPPFLAGS_PLAIN += -DUSE_FAKEPIPES
else
        EXTRA_CPPFLAGS_PLAIN += -DPIPES
endif
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Does this mean that the 64-bit Mingw executable uses real pipes
but the 32-bit executable uses emulation?
Is it only true for Mingw?

	Ethan 

Re: Ready for final 5.2 release?

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

> From: sfeam via gnuplot-beta 

> To: gnuplot-beta
> Cc: 
> Date: 2017/8/29, Tue 01:52
> Subject: Ready for final 5.2 release?
> 
> We've had three release candidate for version 5.2 since May 2017 [*].
> Four bugs have been found and fixed since -rc3, and a few bits of new code
> back-ported from 5.3.
> 
> Does anyone see a need for an -rc5 before the final version 5.2 release?
> 
> If not, I'll plan to package up a 5.2 source tarball at the end of this 
> week.
> 
>     Ethan

In win/Readme-windows.txt, 

* wgnuplot.exe:  GUI version and the default gnuplot executable. As of version 5 
  it emulates pipe functionality.



As of version 5, it emulates pipe functionality.

Now pipe works on also wgnuplot.exe, emulation is not used at present.
The above sentence should be corrected accordingly.

Tatsuro

Ready for final 5.2 release?

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

We've had three release candidate for version 5.2 since May 2017 [*].
Four bugs have been found and fixed since -rc3, and a few bits of new code
back-ported from 5.3.

Does anyone see a need for an -rc5 before the final version 5.2 release?

If not, I'll plan to package up a 5.2 source tarball at the end of this week.

	Ethan



[*] actually four, but -rc4 changed only the Windows packaging.

Re: Two minor patches

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

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

> On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote:
>> On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote:
>>
>> > > 2. The build was broken on a recent Debian system: we were calling
>> > > XInitThreads(), but not linking in -lX11. The patch adds the linkage
>> >
>> > Sigh.  This keeps coming back and back and back.
>> > Adding -lX11 fixes most linux installations but breaks everyone else.
>> >
>> > See for example https://sourceforge.net/p/gnuplot/bugs/1764/
>>
>> OK, I read your links, but it's not obvious how it breaks everyone else.
>> Is the concern that some platforms have wx, but not X11, so the link to
>> libX11 will fail? What if instead of linking to -lX11 we link to
>> $LIBRARIES_FOR_X?
>
> Doesn't that just push the same problem down or up one level?
> The question then becomes how do you figure out what to put
> in $LIBRARIES_FOR_X.

I think this should be fine.

On platforms where we ran ./configure --with-x (default usually) then
$LIBRARIES_FOR_X would contain "-lX11", and the proposed link command
would work.

On platforms X11 isn't available, $LIBRARIES_FOR_X should evaluate to
"", which would be fine.

Presumably, the same should happen if we ./configure --without-x, but
that doesn't work. This is probably a bug in the build system, but this
is a separate issue.

I'm attaching the updated patch

Re: non-color-scaled rgbimage plots

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

On Thursday, 17 August 2017 13:54:44 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > I agree that it makes no sense to apply the palette range (cbrange)
> > to rgb data.
> > 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.
> >
> 
> OK, that sounds like a plan. In the meantime I'm going to apply the
> attached patch to my own builds. This detaches the rgb colors from the
> palette entirely, both for autoscaling and for rendering. Works OK in
> initial testing.

[patch snipped]

Looks good to me.
I've applied it to 5.3 cvs.

	Ethan

Re: Two minor patches

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

On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote:
> On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote:
> 
> > > 2. The build was broken on a recent Debian system: we were calling
> > > XInitThreads(), but not linking in -lX11. The patch adds the linkage
> > 
> > Sigh.  This keeps coming back and back and back.
> > Adding -lX11 fixes most linux installations but breaks everyone else.
> > 
> > See for example https://sourceforge.net/p/gnuplot/bugs/1764/
> 
> OK, I read your links, but it's not obvious how it breaks everyone else.
> Is the concern that some platforms have wx, but not X11, so the link to
> libX11 will fail? What if instead of linking to -lX11 we link to
> $LIBRARIES_FOR_X?

Doesn't that just push the same problem down or up one level?
The question then becomes how do you figure out what to put
in $LIBRARIES_FOR_X.

	Ethan

Re: Two minor patches

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

On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote:

> > 2. The build was broken on a recent Debian system: we were calling
> > XInitThreads(), but not linking in -lX11. The patch adds the linkage
> 
> Sigh.  This keeps coming back and back and back.
> Adding -lX11 fixes most linux installations but breaks everyone else.
> 
> See for example https://sourceforge.net/p/gnuplot/bugs/1764/

OK, I read your links, but it's not obvious how it breaks everyone else.
Is the concern that some platforms have wx, but not X11, so the link to
libX11 will fail? What if instead of linking to -lX11 we link to
$LIBRARIES_FOR_X?

Re: test have delay on first time on gd based terminals on native windows

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

----- Original Message -----
>From: sfeam <sf...@us...>
>To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...> 
>Cc: bma...@we...
>Date: 2017/8/18, Fri 00:40
>Subject: Re: test have delay on first time on gd based terminals on native windows
> 
>On Thursday, 17 August 2017 18:27:21 Tatsuro MATSUOKA wrote:
>> Hello
>> 
>> This is not a bug but and an annoying matter.
>> 
>> On gnuplot 5 (5.0, 5.2, 5.3) on gd based terminals, test has delay for first try
>> 
>> set term png
>> set out 'test.png'
>> test # delay more than 30 seconds for me
>> 
>> 
>> second execution test does not take time
>> 
>> On gnuplot 4.6.7, delay does not happen.
>> 
>> Any suggestions?
>> 
>> Tatsuro
>
>My first guess is the delay comes from the system font cache
>as we have also seen for the wxt terminal.
>
>Try 
>    set term png font medium
>


Your guess seems to be right 


set term png font medium # dalay happened here
set out 'test.png'
test  # delay did not happen here

>That will force it to use an internal font rather than using obtaining
>one from the system.  If there is no delay, then it supports
>the idea that the system font cache is the problem.
>Of course that doesn't fix the problem, it only points to the cause.
>
>    Ethan

Tatsuro

Re: Two minor patches

[Ethan A M. <merritt@u.washington.edu>]

On Thursday, 17 August, 2017 13:51:55 Dima Kogan wrote:
> Here're two minor, but useful patches:
> 
> 1. If we can't find a helper binary (gnuplot_x11, gnuplot_qt), the error
> message now states which environment variable can be used to redirect it

Thanks for that one.


> 2. The build was broken on a recent Debian system: we were calling
> XInitThreads(), but not linking in -lX11. The patch adds the linkage

Sigh.  This keeps coming back and back and back.
Adding -lX11 fixes most linux installations but breaks everyone else.

See for example https://sourceforge.net/p/gnuplot/bugs/1764/

The problem comes from API breakage in wxgtk3.  But not all
platforms use gtk to support wxWidgets.  It is basically
impossible to autodetect whether the locally installed
wxWidgets does or does not require this extra flag.
So instead we note the problem prominently in the Release Notes.
It is the first item in KNOWN ISSUES.

	Ethan




-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: non-color-scaled rgbimage plots

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

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

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

OK, that sounds like a plan. In the meantime I'm going to apply the
attached patch to my own builds. This detaches the rgb colors from the
palette entirely, both for autoscaling and for rendering. Works OK in
initial testing.

Thanks

Two minor patches

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

Here're two minor, but useful patches:

1. If we can't find a helper binary (gnuplot_x11, gnuplot_qt), the error
message now states which environment variable can be used to redirect it

2. The build was broken on a recent Debian system: we were calling
XInitThreads(), but not linking in -lX11. The patch adds the linkage

Re: test have delay on first time on gd based terminals on native windows

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

On Thursday, 17 August 2017 18:27:21 Tatsuro MATSUOKA wrote:
> Hello
> 
> This is not a bug but and an annoying matter.
> 
> On gnuplot 5 (5.0, 5.2, 5.3) on gd based terminals, test has delay for first try
> 
> set term png
> set out 'test.png'
> test # delay more than 30 seconds for me
> 
> 
> second execution test does not take time
> 
> On gnuplot 4.6.7, delay does not happen.
> 
> Any suggestions?
> 
> Tatsuro

My first guess is the delay comes from the system font cache
as we have also seen for the wxt terminal.

Try 
	set term png font medium

That will force it to use an internal font rather than using obtaining
one from the system.  If there is no delay, then it supports
the idea that the system font cache is the problem.
Of course that doesn't fix the problem, it only points to the cause.

	Ethan

test have delay on first time on gd based terminals on native windows

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

Hello

This is not a bug but and an annoying matter.

On gnuplot 5 (5.0, 5.2, 5.3) on gd based terminals, test has delay for first try

set term png
set out 'test.png'
test # delay more than 30 seconds for me


second execution test does not take time

On gnuplot 4.6.7, delay does not happen.

Any suggestions?

Tatsuro