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

Re: bug: x11 terminal grabs mouse selection

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

On Friday 21 August 2009 11:16:06 Ralf Juengling wrote:
> Hi,
> 
> Apologies if this is a known issue.
> 
> When using the x11 terminal in gnuplot 4.2.5, gnuplot
> interferes with the X11 (?) mouse-selection mechanism.
> To see what I mean, just select some text in a terminal
> with the mouse (for copy and paste), then issue a plot
> command. The mouse selection disappears.

Doesn't happen for here, running under linux+KDE.
This is definitely not a general problem, but I'm afraid it doesn't
sound like something that can be diagnosed remotely.

	Ethan


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

bug: x11 terminal grabs mouse selection

[Ralf J. <jue...@cs...>]

Hi,

Apologies if this is a known issue.

When using the x11 terminal in gnuplot 4.2.5, gnuplot
interferes with the X11 (?) mouse-selection mechanism.
To see what I mean, just select some text in a terminal
with the mouse (for copy and paste), then issue a plot
command. The mouse selection disappears.

Thanks,
Ralf

Re: gnuplot manual misprint (no.31)

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

On Friday 07 August 2009, Shigeharu TAKENO wrote:
> shige 08/07 2009
> ----------------
> 
> In docs/gnuplot.doc of current CVS version
> 
>  C RCS $Id: gnuplot.doc,v 1.577 2009/08/05 04:16:49 sfeam Exp $
> 
> I found the following point. 
> 
> ----- From here -----
> --- gnuplot.doc.ORG	2009-08-07 16:14:28.000000000 +0900
> +++ gnuplot.doc	2009-08-07 16:17:45.000000000 +0900
> @@ -5522,7 +5522,7 @@
>         plot for [<variable> in "string of words"]
>  
>   The scope of an iteration ends at the next comma or the end of the
> - command, whichever comes first.  Iteration may be nested.
> + command, whichever comes first.  Iteration may not be nested.
>  
>   Example:
>         plot for [dataset in "apples bananas"] dataset."dat" title dataset
> ----- To here -----
> 
> I think the nesting of iteration is NOT allowed in the current 
> version of gnuplot. If not, such example should be written in 
> the document.

You are correct.  Thanks.

gnuplot manual misprint (no.31)

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

shige 08/07 2009
----------------

In docs/gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.577 2009/08/05 04:16:49 sfeam Exp $

I found the following point. 

----- From here -----
--- gnuplot.doc.ORG	2009-08-07 16:14:28.000000000 +0900
+++ gnuplot.doc	2009-08-07 16:17:45.000000000 +0900
@@ -5522,7 +5522,7 @@
        plot for [<variable> in "string of words"]
 
  The scope of an iteration ends at the next comma or the end of the
- command, whichever comes first.  Iteration may be nested.
+ command, whichever comes first.  Iteration may not be nested.
 
  Example:
        plot for [dataset in "apples bananas"] dataset."dat" title dataset
----- To here -----

I think the nesting of iteration is NOT allowed in the current 
version of gnuplot. If not, such example should be written in 
the document.

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

Re: qtterminal on Solaris 9

[<lod...@us...>]

I have committed a fix for that. I replaced round by the Qt
cross-platform version (qRound)

Jérôme

---------- Initial Header -----------

From      : Ethan Merritt <merritt@u.washington.edu>
To          : gnu...@li...
Cc          : Shigeharu TAKENO <sh...@ie...>
Date      : Tue, 4 Aug 2009 11:15:29 -0700
Subject : Re: qtterminal on Solaris 9

On Tuesday 04 August 2009 02:03:18 Shigeharu TAKENO wrote:
> shige 08/04 2009
> ----------------
> 
> When I compiled gnuplot of CVS version with --enable-qt on 
> Solaris 9, I found some points:
> 
> 1) a string "enable_qt = yes;" in configure.in may not have 
>   spaces.

OK. That's easy to fix.


> 2) a function 'round()' is used in
src/qtterminal/qt_term.cpp and
>   src/qtterminal/QtGnuplotScene.cpp, but Solaris 9 don't
have it.

round() is a C99 function.  Its definition is slightly
different from
   #define round(a) (floor((a)+.5))
because for negative numbers it shifts half-integral values
towards
zero rather than away from zero.

See discussion at
  
http://www-old.cae.wisc.edu/pipermail/help-octave/2008-April/008958.html

Furthermore, testing for #if !defined(round) will return TRUE 
even if the local math library does contain round() as a
function.
So that is not the right test.

Probably we can use an autoconf test for this:

--- gnuplot/configure.in        2009-07-31
09:42:25.000000000 -0700
+++ gnuplot-cvs/configure.in    2009-08-04
11:09:29.000000000 -0700
@@ -79,6 +79,13 @@
 dnl _instead_ of -lm ...
 AC_CHECK_FUNC(sin,,[AC_CHECK_LIB(m,sin)])

+dnl round() is a C99 math library function
+AC_CHECK_LIB(m, round)
+if test "$ac_cv_lib_m_round" = yes; then
+     AC_DEFINE(HAVE_ROUND,1,
+               [ Define if your platform provides a
function round(). ])],
+fi
+
 dnl Header files. ANSI first
 dnl We prefer that the absense of a macro is the norm, so
in syscfg.h
 dnl configure's HAVE_XXXX defines are translated into
NO_XXXX for ANSI




> So I needed the following patch.
> 
> ----- From here -----
> diff -u configure.in.ORG configure.in
> --- configure.in.ORG	Mon Aug  3 13:47:39 2009
> +++ configure.in	Tue Aug  4 17:05:24 2009
> @@ -1022,7 +1022,7 @@
>  AC_ARG_ENABLE(qt,dnl
>  [  --enable-qt      Qt terminal (default disabled)],
>    [if test "$enableval" = yes; then
> -     enable_qt = yes;
> +     enable_qt=yes;
>     fi])
>  
>  if test "${enable_qt}" = yes ; then
> diff -u src/qtterminal/QtGnuplotScene.h.ORG
src/qtterminal/QtGnuplotScene.h
> --- src/qtterminal/QtGnuplotScene.h.ORG	Mon Aug  3
13:47:35 2009
> +++ src/qtterminal/QtGnuplotScene.h	Tue Aug  4 16:50:52 2009
> @@ -49,6 +49,11 @@
>  #include <QGraphicsScene>
>  #include <QTime>
>  
> +/* for Solaris 9 */
> +#if !defined(round)
> +# define round(a) (floor((a)+.5))
> +#endif
> +
>  class QtGnuplotEnhanced;
>  class QtGnuplotWidget;
>  
> diff -u src/qtterminal/qt_term.h.ORG src/qtterminal/qt_term.h
> --- src/qtterminal/qt_term.h.ORG	Mon Aug  3 13:47:36 2009
> +++ src/qtterminal/qt_term.h	Tue Aug  4 16:51:00 2009
> @@ -49,6 +49,11 @@
>  #ifndef GNUPLOT_QT_TERM_H
>  #define GNUPLOT_QT_TERM_H
>  
> +/* for Solaris 9 */
> +#if !defined(round)
> +# define round(a) (floor((a)+.5))
> +#endif
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif /*__cplusplus*/
> ----- To here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
>
------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
Reports 2008 30-Day 
> trial. Simplify your report design, integration and
deployment - and focus on 
> what you do best, core application coding. Discover what's
new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal
Reports 2008 30-Day 
trial. Simplify your report design, integration and
deployment - and focus on 
what you do best, core application coding. Discover what's
new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
gnuplot-beta mailing list
gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta



---------------------- ALICE N°1 de la RELATION CLIENT 2008*--------------------
Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES / BEARING POINT. Secteur Fournisseur d.Accès Internet

Re: qtterminal on Solaris 9

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

On Tuesday 04 August 2009 02:03:18 Shigeharu TAKENO wrote:
> shige 08/04 2009
> ----------------
> 
> When I compiled gnuplot of CVS version with --enable-qt on 
> Solaris 9, I found some points:
> 
> 1) a string "enable_qt = yes;" in configure.in may not have 
>   spaces.

OK. That's easy to fix.


> 2) a function 'round()' is used in src/qtterminal/qt_term.cpp and
>   src/qtterminal/QtGnuplotScene.cpp, but Solaris 9 don't have it.

round() is a C99 function.  Its definition is slightly different from
   #define round(a) (floor((a)+.5))
because for negative numbers it shifts half-integral values towards
zero rather than away from zero.

See discussion at
   http://www-old.cae.wisc.edu/pipermail/help-octave/2008-April/008958.html

Furthermore, testing for #if !defined(round) will return TRUE 
even if the local math library does contain round() as a function.
So that is not the right test.

Probably we can use an autoconf test for this:

--- gnuplot/configure.in        2009-07-31 09:42:25.000000000 -0700
+++ gnuplot-cvs/configure.in    2009-08-04 11:09:29.000000000 -0700
@@ -79,6 +79,13 @@
 dnl _instead_ of -lm ...
 AC_CHECK_FUNC(sin,,[AC_CHECK_LIB(m,sin)])

+dnl round() is a C99 math library function
+AC_CHECK_LIB(m, round)
+if test "$ac_cv_lib_m_round" = yes; then
+     AC_DEFINE(HAVE_ROUND,1,
+               [ Define if your platform provides a function round(). ])],
+fi
+
 dnl Header files. ANSI first
 dnl We prefer that the absense of a macro is the norm, so in syscfg.h
 dnl configure's HAVE_XXXX defines are translated into NO_XXXX for ANSI




> So I needed the following patch.
> 
> ----- From here -----
> diff -u configure.in.ORG configure.in
> --- configure.in.ORG	Mon Aug  3 13:47:39 2009
> +++ configure.in	Tue Aug  4 17:05:24 2009
> @@ -1022,7 +1022,7 @@
>  AC_ARG_ENABLE(qt,dnl
>  [  --enable-qt      Qt terminal (default disabled)],
>    [if test "$enableval" = yes; then
> -     enable_qt = yes;
> +     enable_qt=yes;
>     fi])
>  
>  if test "${enable_qt}" = yes ; then
> diff -u src/qtterminal/QtGnuplotScene.h.ORG src/qtterminal/QtGnuplotScene.h
> --- src/qtterminal/QtGnuplotScene.h.ORG	Mon Aug  3 13:47:35 2009
> +++ src/qtterminal/QtGnuplotScene.h	Tue Aug  4 16:50:52 2009
> @@ -49,6 +49,11 @@
>  #include <QGraphicsScene>
>  #include <QTime>
>  
> +/* for Solaris 9 */
> +#if !defined(round)
> +# define round(a) (floor((a)+.5))
> +#endif
> +
>  class QtGnuplotEnhanced;
>  class QtGnuplotWidget;
>  
> diff -u src/qtterminal/qt_term.h.ORG src/qtterminal/qt_term.h
> --- src/qtterminal/qt_term.h.ORG	Mon Aug  3 13:47:36 2009
> +++ src/qtterminal/qt_term.h	Tue Aug  4 16:51:00 2009
> @@ -49,6 +49,11 @@
>  #ifndef GNUPLOT_QT_TERM_H
>  #define GNUPLOT_QT_TERM_H
>  
> +/* for Solaris 9 */
> +#if !defined(round)
> +# define round(a) (floor((a)+.5))
> +#endif
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif /*__cplusplus*/
> ----- To here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

qtterminal on Solaris 9

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

shige 08/04 2009
----------------

When I compiled gnuplot of CVS version with --enable-qt on 
Solaris 9, I found some points:

1) a string "enable_qt = yes;" in configure.in may not have 
  spaces.
2) a function 'round()' is used in src/qtterminal/qt_term.cpp and
  src/qtterminal/QtGnuplotScene.cpp, but Solaris 9 don't have it.

So I needed the following patch.

----- From here -----
diff -u configure.in.ORG configure.in
--- configure.in.ORG	Mon Aug  3 13:47:39 2009
+++ configure.in	Tue Aug  4 17:05:24 2009
@@ -1022,7 +1022,7 @@
 AC_ARG_ENABLE(qt,dnl
 [  --enable-qt      Qt terminal (default disabled)],
   [if test "$enableval" = yes; then
-     enable_qt = yes;
+     enable_qt=yes;
    fi])
 
 if test "${enable_qt}" = yes ; then
diff -u src/qtterminal/QtGnuplotScene.h.ORG src/qtterminal/QtGnuplotScene.h
--- src/qtterminal/QtGnuplotScene.h.ORG	Mon Aug  3 13:47:35 2009
+++ src/qtterminal/QtGnuplotScene.h	Tue Aug  4 16:50:52 2009
@@ -49,6 +49,11 @@
 #include <QGraphicsScene>
 #include <QTime>
 
+/* for Solaris 9 */
+#if !defined(round)
+# define round(a) (floor((a)+.5))
+#endif
+
 class QtGnuplotEnhanced;
 class QtGnuplotWidget;
 
diff -u src/qtterminal/qt_term.h.ORG src/qtterminal/qt_term.h
--- src/qtterminal/qt_term.h.ORG	Mon Aug  3 13:47:36 2009
+++ src/qtterminal/qt_term.h	Tue Aug  4 16:51:00 2009
@@ -49,6 +49,11 @@
 #ifndef GNUPLOT_QT_TERM_H
 #define GNUPLOT_QT_TERM_H
 
+/* for Solaris 9 */
+#if !defined(round)
+# define round(a) (floor((a)+.5))
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif /*__cplusplus*/
----- To here -----

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

Re: mouse-mode and clipboard-mode proposals

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

Jim,

Not sure what you have in mind for clipboard.  There's an old patch that may be of use:

http://sourceforge.net/tracker/?func=detail&aid=1523316&group_id=2055&atid=302055James

Dan

PS: SourceForge's new color scheme sure is odd.


 R. Van Zandt wrote:
> I would like to propose the patch below, which makes three changes to
> the way mouse-mode (the display in the lower left corner of the mouse
> cursor location) and clipboard-mode (what is written to the clipboard
> on a double click) are handled:
> 
>  - Mode 2 (MOUSE_COORDINATES_FRACTIONAL) works even with logscale.
> 
>  - In mode 2, the coordinates are displayed in this format:   
>        graph  0.692328,  1.01163
>    I.e. including the word "graph".  This is the same format used to
>    position labels or arrows, so it helps the user know what
>    mouse-mode he has.  Also, with clipboard-mode 1 or 2, the user can
>    paste directly into a gnuplot script without having to remember the
>    "graph".  (I can't think of any applications for pasting fractional
>    coordinates other than into a gnuplot script.)
> 
>  - Shortcut keys 1 and 2, that currently change mouse-mode, now also
>    change clipboard-mode to match.  This makes the interface slightly
>    less obscure.  (If you want different formats, you can still use
>    keys 3 and 4 to change clipboard-mode only.)
> 
> The last point might be controversial, which is why I'm posting a
> patch instead of just committing the changes.  
> 
> Actually I don't understand why we have separate mouse- and clipboard-
> modes.  It seems unnecessarily complicated to me.  (I would really
> like to deprecate shortcut keys 3 and 4, and eventually eliminate
> clipboard-mode as a separate concept.)  When is it convenient to have
> the two formats be different?
> 
> 
> By the way, the first two modes are documented this way:
>   0   real coordinates in  brackets e.g. [1.23, 2.45]
>   1   real coordinates w/o brackets e.g.  1.23, 2.45
> 
> The square brackets got dropped somewhere along the line, so at
> present, mode 0 is the same as mode 1.  Actually I never saw the
> application for the square brackets.  But two modes for the same thing
> doesn't make sense either.  How about just omitting the comma in mode
> 0:
> 
>   0   real coordinates separated by spaces e.g.   1.23  2.45
>   1   real coordinates separated by a comma e.g.  1.23, 2.45
> 
> 
>                - Jim Van Zandt
> 
> 
> Index: src/mouse.c
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/mouse.c,v
> retrieving revision 1.121
> diff -u -r1.121 mouse.c
> --- src/mouse.c	24 Jul 2009 01:35:55 -0000	1.121
> +++ src/mouse.c	1 Aug 2009 02:30:54 -0000
> @@ -400,25 +400,24 @@
>  	strcat(format, "]");
>  	sprintf(s, format, xDateTimeFormat(x, buf, mode), y);
>      } else if (mode == MOUSE_COORDINATES_FRACTIONAL) {
> -	double xrange = axis_array[FIRST_X_AXIS].max - axis_array[FIRST_X_AXIS].min;
> -	double yrange = axis_array[FIRST_Y_AXIS].max - axis_array[FIRST_Y_AXIS].min;
> +	double xrange = axis_array[FIRST_X_AXIS].term_upper - axis_array[FIRST_X_AXIS].term_lower;
> +	double yrange = axis_array[FIRST_Y_AXIS].term_upper - axis_array[FIRST_Y_AXIS].term_lower;
>  	/* calculate fractional coordinates.
>  	 * prevent division by zero */
>  	if (xrange) {
> -	    char format[0xff] = "/";
> +	    char format[0xff] = "graph ";
>  	    strcat(format, mouse_setting.fmt);
> -	    sprintf(s, format, (x - axis_array[FIRST_X_AXIS].min) / xrange);
> +	    sprintf(s, format, (mouse_x - axis_array[FIRST_X_AXIS].term_lower) / xrange);
>  	} else {
> -	    sprintf(s, "/(undefined)");
> +	    sprintf(s, "(undefined)");
>  	}
>  	s += strlen(s);
>  	if (yrange) {
>  	    char format[0xff] = ", ";
>  	    strcat(format, mouse_setting.fmt);
> -	    strcat(format, "/");
> -	    sprintf(s, format, (y - axis_array[FIRST_Y_AXIS].min) / yrange);
> +	    sprintf(s, format, (mouse_y - axis_array[FIRST_Y_AXIS].term_lower) / yrange);
>  	} else {
> -	    sprintf(s, ", (undefined)/");
> +	    sprintf(s, ", (undefined)");
>  	}
>      } else if (mode == MOUSE_COORDINATES_REAL1) {
>  	sprintf(s, xy_format(), x, y);	/* w/o brackets */
> @@ -739,6 +738,7 @@
>  incr_mousemode(const int amount)
>  {
>      long int old = mouse_mode;
> +    long int old_clip = clipboard_mode;
>      mouse_mode += amount;
>      if (MOUSE_COORDINATES_ALT == mouse_mode && !mouse_alt_string) {
>  	mouse_mode += amount;	/* stepping over */
> @@ -752,8 +752,10 @@
>  	}
>      }
>      UpdateStatusline();
> +    clipboard_mode = mouse_mode;
>      if (display_ipc_commands()) {
>  	fprintf(stderr, "switched mouse format from %ld to %ld\n", old, mouse_mode);
> +	fprintf(stderr, "switched clipboard format from %ld to %ld\n", old_clip, clipboard_mode);
>      }
>  }
>  
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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: mouse-mode and clipboard-mode proposals

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

On Friday 31 July 2009, James R. Van Zandt wrote:
> 
> I would like to propose the patch below, which makes three changes to
> the way mouse-mode (the display in the lower left corner of the mouse
> cursor location) and clipboard-mode (what is written to the clipboard
> on a double click) are handled:

A related thought has occurred to me.
While you're looking at the mouse coordinate code...

One thing I have wished for several times in the past is a mechanism
to make the mouse format persistent.  That is, you can specify a mouse
format and as it is now the format remains in effect while the plot is
still current.  But if you disconnect from the plot, often because of
the following scenario:
     gnuplot -persist myplot.gp
then even if the mouse format is set in the command script, it is lost
immediately and you only get the default mouse format.

The same issue arises if you want to specify a mouse format for use
with the canvas terminal.  Since the mousing events are never going
to be seen by mouse.c, handling the format there doesn't do any good.

This would mean pushing the format out to the drivers (gnuplot_x11
gnuplot_mouse.js wxt_gui.cpp ...) rather than handling it in mouse.c.
I don't so much care if the idea is fully implemented immediately
for all drivers, but if we at least agree on a framework then I might
have a go at adding support to the canvas terminal.

Re: mouse-mode and clipboard-mode proposals

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

On Friday 31 July 2009, James R. Van Zandt wrote:
> 
> I would like to propose the patch below, which makes three changes to
> the way mouse-mode (the display in the lower left corner of the mouse
> cursor location) and clipboard-mode (what is written to the clipboard
> on a double click) are handled:

Wow. You lost me on this one. I didn't even know there was such a thing
as "clipboard mode".  As best as I can tell, it does exactly nothing on
my home linux machine.  No combination of clicks or hotkeys results in 
any coordinate strings appearing in the clipboard tool.  I've tried both
x11 and wxt, and I've tried both middle-mouse and control-v to retrieve
the clipboard entry as well as looking in the clipboard log.  I could
try on one of the lab machines tomorrow, but they are similary configured
so I doubt it will behave any differently there.

So at least in my environment, the whole clipboard issue is moot.
I have no objection to a mode that reads out in graph coordinates.

	Ethan


> 
>  - Mode 2 (MOUSE_COORDINATES_FRACTIONAL) works even with logscale.
> 
>  - In mode 2, the coordinates are displayed in this format:   
>        graph  0.692328,  1.01163
>    I.e. including the word "graph".  This is the same format used to
>    position labels or arrows, so it helps the user know what
>    mouse-mode he has.  Also, with clipboard-mode 1 or 2, the user can
>    paste directly into a gnuplot script without having to remember the
>    "graph".  (I can't think of any applications for pasting fractional
>    coordinates other than into a gnuplot script.)
> 
>  - Shortcut keys 1 and 2, that currently change mouse-mode, now also
>    change clipboard-mode to match.  This makes the interface slightly
>    less obscure.  (If you want different formats, you can still use
>    keys 3 and 4 to change clipboard-mode only.)
> 
> The last point might be controversial, which is why I'm posting a
> patch instead of just committing the changes.  
> 
> Actually I don't understand why we have separate mouse- and clipboard-
> modes.  It seems unnecessarily complicated to me.  (I would really
> like to deprecate shortcut keys 3 and 4, and eventually eliminate
> clipboard-mode as a separate concept.)  When is it convenient to have
> the two formats be different?
> 
> 
> By the way, the first two modes are documented this way:
>   0   real coordinates in  brackets e.g. [1.23, 2.45]
>   1   real coordinates w/o brackets e.g.  1.23, 2.45
> 
> The square brackets got dropped somewhere along the line, so at
> present, mode 0 is the same as mode 1.  Actually I never saw the
> application for the square brackets.  But two modes for the same thing
> doesn't make sense either.  How about just omitting the comma in mode
> 0:
> 
>   0   real coordinates separated by spaces e.g.   1.23  2.45
>   1   real coordinates separated by a comma e.g.  1.23, 2.45
> 
> 
>                - Jim Van Zandt
> 
> 
> Index: src/mouse.c
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/mouse.c,v
> retrieving revision 1.121
> diff -u -r1.121 mouse.c
> --- src/mouse.c	24 Jul 2009 01:35:55 -0000	1.121
> +++ src/mouse.c	1 Aug 2009 02:30:54 -0000
> @@ -400,25 +400,24 @@
>  	strcat(format, "]");
>  	sprintf(s, format, xDateTimeFormat(x, buf, mode), y);
>      } else if (mode == MOUSE_COORDINATES_FRACTIONAL) {
> -	double xrange = axis_array[FIRST_X_AXIS].max - axis_array[FIRST_X_AXIS].min;
> -	double yrange = axis_array[FIRST_Y_AXIS].max - axis_array[FIRST_Y_AXIS].min;
> +	double xrange = axis_array[FIRST_X_AXIS].term_upper - axis_array[FIRST_X_AXIS].term_lower;
> +	double yrange = axis_array[FIRST_Y_AXIS].term_upper - axis_array[FIRST_Y_AXIS].term_lower;
>  	/* calculate fractional coordinates.
>  	 * prevent division by zero */
>  	if (xrange) {
> -	    char format[0xff] = "/";
> +	    char format[0xff] = "graph ";
>  	    strcat(format, mouse_setting.fmt);
> -	    sprintf(s, format, (x - axis_array[FIRST_X_AXIS].min) / xrange);
> +	    sprintf(s, format, (mouse_x - axis_array[FIRST_X_AXIS].term_lower) / xrange);
>  	} else {
> -	    sprintf(s, "/(undefined)");
> +	    sprintf(s, "(undefined)");
>  	}
>  	s += strlen(s);
>  	if (yrange) {
>  	    char format[0xff] = ", ";
>  	    strcat(format, mouse_setting.fmt);
> -	    strcat(format, "/");
> -	    sprintf(s, format, (y - axis_array[FIRST_Y_AXIS].min) / yrange);
> +	    sprintf(s, format, (mouse_y - axis_array[FIRST_Y_AXIS].term_lower) / yrange);
>  	} else {
> -	    sprintf(s, ", (undefined)/");
> +	    sprintf(s, ", (undefined)");
>  	}
>      } else if (mode == MOUSE_COORDINATES_REAL1) {
>  	sprintf(s, xy_format(), x, y);	/* w/o brackets */
> @@ -739,6 +738,7 @@
>  incr_mousemode(const int amount)
>  {
>      long int old = mouse_mode;
> +    long int old_clip = clipboard_mode;
>      mouse_mode += amount;
>      if (MOUSE_COORDINATES_ALT == mouse_mode && !mouse_alt_string) {
>  	mouse_mode += amount;	/* stepping over */
> @@ -752,8 +752,10 @@
>  	}
>      }
>      UpdateStatusline();
> +    clipboard_mode = mouse_mode;
>      if (display_ipc_commands()) {
>  	fprintf(stderr, "switched mouse format from %ld to %ld\n", old, mouse_mode);
> +	fprintf(stderr, "switched clipboard format from %ld to %ld\n", old_clip, clipboard_mode);
>      }
>  }
>  
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

mouse-mode and clipboard-mode proposals

[James R. V. Z. <jr...@co...>]

I would like to propose the patch below, which makes three changes to
the way mouse-mode (the display in the lower left corner of the mouse
cursor location) and clipboard-mode (what is written to the clipboard
on a double click) are handled:

 - Mode 2 (MOUSE_COORDINATES_FRACTIONAL) works even with logscale.

 - In mode 2, the coordinates are displayed in this format:   
       graph  0.692328,  1.01163
   I.e. including the word "graph".  This is the same format used to
   position labels or arrows, so it helps the user know what
   mouse-mode he has.  Also, with clipboard-mode 1 or 2, the user can
   paste directly into a gnuplot script without having to remember the
   "graph".  (I can't think of any applications for pasting fractional
   coordinates other than into a gnuplot script.)

 - Shortcut keys 1 and 2, that currently change mouse-mode, now also
   change clipboard-mode to match.  This makes the interface slightly
   less obscure.  (If you want different formats, you can still use
   keys 3 and 4 to change clipboard-mode only.)

The last point might be controversial, which is why I'm posting a
patch instead of just committing the changes.  

Actually I don't understand why we have separate mouse- and clipboard-
modes.  It seems unnecessarily complicated to me.  (I would really
like to deprecate shortcut keys 3 and 4, and eventually eliminate
clipboard-mode as a separate concept.)  When is it convenient to have
the two formats be different?


By the way, the first two modes are documented this way:
  0   real coordinates in  brackets e.g. [1.23, 2.45]
  1   real coordinates w/o brackets e.g.  1.23, 2.45

The square brackets got dropped somewhere along the line, so at
present, mode 0 is the same as mode 1.  Actually I never saw the
application for the square brackets.  But two modes for the same thing
doesn't make sense either.  How about just omitting the comma in mode
0:

  0   real coordinates separated by spaces e.g.   1.23  2.45
  1   real coordinates separated by a comma e.g.  1.23, 2.45


               - Jim Van Zandt


Index: src/mouse.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/mouse.c,v
retrieving revision 1.121
diff -u -r1.121 mouse.c
--- src/mouse.c	24 Jul 2009 01:35:55 -0000	1.121
+++ src/mouse.c	1 Aug 2009 02:30:54 -0000
@@ -400,25 +400,24 @@
 	strcat(format, "]");
 	sprintf(s, format, xDateTimeFormat(x, buf, mode), y);
     } else if (mode == MOUSE_COORDINATES_FRACTIONAL) {
-	double xrange = axis_array[FIRST_X_AXIS].max - axis_array[FIRST_X_AXIS].min;
-	double yrange = axis_array[FIRST_Y_AXIS].max - axis_array[FIRST_Y_AXIS].min;
+	double xrange = axis_array[FIRST_X_AXIS].term_upper - axis_array[FIRST_X_AXIS].term_lower;
+	double yrange = axis_array[FIRST_Y_AXIS].term_upper - axis_array[FIRST_Y_AXIS].term_lower;
 	/* calculate fractional coordinates.
 	 * prevent division by zero */
 	if (xrange) {
-	    char format[0xff] = "/";
+	    char format[0xff] = "graph ";
 	    strcat(format, mouse_setting.fmt);
-	    sprintf(s, format, (x - axis_array[FIRST_X_AXIS].min) / xrange);
+	    sprintf(s, format, (mouse_x - axis_array[FIRST_X_AXIS].term_lower) / xrange);
 	} else {
-	    sprintf(s, "/(undefined)");
+	    sprintf(s, "(undefined)");
 	}
 	s += strlen(s);
 	if (yrange) {
 	    char format[0xff] = ", ";
 	    strcat(format, mouse_setting.fmt);
-	    strcat(format, "/");
-	    sprintf(s, format, (y - axis_array[FIRST_Y_AXIS].min) / yrange);
+	    sprintf(s, format, (mouse_y - axis_array[FIRST_Y_AXIS].term_lower) / yrange);
 	} else {
-	    sprintf(s, ", (undefined)/");
+	    sprintf(s, ", (undefined)");
 	}
     } else if (mode == MOUSE_COORDINATES_REAL1) {
 	sprintf(s, xy_format(), x, y);	/* w/o brackets */
@@ -739,6 +738,7 @@
 incr_mousemode(const int amount)
 {
     long int old = mouse_mode;
+    long int old_clip = clipboard_mode;
     mouse_mode += amount;
     if (MOUSE_COORDINATES_ALT == mouse_mode && !mouse_alt_string) {
 	mouse_mode += amount;	/* stepping over */
@@ -752,8 +752,10 @@
 	}
     }
     UpdateStatusline();
+    clipboard_mode = mouse_mode;
     if (display_ipc_commands()) {
 	fprintf(stderr, "switched mouse format from %ld to %ld\n", old, mouse_mode);
+	fprintf(stderr, "switched clipboard format from %ld to %ld\n", old_clip, clipboard_mode);
     }
 }
 

Re: getting CVS gnuplot to build

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

On Wednesday 29 July 2009, Allin Cottrell wrote:
> On Wed, 29 Jul 2009, Allin Cottrell wrote:
> >
> > * Revert configure.in to revision 1.248.2.2 (or possibly later)
> >
> > http://gnuplot.cvs.sourceforge.net/viewvc/*checkout*/gnuplot/gnuplot/configure.in?revision=1.248.2.2
> >
> > * Revert src/Makefile.am ...

I have flipped the state of configuration defaults so that the new qt terminal
is only built if you explicitly
    ./configure --enable-qt

Tested on linux machines with and without qt + lrelease, but not tested on OSX.

Somewhere in the process my original problem with dependencies went away.
I suspect that not all of the qt-related files are being cleaned up by
'make clean' or even 'make distclean',  so it currently requires a fresh
download to be sure that the default state is being tested.
Also, be sure to use the -d flag to "cvs update":

    cvs update -d 

	Ethan

Re:Qt, grrr...

[<lod...@us...>]

> Allin Cottrell wrote:
> Following up on Ethan's message -- excuse me, but who
committed
> this crap?  Looks like "lodewyck".  There's no way that the
> absence of Qt should halt a gnuplot configure and build
(as I have
> just confirmed).
>
> lodewyck: please get a clue before committing to gnuplot CVS.

Sorry for the inconvenience. It should be fixed now. I'll
stop fiddling with build systems in the future.

Jérôme


---------------------- ALICE N°1 de la RELATION CLIENT 2008*--------------------
Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES / BEARING POINT. Secteur Fournisseur d.Accès Internet

Re: getting CVS gnuplot to build

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

On Wed, 29 Jul 2009, Allin Cottrell wrote:

> * Get current CVS gnuplot
>
> * Revert configure.in to revision 1.248.2.2 (or possibly later)
>
> http://gnuplot.cvs.sourceforge.net/viewvc/*checkout*/gnuplot/gnuplot/configure.in?revision=1.248.2.2
>
> * Revert src/Makefile.in ...

Sorry, that's src/Makefile.am

A.C.

Qt, grrr...

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

Following up on Ethan's message -- excuse me, but who committed
this crap?  Looks like "lodewyck".  There's no way that the
absence of Qt should halt a gnuplot configure and build (as I have
just confirmed).

lodewyck: please get a clue before committing to gnuplot CVS.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

getting CVS gnuplot to build

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

* Get current CVS gnuplot

* Revert configure.in to revision 1.248.2.2 (or possibly later)

http://gnuplot.cvs.sourceforge.net/viewvc/*checkout*/gnuplot/gnuplot/configure.in?revision=1.248.2.2

* Revert src/Makefile.in to revision 1.69 (it's possible that a
later revision will work):

http://gnuplot.cvs.sourceforge.net/viewvc/*checkout*/gnuplot/gnuplot/src/Makefile.am?revision=1.69

Then do ./prepare etc. as usual.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: Qt build failure from today's CVS

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

Hello

I have encountered other problem on cygwin(1.7) build.  My system do not have Qt.

At the ./configure, the Qt check stop the configure script and do not allow to build without Qt.

***********
configure: WARNING: The cairo terminals will not be compiled.
checking for QT... configure: WARNING:
Package requirements (QtCore >= 4.5 QtGui >= 4.5 QtNetwork >= 4.5 QtSvg >= 4.5) were not met:

No package 'QtCore' found
No package 'QtGui' found
No package 'QtNetwork' found
No package 'QtSvg' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables QT_CFLAGS
and QT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

configure: WARNING: The Qt terminal will not be compiled.
configure: error: conditional "HAVE_LRELEASE" was never defined.
Usually this means the macro was only invoked conditionally.
**************************

The ./configure stopped at the point shown in above and do not go forward to build without Qt.

The bug may be introduced the change 

2009-07-29  Jテゥrテエme Lodewyck <lod...@us...>
	* configue.in src/Makefile.am: better check for Qt tools
	moc uic and lrelease.

Please check the change the above.

Regards

Tatsuro

PS. Hello Ethan
Sorry for my previous mail.  I have mistaken to handle of the mail program and sent the mail only to
you. Please ignore and delete the mail.


--- Ethan Merritt  wrote:

> Fresh download + prepare + configure + build
> using today's CVS fails with the following messages:
> 
> make[3]: Entering directory `/home/merritt/cvs/gnuplot-cvs/src'
> uic -o ui_QtGnuplotSettings.h qtterminal/QtGnuplotSettings.ui
> make[3]: *** No rule to make target `qtgnuplot_fr.qm', needed by `alloc.o'.  Stop.
> make[3]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs'
> make: *** [all] Error 2
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/



--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Qt build failure from today's CVS

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

Fresh download + prepare + configure + build
using today's CVS fails with the following messages:

make[3]: Entering directory `/home/merritt/cvs/gnuplot-cvs/src'
uic -o ui_QtGnuplotSettings.h qtterminal/QtGnuplotSettings.ui
make[3]: *** No rule to make target `qtgnuplot_fr.qm', needed by `alloc.o'.  Stop.
make[3]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/merritt/cvs/gnuplot-cvs/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/merritt/cvs/gnuplot-cvs'
make: *** [all] Error 2

Re: mouse pan and zoom

[James R. V. Z. <jr...@co...>]

Ethan Merritt wrote:
>On Thursday 23 July 2009 19:12:56 James R. Van Zandt wrote:
>
>> I revised plot3d.c to fix the X and Y limits before checking for valid
>> Z values:
...
>> 
>> It works here.  However, I'd appreciate someone with a better
>> understanding of the code checking for side effects.
>
>I don't know if it counts as a side-effect, but after setting
>
>   set view equal xyz
>
>the 3D zoom behavior (control + mouse wheel) is unexpected.
>I would have expected the whole plot to get bigger or smaller;
>instead the x/y area remains fixed, the x and y scales change,
>and the z axis grows correspondingly longer or shorter.
>
>Note:  since 'set view equal xyz' doesn't work in the x11 terminal anyhow,
>you would need to use the wxt or maybe qt terminal to see what I'm describing. 

I'm not familiar with "set view equal xyz", but it seems to do
*something* here, in the x11 terminal.  E.g., provided I start with a
square window, these commands:

    set parametric
    set view equal xyz
    set view 58,228
    set hidden3d
    set isosamples 30,30
    set vrange [-pi:pi]
    set urange [-2:2]
    set xrange [-2:2]
    set yrange [-1.5:1.5]
    set ticslevel .2
    splot cos(u)+.5*cos(u)*cos(v),.5*sin(v),sin(u)+.5*sin(u)*cos(v)

will plot with equal screen distance per axis distance for all three
axes.  (With a rectangular window, the vertical scaling is off.  Is
that the bug you're referring to?  If so, then maybe it should be
mentioned in the docs?)

Assuming that's what it's supposed to do, then I believe the
control-wheel is handling the X and Y axes correctly.  Perhaps it
should scale the Z the same way (i.e. the figure grows, but parts
outside the plot range don't get drawn).  However, I wasn't able to
implement Z scaling.  I did include some code that used alt-wheel to
scroll up in Z.  However, it's commented out* because do_zoom() and
apply_zoom() don't implement anything for Z, and I didn't understand
the logic well enough to modify them.  (Feel free to delete that part
if you think it clutters the code.)

At least, control-wheel does maintain the relative scaling.

         - Jim Van Zandt

* actually it's conditional on DO_ZOOM_AND_APPLY_ZOOM_FIXED_TO_HANDLE_Z_AXIS.

Re: mouse pan and zoom

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

On Thursday 23 July 2009 19:12:56 James R. Van Zandt wrote:
> 

> I revised plot3d.c to fix the X and Y limits before checking for valid
> Z values:
> 
>     axis_checked_extend_empty_range(FIRST_X_AXIS, "All points x value undefined");
>     axis_revert_and_unlog_range(FIRST_X_AXIS);
>     axis_checked_extend_empty_range(FIRST_Y_AXIS, "All points y value undefined");
>     axis_revert_and_unlog_range(FIRST_Y_AXIS);
>     if (splot_map)
> 	axis_checked_extend_empty_range(FIRST_Z_AXIS, NULL); /* Suppress warning message */
>     else
> 	axis_checked_extend_empty_range(FIRST_Z_AXIS, "All points z value undefined");
> 
>     axis_revert_and_unlog_range(FIRST_Z_AXIS);
> 
> It works here.  However, I'd appreciate someone with a better
> understanding of the code checking for side effects.
> 
> 	   - Jim Van Zandt

I don't know if it counts as a side-effect, but after setting

   set view equal xyz

the 3D zoom behavior (control + mouse wheel) is unexpected.
I would have expected the whole plot to get bigger or smaller;
instead the x/y area remains fixed, the x and y scales change,
and the z axis grows correspondingly longer or shorter.

Note:  since 'set view equal xyz' doesn't work in the x11 terminal anyhow,
you would need to use the wxt or maybe qt terminal to see what I'm describing. 

	Ethan Merritt

Re: mouse pan and zoom

[James R. V. Z. <jr...@co...>]

On Tuesday I wrote:
 >In the mean time I've found a simpler approach:
 >
 > if (modifier_mask & Mod_Shift) {
 >    /* scroll left */
 >    xmin = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,1.1*axis_array[FIRST_X_AXIS].min 
 >					     -.1*axis_array[FIRST_X_AXIS].max);
 >    ymin = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].min);
 >    x2min = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,1.1*axis_array[SECOND_X_AXIS].min 
 >					       -.1*axis_array[SECOND_X_AXIS].max);
 >    y2min = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].min);
 >
 >    xmax = AXIS_DE_LOG_VALUE(FIRST_X_AXIS,.1*axis_array[FIRST_X_AXIS].min 
 >					    +.9*axis_array[FIRST_X_AXIS].max);
 >    ymax = AXIS_DE_LOG_VALUE(FIRST_Y_AXIS,axis_array[FIRST_Y_AXIS].max);
 >    x2max = AXIS_DE_LOG_VALUE(SECOND_X_AXIS,.1*axis_array[SECOND_X_AXIS].min 
 >					      +.9*axis_array[SECOND_X_AXIS].max);
 >    y2max = AXIS_DE_LOG_VALUE(SECOND_Y_AXIS,axis_array[SECOND_Y_AXIS].max);
 >    do_zoom(xmin, ymin, x2min, y2min, xmax, ymax, x2max, y2max);
 >    if (display_ipc_commands()) {
 >	 fprintf(stderr, "scroll left.\n");
 >    }
 > } 
 >
 >Since this doesn't involve MousePosToGraphPosReal(), it works even for
 >splot.  I don't know whether this change would affect the other terminals.
 >
 >I haven't checked in this change because I found a bug: If I plot a
 >function defined only for certain values of Y, and set logscale Y, and
 >scroll past the defined region, then it breaks.  E.g.
 >
 >  set logscale y;set xrange [0:5];set yrange [.01:10];
 >  splot sqrt(1.02-(1- x)**2 - (1-y)**2)
 >
 >I haven't diagnosed that problem yet.

I have zoom and pan with the mouse wheel working for 3D as well as 2D plots.

I found the problem mentioned above in this section of plot3d.c: 

    axis_checked_extend_empty_range(FIRST_X_AXIS, "All points x value undefined");
    axis_checked_extend_empty_range(FIRST_Y_AXIS, "All points y value undefined");
    if (splot_map)
	axis_checked_extend_empty_range(FIRST_Z_AXIS, NULL); /* Suppress warning message */
    else
	axis_checked_extend_empty_range(FIRST_Z_AXIS, "All points z value undefined");

    axis_revert_and_unlog_range(FIRST_X_AXIS);
    axis_revert_and_unlog_range(FIRST_Y_AXIS);
    axis_revert_and_unlog_range(FIRST_Z_AXIS);

The test function in the splot command above is defined only for -.01
< y < 2.01.  With logscale y, if I scroll up far enough that all the
defined points are outside the plot range, then I get the "All points
z value undefined" message and it abandons the plot.  The problem was
that axis_array[FIRST_Y_AXIS].min and .max almost always hold
transformed values (logs of the minimum and maximum values to be
plotted).  The exception is that when mouse commands adjust the scale,
the untransformed values are stored there.  They are supposed to be
converted back to logs by the call to axis_revert_and_unlog_range()
shown above.  If the conversion never happens, then scaling is messed
up - e.g. instead of yrange [.01:20] you would get [10**.01 : 10**20],
and just turning the mouse wheel the other direction cannot fix it.

I revised plot3d.c to fix the X and Y limits before checking for valid
Z values:

    axis_checked_extend_empty_range(FIRST_X_AXIS, "All points x value undefined");
    axis_revert_and_unlog_range(FIRST_X_AXIS);
    axis_checked_extend_empty_range(FIRST_Y_AXIS, "All points y value undefined");
    axis_revert_and_unlog_range(FIRST_Y_AXIS);
    if (splot_map)
	axis_checked_extend_empty_range(FIRST_Z_AXIS, NULL); /* Suppress warning message */
    else
	axis_checked_extend_empty_range(FIRST_Z_AXIS, "All points z value undefined");

    axis_revert_and_unlog_range(FIRST_Z_AXIS);

It works here.  However, I'd appreciate someone with a better
understanding of the code checking for side effects.

	   - Jim Van Zandt

Re: irreversibly reversing range

[Hans-Bernhard B. <HBB...@t-...>]

Mojca Miklavec wrote:

> plot [0:10] sin(x)
   show xrange
> plot [10:0] sin(x)
   show xrange
> plot [0:10] sin(x)
   show xrange

I suggest everyone who tries this puts in those 'show xrange' between 
plots to see what actually happens.

There are two separate issues here.

1) plot [10:0] sin(x) may never change the state of the reverse option 
of 'set xrange'.  It doesn't change the range itself, so it should leave 
the reverse option alone, too.  But this in and of itself is relatively 
harmless.  This bug has been in the program since at least 4.2.3

2) The visible bug that the x axis is actually still reversed in the 
third plot appears to be newer.  It was introduced after 4.2.3, and is 
still  present in the current CVS head.

Re: irreversibly reversing range

[Hans-Bernhard B. <HBB...@t-...>]

Ethan Merritt wrote:

> IMHO the real problem is that placing a range in the plot command itself
>    plot ... [foo:baz] ...
> does not have an obvious meaning.

Well, actually this one has no meaning at all --- in a plot command the 
range comes first, or not at all, i.e. it must be

    plot [foo:baz] ...

And thus modified it does have a well-documented meaning (see "help plot 
ranges"): it sets the range for the duration of that plot command. 
That's been so for as long as it existed.  IMHO that should qualify as 
obvious.

If memory serves originally there was only this range option in the 
'plot' argument list.  "Set xrange" was added later, to make the command 
interface more efficient when there are lots of plots with the same range.

Re: irreversibly reversing range

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

On Tue, Jul 21, 2009 at 17:45, Ethan Merritt wrote:
> On Tuesday 21 July 2009, Mojca Miklavec wrote:
>> On Tue, Jul 21, 2009 at 14:39, Thomas Sefzick wrote:
>> >
>> > set xrange [] noreverse
>>
>> Thanks. But shouldn't it change back automatically?
>>
>> It automatically changes to "reverse" as soon as one uses [more:less],
>> but doesn't automatically change back.
>
> I tend to agree with you on this point, but...
>
>> I mean ...
>>
>> > show xrange
>>       set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
>> > plot [0:10] sin(x)
>> > show xrange
>>       set xrange [ * : * ] noreverse nowriteback  # (currently [0.00000:10.0000] )
>> > plot  sin(x)
>> # only "currently" changes, but gets restored as soon as one drops
>> using explicit [:]
>> > show xrange
>>       set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
>> > plot [10:0] sin(x)
>> > show xrange
>>       set xrange [ * : * ] reverse nowriteback  # (currently [10.0000:0.00000] )
>> > plot sin(x)
>> # in my opinion this should become "noreverse" automatically
>
> there I completely disagree.  You set the range to be [10:0], and for a
> subsequent plot to silently change that is a really bad idea.
>
> IMHO the real problem is that placing a range in the plot command itself
>   plot ... [foo:baz] ...
> does not have an obvious meaning.
> Does that range apply to only the clause it appears in?
> Does it apply to the entire plot command?
> Does it persist after the plot command?

It (almost) never does.
    plot [foo:baz] something
plots betwee foo and baz. In next plot this setting is (always) forgotten.

When working with data files one usually doesn't want to have xrange
defined, so one alternative is to use
    set xrange [foo:baz]
    plot sin(x)
    set xrange restore
    plot 'a.dat'
as opposed to
    plot [foo:baz] sin(x)
    plot 'a.dat'
but I prefer the second one (much shorter). Since one cannot set
"subrange" of plots anyway, i.e.
    plot 'a.dat', [0:1] f(x)
doesn't work, one needs to use
    plot 'a.dat', (x>=0 && x<=1) ? f(x) : 1/0
instead, the "plot [foo:baz]" seem very well defined to me, but I
might be missing some weird cases (multiplots?) that I don't know
well.

> Does it affect the value of variables evaluated during the plot command?
>
> Yes, it is possible to determine the answers to these questions by experimentation,
> but it seems to me that the better approach is simply not to use this construct.
> There are no such ambiguities associated with an explicit
>  set xrange [foo:baz];
>  plot ...

Sure, but see above. That means almost twice as much typing.

The fact is that one almost never needs reversed axis, so the issue
hardly affects anyone and therefore has a low priority anyway. (I
purely accidentally deleted one chacater too much when specifying the
range and have been bitten by that unexpected behaviour. I don't
expect myself to be affected in any other circumstances.)

I would call it a tiny bug, but whether it's worth fixing (or if it's
considered a bug at all) still depends on developers.

Mojca


>> # unless someone uses "set xrange [] reverse" by explicitely calling it
>> > show xrange
>>       set xrange [ * : * ] reverse nowriteback  # (currently [10.0000:-10.0000] )
>>
>> I didn't check internals, but maybe a separate variable is needed to
>> track "current reverse" just as there is "current range" after #.
>>
>> Mojca
>>
>> > Mojca Miklavec wrote:
>> >>
>> >> Hello,
>> >>
>> >> I accidentally used "plot [bigger:smaller]", but when I corrected the
>> >> mistake, the plotting range didn't restore to the appropriate value.
>> >> Would it make sense to fix that behaviour?
>> >>
>> >> Example:
>> >>
>> >> # ok
>> >> plot [0:10] sin(x)
>> >> # ok
>> >> plot [10:0] sin(x)
>> >> # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset"
>> >> does
>> >> plot [0:10] sin(x)
>> >>
>> >> Thanks,
>> >>     Mojca

Re: irreversibly reversing range

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

On Tuesday 21 July 2009, Mojca Miklavec wrote:
> On Tue, Jul 21, 2009 at 14:39, Thomas Sefzick wrote:
> >
> > set xrange [] noreverse
> 
> Thanks. But shouldn't it change back automatically?
> 
> It automatically changes to "reverse" as soon as one uses [more:less],
> but doesn't automatically change back.

I tend to agree with you on this point, but...
 
> I mean ...
> 
> > show xrange
> 	set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
> > plot [0:10] sin(x)
> > show xrange
> 	set xrange [ * : * ] noreverse nowriteback  # (currently [0.00000:10.0000] )
> > plot  sin(x)
> # only "currently" changes, but gets restored as soon as one drops
> using explicit [:]
> > show xrange
> 	set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
> > plot [10:0] sin(x)
> > show xrange
> 	set xrange [ * : * ] reverse nowriteback  # (currently [10.0000:0.00000] )
> > plot sin(x)
> # in my opinion this should become "noreverse" automatically

there I completely disagree.  You set the range to be [10:0], and for a
subsequent plot to silently change that is a really bad idea.

IMHO the real problem is that placing a range in the plot command itself
   plot ... [foo:baz] ...
does not have an obvious meaning.
Does that range apply to only the clause it appears in?
Does it apply to the entire plot command?
Does it persist after the plot command?
Does it affect the value of variables evaluated during the plot command?

Yes, it is possible to determine the answers to these questions by experimentation,
but it seems to me that the better approach is simply not to use this construct.
There are no such ambiguities associated with an explicit
  set xrange [foo:baz];
  plot ...

	Ethan

> # unless someone uses "set xrange [] reverse" by explicitely calling it
> > show xrange
> 	set xrange [ * : * ] reverse nowriteback  # (currently [10.0000:-10.0000] )
> 
> I didn't check internals, but maybe a separate variable is needed to
> track "current reverse" just as there is "current range" after #.
> 
> Mojca
> 
> > Mojca Miklavec wrote:
> >>
> >> Hello,
> >>
> >> I accidentally used "plot [bigger:smaller]", but when I corrected the
> >> mistake, the plotting range didn't restore to the appropriate value.
> >> Would it make sense to fix that behaviour?
> >>
> >> Example:
> >>
> >> # ok
> >> plot [0:10] sin(x)
> >> # ok
> >> plot [10:0] sin(x)
> >> # wrong; plots as [10:0]; "set xrange restore" doesn't help; only "reset"
> >> does
> >> plot [0:10] sin(x)
> >>
> >> Thanks,
> >>     Mojca
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>