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

Re: pause mouse any: wrong key for MB1

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

I have just tried the current cvs to which the enclosed patch has been applied 
but all the commands
 	pause mouse ...
do not work now (gnuplot command prompt is frozen till Ctrl/C).
Can you please repair it?
Thanks, Petr


On Thu, 31 Jul 2014, sfeam wrote:

> On Thursday, 31 July 2014 03:40:40 PM Petr Mikulik wrote:
>> More observation for various gnuplot versions:
>>
>> 4.6.1:		MB1 returns correct value
>>
>> 4.6.2 - 4.6.4:	"pause mouse any" ignores MB1
>>  		"pause mouse button1" never ends
>>
>> 4.6.5:		pause mouse works, but returns incorrect value of MB1
>>
>>
>> (I have found this problem as ginput() of Octave broke after a change of
>> gnuplot binary from /usr/bin (OpenSUSE 12.3) to /usr/local/bin.)
>>
>>> ----- Original Message -----
>>>> I've noticed that
>>>>     plot x
>>>>     pause mouse any
>>>>     show var
>>>>
>>>> does not work correctly if you click MB1; it produces
>>>>          MOUSE_KEY = 1063
>>>>          MOUSE_CHAR = "'"
>>>> instead of
>>>>          MOUSE_BUTTON = 1
>>>>          MOUSE_KEY = 1
>>>>          MOUSE_CHAR = "\001"
>>>>
>>>> It works fine for gnuplot 4.5.1 but is wrong in the latests releases including
>>>> cvs, using all x11, wxt and qt terminals.
>>>>
>>>> What's going wrong?
>
> I don't have time to test this properly, but the following may fix it.
> %%%%%%
> --- gnuplot/src/mouse.c	2014-07-22 22:45:48.000000000 -0700
> +++ gnuplot-cvs/src/mouse.c	2014-07-31 22:15:36.096081154 -0700
> @@ -1816,7 +1816,13 @@ event_buttonpress(struct gp_event_t *ge)
>     } else if (ALMOST2D) {
>         if (!setting_zoom_region) {
> 	    if (1 == b) {
> -	      /* not bound in 2d graphs */
> +	      /* "pause button1" or "pause any" takes precedence over key bindings */
> +		if (paused_for_mouse & PAUSE_BUTTON1) {
> +		    load_mouse_variables(mouse_x, mouse_y, TRUE, b);
> +		    event_reset(ge);
> +		    return;
> +		}
> +
> 	    } else if (2 == b) {
> 		/* not bound in 2d graphs */
> 	    } else if (3 == b &&
> %%%%%%
>
> 	Ethan

Re: pause mouse any: wrong key for MB1

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

On Thursday, 31 July 2014 03:40:40 PM Petr Mikulik wrote:
> More observation for various gnuplot versions:
> 
> 4.6.1:		MB1 returns correct value
> 
> 4.6.2 - 4.6.4:	"pause mouse any" ignores MB1
>  		"pause mouse button1" never ends
> 
> 4.6.5:		pause mouse works, but returns incorrect value of MB1
> 
> 
> (I have found this problem as ginput() of Octave broke after a change of 
> gnuplot binary from /usr/bin (OpenSUSE 12.3) to /usr/local/bin.)
> 
> > ----- Original Message -----
> >> I've noticed that
> >>     plot x
> >>     pause mouse any
> >>     show var
> >> 
> >> does not work correctly if you click MB1; it produces
> >>          MOUSE_KEY = 1063
> >>          MOUSE_CHAR = "'"
> >> instead of
> >>          MOUSE_BUTTON = 1
> >>          MOUSE_KEY = 1
> >>          MOUSE_CHAR = "\001"
> >> 
> >> It works fine for gnuplot 4.5.1 but is wrong in the latests releases including 
> >> cvs, using all x11, wxt and qt terminals.
> >> 
> >> What's going wrong?

I don't have time to test this properly, but the following may fix it.
%%%%%%
--- gnuplot/src/mouse.c	2014-07-22 22:45:48.000000000 -0700
+++ gnuplot-cvs/src/mouse.c	2014-07-31 22:15:36.096081154 -0700
@@ -1816,7 +1816,13 @@ event_buttonpress(struct gp_event_t *ge)
     } else if (ALMOST2D) {
         if (!setting_zoom_region) {
 	    if (1 == b) {
-	      /* not bound in 2d graphs */
+	      /* "pause button1" or "pause any" takes precedence over key bindings */
+		if (paused_for_mouse & PAUSE_BUTTON1) {
+		    load_mouse_variables(mouse_x, mouse_y, TRUE, b);
+		    event_reset(ge);
+		    return;
+		}
+
 	    } else if (2 == b) {
 		/* not bound in 2d graphs */
 	    } else if (3 == b && 
%%%%%%

	Ethan

Re: pause mouse any: wrong key for MB1

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

More observation for various gnuplot versions:

4.6.1:		MB1 returns correct value

4.6.2 - 4.6.4:	"pause mouse any" ignores MB1
 		"pause mouse button1" never ends

4.6.5:		pause mouse works, but returns incorrect value of MB1


(I have found this problem as ginput() of Octave broke after a change of 
gnuplot binary from /usr/bin (OpenSUSE 12.3) to /usr/local/bin.)

> ----- Original Message -----
>> I've noticed that
>>     plot x
>>     pause mouse any
>>     show var
>> 
>> does not work correctly if you click MB1; it produces
>>          MOUSE_KEY = 1063
>>          MOUSE_CHAR = "'"
>> instead of
>>          MOUSE_BUTTON = 1
>>          MOUSE_KEY = 1
>>          MOUSE_CHAR = "\001"
>> 
>> It works fine for gnuplot 4.5.1 but is wrong in the latests releases including 
>> cvs, using all x11, wxt and qt terminals.
>> 
>> What's going wrong?


---
Petr Mikulik

Re: small fix for 64-bit Windows build

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

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

> From: Tatsuro MATSUOKA 
> To: Allin Cottrell ; gnuplot-beta
> Cc: 
> Date: 2014/7/30, Wed 09:15
> Subject: Re: small fix for 64-bit Windows build
> 
> ----- Original Message -----
> 
>>  From: Allin Cottrell 
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2014/7/28, Mon 21:26
>>  Subject: small fix for 64-bit Windows build
>> 
>>  In current CVS (on the 4.6 branch at least) the initial gnuplot screen 
> shows the 
>>  "Build System" as "MS-Windows 32 bit" for a Windows 
> build 
>>  regardless of the actual word length. The attached small patch to 
> src/syscfg.h 
>>  fixes this.
> 
> 
> I also noticed the phenomena and had been applied modification as a local 
> patch. 
> 
> The patch is applied to only cvs (5.0rc) branch but not 4.6-stable branch.
> The phenomenon was found in the 4.6 branch and 4.6 branch now supports win64 
> build.
> 
> 2013-07-04  Bastian Maerkisch  <bma...@we...>
> 
> * src/internal.c src/win/wcommon.h src/win/wgraph.c src/win/winmain.c
> src/win/wmenu.c src/win/wprinter.c src/win/wtext.c  
> src/win/wgnuplot.rc src/win/wgnuplot.exe.manifest64:
> Backport support for Win64 from version 5 which was originally
> developed by Allin Cottrell.
> 
> So my opinion is that the patch is also better to be applied to 4.6 branch.
> 
> Tatsuro


The modification to 4.6 branch on 2014-07-28 breaks mingw build on both 32 and 64 bit using MinGW w64 complier.
I have filed the issue to the bug ticket and some workaround is shown:

https://sourceforge.net/p/gnuplot/bugs/1451/


Tatsuro

Re: pause mouse any: wrong key for MB1

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

----- Original Message -----
> From: Petr Mikulik 
> To: gnuplot-beta <gnuplot-beta
> Cc: 
> Date: 2014/7/30, Wed 23:38
> Subject: pause mouse any: wrong key for MB1
> 
> I've noticed that
>     plot x
>     pause mouse any
>     show var
> 
> does not work correctly if you click MB1; it produces
>          MOUSE_KEY = 1063
>          MOUSE_CHAR = "'"
> instead of
>          MOUSE_BUTTON = 1
>          MOUSE_KEY = 1
>          MOUSE_CHAR = "\001"
> 
> It works fine for gnuplot 4.5.1 but is wrong in the latests releases including 
> cvs, using all x11, wxt and qt terminals.
> 
> What's going wrong?


gnuplot 4.5.1?


Is this 4.4.1 or 4.6.1?

Tatsuro

pause mouse any: wrong key for MB1

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

I've noticed that
 	plot x
 	pause mouse any
 	show var

does not work correctly if you click MB1; it produces
         MOUSE_KEY = 1063
         MOUSE_CHAR = "'"
instead of
         MOUSE_BUTTON = 1
         MOUSE_KEY = 1
         MOUSE_CHAR = "\001"

It works fine for gnuplot 4.5.1 but is wrong in the latests releases including 
cvs, using all x11, wxt and qt terminals.

What's going wrong?

---
Petr Mikulik

Re: small fix for 64-bit Windows build

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

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

> From: Allin Cottrell 
> To: gnuplot-beta
> Cc: 
> Date: 2014/7/28, Mon 21:26
> Subject: small fix for 64-bit Windows build
> 
> In current CVS (on the 4.6 branch at least) the initial gnuplot screen shows the 
> "Build System" as "MS-Windows 32 bit" for a Windows build 
> regardless of the actual word length. The attached small patch to src/syscfg.h 
> fixes this.


I also noticed the phenomena and had been applied modification as a local patch. 

The patch is applied to only cvs (5.0rc) branch but not 4.6-stable branch.
The phenomenon was found in the 4.6 branch and 4.6 branch now supports win64 build.

2013-07-04  Bastian Maerkisch  <bma...@we...>

* src/internal.c src/win/wcommon.h src/win/wgraph.c src/win/winmain.c
src/win/wmenu.c src/win/wprinter.c src/win/wtext.c  
src/win/wgnuplot.rc src/win/wgnuplot.exe.manifest64:
Backport support for Win64 from version 5 which was originally
developed by Allin Cottrell.

So my opinion is that the patch is also better to be applied to 4.6 branch.

Tatsuro

small fix for 64-bit Windows build

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

In current CVS (on the 4.6 branch at least) the initial gnuplot screen 
shows the "Build System" as "MS-Windows 32 bit" for a Windows build 
regardless of the actual word length. The attached small patch to 
src/syscfg.h fixes this.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: invisible grid in current CVS

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

On Fri, 25 Jul 2014, Ethan A Merritt wrote:

> On Friday, 25 July, 2014 20:18:33 Allin Cottrell wrote:
>> I'm comparing the grid lines shown by gnuplot 4.6.5 and gnuplot 5.0 rc1
>> (CVS as of 2014-07-25) for the following script:
>>
>> set term pngcairo
>> set output 'test.png'
>> set grid ytics
>> plot sin(x)
>>
>> In 4.6.5 the grid is fairly discreet but clearly visible. In CVS it's
>> pretty much subliminal, barely visible. Is this intended?
>
> I was just noticing the same thing in some plots I was preparing today.
> Not sure what's going on there.
> The grid is also [supposed to be] dotted, so maybe there is an
> interaction between the new dot/dash code and the grid linetype?

Follow-up: various terminals that behaved cconsistently in respect of grid 
lines in 4.6.5 (all showing suitable dotted black lines) now behave quite 
differently in CVS. Three that are of particular interest to me behave 
thus:

pngcairo: grid lines practically invisible (not good, too light)
pdfcairo: grid lines solid black (not good, too heavy)
postscript, eps: still OK, as in 4.6.5.

I've taken a look at what I take to be the relevant source, but I can't 
grok all the macros that seem to be doing the work.

Allin Cottrell

Re: invisible grid in current CVS

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

On Friday, 25 July, 2014 20:18:33 Allin Cottrell wrote:
> I'm comparing the grid lines shown by gnuplot 4.6.5 and gnuplot 5.0 rc1 
> (CVS as of 2014-07-25) for the following script:
> 
> set term pngcairo
> set output 'test.png'
> set grid ytics
> plot sin(x)
> 
> In 4.6.5 the grid is fairly discreet but clearly visible. In CVS it's 
> pretty much subliminal, barely visible. Is this intended?

I was just noticing the same thing in some plots I was preparing today.
Not sure what's going on there.
The grid is also [supposed to be] dotted, so maybe there is an 
interaction between the new dot/dash code and the grid linetype?

	Ethan

invisible grid in current CVS

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

I'm comparing the grid lines shown by gnuplot 4.6.5 and gnuplot 5.0 rc1 
(CVS as of 2014-07-25) for the following script:

set term pngcairo
set output 'test.png'
set grid ytics
plot sin(x)

In 4.6.5 the grid is fairly discreet but clearly visible. In CVS it's 
pretty much subliminal, barely visible. Is this intended?

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: --without-x and 'make check' will create broken symlink to gnuplot_x11

[Jun T. <tak...@kb...>]

On 2014/07/18, at 3:46, Ethan Merritt <eam...@gm...> wrote:
> so I am inclined to remove the symlink
> generation from the demo Makefile. 

I have no idea what is "the correct" fix here, because I don't
know how many uses are (or will be) using --program-suffix.

If --program-suffix is ever being used, however, I feel the problem
that it doesn't work for qt terminal is somewhat more serious,
because the finally installed gnuplot (not 'make check') is broken.
It may be fixed by, for example, importing the method used in
term/x11.term (line 218-222) to src/qtterminal/qt_term.cpp (line 228).
But if nobody is complaining about this problem, maybe it can be left
as is (probably only very few people are using --program-suffix).

Re: --without-x and 'make check' will create broken symlink to gnuplot_x11

[Ethan M. <eam...@gm...>]

I suspect that the --program-suffix option was not taken into account
when putting together the gnuplot build system. I assume the reason
for adding a suffix is so that you can have multiple versions. The
build system assumes that this is handled by placing a file with a
fixed name in a version-specific directory, not by placing
alternatively named files in a single directory.

If you really need this capability, I think the build system would
have to be modified so that selection of the --program-suffix option
actually modifies the source of .../term/x11.trm to call the outboard
driver using a different name.  But I honestly don't see why this is
desirable.

Meanwhile your original observation that the "make check" can break if
x11 is not used remains true, so I am inclined to remove the symlink
generation from the demo Makefile.  I would expect that anyone who
understands this well enough to select --program-suffix also knows
enough to create a symlink themself if necessary.

  Ethan


On Wed, Jul 16, 2014 at 4:28 PM, Jun T. <tak...@kb...> wrote:
>
> 2014/07/17 06:26、Ethan A Merritt <sf...@us...> のメール：
>
>>> i.e., gnuplot-5 tries to start gnuplot_qt but in $HOME/libexec there is
>>> gnuplot_qt-5 but not gnuplot_qt (assuming I haven't installed gnuplot
>>> with --prefix=$HOME but without --program-suffix before).
>>
>> That is the purpose of the environment variable GNUPLOT_DRIVER_DIR.
>
> Yes, I know.
> Please notice that I added --program-suffix='-5' to the configure options.
> After I run 'make install', gnuplot-5 is installed in $prefix/bin/,
> and gnuplot_qt-5 is installed in $prefix/libexec/gnuplot/5.0/gnuplot_qt-5.
> But If I start $prefix/bin/gnuplot-5, it tries to start
> $prefix/libexec/gnuplot/5.0/gnuplot_qt, which does not exists.
> I guess in the case of x11 terminal $prefix/bin/gnuplot will start
> $prefix/libexec/gnuplot/5.0/gnuplot_x11-5 (NOT gnuplot_x11) to avoid
> this problem.
>
>> .../demo/Makefile sets this to GNUPLOT_DRIVER_DIR=$$bdir/../src
>> so that gnuplot_x11 and gnuplot_qt are correctly found in the build directory
>> rather than in the system install directory (since "make check" can be run
>> before installation).
>
> In the case of qt terminal, src/gnuplot (not yet installed; run while
> make check) tries to start $GNUPLOT_DRIVER_DIR/gnuplot_qt, which exists.
> I guess (just a guess) that, in the case of x11 terminal, src/gnuplot
> will try to start $GNUPLOT_DRIVER_DIR/gnuplot_x11-5, which does NOT exist.
> So 'make check' will make a symlink in src/ (i.e., in GNUPLOT_DRIVER_DIR) as
> ln -s gnuplot_x11 gnuplot_x11-5
>

Re: --without-x and 'make check' will create broken symlink to gnuplot_x11

[Jun T. <tak...@kb...>]

(I'm resending this because I've forgot to include gnuplot-beta in To:)

2014/07/17 06:26, Ethan A Merritt <sf...@us...> wrote:

>> i.e., gnuplot-5 tries to start gnuplot_qt but in $HOME/libexec there is
>> gnuplot_qt-5 but not gnuplot_qt (assuming I haven't installed gnuplot
>> with --prefix=$HOME but without --program-suffix before).
> 
> That is the purpose of the environment variable GNUPLOT_DRIVER_DIR.

Yes, I know.
Please notice that I added --program-suffix='-5' to the configure options.
After I run 'make install', gnuplot-5 is installed in $prefix/bin/,
and gnuplot_qt-5 is installed in $prefix/libexec/gnuplot/5.0/gnuplot_qt-5.
But If I start $prefix/bin/gnuplot-5, it tries to start
$prefix/libexec/gnuplot/5.0/gnuplot_qt, which does not exists.
I guess in the case of x11 terminal $prefix/bin/gnuplot will start
$prefix/libexec/gnuplot/5.0/gnuplot_x11-5 (NOT gnuplot_x11) to avoid
this problem.

> .../demo/Makefile sets this to GNUPLOT_DRIVER_DIR=$$bdir/../src
> so that gnuplot_x11 and gnuplot_qt are correctly found in the build directory
> rather than in the system install directory (since "make check" can be run
> before installation).

In the case of qt terminal, src/gnuplot (not yet installed; run while
make check) tries to start $GNUPLOT_DRIVER_DIR/gnuplot_qt, which exists.
I guess (just a guess) that, in the case of x11 terminal, src/gnuplot
will try to start $GNUPLOT_DRIVER_DIR/gnuplot_x11-5, which does NOT exist.
So 'make check' will make a symlink in src/ (i.e., in GNUPLOT_DRIVER_DIR) as
ln -s gnuplot_x11 gnuplot_x11-5

Re: --without-x and 'make check' will create broken symlink to gnuplot_x11

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

On Thursday, 17 July, 2014 04:48:22 Jun T. wrote:
> 
> 2014/07/17 02:26, Ethan A Merritt <sf...@us...> wrote:
> 
> > Does anyone know what was the original intent of creating a symlink?
> 
> The following is just my guess; not tested on Linux with x11 terminal.
> I can test only on Mac now, but:
> 
> $ ./configure --prefix=$HOME --program-suffix='-5' --with-qt ...
> $ make
> 
> then gnuplot and gnuplot_qt are built in src/, and
> 
> $ make install
> 
> this will install gnuplot as $HOME/bin/gnuplot-5, and gnuplot_qt as
> $HOME/libexec/gnuplot/5.0/gnuplot_qt-5 (they are renamed when installed).
> But qt terminal doesn't work:
> 
> $ $HOME/bin/gnuplot-5
> gnuplot> set term qt
> gnuplot> plot sin(x)
> Could not start gnuplot_qt with path "$HOME/libexec/gnuplot/5.0/gnuplot_qt"
> 
> i.e., gnuplot-5 tries to start gnuplot_qt but in $HOME/libexec there is
> gnuplot_qt-5 but not gnuplot_qt (assuming I haven't installed gnuplot
> with --prefix=$HOME but without --program-suffix before).

That is the purpose of the environment variable GNUPLOT_DRIVER_DIR.

.../demo/Makefile sets this to GNUPLOT_DRIVER_DIR=$$bdir/../src
so that gnuplot_x11 and gnuplot_qt are correctly found in the build directory
rather than in the system install directory (since "make check" can be run
before installation).

	Ethan

Re: --without-x and 'make check' will create broken symlink to gnuplot_x11

[Jun T. <tak...@kb...>]

2014/07/17 02:26, Ethan A Merritt <sf...@us...> wrote:

> Does anyone know what was the original intent of creating a symlink?

The following is just my guess; not tested on Linux with x11 terminal.
I can test only on Mac now, but:

$ ./configure --prefix=$HOME --program-suffix='-5' --with-qt ...
$ make

then gnuplot and gnuplot_qt are built in src/, and

$ make install

this will install gnuplot as $HOME/bin/gnuplot-5, and gnuplot_qt as
$HOME/libexec/gnuplot/5.0/gnuplot_qt-5 (they are renamed when installed).
But qt terminal doesn't work:

$ $HOME/bin/gnuplot-5
gnuplot> set term qt
gnuplot> plot sin(x)
Could not start gnuplot_qt with path "$HOME/libexec/gnuplot/5.0/gnuplot_qt"

i.e., gnuplot-5 tries to start gnuplot_qt but in $HOME/libexec there is
gnuplot_qt-5 but not gnuplot_qt (assuming I haven't installed gnuplot
with --prefix=$HOME but without --program-suffix before).

I guess x11 terminal is 'fixed' so that gnuplot_x11-5 (not gnuplot_x11)
is correctly called. But when we run 'make check', gnuplot_x11 is in src/
but gnuplot_x11-5 is not, so 'make check' will create a symlink as
ln gnuplot_x11 gnuplot_x11-5.

Re: --without-x and 'make check' will create broken symlink to gnuplot_x11

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

On Wednesday, 16 July, 2014 21:47:30 Jun T. wrote:
> If I build gnuplot by
> 
> $ ./configure --without-x ...
> $ make
> 
> then gnuplot_x11 is not built, of course. But if I run
> 
> $ make DEMO=xxx.dem check
> 
> then a broken symlink src/gnuplot_x11 is created which points
> to itself.

Very strange.  I have no idea why it does that.

> If I run 'make check' again (with different value
> for DEMO, for example), then it fails as:
> 
> Mac:
>   ln: ../src/gnuplot_x11: File exists
> Linux:
>   ln: accessing `../src/gnuplot_x11': Too many levels of symbolic links
> 
> and I must manually remove the symlink. Not serious but annoying.
> A possible fix is at the end of this post.

I suspect a better fix is to remove that whole section of the Makefile.
It isn't needed for any other terminal, and I don't see why it would be
needed for X11 either:

%%%%%%
--- old/gnuplot/demo/Makefile.am.in	2014-03-03 10:36:23.000000000 -0800
+++ new/gnuplot/demo/Makefile.am.in	2014-07-16 10:07:03.000000000 -0700
@@ -21,13 +21,7 @@
 	@echo Creating binary data files
 	@../src/bf_test
 
-transform = @program_transform_name@
-GNUPLOT_X11 = `echo gnuplot_x11 | sed '$(transform)'`$(EXEEXT)
-
 check-prepare:
-	@if test ! -e "$(top_builddir)/src/$(GNUPLOT_X11)"; then\
-	   $(LN_S) gnuplot_x11 $(top_builddir)/src/$(GNUPLOT_X11); \
-	fi
 
 check-local: check-noninteractive
 
%%%%%%


Does anyone know what was the original intent of creating a symlink?

	Ethan



> 
> # I guess gnuplot_x11 should be gnuplot_x11$(EXEEXT) if anyone ever
> # builds x11 terminal on Windows and installs it with a name other than
> # gnuplot_x11.exe. But I can't test on Windows (cygwin with X11?).
> 
> Another minor problem is that this broken symlink src/gnuplot_x11 is
> not removed by 'make clean' or 'make distclean' if qt terminal is not
> built. src/Makefile.am has 
> 
> clean-demo:
>        rm -f $(GNUPLOT_X11)
> 
> but it is in the block "if BUILD_QT ... endif". Why?
> 
> Jun
> 
> 
> 
> Index: demo/Makefile.am.in
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/demo/Makefile.am.in,v
> retrieving revision 1.40
> diff -u -r1.40 Makefile.am.in
> --- demo/Makefile.am.in	2 Mar 2014 06:23:55 -0000	1.40
> +++ demo/Makefile.am.in	16 Jul 2014 06:04:51 -0000
> @@ -25,7 +25,8 @@
> GNUPLOT_X11 = `echo gnuplot_x11 | sed '$(transform)'`$(EXEEXT)
> 
> check-prepare:
> -	@if test ! -e "$(top_builddir)/src/$(GNUPLOT_X11)"; then\
> +	@if test ! -e "$(top_builddir)/src/$(GNUPLOT_X11)" \
> +	        -a -e "$(top_builddir)/src/gnuplot_x11"; then
>  	   $(LN_S) gnuplot_x11 $(top_builddir)/src/$(GNUPLOT_X11); \
>  	fi
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

--without-x and 'make check' will create broken symlink to gnuplot_x11

[Jun T. <tak...@kb...>]

If I build gnuplot by

$ ./configure --without-x ...
$ make

then gnuplot_x11 is not built, of course. But if I run

$ make DEMO=xxx.dem check

then a broken symlink src/gnuplot_x11 is created which points
to itself. If I run 'make check' again (with different value
for DEMO, for example), then it fails as:

Mac:
  ln: ../src/gnuplot_x11: File exists
Linux:
  ln: accessing `../src/gnuplot_x11': Too many levels of symbolic links

and I must manually remove the symlink. Not serious but annoying.
A possible fix is at the end of this post.

# I guess gnuplot_x11 should be gnuplot_x11$(EXEEXT) if anyone ever
# builds x11 terminal on Windows and installs it with a name other than
# gnuplot_x11.exe. But I can't test on Windows (cygwin with X11?).

Another minor problem is that this broken symlink src/gnuplot_x11 is
not removed by 'make clean' or 'make distclean' if qt terminal is not
built. src/Makefile.am has 

clean-demo:
       rm -f $(GNUPLOT_X11)

but it is in the block "if BUILD_QT ... endif". Why?

Jun



Index: demo/Makefile.am.in
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/demo/Makefile.am.in,v
retrieving revision 1.40
diff -u -r1.40 Makefile.am.in
--- demo/Makefile.am.in	2 Mar 2014 06:23:55 -0000	1.40
+++ demo/Makefile.am.in	16 Jul 2014 06:04:51 -0000
@@ -25,7 +25,8 @@
GNUPLOT_X11 = `echo gnuplot_x11 | sed '$(transform)'`$(EXEEXT)

check-prepare:
-	@if test ! -e "$(top_builddir)/src/$(GNUPLOT_X11)"; then\
+	@if test ! -e "$(top_builddir)/src/$(GNUPLOT_X11)" \
+	        -a -e "$(top_builddir)/src/gnuplot_x11"; then
 	   $(LN_S) gnuplot_x11 $(top_builddir)/src/$(GNUPLOT_X11); \
 	fi

Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect

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

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

> From: Allin Cottrell 
> To: Ethan A Merritt 
> Cc: gnuplot-beta> Date: 2014/7/16, Wed 09:16
> Subject: Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect
> 
> On Tue, 15 Jul 2014, Ethan A Merritt wrote:
> 
>>  On Tuesday, 15 July, 2014 19:36:23 Allin Cottrell wrote:
>>> 
>>>  While we're on this topic, this is not not due to a problem at
>>>  sourceforge: at the URL
>>> 
>>>  http://www.gnuplot.info/download.html
>>> 
>>>  we read that the current gnuplot version is 4.6.0 (March 8, 2012).
>>>  Not surprisingly, this is the #1 hit when one googles "current
>>>  gnuplot version". I'd recommend that this page be updated or
>>>  (preferably) replaced by a redirect to sourceforge.
>> 
>>  Update - yes (done)
>>  Redirect - I don't understand. The page already lives on SourceForge.
> 
> On the redirect issue: it seems I was misled by the prima facie URL, 
> http://www.gnuplot.info/download.html
> 
> Nonetheless, I think that this page is an unnecessary hostage to 
> fortune (do you really want to have to remember to update it after 
> every release?), and might better redirect to 
> http://sourceforge.net/projects/gnuplot/files/
> 
> Allin Cottrell
> 


In the http://sourceforge.net/projects/gnuplot/files/
I found old description:


Binary packages for Windows
    4.6.5 final release versions not here yet
    testing version (gp465-win32-mingw-rc1) available in testing folder

The above should be replaced by the corresponding part of 
http://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.5/

Binary packages for Windows
    gp465-win32-setup.exe   Windows binary installer
    gp465-win32.zip         Windows binary zip package

Tatsuro

Fwd: Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect

[Clark G. <cla...@fa...>]

Sorry, should have sent to the list.

Clark

---------- Forwarded message ----------
From: Clark Gaylord <cla...@fa...>
Date: Jul 15, 2014 8:17 PM
Subject: Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect
To: Ethan A Merritt <sf...@us...>
Cc: 

> The canonical name should be gnuplot.info
>
> For IPv4 today, this is the same thing as SourceForge (not a redirect). For IPv6 it actually still goes to Virginia Tech, since at last check the v6 connectivity at SourceForge was lagging. I should probably revisit that, but the point is that the SourceForge hosting is merely an accident of hosting (albeit where we've been for a while now), and all press should point to gnuplot.info.
>
> --ckg
>
> On Jul 15, 2014 7:52 PM, Ethan A Merritt <sf...@us...> wrote:
> >
> > On Tuesday, 15 July, 2014 19:36:23 Allin Cottrell wrote: 
> > > 
> > > While we're on this topic, this is not not due to a problem at 
> > > sourceforge: at the URL 
> > > 
> > > http://www.gnuplot.info/download.html 
> > > 
> > > we read that the current gnuplot version is 4.6.0 (March 8, 2012). 
> > > Not surprisingly, this is the #1 hit when one googles "current 
> > > gnuplot version". I'd recommend that this page be updated or 
> > > (preferably) replaced by a redirect to sourceforge. 
> >
> > Update - yes (done) 
> > Redirect - I don't understand. The page already lives on SourceForge. 
> >
> > > 
> > > Allin Cottrell 
> >
> > ------------------------------------------------------------------------------ 
> > Want fast and easy access to all the code in your enterprise? Index and 
> > search up to 200,000 lines of code with a free copy of Black Duck 
> > Code Sight - the same software that powers the world's largest code 
> > search on Ohloh, the Black Duck Open Hub! Try it now. 
> > http://p.sf.net/sfu/bds 
> > _______________________________________________ 
> > gnuplot-beta mailing list 
> > gnu...@li... 
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta 

Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect

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

On Tue, 15 Jul 2014, Ethan A Merritt wrote:

> On Tuesday, 15 July, 2014 19:36:23 Allin Cottrell wrote:
>>
>> While we're on this topic, this is not not due to a problem at
>> sourceforge: at the URL
>>
>> http://www.gnuplot.info/download.html
>>
>> we read that the current gnuplot version is 4.6.0 (March 8, 2012).
>> Not surprisingly, this is the #1 hit when one googles "current
>> gnuplot version". I'd recommend that this page be updated or
>> (preferably) replaced by a redirect to sourceforge.
>
> Update - yes (done)
> Redirect - I don't understand. The page already lives on SourceForge.

On the redirect issue: it seems I was misled by the prima facie URL, 
http://www.gnuplot.info/download.html

Nonetheless, I think that this page is an unnecessary hostage to 
fortune (do you really want to have to remember to update it after 
every release?), and might better redirect to 
http://sourceforge.net/projects/gnuplot/files/

Allin Cottrell

Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect

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

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

> From: Tatsuro MATSUOKA 
> To: Allin Cottrell merritt 
> Cc: gnuplot-beta
> Date: 2014/7/16, Wed 08:58
> Subject: Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect
> 
> ----- Original Message -----
> 
>>  From: Allin Cottrell 
>>  To: Ethan A Merritt 
>>  Cc: gnuplot-beta Tatsuro MATSUOKA 
>>  Date: 2014/7/16, Wed 08:36
>>  Subject: Re: http://www.gnuplot.info/development/index.html "see 
> ChangeLog" is incorrect
>>>   It seems the SourceForge site is having problems today.
>> 
>>  While we're on this topic, this is not not due to a problem at 
>>  sourceforge: at the URL
>> 
>>  http://www.gnuplot.info/download.html
>> 
>>  we read that the current gnuplot version is 4.6.0 (March 8, 2012). 
>>  Not surprisingly, this is the #1 hit when one googles "current 
>>  gnuplot version". I'd recommend that this page be updated or 
>>  (preferably) replaced by a redirect to sourceforge.
>> 
>>  Allin Cottrell
> 
> 
> I read the page that the current gnuplot version is 4.6.5 (Feb 2014). 
> In addition, I can see:
> 
> Version 5.0 coming soon
> 
> Testing versions here
> Release candidate 5.0.rc1 .
> 
> I suspect that your browser is cashed and stay old.
> 
> Tatsuro
> 


Sorry I have misled the situation. The page was just updated by Ethan before I looked it today.

Tatsuro

Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect

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

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

> From: Allin Cottrell 
> To: Ethan A Merritt 
> Cc: gnuplot-beta Tatsuro MATSUOKA 
> Date: 2014/7/16, Wed 08:36
> Subject: Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect
>>  It seems the SourceForge site is having problems today.
> 
> While we're on this topic, this is not not due to a problem at 
> sourceforge: at the URL
> 
> http://www.gnuplot.info/download.html
> 
> we read that the current gnuplot version is 4.6.0 (March 8, 2012). 
> Not surprisingly, this is the #1 hit when one googles "current 
> gnuplot version". I'd recommend that this page be updated or 
> (preferably) replaced by a redirect to sourceforge.
> 
> Allin Cottrell


I read the page that the current gnuplot version is 4.6.5 (Feb 2014). 

Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect

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

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

> From: Allin Cottrell 
> To: Ethan A Merritt 
> Cc: gnuplot-beta Tatsuro MATSUOKA 
> Date: 2014/7/16, Wed 08:36
> Subject: Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect
>>  It seems the SourceForge site is having problems today.
> 
> While we're on this topic, this is not not due to a problem at 
> sourceforge: at the URL
> 
> http://www.gnuplot.info/download.html
> 
> we read that the current gnuplot version is 4.6.0 (March 8, 2012). 
> Not surprisingly, this is the #1 hit when one googles "current 
> gnuplot version". I'd recommend that this page be updated or 
> (preferably) replaced by a redirect to sourceforge.
> 
> Allin Cottrell


I read the page that the current gnuplot version is 4.6.5 (Feb 2014). 
In addition, I can see:

Version 5.0 coming soon

Testing versions here
Release candidate 5.0.rc1 .

I suspect that your browser is cashed and stay old.

Tatsuro

Re: http://www.gnuplot.info/development/index.html "see ChangeLog" is incorrect

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

On Tuesday, 15 July, 2014 19:36:23 Allin Cottrell wrote:
> 
> While we're on this topic, this is not not due to a problem at 
> sourceforge: at the URL
> 
> http://www.gnuplot.info/download.html
> 
> we read that the current gnuplot version is 4.6.0 (March 8, 2012). 
> Not surprisingly, this is the #1 hit when one googles "current 
> gnuplot version". I'd recommend that this page be updated or 
> (preferably) replaced by a redirect to sourceforge.

Update - yes (done)
Redirect - I don't understand. The page already lives on SourceForge.

> 
> Allin Cottrell