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

Re: Any issues that would hold up release of 4.6.1?

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 20 September 2012, Mojca Miklavec wrote:
> On Thu, Sep 20, 2012 at 6:58 PM, Ethan Merritt wrote:
> > On Thu, Sep 20, 2012 at 4:34 AM, Mojca Miklavec
> > <moj...@gm...> wrote:
> >> The problem is that files
> >>         docs/gnuplot-eldoc.el
> >>         docs/gnuplot-eldoc.elc
> >>         docs/gnuplot.texi
> >> are generated inside sources instead of being generated in the
> >> directory where configure script is run (when doing out-of-source
> >> build). This seems to be a bug in Makefile.in. The files gnuplot.elc
> >> and gnuplot-gui.elc are installed properly (generated in the proper
> >> place). The gnuplot-eldoc.el[c] is not.
> >>
> >> Mojca
> >
> > I can't reproduce that under any set of conditions:
> >   1) normal emacs - check
> >   2) no emacs - check
> >   3) renamed emacs - check
> >
> > Are you building/installing directly from the CVS tree or are you
> > creating a distribution tarball and testing that?
> 
> I'm building directly from the CVS tree (branch-4-6-stable), but I'm
> doing an *out of source* configure/make.
> 
> Here would be the exact rules to reproduce the error:
> 
> ~> mkdir gnuplot && cd gnuplot
> ~/gnuplot> mkdir sources
> ~/gnuplot> mkdir build
> ~/gnuplot> cd sources
> ~/gnuplot/sources> <checkout here>
> ~/gnuplot/sources> ./prepare
> ~/gnuplot/sources> cd ../build
> ~/gnuplot/build> ../sources/configure --prefix=$PWD/install
> ~/gnuplot/build> make
> ~/gnuplot/build> make install # this fails

After fighting with this all day yesterday, I decided to instead
backport the emacs+info related Makefile scripting from 4.7 to 4.6.
Please let me know whether the modified .../docs/Makefile.in 
from today's CVS resolves your out-of-source build problems.

	Ethan

Re: Any issues that would hold up release of 4.6.1?

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

On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === emacs ===
>> Mojca Miklavec <moj...@gm...>
>> Not a major showstopper, but I would be grateful if someone could take
>> a look at the attached patch for emacs (and apply before the release
>> it if possible). The problem is that setting
>>     EMACS=/path/to/some/Emacs ./configure
>> is later "reset" with
>>     EMACS=`basename $EMACS`
>> in lisp/configure[.in], so version checking and all further
>> emacs-related operation fail to work properly since they call whatever
>> emacs/xemacs comes first in PATH instead of the one requested by user.
>
> I am very reluctant to make changes to the configuration system for 4.6.1
> that have not previously been tested in the development tree.
> That said, I am willing to have a look at this if you can you clarify
> what the problem actually is.
>
> Which of these is happening?
> 1) you have an "emacs" in your path that is incapable of compiling the
>    three files gnuplot.elc gnuplot-gui.elc gnuplot-eldoc.elc?
> 2) The version check to see if emacs is older than version 20.3 fails?
> 3) The *.elc files are compiled properly but installed in the wrong
>    site-lisp directory?
>
> As to (2) is any of this still needed?  The README says that the
> info-look.xxx files are a work-around for incompatibilities in ancient
> versions of emacs and Xemacs.  Can we just get rid of these files and
> get rid of that section of the Makefile?

I'm very grateful for removing that ancient portion of code from
lisp/configure.in, however the
     EMACS=`basename $EMACS`
line is still causing problems (both in trunk and in branch-4-6-stable).

Can someone else please test if the following works or fails for you?

    # provided that /usr/bin/emacs is a valid emacs binary
    ln -s /usr/bin/emacs /tmp/myemacs
    which myemacs
        # should not return anything
    cd /path/to/gnuplot
    EMACS=/tmp/myemacs ./configure
    make

For me it fails with:

./doc2gih ../../original/docs/gnuplot.doc gnuplot.gih
Making all in lisp
myemacs -batch -q -no-site-file -l ../../original/lisp/dot.el -f
batch-byte-compile gnuplot.el
make[2]: myemacs: No such file or directory
make[2]: *** [gnuplot.elc] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

And the following trivial patch solves the issue:

--- a/lisp/configure.in
+++ b/lisp/configure.in
@@ -13,8 +13,6 @@ AC_SET_MAKE
 AC_PROG_INSTALL
 AM_PATH_LISPDIR

-EMACS=`basename $EMACS`
-
 AC_CHECK_PROGS(DVIPS, dvips, no)
 AC_CHECK_PROGS(LATEX, latex latex2e, no)
 AC_PATH_PROG(MAKEINFO, makeinfo, no)

Is this only a problem on my machine or are others able to reproduce
the problem?

(The line used to be used until recently to be able to compare if
$EMACS equals to "emacs" or "xemacs", but those lines have gone, so I
don't see any good reason to keep that line any more.)

Thank you very much,
    Mojca

PS: I know that calling emacs "myemacs" might seems like an imaginary
problem, but it is a real problem on Mac OS X where (the desired)
EMACS binary is often not in PATH and it is called "Emacs", with
uppercase, and it either fails completely or uses the wrong binary.
This is just a simple minimal example which should demonstrate the
problem on systems other than Mac.

Re: Any issues that would hold up release of 4.6.1?

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

On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === BOOLEANS ===
>> Mojca Miklavec <moj...@gm...>
>> Definitions of BOOL are still problematic (and configuration is broken
>> on Solaris, older Macs, ...).
>
> My understanding of the situation on Solaris is that no single fix will
> work for all versions of Solaris.

I admit that I don't know enough of Solaris, but the current approach with
    #if defined(__SUNPRO_CC)
and so on (possibly for every single compiler on the planet) is
somewhat doomed to fail.

The problematic code is not the solaris-specific one, but the whole
block in src/syscfg.h starting with #if HAVE_STDBOOL_H.

The reason why 99.9% users don't notice any problem is because of this chunk:

    #if HAVE_STDBOOL_H
    # include <stdbool.h> /* this part is OK and covers 99% users */
    #else
    /* here is where it gets problematic/wrong; it works/workeded only
until C++ code has been added ... */
    #fi

Most users never see the problematic else part. In principle that part
should work for everyone (even thouse with HAVE_STDBOOL_H defined to
true), but currently that is not the case.

> The versions differ from each other,
> and the requirements for C++ reportedly conflict with those for C.

True. The main problem is that one can have _Bool and the other one
not. Actually, there is no reason why C++ would need a "_Bool" type if
it already has "bool". So most of the time it's only a question of
whether _Bool is defined in C. But the conditional behaves as if _Bool
either has to be defined in both C/C++ or in none of them, and then
tries to do
    # define bool _Bool
in C++, that is: break a previously working "bool" by redefining it to
a nonexistent "_Bool".

> But I'm working from ignorance, relying on Solaris users to provide help.
> I have 2 (3?) times previously applied patches that were submitted to
> handle Bool on some version of Solaris, and each time people reported
> that the change caused breakage on other systems.  So unless someone has
> a patch that has been well tested on multiple versions of Solaris,
> I won't touch this.

Why not trusting developers of gnulib with a wide user base and their
code being used on most exotic system?
Or simply use the most trivial code that works?

My guess would be that the following should work (or at least cover 9
out of 10 currently problematic cases):

#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# ifndef __cplusplus
# if ! HAVE__BOOL
typedef unsigned char _Bool;
# endif
# define bool _Bool
# define false 0
# define true 1
# endif
#endif

but then again, taking code from gnulib should be a much better tested
solution. (If any system lacks "bool" in C++, the code above won't
cover that.)

> It is of course unfortunate that the Solaris compilers have a problem
> with standard C/C++ Booleans.  It is likewise unfortunate that MSVC isn't
> ANSI-compliant with regard to initializing named fields in a structure,
> and unfortunate that some platforms lack a usable version of snprintf().
> We do try to accommodate in the source code where possible, but at some
> point it's just not worth the effort.
>
> Anyhow, this is clearly a long-term issue and not something that can
> quickly be patched for 4.6.1.

Given the broad number of exotic software where this needs to be tested ...
I agree, putting a patch into trunk might actually be a safer bet.

Mojca

PS: current code from gnulib, with comments stripped off:

#if defined __BEOS__ && !defined __HAIKU__
# include <OS.h> /* defines bool but not _Bool */
# undef false
# undef true
#endif

#ifdef __cplusplus
# define _Bool bool
# define bool bool
#else
# if defined __BEOS__ && !defined __HAIKU__
#  if !HAVE__BOOL
typedef bool _Bool;
#  endif
# else
#  if !defined __GNUC__
#   define _Bool signed char
#  else
#   if !HAVE__BOOL
typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
#   endif
#  endif
# endif
# define bool _Bool
#endif

#ifdef __cplusplus
# define false false
# define true true
#else
# define false 0
# define true 1
#endif

#define __bool_true_false_are_defined 1

Re: Any issues that would hold up release of 4.6.1?

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

On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === Aquaterm ===
>> Mojca Miklavec <moj...@gm...>
>> I would be very very grateful if this patch could be applied:
>> http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-configure-aquaterm.diff?rev=96897
>> (only "configure.in", "m4/apple.m4" and the first line of "term/aquaterm.trm")
>> --- configure.in.orig
>> +++ configure.in
>> @@ -1366,5 +1366,5 @@
>>
>> -if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then
>> +if test "$with_aquaterm" = yes; then
>>    AC_MSG_RESULT([  aqua terminal: yes])
>>  else
>>    AC_MSG_RESULT([  aqua terminal: no])
>
> That change is not in the main branch. Are you sure it is needed?

The main branch has not been patched either. (This patch is only valid
[and required] iff new m4/apple.m4 is included.)

>> m4/apple.m4
> This patch bears little resemblance to what is currently in 4.7.

That patch was against 4.6.0. I'm attaching apple.m4 just in case.

> Does the build system in 4.7 work, or not?

Not without extra fiddling of the system.

> If the 4.7 version does work, should I just copy it to 4.6?
> If not, then please submit a patch against 4.7 rather than 4.6
> and we'll work from there.

Attached.

>> term/aquaterm.trm
>> --- term/aquaterm.trm.orig
>> +++ term/aquaterm.trm
>> @@ -94,3 +94,3 @@
>>  #ifdef TERM_BODY
>> -#import <aquaterm/AQTAdapter.h>
>> +#import <AquaTerm/AQTAdapter.h>
>
> OK.

The same holds here: this should only be included iff the m4/apple.m4
is patched at the same time.

Mojca

Re: Any issues that would hold up release of 4.6.1?

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

On Tue, Sep 18, 2012 at 8:48 PM, Ethan A Merritt wrote:
>
> === emacs ===
>> Mojca Miklavec <moj...@gm...>
>> Not a major showstopper, but I would be grateful if someone could take
>> a look at the attached patch for emacs (and apply before the release
>> it if possible). The problem is that setting
>>     EMACS=/path/to/some/Emacs ./configure
>> is later "reset" with
>>     EMACS=`basename $EMACS`
>> in lisp/configure[.in], so version checking and all further
>> emacs-related operation fail to work properly since they call whatever
>> emacs/xemacs comes first in PATH instead of the one requested by user.
>
> I am very reluctant to make changes to the configuration system for 4.6.1
> that have not previously been tested in the development tree.
> That said, I am willing to have a look at this if you can you clarify
> what the problem actually is.

To understand the problem better please try the following
    ln -s /usr/bin/emacs /tmp/myemacs
    EMACS=/tmp/myemacs ./configure

> Which of these is happening?
>
> 1) you have an "emacs" in your path that is incapable of compiling the
>    three files gnuplot.elc gnuplot-gui.elc gnuplot-eldoc.elc?
> 2) The version check to see if emacs is older than version 20.3 fails?
> 3) The *.elc files are compiled properly but installed in the wrong
>    site-lisp directory?

In my case none of the above. But two other things go wrong:
1.) The code
    if test "$EMACS" = emacs ; then
doesn't recognize uppercase "Emacs". There's nothing wrong with that
since I'm not interested in the patch anyway, but the "else" part
doesn't reset
    INFO_LOOK_ELC=
so after
    EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
../gnuplot/configure && make
I end up with

Wrote /tmp/gnuplot-build/lisp/gnuplot.elc
Emacs -batch -q -no-site-file -l ../../gnuplot/lisp/dot.el -f
batch-byte-compile gnuplot-gui.el
Wrote /tmp/gnuplot-build/lisp/gnuplot-gui.elc
make[2]: *** No rule to make target `info-look.elc', needed by `elcs'.  Stop.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

2.) Version checking is either done with the wrong EMACS binary, or
not at all (if that binary is not the first one with the same name in
path). Gnuplot first accepts user's explicit request to use a specific
binary like
    /Applications/Emacs.app/Contents/MacOS/Emacs
in my case, but then tries to call
    Emacs --version
which either uses /usr/bin/emacs or /opt/local/bin/emacs (a different
binary) from PATH or completely fails in case of case sensitive file
systems. In the example I suggested above compilation breaks with

./doc2gih ../../gnuplot/docs/gnuplot.doc gnuplot.gih
Making all in lisp
myemacs -batch -q -no-site-file -l ../../gnuplot/lisp/dot.el -f
batch-byte-compile gnuplot.el
make[2]: myemacs: No such file or directory
make[2]: *** [gnuplot.elc] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


> As to (2) is any of this still needed?  The README says that the
> info-look.xxx files are a work-around for incompatibilities in ancient
> versions of emacs and Xemacs.  Can we just get rid of these files and
> get rid of that section of the Makefile?

(I wanted to suggest that, but didn't dare to.)

Mojca

Re: Any issues that would hold up release of 4.6.1?

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

> On Monday, September 17, 2012 04:08:25 pm Ethan A Merritt wrote:
> > Is anyone aware of an unresolved bug or other reason to hold off
> > release of version 4.6.1?  If not, I will probably package it up
> > for release next weekend.
>  

=== qt ===
> Daniel J Sebald <dan...@ie...>
> Is Qt terminal in 4.6.1?  The only thing I can think of is supporting 
> Windows properly in Qt term, but no volunteers with a Windows machine 
> have stepped forward yet.

Qt was already added in 4.6.0.  4.6.1 will contain a few already-applied 
patches related to installation on OSX.  


=== emacs ===
> Mojca Miklavec <moj...@gm...>
> Not a major showstopper, but I would be grateful if someone could take
> a look at the attached patch for emacs (and apply before the release
> it if possible). The problem is that setting
>     EMACS=/path/to/some/Emacs ./configure
> is later "reset" with
>     EMACS=`basename $EMACS`
> in lisp/configure[.in], so version checking and all further
> emacs-related operation fail to work properly since they call whatever
> emacs/xemacs comes first in PATH instead of the one requested by user.

I am very reluctant to make changes to the configuration system for 4.6.1
that have not previously been tested in the development tree.  
That said, I am willing to have a look at this if you can you clarify 
what the problem actually is.

Which of these is happening?
1) you have an "emacs" in your path that is incapable of compiling the 
   three files gnuplot.elc gnuplot-gui.elc gnuplot-eldoc.elc?
2) The version check to see if emacs is older than version 20.3 fails?
3) The *.elc files are compiled properly but installed in the wrong
   site-lisp directory?

As to (2) is any of this still needed?  The README says that the 
info-look.xxx files are a work-around for incompatibilities in ancient
versions of emacs and Xemacs.  Can we just get rid of these files and
get rid of that section of the Makefile?  


=== Aquaterm ===
> Mojca Miklavec <moj...@gm...>
> I would be very very grateful if this patch could be applied:
> http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-configure-aquaterm.diff?rev=96897
> (only "configure.in", "m4/apple.m4" and the first line of "term/aquaterm.trm")
> --- configure.in.orig
> +++ configure.in
> @@ -1366,5 +1366,5 @@
>  
> -if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then
> +if test "$with_aquaterm" = yes; then
>    AC_MSG_RESULT([  aqua terminal: yes])
>  else
>    AC_MSG_RESULT([  aqua terminal: no])
 
That change is not in the main branch. Are you sure it is needed?
 
> m4/apple.m4
This patch bears little resemblance to what is currently in 4.7.
Does the build system in 4.7 work, or not?  
If the 4.7 version does work, should I just copy it to 4.6?
If not, then please submit a patch against 4.7 rather than 4.6
and we'll work from there.

> term/aquaterm.trm
> --- term/aquaterm.trm.orig
> +++ term/aquaterm.trm
> @@ -94,3 +94,3 @@
>  #ifdef TERM_BODY
> -#import <aquaterm/AQTAdapter.h>
> +#import <AquaTerm/AQTAdapter.h>

OK.


=== BOOLEANS ===
> Mojca Miklavec <moj...@gm...>
> Definitions of BOOL are still problematic (and configuration is broken
> on Solaris, older Macs, ...).

My understanding of the situation on Solaris is that no single fix will
work for all versions of Solaris.  The versions differ from each other,
and the requirements for C++ reportedly conflict with those for C.
But I'm working from ignorance, relying on Solaris users to provide help.
I have 2 (3?) times previously applied patches that were submitted to
handle Bool on some version of Solaris, and each time people reported
that the change caused breakage on other systems.  So unless someone has
a patch that has been well tested on multiple versions of Solaris, 
I won't touch this.

It is of course unfortunate that the Solaris compilers have a problem
with standard C/C++ Booleans.  It is likewise unfortunate that MSVC isn't
ANSI-compliant with regard to initializing named fields in a structure,
and unfortunate that some platforms lack a usable version of snprintf(). 
We do try to accommodate in the source code where possible, but at some
point it's just not worth the effort.

Anyhow, this is clearly a long-term issue and not something that can
quickly be patched for 4.6.1.

	Ethan

Bool (was: Any issues that would hold up release of 4.6.1?)

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

On Tue, Sep 18, 2012 at 1:08 AM, Ethan A Merritt wrote:
>
> Is anyone aware of an unresolved bug or other reason to hold off
> release of version 4.6.1?  If not, I will probably package it up
> for release next weekend.

Definitions of BOOL are still problematic (and configuration is broken
on Solaris, older Macs, ...).

Citing:

On Thu, Aug 30, 2012 at 3:55 PM, Paul Eggert wrote:
> On 08/30/2012 06:27 AM, Mojca Miklavec wrote:
>> what would you use as a replacement for this chunk of
>> code in gnuplot then until a C++-specific test in autoconf tools is
>> written?
>
> I'd use the latest gnulib version of stdbool.in.h which I just
> checked in a few hours ago.

The link to that version is here:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/stdbool.in.h;h=1261936ae8fa33e76fb9986389c077a748058f5a;hb=HEAD

Link to bug tracker:
http://sourceforge.net/tracker/?func=detail&aid=3562307&group_id=2055&atid=302055
(with my "simplified" patch proposal)

(But one could try to patch the trunk first. The bug manifests only in
not-so-mainstream systems, but the patch affects everyone. Having some
extra time to make sure that no other systems are broken could help.)

Mojca

AquaTerm configuration (was: Any issues that would hold up release of 4.6.1?)

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

On Tue, Sep 18, 2012 at 1:08 AM, Ethan A Merritt wrote:
>
> Is anyone aware of an unresolved bug or other reason to hold off
> release of version 4.6.1?  If not, I will probably package it up
> for release next weekend.

I would be very very grateful if this patch could be applied:
    http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-configure-aquaterm.diff?rev=96897
(only "configure.in", "m4/apple.m4" and the first line of
"term/aquaterm.trm" are relevant; the other files in the diff are
auto-generated and the second line of aquaterm.trm has been patched
upstream).

AquaTerm 1.1.1 has recently been released which doesn't install the
libraries needed for "-laquaterm" LDFLAG(S) to work. So AquaTerm
configuration is more or less broken at the moment except for those
with very old 32-bit libraries or those who manually fiddle with the
system.

The patch is now being used in MacPorts for about a month and there
were no complaints so far.

I'm very happy that both wxt & qt have been finally polished out, so
this is almost the last piece of puzzle missing for a smooth
experience of Mac OS X users. The only other configuration issue on
older macs is buggy HAVE__BOOL.

Thank you,
    Mojca

undesired EMACS=`basename $EMACS` (was: Any issues that would hold up release of 4.6.1?)

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

On Tue, Sep 18, 2012 at 1:08 AM, Ethan A Merritt wrote:
>
> Is anyone aware of an unresolved bug or other reason to hold off
> release of version 4.6.1?  If not, I will probably package it up
> for release next weekend.

Hello,

Not a major showstopper, but I would be grateful if someone could take
a look at the attached patch for emacs (and apply before the release
it if possible). The problem is that setting
    EMACS=/path/to/some/Emacs ./configure
is later "reset" with
    EMACS=`basename $EMACS`
in lisp/configure[.in], so version checking and all further
emacs-related operation fail to work properly since they call whatever
emacs/xemacs comes first in PATH instead of the one requested by user.

If one points the variable to (rather standard location)
    EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs
it even fails on case-sensitive systems (even if another "emacs"
itself is present in PATH, it doesn't recognize it). On
case-insensitive systems it works, but is wrong as it picks the wrong
binary to do the version check.

Apparently the following
    INFO_LOOK_ELC=
also needs to be reset to an empty value when patching info-look.el is
not needed. That problem only manifested itself because the binary is
called "Emacs" and not "emacs" or "xemacs". The file info-look.el
doesn't need patching, so it's irrelevant if
    test `basename $EMACS` = emacs
fails to recognize "Emacs", but INFO_LOOK_ELC has to become empty in
the same way as in
  if test "$vnum" -ge 2030 ; then
    info_look="not needed with emacs $emacs_version"
    INFO_LOOK_ELC=
  else

The bug was reported by Jamison (CC-ed).

Thank you,
    Mojca


--- lisp/configure.in.orig
+++ lisp/configure.in
@@ -13,8 +13,6 @@ AC_SET_MAKE
 AC_PROG_INSTALL
 AM_PATH_LISPDIR

-EMACS=`basename $EMACS`
-
 AC_CHECK_PROGS(DVIPS, dvips, no)
 AC_CHECK_PROGS(LATEX, latex latex2e, no)
 AC_PATH_PROG(MAKEINFO, makeinfo, no)
@@ -75,7 +73,7 @@ AC_MSG_RESULT([$emacs_version])
 vnum=`echo $emacs_version |awk -F\. '{print 100*$1+$2}'`

 AC_MSG_CHECKING([whether info-look.el is needed])
-if test "$EMACS" = emacs ; then
+if test `basename $EMACS` = emacs ; then
   if test "$vnum" -ge 2030 ; then
     info_look="not needed with emacs $emacs_version"
     INFO_LOOK_ELC=
@@ -83,7 +81,7 @@ if test "$EMACS" = emacs ; then
     info_look="using info-look.20.2.el"
     cp info-look.20.2.el info-look.el
   fi
-elif test "$EMACS" = xemacs ; then
+elif test `basename $EMACS` = xemacs ; then
   if test "$vnum" -ge 2000 ; then
     info_look="using info-look.20.3.el"
     cp info-look.20.3.el info-look.el
@@ -93,6 +91,7 @@ elif test "$EMACS" = xemacs ; then
   fi
 else
   info_look="using none"
+  INFO_LOOK_ELC=
 fi
 AC_MSG_RESULT([$info_look])

Re: Any issues that would hold up release of 4.6.1?

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

On 09/17/2012 06:08 PM, Ethan A Merritt wrote:
> The NEWS file lists 30 bug fixes that have accummulated since the
> release of version 4.6.  That is more than is usual between
> incremental releases.
>
> Is anyone aware of an unresolved bug or other reason to hold off
> release of version 4.6.1?  If not, I will probably package it up
> for release next weekend.

Is Qt terminal in 4.6.1?  The only thing I can think of is supporting 
Windows properly in Qt term, but no volunteers with a Windows machine 
have stepped forward yet.  Oh well.

Dan


>
> 	Ethan
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Any issues that would hold up release of 4.6.1?

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

The NEWS file lists 30 bug fixes that have accummulated since the
release of version 4.6.  That is more than is usual between
incremental releases.

Is anyone aware of an unresolved bug or other reason to hold off
release of version 4.6.1?  If not, I will probably package it up
for release next weekend.

	Ethan

gnuplot manual misprint (no.38)

[Shigeharu T. <sh...@ie...>]

shige 09/12 2012
----------------

In docs/gnuplot.doc 

 C RCS $Id: gnuplot.doc,v 1.746 2012/08/24 21:28:38 sfeam Exp $

and man/gnuplot.1 of current CVS version, I found the following 
points which may be typo: 

----- From here -----
--- docs/gnuplot.doc.ORG	2012-08-26 17:55:26.000000000 +0900
+++ docs/gnuplot.doc	2012-09-12 16:05:47.000000000 +0900
@@ -12404,7 +12404,7 @@
 ?set y2range
 ?show y2range
 ?y2range
- The `set y2range` command sets the horizontal range that will be displayed on
+ The `set y2range` command sets the vertical range that will be displayed on
  the y2 (right) axis.  See `set xrange` for the full set of command options.
  This command is ignored if the y2 axis range is explicitly linked to the
  y axis.  See `set link`.
--- man/gnuplot.1.ORG	2012-09-08 12:41:13.000000000 +0900
+++ man/gnuplot.1	2012-09-12 16:07:48.000000000 +0900
@@ -60,7 +60,7 @@
 with X servers. This terminal type is set automatically at startup if
 the \fBGNUTERM\fR environment variable is set to x11,
 or if the \fB\-display\fR command line option is used.
-For terminal type Ix11, \fIgnuplot\fP
+For terminal type x11, \fIgnuplot\fP
 accepts the standard X Toolkit options and resources such as geometry, font,
 and background. See the X(1) man page for a description of common options.
 For additional X options specific to gnuplot, type \fIhelp x11\fP on the
@@ -145,4 +145,4 @@
 .SH SEE ALSO
 See the printed manual or the on-line help for details on specific commands.
 Project web site at 
-/I http://gnuplot.info
+.I http://gnuplot.info
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Re: irreversibly reversing range

[Karl-Friedrich R. <mai...@gm...>]

On 09.09.2012 23:50, sfeam (Ethan Merritt) wrote:
> 
> <aside>  
> As you probably recall, my opinion is that a range specifier in the plot 
> command is always a bad idea.  If it were just me, I'd remove that option
> altogether.  The only reason I can see to allow it is if it is changed so
> that the in-line range applies only to the immediately following plot clause.
> That way you could get separate ranges for separate plots:
>    plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x)
> I don't really like that either, but at least it would provide a 
> capability that isn't addressed by simply doing "set xrange" first.
> </aside>

I´d strongly advocate that change, it seems a most stringent solution!

That way, the range in the plot command would only refer to the
sampling (one could even expand it to include an increment like in
"for [::]", e.g. plot [0:2:0.2] f(x)).

Then the autoscaling would only rely on the actual points the plot
(be it a function or datafile) returns, and adding "reverse" would
always have the expected effect of having the highest numbers on the
left.

Default sampling range for function plots then is [-10:10], and
there is just no need for a default range of the scaling of the
abscissa.

Best regards,

  Karl

Re: irreversibly reversing range

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

On 09/10/2012 10:33 PM, sfeam (Ethan Merritt) wrote:

> Since the historical behavior has been strange, to say the least,
> I think we are free establish more reasonable behavior starting
> with the eventual release 5.0.  It is my position that the "reverse"
> keyword should explicitly affect only autoscaling, even though the
> documentation has in the past only said this is "intended" rather
> than "guaranteed".

Something that could have been done instead of the "reverse" option is 
to have put control for orientation within the autoscaling syntax, e.g., 
[*:-*] just as with the non-auto-adjust.  It seems that has become 
overloaded anyway with specifiers like [30:40<*].  Whether that is 
better in the long run, not sure.  That means there can't be multiple 
xranges in a plot command unless the all result in the same orientation.


> 4)  Dan provided a test case that resulted in a blank entry in the
>      "currently" field of "show range".  I haven't looked into that
>      one yet, but it appears to be a bug in the "show" command
>      rather than a real problem with the plot or autoscaling.

I see that the field is blank before even doing the plot, so yes 
probably a "show" issue...  I will look into the 'writeback' option as well.

Dan

Re: irreversibly reversing range

[Tait <gnu...@t4...>]

> >>> <aside>
> >>> As you probably recall, my opinion is that a range specifier in the plot
> >>> command is always a bad idea.  If it were just me, I'd remove that option
> >>> altogether.  The only reason I can see to allow it is if it is changed so
> >>> that the in-line range applies only to the immediately following plot clause.
> >>> That way you could get separate ranges for separate plots:
> >>>      plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x)
> >>> I don't really like that either, but at least it would provide a
> >>> capability that isn't addressed by simply doing "set xrange" first.
> >>> </aside>
> >>
> >> Yes, I sort of agree with that.  That is why I picked the phrasing that
> >> the range is associated with the data, not the orientation of the axis.
> >>    Given the example you wrote, the paradigm is that [10:20] means the
> >> data for which x is between 10 and 20, and in that case [20:10] is no
> >> different than [10:20].  Using the range specifier to control the
> >> orientation of the plot in your example would be a mess.

I like the idea of separating axis range from (data/function) plot range.
It's a somewhat frequently-asked question how to use a different range for
a function than what is used for the axis, and the current solution -- to
use a ternary -- isn't especially elegant.

As suggested, it would then become natural to allow "set xrange reversed"
by itself.

> gnuplot> set xrange [9:*]
> gnuplot> show xrange
> 
> 	set xrange [ 9.00000 : * ] noreverse nowriteback  # (currently [:10.0000] )
> 
> gnuplot> plot '-'
> input data ('e' ends) > 5 5
> input data ('e' ends) > 8 8
> input data ('e' ends) > 12 12
> input data ('e' ends) > 15 15
> input data ('e' ends) > e
> gnuplot> show xrange
> 
> 	set xrange [ 9.00000 : * ] noreverse nowriteback  # (currently [:15.0000] )
> 
> 
> My plot is showing the xaxis starting at 9 and ending at 15.  Shouldn't 
> that be saying "currently [9.0000:15.0000]", because that is currently 
> what the range is on the plot?

What you're asking about is GPVAL_X_MAX, which is not the same as the
xrange. If you were to continue by plotting another data set that
extended to 22, then you would rightly expect to (and gnuplot would)
scale to the new x-max of 22. The possibility to have the autoscale
performed only on the first plot, then locked into place is supported
by the "writeback" option.

I don't normally use writeback, but in trying it just now, it appears to
be broken. Both "set xrange [9:*] writeback" and "set xrange [*:*]
writeback" followed by the plot above fail to write the range back as
they should. It's left auto-scaled.

(And if we support "set xrange [no]reverse" we should likewise support
"set xrange [no]writeback".)

Re: irreversibly reversing range

[sfeam (E. Merritt) <eam...@gm...>]

On Monday, 10 September 2012, Hans-Bernhard Bröker wrote:
> On 11.09.2012 00:34, Ethan A Merritt wrote:
> 
> > You do know that the [*:*] part of that command is entirely ignored?
> > As I said, autoscaling only applies to data plots, not function plots.
> 
> For the independent axes of a function plot, yes.  Not so much for the 
> dependent ones (y in a plot, z in an splot, all of them in a parametric 
> one).

Yes, of course.  So far the discussion has concerned the x-axis
range in a 2D function plot (not polar, not parametric).

The same issue arises for both x- and y- axes in a 3D plot, with the
additional complication that in the past "set/unset view map"
implicitly toggled their internal flag AXIS_REVERSE, thus making its
eventual state even less understandable.
 
> > I don't see it that way.   To me it seems very intuitive.
> > [30:50] means start at 30 and go to 50.
> > [50:30] means start at 50 and go to 30.
> > The word "reverse" is never needed when you are specifying explicit limits.
> 
> But what about the cases where only half the limits are explicit?
> 
> 	set yrange [30:*] reverse
> 
> has been meaningful for quite a while now.  Changing that should require 
> a pretty good reason.

I may be missing a scenario, but so far as I know that command has 
exactly same effect in the current 4.7 as it had in earlier versions. 
It is an example of autoscaling.

> > The `reverse` keyword was added sometime between versions 3.5 and 3.7
> > Its documentation has always said
> >    `reverse` is intended primarily for use with `autoscale`
> 
> But that doesn't mean it should have no effect otherwise.

Since the historical behavior has been strange, to say the least,
I think we are free establish more reasonable behavior starting 
with the eventual release 5.0.  It is my position that the "reverse"
keyword should explicitly affect only autoscaling, even though the
documentation has in the past only said this is "intended" rather 
than "guaranteed".  

> > Dan, you are again showing tests with function plots.
> > I keep pointing out that the x-axis autoscaling commands, including the
> > * character in a "set xrange" command _do not apply_ to the samples generated
> > for functions.
> 
> Which is only half true.
> 
> It's true that auto-scaling an independent variable for a _pure_ 
> function plot makes no sense --- which is why gnuplot always replaced it 
> by a default range.  But as soon as x becomes a dependent variable 
> (parametric mode, polar mode), or data files enter the picture, 
> auto-scaling x becomes well-defined and worth having.

Sure.  No one is disputing that.  

The specific issues that I take from this discussion are

1)  How to fix the long-standing problem that the 'reverse' flag
    is set implicitly but can only be cleared explicitly, leading
    to context-dependent output from explict range commands?
    My solution is to ignore the reverse flag whenever foo and baz are
    both given, applying it only if the axis limits are chosen by
    autoscaling.  That removes the context-dependence and is 
    consistent with the previous "intended" use.

2)  The plot produced by 
        plot [30:40<*] x
    is very strange.   Bug?  Unreasonable command?
    In any case the issue has been present since the introduction of
    conditional range limits by Volker Dobler's patch 2 years ago.
    It's not related to "reverse".

3)  The empty range plot produced by 
        plot [10:*] x
    is unexpected, although understandable if you remember that the 
    implicit upper axis limit is 10 by default.
    Bug?  Unreasonable command?   Should it do something else entirely?
    Again this is not directly related to "reverse".

4)  Dan provided a test case that resulted in a blank entry in the
    "currently" field of "show range".  I haven't looked into that
    one yet, but it appears to be a bug in the "show" command 
    rather than a real problem with the plot or autoscaling.

Re: irreversibly reversing range

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

On 09/10/2012 05:34 PM, Ethan A Merritt wrote:
> On Monday, September 10, 2012 01:16:41 pm Daniel J Sebald wrote:

>>> <aside>
>>> As you probably recall, my opinion is that a range specifier in the plot
>>> command is always a bad idea.  If it were just me, I'd remove that option
>>> altogether.  The only reason I can see to allow it is if it is changed so
>>> that the in-line range applies only to the immediately following plot clause.
>>> That way you could get separate ranges for separate plots:
>>>      plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x)
>>> I don't really like that either, but at least it would provide a
>>> capability that isn't addressed by simply doing "set xrange" first.
>>> </aside>
>>
>> Yes, I sort of agree with that.  That is why I picked the phrasing that
>> the range is associated with the data, not the orientation of the axis.
>>    Given the example you wrote, the paradigm is that [10:20] means the
>> data for which x is between 10 and 20, and in that case [20:10] is no
>> different than [10:20].  Using the range specifier to control the
>> orientation of the plot in your example would be a mess.
>
> The way I view it is that   "set xrange [FOO:BAZ]" means the left
> end of the axis is pinned at FOO and the right end is pinned at BAZ.
> The makes sense both externally (what the user sees) and internally
> (mapping a numerical coordinate onto a screen position).
>
> I will note that my primary motivation for the change in 4.7 was to clean
> up the code internally.  The fact that it also IMHO makes a more sensible
> user-visible syntax is just a side benefit.  The change removed a
> tangle of calls and macros like check_axis_reversed(), CHECK_REVERSE,
> AXIS_ACTUAL_MIN, etc, and made it a lot easier to implement linked
> primary/secondary axes.  It also fixed corruption in the zoom/restore
> state if the AXIS_REVERSE flag somehow got set while a plot was zoomed.

That's good.  There's a natural complexity to these sorts of things and 
controlling the range doesn't seem like it should be so complex.


>> Anyway, the most affect on backward compatibility is
>> ["reverse" only applies to the autoadjust settings]
>> so I'm wondering why that change is preferred.
>
> The `reverse` keyword was added sometime between versions 3.5 and 3.7
> Its documentation has always said
>    `reverse` is intended primarily for use with `autoscale`

Oh, then that was a bug when released.  The "NB: This is a change 
introduced in version 4.7." comment in the xrange documentation suggests 
the old behavior was intentional.  I have the fix for Octave ready to go 
then.


> Dan, you are again showing tests with function plots.
> I keep pointing out that the x-axis autoscaling commands, including the
> * character in a "set xrange" command _do not apply_ to the samples generated
> for functions.   I am pretty sure that whatever result you get is pure
> happenstance; it was not a deliberate design decision, and the use of * for
> function domains was never documented because its use was not intended.

I included the function x so that it illustrates the data points passing 
through the line and that things are working properly.  Try without the 
function x and it is the same result.  I'll do this with a bit more 
detail, and I will use 9 as a lower limit so as to rule out some strange 
conflict between the [-10:10] of the default range:

	G N U P L O T
	Version 4.7 patchlevel 0    last modified 2012-06-19
	Build System: Linux x86_64

	Copyright (C) 1986-1993, 1998, 2004, 2007-2012
	Thomas Williams, Colin Kelley and many others

	gnuplot home:     http://www.gnuplot.info
	mailing list:     gnu...@li...
	faq, bugs, etc:   type "help FAQ"
	immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot> show xrange

	set xrange [ * : * ] noreverse nowriteback  # (currently 
[-10.0000:10.0000] )

gnuplot> set xrange [9:*]
gnuplot> show xrange

	set xrange [ 9.00000 : * ] noreverse nowriteback  # (currently [:10.0000] )

gnuplot> plot '-'
input data ('e' ends) > 5 5
input data ('e' ends) > 8 8
input data ('e' ends) > 12 12
input data ('e' ends) > 15 15
input data ('e' ends) > e
gnuplot> show xrange

	set xrange [ 9.00000 : * ] noreverse nowriteback  # (currently [:15.0000] )


My plot is showing the xaxis starting at 9 and ending at 15.  Shouldn't 
that be saying "currently [9.0000:15.0000]", because that is currently 
what the range is on the plot?

Dan

Re: irreversibly reversing range

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

On Monday, September 10, 2012 01:16:41 pm Daniel J Sebald wrote:
> > None of the above test commands make sense, IMHO.
> > Function plots require a complete range specifier.
> > I'd be in favor of giving an error message in each of those cases.
> > That is, disallow '*' in the range specifier for function plots.
> 
> gnuplot has always sought to make as much sense out of a command as 
> possible and try plotting something.  The following is default behavior:
> 
> gnuplot> plot [*:*] x

You do know that the [*:*] part of that command is entirely ignored?
As I said, autoscaling only applies to data plots, not function plots.
So far as I know that has always been true.

> gnuplot> plot [*:*] '-'
> input data ('e' ends) > 1 1
> input data ('e' ends) > 2 1
> input data ('e' ends) > e
> Warning: empty y range [1:1], adjusting to [0.99:1.01]
> 
> How can one say the default range specifier makes any more sense than 
> does [30:*]?

My view is that neither [*:*] nor [30:*] have a natural meaning in the
absence of data.   As you discovered, it happens that the '30' replaces
the default '-10' for function plots while the '*' is ignored leaving the
default '10'.  But I don't think that was by design, because  
'*' was never intended for use with function plots in the first place.


> 
> > <aside>
> > As you probably recall, my opinion is that a range specifier in the plot
> > command is always a bad idea.  If it were just me, I'd remove that option
> > altogether.  The only reason I can see to allow it is if it is changed so
> > that the in-line range applies only to the immediately following plot clause.
> > That way you could get separate ranges for separate plots:
> >     plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x)
> > I don't really like that either, but at least it would provide a
> > capability that isn't addressed by simply doing "set xrange" first.
> > </aside>
> 
> Yes, I sort of agree with that.  That is why I picked the phrasing that 
> the range is associated with the data, not the orientation of the axis. 
>   Given the example you wrote, the paradigm is that [10:20] means the 
> data for which x is between 10 and 20, and in that case [20:10] is no 
> different than [10:20].  Using the range specifier to control the 
> orientation of the plot in your example would be a mess.

The way I view it is that   "set xrange [FOO:BAZ]" means the left
end of the axis is pinned at FOO and the right end is pinned at BAZ.
The makes sense both externally (what the user sees) and internally
(mapping a numerical coordinate onto a screen position).

I will note that my primary motivation for the change in 4.7 was to clean
up the code internally.  The fact that it also IMHO makes a more sensible
user-visible syntax is just a side benefit.  The change removed a
tangle of calls and macros like check_axis_reversed(), CHECK_REVERSE, 
AXIS_ACTUAL_MIN, etc, and made it a lot easier to implement linked
primary/secondary axes.  It also fixed corruption in the zoom/restore
state if the AXIS_REVERSE flag somehow got set while a plot was zoomed.


> >> I would think that "reverse" could
> >> be viewed as "do all the range computations, then when all done reverse
> >> the range".
> >
> > That is indeed what it now means. At least that's the intent.
> > Do you have an example that works otherwise?
> 
> Well, the change in 4.7 doesn't mean that anymore.  The following 
> produce the same graph:
> 
> gnuplot> set xrange [30:50]
> gnuplot> plot x
> gnuplot> set xrange [30:50] reverse
> gnuplot> plot x
> 
> Those of us familiar with range specifier history aren't that confused 
> by this.  But someone using gnuplot for the first time will by 
> befuddled.  In one case the user needs to use the term "reverse" to 
> change the orientation, in another case the user needs to change the 
> order of the numbers in the range specifier.

I don't see it that way.   To me it seems very intuitive.
[30:50] means start at 30 and go to 50.
[50:30] means start at 50 and go to 30.   
The word "reverse" is never needed when you are specifying explicit limits.
It's only relevant when the limits are not known in advance - the autoscale
from data case. 

> Why shouldn't one be allowed to input:
> 
> gnuplot> set xrange reverse
>                      ^
>           expecting '[' or 'restore'
> 
> on its own?

I don't know.  But that isn't a recent change - it's always been that way.

> Anyway, the most affect on backward compatibility is 
> ["reverse" only applies to the autoadjust settings]
> so I'm wondering why that change is preferred.  

The `reverse` keyword was added sometime between versions 3.5 and 3.7
Its documentation has always said
  `reverse` is intended primarily for use with `autoscale`

> >> In any case, I have a patch all set for Octave to address the proposed
> >> mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an
> >> official release.  Perhaps we could address the bugs I described above
> >> with the current proposed 4.7 behavior in mind and then reassess how
> >> one-side-autoadjust works.  That is, fix things so that:
> >>
> >> [a:*] - The autoadjust value * is greater than a
> >> [*:b] - The autoadjust value * is less than b
> >
> > That's what it does now in 4.7, at least for me.
> > Again, do you have an example of data-driven autoscaling that
> > gives some other result?
> 
> OK, I'm going to just try a few plots here:
> 
> gnuplot> reset
> gnuplot> plot [10:*] '-', x
> input data ('e' ends) > 5 5
> input data ('e' ends) > 8 8
> input data ('e' ends) > 12 12
> input data ('e' ends) > 15 15
> input data ('e' ends) > e
> gnuplot> show xrange
> 
> 	set xrange [ * : * ] noreverse nowriteback  # (currently 
> [10.0000:15.0000] )
> 
> LOOKS GOOD...
> 
> gnuplot> plot [*:10] '-', x
> input data ('e' ends) > 5 5
> input data ('e' ends) > 8 8
> input data ('e' ends) > 12 12
> input data ('e' ends) > 15 15
> input data ('e' ends) > e
> gnuplot> show xrange
> 
> 	set xrange [ * : * ] noreverse nowriteback  # (currently 
> [5.00000:10.0000] )
> 
> LOOKS GOOD...
> 
> gnuplot> set xrange [10:*] reverse
> gnuplot> plot '-', x
> input data ('e' ends) > 5 5
> input data ('e' ends) > 8 8
> input data ('e' ends) > 12 12
> input data ('e' ends) > 15 15
> input data ('e' ends) > e
> gnuplot> show xrange
> 
> 	set xrange [ 10.0000 : * ] reverse nowriteback  # (currently [:10.0000] )
> 
> THE PLOT LOOKS GOOD, BUT I WONDER WHY "currently" DOESN'T SAY 
> "[15.0000:10.0000]" OR "[10.0000:15.0000] reverse"...
> 
> gnuplot> set xrange [*:10] reverse
> gnuplot> plot '-', x
> input data ('e' ends) > 5 5
> input data ('e' ends) > 8 8
> input data ('e' ends) > 12 12
> input data ('e' ends) > 15 15
> input data ('e' ends) > e
> gnuplot> show xrange
> 
> 	set xrange [ * : 10.0000 ] reverse nowriteback  # (currently [10.0000:] )
> 
> AGAIN, PLOT IS AS EXPECTED BUT THE "currently" IS INCOMPLETE WHERE I 
> THINK IT SHOULD SAY "[10.0000:5.0000]".

Dan, you are again showing tests with function plots.
I keep pointing out that the x-axis autoscaling commands, including the 
* character in a "set xrange" command _do not apply_ to the samples generated
for functions.   I am pretty sure that whatever result you get is pure
happenstance; it was not a deliberate design decision, and the use of * for
function domains was never documented because its use was not intended.

If you think there is a need to introduce a specific documented effect of
"set xrange [min:*]" on a subsequent function plot - please make a proposal.
Up to now that command has no documented meaning.


	Ethan

Re: irreversibly reversing range

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

On 09/09/2012 04:50 PM, sfeam (Ethan Merritt) wrote:
> On Sunday, 09 September 2012, Daniel J Sebald wrote:
>> This morning I came to wonder, What if one wants one end of the range
>> fixed while the other is autoscaled?  So I tried a few things, and the
>> results certainly aren't intuitive, or are buggy.
>>
>> Say, for example, my intention is to make a plot for which the left side
>> starts at x=30 and is autoscaled on the right side.  I try
>>
>> gnuplot>  plot [30:*] x
>>
>> and get something very unexpected, unless I really think about it.
>
> Autoscaling doesn't have an obvious meaning for function plots.
> Normally that command would be followed by 'plot<datafile>', with
> the meaning that points with x<30 would not be plotted.
>
>> First, the result is reversed, slightly unexpected.  Then I wonder, 10
>> is the "upper" range?  OK, now I see.  If I were to "plot x", the lower
>> range is 0 and upper range 10 by definition.
>
> Not quite.  The default range for function plots is [-10:10]
>
>> So that is where the
>> reverse axis is coming from.  That means if one does
>>
>> gnuplot>  plot [3:*] x
>>
>> it comes out non-reversed.  And yes that is the result.  OK, perhaps
>> gnuplot should be changed so that the upper limit is "rangemin + 10",
>> and the symmetric case "rangemax - 10".
>>
>> Out of curiosity I try
>>
>> gnuplot>  set xrange [3:*] reverse
>> gnuplot>  plot x
>>
>> and the graph changes.  However,
>>
>> gnuplot>  set xrange [30:*] noreverse
>> gnuplot>  plot x
>> gnuplot>  set xrange [30:*] reverse
>> gnuplot>  plot x
>>
>> brings no change in the graph.  Perhaps that is just a ramification of
>> the "rangemin + 10" issue.
>>
>> So, I wonder how I can get better control of the range settings and
>> achieve the initial goal of left end of plot fixed at thirty and the
>> right end autoadjust.  How about
>>
>> gnuplot>  plot [30:40<*] x
>
> None of the above test commands make sense, IMHO.
> Function plots require a complete range specifier.
> I'd be in favor of giving an error message in each of those cases.
> That is, disallow '*' in the range specifier for function plots.

gnuplot has always sought to make as much sense out of a command as 
possible and try plotting something.  The following is default behavior:

gnuplot> plot [*:*] x

gnuplot> plot [*:*] '-'
input data ('e' ends) > 1 1
input data ('e' ends) > 2 1
input data ('e' ends) > e
Warning: empty y range [1:1], adjusting to [0.99:1.01]

How can one say the default range specifier makes any more sense than 
does [30:*]?


> <aside>
> As you probably recall, my opinion is that a range specifier in the plot
> command is always a bad idea.  If it were just me, I'd remove that option
> altogether.  The only reason I can see to allow it is if it is changed so
> that the in-line range applies only to the immediately following plot clause.
> That way you could get separate ranges for separate plots:
>     plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x)
> I don't really like that either, but at least it would provide a
> capability that isn't addressed by simply doing "set xrange" first.
> </aside>

Yes, I sort of agree with that.  That is why I picked the phrasing that 
the range is associated with the data, not the orientation of the axis. 
  Given the example you wrote, the paradigm is that [10:20] means the 
data for which x is between 10 and 20, and in that case [20:10] is no 
different than [10:20].  Using the range specifier to control the 
orientation of the plot in your example would be a mess.


>> I would think that "reverse" could
>> be viewed as "do all the range computations, then when all done reverse
>> the range".
>
> That is indeed what it now means. At least that's the intent.
> Do you have an example that works otherwise?

Well, the change in 4.7 doesn't mean that anymore.  The following 
produce the same graph:

gnuplot> set xrange [30:50]
gnuplot> plot x
gnuplot> set xrange [30:50] reverse
gnuplot> plot x

Those of us familiar with range specifier history aren't that confused 
by this.  But someone using gnuplot for the first time will by 
befuddled.  In one case the user needs to use the term "reverse" to 
change the orientation, in another case the user needs to change the 
order of the numbers in the range specifier.

There were sort of three small changes made here:

1) "reverse" no longer has an effect on the range specification, i.e., 
specifying "[30:50] reverse" doesn't peculiarly change the specification 
to "[50:30]"

2) The range specification no longer toggles the "{no}reverse" option so 
that it gets stuck.

3) "reverse" only applies to the autoadjust settings.

1 and 2 I'm happy to see, but I would also add that with those changes 
it seems to me that the range specification numbers and "reverse" are 
decoupled.  Why shouldn't one be allowed to input:

gnuplot> set xrange reverse
                     ^
          expecting '[' or 'restore'

on its own?

Anyway, the most affect on backward compatibility is 3 above, so I'm 
wondering why that change is preferred.  One could argue that

set [*:*] reverse

would otherwise still stick "reverse".  However, the user now has to 
intentionally changed the setting rather than it happening as a 
consequence of the range specification.


>> In any case, I have a patch all set for Octave to address the proposed
>> mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an
>> official release.  Perhaps we could address the bugs I described above
>> with the current proposed 4.7 behavior in mind and then reassess how
>> one-side-autoadjust works.  That is, fix things so that:
>>
>> [a:*] - The autoadjust value * is greater than a
>> [*:b] - The autoadjust value * is less than b
>
> That's what it does now in 4.7, at least for me.
> Again, do you have an example of data-driven autoscaling that
> gives some other result?

OK, I'm going to just try a few plots here:

gnuplot> reset
gnuplot> plot [10:*] '-', x
input data ('e' ends) > 5 5
input data ('e' ends) > 8 8
input data ('e' ends) > 12 12
input data ('e' ends) > 15 15
input data ('e' ends) > e
gnuplot> show xrange

	set xrange [ * : * ] noreverse nowriteback  # (currently 
[10.0000:15.0000] )

LOOKS GOOD...

gnuplot> plot [*:10] '-', x
input data ('e' ends) > 5 5
input data ('e' ends) > 8 8
input data ('e' ends) > 12 12
input data ('e' ends) > 15 15
input data ('e' ends) > e
gnuplot> show xrange

	set xrange [ * : * ] noreverse nowriteback  # (currently 
[5.00000:10.0000] )

LOOKS GOOD...

gnuplot> set xrange [10:*] reverse
gnuplot> plot '-', x
input data ('e' ends) > 5 5
input data ('e' ends) > 8 8
input data ('e' ends) > 12 12
input data ('e' ends) > 15 15
input data ('e' ends) > e
gnuplot> show xrange

	set xrange [ 10.0000 : * ] reverse nowriteback  # (currently [:10.0000] )

THE PLOT LOOKS GOOD, BUT I WONDER WHY "currently" DOESN'T SAY 
"[15.0000:10.0000]" OR "[10.0000:15.0000] reverse"...

gnuplot> set xrange [*:10] reverse
gnuplot> plot '-', x
input data ('e' ends) > 5 5
input data ('e' ends) > 8 8
input data ('e' ends) > 12 12
input data ('e' ends) > 15 15
input data ('e' ends) > e
gnuplot> show xrange

	set xrange [ * : 10.0000 ] reverse nowriteback  # (currently [10.0000:] )

AGAIN, PLOT IS AS EXPECTED BUT THE "currently" IS INCOMPLETE WHERE I 
THINK IT SHOULD SAY "[10.0000:5.0000]".

Dan

Re: irreversibly reversing range

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 09 September 2012, Daniel J Sebald wrote:
> This morning I came to wonder, What if one wants one end of the range 
> fixed while the other is autoscaled?  So I tried a few things, and the 
> results certainly aren't intuitive, or are buggy.
> 
> Say, for example, my intention is to make a plot for which the left side 
> starts at x=30 and is autoscaled on the right side.  I try
> 
> gnuplot> plot [30:*] x
> 
> and get something very unexpected, unless I really think about it. 

Autoscaling doesn't have an obvious meaning for function plots.
Normally that command would be followed by 'plot <datafile>', with
the meaning that points with x<30 would not be plotted.

> First, the result is reversed, slightly unexpected.  Then I wonder, 10 
> is the "upper" range?  OK, now I see.  If I were to "plot x", the lower 
> range is 0 and upper range 10 by definition.  

Not quite.  The default range for function plots is [-10:10]

> So that is where the 
> reverse axis is coming from.  That means if one does
> 
> gnuplot> plot [3:*] x
> 
> it comes out non-reversed.  And yes that is the result.  OK, perhaps 
> gnuplot should be changed so that the upper limit is "rangemin + 10", 
> and the symmetric case "rangemax - 10".
> 
> Out of curiosity I try
> 
> gnuplot> set xrange [3:*] reverse
> gnuplot> plot x
> 
> and the graph changes.  However,
> 
> gnuplot> set xrange [30:*] noreverse
> gnuplot> plot x
> gnuplot> set xrange [30:*] reverse
> gnuplot> plot x
> 
> brings no change in the graph.  Perhaps that is just a ramification of 
> the "rangemin + 10" issue.
> 
> So, I wonder how I can get better control of the range settings and 
> achieve the initial goal of left end of plot fixed at thirty and the 
> right end autoadjust.  How about
> 
> gnuplot> plot [30:40<*] x

None of the above test commands make sense, IMHO.
Function plots require a complete range specifier.
I'd be in favor of giving an error message in each of those cases.
That is, disallow '*' in the range specifier for function plots.

<aside>  
As you probably recall, my opinion is that a range specifier in the plot 
command is always a bad idea.  If it were just me, I'd remove that option
altogether.  The only reason I can see to allow it is if it is changed so
that the in-line range applies only to the immediately following plot clause.
That way you could get separate ranges for separate plots:
   plot [10:20] f1(x), [20:30] f2(x), [30:100] f3(x)
I don't really like that either, but at least it would provide a 
capability that isn't addressed by simply doing "set xrange" first.
</aside>
  
> I would think that "reverse" could 
> be viewed as "do all the range computations, then when all done reverse 
> the range".

That is indeed what it now means. At least that's the intent. 
Do you have an example that works otherwise?

> In any case, I have a patch all set for Octave to address the proposed 
> mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an 
> official release.  Perhaps we could address the bugs I described above 
> with the current proposed 4.7 behavior in mind and then reassess how 
> one-side-autoadjust works.  That is, fix things so that:
> 
> [a:*] - The autoadjust value * is greater than a
> [*:b] - The autoadjust value * is less than b

That's what it does now in 4.7, at least for me.
Again, do you have an example of data-driven autoscaling that
gives some other result?

Re: irreversibly reversing range

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

This morning I came to wonder, What if one wants one end of the range 
fixed while the other is autoscaled?  So I tried a few things, and the 
results certainly aren't intuitive, or are buggy.

Say, for example, my intention is to make a plot for which the left side 
starts at x=30 and is autoscaled on the right side.  I try

gnuplot> plot [30:*] x

and get something very unexpected, unless I really think about it. 
First, the result is reversed, slightly unexpected.  Then I wonder, 10 
is the "upper" range?  OK, now I see.  If I were to "plot x", the lower 
range is 0 and upper range 10 by definition.  So that is where the 
reverse axis is coming from.  That means if one does

gnuplot> plot [3:*] x

it comes out non-reversed.  And yes that is the result.  OK, perhaps 
gnuplot should be changed so that the upper limit is "rangemin + 10", 
and the symmetric case "rangemax - 10".

Out of curiosity I try

gnuplot> set xrange [3:*] reverse
gnuplot> plot x

and the graph changes.  However,

gnuplot> set xrange [30:*] noreverse
gnuplot> plot x
gnuplot> set xrange [30:*] reverse
gnuplot> plot x

brings no change in the graph.  Perhaps that is just a ramification of 
the "rangemin + 10" issue.

So, I wonder how I can get better control of the range settings and 
achieve the initial goal of left end of plot fixed at thirty and the 
right end autoadjust.  How about

gnuplot> plot [30:40<*] x

?  The above looks to be a bug.  What I'm seeing here is:

[x11 terminal] A plot range running from x=30 at left, to x=40 at right 
(that's good).  Then there is a red line that appears in the upper left 
corner as though it originated from the origin and extended to (30,30).

[Qt terminal] Similar to the result of x11 terminal, but there is an 
additional aberrant line running vertical across the screen.

So, there might be two (more) bugs there, one Qt-specific, the other not 
specific to a terminal.

...

Anyway, my mind keeps floating back to wondering if there is an inherent 
problem of too much flexibility in allowing the orientation of the axis 
to be changed by the numeric order relationship in the range setting.

As Ethan described, most definitely the numeric values in the range have 
to be decoupled from any influence on toggling "{no}reverse".  (See ** 
below.)  But I still wonder if the latest version (4.7 beta) is a more 
incompatible change than necessary.  I would think that "reverse" could 
be viewed as "do all the range computations, then when all done reverse 
the range".

In any case, I have a patch all set for Octave to address the proposed 
mod in 4.7 beta, but I'm reluctant to apply it until 4.7 becomes an 
official release.  Perhaps we could address the bugs I described above 
with the current proposed 4.7 behavior in mind and then reassess how 
one-side-autoadjust works.  That is, fix things so that:

[a:*] - The autoadjust value * is greater than a
[*:b] - The autoadjust value * is less than b

Dan



On 09/08/2012 05:05 PM, Daniel J Sebald wrote:
> On 09/08/2012 03:42 PM, Ethan Merritt wrote:
>> On Saturday, 08 September 2012, Daniel J Sebald wrote:
>>> I see there is new behavior for the option "reverse" for gnuplot version
>>> 4.7+.  It seems to me the change is that "{no}reverse" now only applies
>>> to autoscaling.  (In fact, the documentation ostensibly says that.)
>>>
>>> Could someone write a one or two sentence summary of why the change.
>>> E.g., the previous behavior was too confusing or caused a conflict?  I
>>> just want to be able to explain why the change if asked.
>>
>> The old behaviour was bizarre.  Example:
>> gnuplot>   set xrange [1:0]
>> gnuplot>   show xrange
>>           set xrange [ 0.00000 : 1.00000 ] reverse nowriteback
>
> Well, I don't see why "reverse" should have been set on account of that.
>    It should have been
>
> **
> gnuplot>   show xrange
>             set xrange [ 1.00000 : 0.00000 ] noreverse nowriteback
>
>
>> gnuplot>   set xrange [0:1]
>> gnuplot>   show xrange
>>           set xrange [ 0.00000 : 1.00000 ] reverse nowriteback
>>
>> Notice that the "reverse" property is now stuck, and no ordinary
>> sequence of autoscaling/autorange/set xrange commands will unstick it.
>> Only an explicit "set xr [<something>:<something>] noreverse"
>> will work, but inside a script you can't know in advance when this
>> might be necessary, and at that point you may not know what the
>> correct<something>   is anyhow.
>
> Yes, bizarre.
>
>
>> See also various old bug reports going back 10 years or so, e.g. #230686.
>>
>>>
>>> Reverse axes aren't used real often, except in the case of y-axis and
>>> images where it is quite common to see the origin in the upper left
>>> corner of a plot.  (Octave will need a change to address this.)
>>
>> You have neglected that case of inverted axis scaling   x2 = F(1/x1)
>> Consider, for example:
>>      http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/
>
> But x2, y2 are not controlled by anything inside a plot statement.  From
> the "plot->range" documentation:
>
>          plot [-pi:pi] [-1.3:1.3] [-1:1] sin(t),t**2
>
>    Note that the x2range and y2range cannot be specified here---`set x2range`
>    and `set y2range` must be used.
>
>
> OK, so rethinking what I first wrote as an alternative, its seems a
> simpler alternative might be to not modify the "{no}reverse" setting on
> the basis of the in-command ranges (** above).  I'm just wondering if
> people are more inclined to think that "reverse" means to reverse the
> axis direction all of the time rather than just for the one case of
> autoscaling.
>
> Dan
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: irreversibly reversing range

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

On 09/08/2012 05:05 PM, Daniel J Sebald wrote:

>>> Reverse axes aren't used real often, except in the case of y-axis and
>>> images where it is quite common to see the origin in the upper left
>>> corner of a plot.  (Octave will need a change to address this.)
>>
>> You have neglected that case of inverted axis scaling   x2 = F(1/x1)
>> Consider, for example:
>>      http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/

Oh, I see what you meant.  Sure, reversing the orientation is useful.

Dan

Re: irreversibly reversing range

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

On 09/08/2012 03:42 PM, Ethan Merritt wrote:
> On Saturday, 08 September 2012, Daniel J Sebald wrote:
>> I see there is new behavior for the option "reverse" for gnuplot version
>> 4.7+.  It seems to me the change is that "{no}reverse" now only applies
>> to autoscaling.  (In fact, the documentation ostensibly says that.)
>>
>> Could someone write a one or two sentence summary of why the change.
>> E.g., the previous behavior was too confusing or caused a conflict?  I
>> just want to be able to explain why the change if asked.
>
> The old behaviour was bizarre.  Example:
> gnuplot>  set xrange [1:0]
> gnuplot>  show xrange
>          set xrange [ 0.00000 : 1.00000 ] reverse nowriteback

Well, I don't see why "reverse" should have been set on account of that. 
  It should have been

**
gnuplot>  show xrange
           set xrange [ 1.00000 : 0.00000 ] noreverse nowriteback


> gnuplot>  set xrange [0:1]
> gnuplot>  show xrange
>          set xrange [ 0.00000 : 1.00000 ] reverse nowriteback
>
> Notice that the "reverse" property is now stuck, and no ordinary
> sequence of autoscaling/autorange/set xrange commands will unstick it.
> Only an explicit "set xr [<something>:<something>] noreverse"
> will work, but inside a script you can't know in advance when this
> might be necessary, and at that point you may not know what the
> correct<something>  is anyhow.

Yes, bizarre.


> See also various old bug reports going back 10 years or so, e.g. #230686.
>
>>
>> Reverse axes aren't used real often, except in the case of y-axis and
>> images where it is quite common to see the origin in the upper left
>> corner of a plot.  (Octave will need a change to address this.)
>
> You have neglected that case of inverted axis scaling   x2 = F(1/x1)
> Consider, for example:
>     http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/

But x2, y2 are not controlled by anything inside a plot statement.  From 
the "plot->range" documentation:

        plot [-pi:pi] [-1.3:1.3] [-1:1] sin(t),t**2

  Note that the x2range and y2range cannot be specified here---`set x2range`
  and `set y2range` must be used.


OK, so rethinking what I first wrote as an alternative, its seems a 
simpler alternative might be to not modify the "{no}reverse" setting on 
the basis of the in-command ranges (** above).  I'm just wondering if 
people are more inclined to think that "reverse" means to reverse the 
axis direction all of the time rather than just for the one case of 
autoscaling.

Dan

Re: irreversibly reversing range

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

On Saturday, 08 September 2012, Daniel J Sebald wrote:
> I see there is new behavior for the option "reverse" for gnuplot version 
> 4.7+.  It seems to me the change is that "{no}reverse" now only applies 
> to autoscaling.  (In fact, the documentation ostensibly says that.)
> 
> Could someone write a one or two sentence summary of why the change. 
> E.g., the previous behavior was too confusing or caused a conflict?  I 
> just want to be able to explain why the change if asked.

The old behaviour was bizarre.  Example:
gnuplot> set xrange [1:0]
gnuplot> show xrange
        set xrange [ 0.00000 : 1.00000 ] reverse nowriteback
gnuplot> set xrange [0:1]
gnuplot> show xrange
        set xrange [ 0.00000 : 1.00000 ] reverse nowriteback

Notice that the "reverse" property is now stuck, and no ordinary
sequence of autoscaling/autorange/set xrange commands will unstick it.  
Only an explicit "set xr [<something>:<something>] noreverse"
will work, but inside a script you can't know in advance when this
might be necessary, and at that point you may not know what the
correct <something> is anyhow.

See also various old bug reports going back 10 years or so, e.g. #230686.

> 
> Reverse axes aren't used real often, except in the case of y-axis and 
> images where it is quite common to see the origin in the upper left 
> corner of a plot.  (Octave will need a change to address this.)

You have neglected that case of inverted axis scaling   x2 = F(1/x1)
Consider, for example:
   http://skuld.bmsc.washington.edu/people/merritt/gnuplot/linkedaxes/

> I also want to confirm that the new behavior is really what is desired. 
>   If there is something that may have been wrong with the previous 
> behavior it is that the old syntax was too flexible.  I think it was 
> Ethan that pointed out controlling the axis from within the plot command 
> itself was problematic, e.g.,
> 
> plot [0:500] x

Yeah, that too.   If the "reverse" flag got stuck on, the in-line
range specifiers didn't work reliably.

	Ethan

 
> I see the point in the sense that multiple items with different range 
> settings can be a conflict.  Maybe we shouldn't think of the range 
> specified within the plot command as "axis range".
> 
> Perhaps it is the fact that range setting itself can control the 
> orientation of an axes, i.e., [500:0].  If that were disallowed, then 
> there would still be an ability to control range within the plot 
> command, but not be able to control the orientation of the axis.
> 
> So rather than the change "reverse only applies to autoscaling", another 
> change could have been "range limits no longer control orientation".  So 
> that would mean
> 
> set xrange [0:500]
> set xrange [500:0]
> plot [0:500]
> plot [500:0]
> 
> all mean the same thing, i.e., the xaxis range is from 0 to 500 using 
> the typical Cartesian orientation.  Also
> 
> set xrange [0:500] reverse
> set xrange [500:0] reverse
> set xrange reverse
> plot [0:500]
> set xrange reverse
> plot [500:0]
> 
> would all mean the same thing, i.e., the xaxis range is from 0 to 500 
> but using the reverse orientation.
> 
> Dan
> 

Re: irreversibly reversing range

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

I see there is new behavior for the option "reverse" for gnuplot version 
4.7+.  It seems to me the change is that "{no}reverse" now only applies 
to autoscaling.  (In fact, the documentation ostensibly says that.)

Could someone write a one or two sentence summary of why the change. 
E.g., the previous behavior was too confusing or caused a conflict?  I 
just want to be able to explain why the change if asked.

Reverse axes aren't used real often, except in the case of y-axis and 
images where it is quite common to see the origin in the upper left 
corner of a plot.  (Octave will need a change to address this.)

I also want to confirm that the new behavior is really what is desired. 
  If there is something that may have been wrong with the previous 
behavior it is that the old syntax was too flexible.  I think it was 
Ethan that pointed out controlling the axis from within the plot command 
itself was problematic, e.g.,

plot [0:500] x

I see the point in the sense that multiple items with different range 
settings can be a conflict.  Maybe we shouldn't think of the range 
specified within the plot command as "axis range".

Perhaps it is the fact that range setting itself can control the 
orientation of an axes, i.e., [500:0].  If that were disallowed, then 
there would still be an ability to control range within the plot 
command, but not be able to control the orientation of the axis.

So rather than the change "reverse only applies to autoscaling", another 
change could have been "range limits no longer control orientation".  So 
that would mean

set xrange [0:500]
set xrange [500:0]
plot [0:500]
plot [500:0]

all mean the same thing, i.e., the xaxis range is from 0 to 500 using 
the typical Cartesian orientation.  Also

set xrange [0:500] reverse
set xrange [500:0] reverse
set xrange reverse
plot [0:500]
set xrange reverse
plot [500:0]

would all mean the same thing, i.e., the xaxis range is from 0 to 500 
but using the reverse orientation.

Dan