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

Re: Clipping of arrows buggy

[Hans-Bernhard B. <br...@ph...>]

Harald Harders wrote:
> In large splots with screen size above 1, arrows that are totally outside
> the screen coordinates 1,1 are not plotted, see example:

It might help if you explained in more detail what *exactly* is wrong 
about the multi-page output generated by this script.  This is probably 
related to this old bug report at SF.net:

[ 839739 ] 'set arrow' to far away points causes garbage

I don't think 'set size' being larger than one is supposed to have 
anything to do with this --- 'screen' coordinates are meant to be 
relative to the actual screen size, not the default.

Re: Clipping of arrows buggy

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

Ethan Merritt wrote:

>On Monday 17 January 2005 01:50 pm, Harald Harders wrote:
>  
>
>>In large splots with screen size above 1, arrows that are totally outside
>>the screen coordinates 1,1 are not plotted, see example:
>>    
>>
>
>Harald:
>
>I see no difference in the output before applying your patch
>and after applying your patch.  What, exactly, is the change
>supposed to be?
>  
>

I'm not understanding this one either, Harald.  I've run your example, 
and the arrows that are visible make sense.  They are specified relative 
to the screen and come out looking the same in all plots.  However, the 
plots are extended past the visible part of the plot.  I think I 
understand that the arrow you've plotted

set arrow from screen 1.1,0 rto screen 0,.5 as 1

doesn't appear.  However, that shouldn't appear because no portion of it 
lies within the visible part of the image.  On the other hand, it still 
doesn't appear even if a *portion* of the arrow should appear on the 
screen.  So that may be your point, no?  For example, changing the above to

set arrow from screen 1.1,0 rto screen -.5,.5 as 1

should give a portion of an arrow.  That should be made to work fairly 
easy.  Afterall, the enlarged splots and plots show only a portion of 
the axis on the screen.  The arrows shouldn't be done any differently.  
Can the conditional test be removed altogether?  The clipping should be 
done at a lower level I would think.

Dan

PS:  One other thing I notice about splot is that the tics appear right 
up against the x and y axes.  The z tics look nice.

Re: Clipping of arrows buggy

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

On Monday 17 January 2005 01:50 pm, Harald Harders wrote:
> 
> In large splots with screen size above 1, arrows that are totally outside
> the screen coordinates 1,1 are not plotted, see example:

Harald:

I see no difference in the output before applying your patch
and after applying your patch.  What, exactly, is the change
supposed to be?


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Clipping of arrows buggy

[Harald H. <h.h...@tu...>]

In large splots with screen size above 1, arrows that are totally outside
the screen coordinates 1,1 are not plotted, see example:

set size 1.8,1.8
set terminal postscript color linewidth 4
set output 'gnuplotbug.ps'
set style arrow 1 nohead lt 1 front
set xrange [0:1]
set yrange [0:1]
set zrange [0:1]
set arrow from screen 1,0 rto screen 0,1 as 1
set arrow from screen 0,1 rto screen 1,0 as 1
set arrow from screen 0,0 rto screen 0,1 as 1
set arrow from screen 0,0 rto screen 1,0 as 1
set arrow from screen 1.1,0 rto screen 0,.5 as 1
set arrow from screen 0.9,0 rto screen 0,.5 as 1
set label '1' at screen 0.9,0.9
set label '2' at screen 1.0,1.0
set label '3' at screen 1.1,1.1
set label '4' at screen 0.1,0.1
set label '5' at screen 0.0,0.0
set label '6' at screen -0.1,-0.1
splot 1/0 notitle
plot 1/0 notitle
set multiplot
set size 0.8,0.8
set origin 0.1,0.1
splot 1/0 notitle
unset multiplot
set multiplot
set size 0.8,0.8
set origin 0.1,0.1
plot 1/0 notitle
unset multiplot
set output

I have written a patch that seems to work both with and without multiplot.
There is still one strange thing: Have a look at the arrows at the upper
corners. In 2d plots they are there, in 3d plots they are cut off. What is
the right behaviour?

Harald






Here is the patch:

diff -uNr orig/src/gadgets.c arrow/src/gadgets.c
--- orig/src/gadgets.c	2005-01-11 17:39:34.000000000 +0100
+++ arrow/src/gadgets.c	2005-01-17 22:41:05.000000000 +0100
@@ -62,6 +62,8 @@
 float xsize = 1.0;		/* scale factor for size */
 float ysize = 1.0;		/* scale factor for size */
 float zsize = 1.0;		/* scale factor for size */
+float global_xsize = 1.0;	/* scale factor for size */
+float global_ysize = 1.0;	/* scale factor for size */
 float xoffset = 0.0;		/* x origin */
 float yoffset = 0.0;		/* y origin */
 float aspect_ratio = 0.0;	/* don't attempt to force it */
diff -uNr orig/src/gadgets.h arrow/src/gadgets.h
--- orig/src/gadgets.h	2005-01-11 17:39:34.000000000 +0100
+++ arrow/src/gadgets.h	2005-01-17 22:37:56.000000000 +0100
@@ -249,6 +249,8 @@
 extern float xsize;		/* x scale factor for size */
 extern float ysize;		/* y scale factor for size */
 extern float zsize;		/* z scale factor for size */
+extern float global_xsize;	/* x scale factor for size */
+extern float global_ysize;	/* y scale factor for size */
 extern float xoffset;		/* x origin setting */
 extern float yoffset;		/* y origin setting */
 extern float aspect_ratio;	/* 1.0 for square */
diff -uNr orig/src/graph3d.c arrow/src/graph3d.c
--- orig/src/graph3d.c	2005-01-05 21:48:48.000000000 +0100
+++ arrow/src/graph3d.c	2005-01-17 22:47:42.000000000 +0100
@@ -453,8 +453,15 @@

     /* EAM  FIXME - Is this a sufficiently general test for out-of-bounds? */
     /*              Should we test the other end of the arrow also?        */
-    if (*sx < 0 || *sx > term->xmax || *sy < 0 || *sy > term->ymax)
+    if ((*sx < 0) ||
+	(multiplot && (*sx > term->xmax * global_xsize)) ||
+	(!multiplot && (*sx > term->xmax * xsize)) ||
+	(*sy < 0) ||
+	(multiplot && (*sy > term->ymax * global_ysize)) ||
+	(!multiplot && (*sy > term->ymax * ysize))) {
+	FPRINTF((stderr,"get_arrow3d: skipping out-of-bounds arrow\n"));
 	return FALSE;
+    }

     if (arrow->relative) {
 	map3d_position_r(&(arrow->end), ex, ey, "arrow");
@@ -484,7 +491,12 @@
 	map3d_position(&this_label->place, &x, &y, "label");

 	/* EAM FIXME - Is this a sufficient test for out-of-bounds? */
-	if (x < 0 || x > term->xmax || y < 0 || y > term->ymax) {
+	if ((x < 0) ||
+	    (multiplot && (x > term->xmax * global_xsize)) ||
+	    (!multiplot && (x > term->xmax * xsize)) ||
+	    (y < 0) ||
+	    (multiplot && (y > term->ymax * global_ysize)) ||
+	    (!multiplot && (y > term->ymax * ysize))) {
 	    FPRINTF((stderr,"place_labels3d: skipping out-of-bounds label\n"));
 	    continue;
 	}
diff -uNr orig/src/set.c arrow/src/set.c
--- orig/src/set.c	2005-01-12 20:38:52.000000000 +0100
+++ arrow/src/set.c	2005-01-17 22:39:43.000000000 +0100
@@ -3070,6 +3070,10 @@
 	    }
 	}
     }
+    if (!multiplot) {
+	global_xsize = xsize;
+	global_ysize = ysize;
+    }
 }


diff -uNr orig/src/term.c arrow/src/term.c
--- orig/src/term.c	2005-01-12 20:38:52.000000000 +0100
+++ arrow/src/term.c	2005-01-17 22:39:18.000000000 +0100
@@ -606,7 +606,10 @@

     multiplot = TRUE;
     mp_layout.auto_layout = FALSE;
-
+
+    global_xsize = xsize;
+    global_ysize = ysize;
+
     /* check for optional multiplot layout */
     if (!END_OF_COMMAND && almost_equals(c_token,"lay$out")) {
 	struct value a;


-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Proposal to change behavior of "pause mouse key"

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

Recent discussions with Jacques Bouchard about making multiple
plot windows appear "active" to the user led to patchset #1090199
on SourceForge, which introduces a "bind all <key> <command>"
option so that hotkeys are can be accepted by all X11 plot windows.

But this ran into an old sore point that mouse zooming does
not work during either "pause mouse" or "pause mouse key". 

I propose to modify "pause mouse key" so that mouse clicks,
in particular zooming, do not terminate the pause command.
This is needed for Jacques' application, and makes more sense
to me anyhow.

As I recall, Petr was the one who wanted "pause mouse key" to
terminate on either mouse click or keystroke.  Is that still
true?  Would it be OK to make this a separate option?

  pause mouse:
	terminate on mouse click
	hotkeys ("bind <key> <foo>") work as normal
  pause mouse key:
	mouse clicks work as normal, including zoom (CHANGE)
	terminate on keypress in plot window
  pause mouse any
	terminates on either mouse click or keystroke (NEW)

Or maybe we should look ahead to other possible pause variants,
and introduce new keywords, allowing multiple termination conditions:

  pause mouse {key|button1|button2|...} "text prompt"

Example:
  pause mouse button1 key  "Hit any key or use left mouse button"

Default (current "pause mouse"):
  pause mouse button1 button2 button3

What do you think?

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

Re: Povray terminal output

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

Hans-Bernhard Broeker wrote:

> Ga=C3=ABl Varoquaux wrote:
>
>>   This is a bit a crazy idea, but I was wondering if it would be=20
>> possible to
>> have a povray terminal output for gnuplot, a bit like the latex=20
>> terminal. I
>> don't know povray much so I don't know how suited it would be for=20
>> displaying the
>> 2D elements of a gnuplot output, but it is clearly very powerfull for=20
>> 3D display.
>
>
> That issue of 2D vs. 3D is actually a major part of the problem.=20
> gnuplot's terminal driver layer is entirely 2D by design.  The only=20
> case where 3D data actually survives into an splot's output is 'set=20
> term table'.  IIRC, filtering that into POVray as, say, a heightfield=20
> is quite easy.  It'll probably be even easier by way of a 'with image'=20
> or pm3d output saved to graylevel image, which POVray already accepts a=
s
> heightfield input.


This probably comes back to the topic of Gnuplot saving so many, often=20
unused, variables per point.  A lot of work, yes.  Although, it might=20
not be too difficult to create a setup whereby the "width" of=20
multidimensional data is varied depending upon the plot.  But again, I'd=20
wait until 2D/3D are made more similar before attempting anything like th=
at.

Dan

Re: Povray terminal output

[Hans-Bernhard B. <br...@ph...>]

Ga=C3=ABl Varoquaux wrote:

>   This is a bit a crazy idea, but I was wondering if it would be possib=
le to
> have a povray terminal output for gnuplot, a bit like the latex termina=
l. I
> don't know povray much so I don't know how suited it would be for displ=
aying the
> 2D elements of a gnuplot output, but it is clearly very powerfull for 3=
D display.

That issue of 2D vs. 3D is actually a major part of the problem.=20
gnuplot's terminal driver layer is entirely 2D by design.  The only case =

where 3D data actually survives into an splot's output is 'set term=20
table'.  IIRC, filtering that into POVray as, say, a heightfield is=20
quite easy.  It'll probably be even easier by way of a 'with image' or=20
pm3d output saved to graylevel image, which POVray already accepts as
heightfield input.

Re: Data presentation question.

[Hans-Bernhard B. <br...@ph...>]

Justace Clutter wrote:

> 	I have a small question concerning plotting.  I have a 4-D data set,
> x,y,z, and scalar value.  I would like to plot this and get a grid  a 3D
> grid with the color of the grid point mapped to a color based on the 4th
> column number.  I thought this was the default for the pm3d style.  But
> it is not. 

I wonder what made you think it would be...

PM3D plots coloured solid surfaces.  Not grids (--> lines), not points, 
but solid-filled triangulated surface meshes.


	set pm3d explicit
	splot 'datafile' using 1:2:3:4 with points palette

should do what you want.

Povray terminal

[V. <var...@cl...>]

   Hello,

  I know this is a crazy idea, but I was wondering if there where plans to build
a    povray terminal that would allow gnuplot to produce povray files (just like
it can produce tex file).

   I think this would really be fantastique, gnuplot could then act as a common
data processing and displaying interface. This would be very convenient for the
user (only one language to learn), and this would allow other scientific
applications (such as Maxima) to use povray through gnuplot.

   This probably involves a fair about of work but I think in would increase the
scope a gnuplot by a large amount, hopefully pushing many scientific
applications to have a gnuplot output.

      Regards,

               Gaël Varoquaux

PS : I allready sent a similar message to mailing list but it did not appear on
the archive, so I am trying again

Data presentation question.

[Justace C. <pro...@co...>]

Gnuplot users and developers,

	I have a small question concerning plotting.  I have a 4-D data set,
x,y,z, and scalar value.  I would like to plot this and get a grid  a 3D
grid with the color of the grid point mapped to a color based on the 4th
column number.  I thought this was the default for the pm3d style.  But
it is not.  I did some searching online but I did not find a whole lot
of information out there about it.  I found a lot of example of pm3d
stuff but not what I was looking for.  Possibly it can not be done.  Can
anybody give me any guidance on this.  Thanks in advance.

Justace

P.S.  Here are the first few lines of the data file....

  0.0500000007  0.0399999991  0.200000003  1.03786671
  0.0500000007  0.0399999991  0.400000006  1.03786671
  0.0500000007  0.0399999991  0.600000024  1.03786671
  0.0500000007  0.0399999991  0.800000012  1.03786671
  0.0500000007  0.0399999991  1.  1.03786671
  0.0500000007  0.0799999982  0.200000003  1.03824031
  0.0500000007  0.0799999982  0.400000006  1.03824019
  0.0500000007  0.0799999982  0.600000024  1.03824031
  0.0500000007  0.0799999982  0.800000012  1.03824031
  0.0500000007  0.0799999982  1.  1.03824031

Povray terminal output

[V. <var...@cl...>]

   Hello,

  This is a bit a crazy idea, but I was wondering if it would be possible to
have a povray terminal output for gnuplot, a bit like the latex terminal. I
don't know povray much so I don't know how suited it would be for displaying the
2D elements of a gnuplot output, but it is clearly very powerfull for 3D display.

  Why not use povray directly ? First because povray takes longer to learn, but
more important, because quite a few programs already use gnuplot as an output
routine (for instance maxima), adding a povray terminal to gnuplot would
increase the scope of gnuplot, establishing it as a excellent output driver for
scientific programs.

    I am aware this is a lot of work, but it would be so convienent.

      Regards,

             Gaël Varoquaux

Re: gd.trm and multiple plots with png

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

On Thursday 13 January 2005 05:02 pm, Hans-Bernhard Broeker wrote:
>
> It may not even be strictly necessary --- at least not for GIF files
> generated by gd.trm.  GIF files can, at least in principle, hold
> multiple pages.  But I suspect the GD library doesn't support this
> (admittedly rarely used) feature, so gd.trm can't do anything about
> that.

Tom Boutell says it is scheduled for an upcoming version of libgd.
And, as I mentioned already, png could be supported this way also.
But I don't know of any specific plans to add multi-image png
support to libgd.


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

mailing list delay

[Jacques B. <jac...@no...>]

Today I sent a message (subject: Re: empty data-files) to this mailing 
list from:

http://news.gmane.org/gmane.comp.graphics.gnuplot.devel

but:

- I can't see it in the mailing list archive
- I didn't receive the message at jac...@no...

Has the message been delivered to the mailing list?
How often is the archive updated?
What's the problem?

Re: empty data-files

[Jacques B. <jac...@on...>]

Petr Mikulik <mikulik <at> physics.muni.cz> writes:
> This behviour is fine with me, just there should be an int_error("nothing to
> plot") if there was only a single (empty) file to plot. Please update your
> patch, add taking care of 3d plots.

In that case, you get this:
         warning: no valid data points found in specified file
         all points y value undefined!
Clear enough, isn't it?

> What should happen here:
>  plot x*x, 'empty.dat'

You get this:
         warning: no valid data points found in specified file
         x range is invalid
So you have to use, for example:
plot [-1:1] x*x, 'empty.dat'

The titles x*x and 'empty.dat' are shown, but only x*x is plotted. Not bad.

----------------------------------------------------------------------------
Ethan Merritt <merritt <at> u.washington.edu> writes:
> It's more complicated that that.  The first thing that will happen
> if you just change int_error into int_warn is likely to be a 
> divide-by-zero error as the autoscaling fails.

That doesn't happen. If an empy datafile is plotted alone, you get:
         warning: no valid data points found in specified file 
         all points y value undefined!

> Beyond that, there
> is the question of consistent behaviour of the plot.
> For instance, "skipping" a plot  should not change the color
> assignments of the remaining plots.

There is no change of color.
There is no "skipping" (the title of an empty plot is still there).

----------------------------------------------------------------------------
Hans-Bernhard Broeker <broeker <at> physik.rwth-aachen.de> writes:
> But the plot command, as given, still is wrong.  An entire dataset is 
> missing --- there'll consequently be all kinds of strange behaviour on the 
> plot, which are pretty much guaranteed to make the resulting diagram at 
> least hard to interpret, possibly unusable.

Only the points are missing. The title of each empty dataset is still there. So
the plot command is _not_ wrong.

> If so, then it's a grave bug in the generator that it didn't notice it
> just created a datafile without any data in it.

The bug is not in the generator but in gnuplot. An empty datafile is not wrong.

> That would cause a new problem: gnuplot would now try to generate a plot, 
> even if *none* of the files in the plot contain any data.

No plot is generated in that case. You just get this message:
         all points y value undefined!

And in fact, that behavior doesn't suit me: I would like gnuplot to generate a
plot with no point in it, but with a title and labels (the x and y ranges must
be set in that case of course). I use gnuplot to plot real time data, and I draw
only the data of the last minutes. If in that time there is no data at all, I
want to see the plot all the same (and I certainly don't want gnuplot to stop).

---------------------------------------------------------------------------
SUMMARY: I can't see any drawback in my small patch. But it is no enough. It
should be possible to plot an empty datafile (everything but the points).

Re: Bug or pipe issue?

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

> > > >I suppose that in principle the input stream during a
> > > >plot '-' command could be copied to a temp file so that
> > > >it was available for re-reading.  That might be a useful
> > > >thing for more reasons than just mouse zooming.
> > >
> > > For doing a replot without having to re-enter the data, perhaps? :-)
> >
> > It would be useful. With some associated 'set ...' to switch this caching
> > on/off.
>
> Of course, the data is already present in gnuplot's internal
> arrays.
>
> In principle a "zoom" operation wouldn't need to reread the files.
> So it might be possible to implement zoom as a partial replot
> that skips the step of re-reading the data and maybe other
> steps in the full plot/replot pathway.

It works this way with "splot" and rotations by mouse.
For zoom to work the same way, it would need some loop over data to change
validity of points for new ranges.

---
PM

Re: empty data-files

[Hans-Bernhard B. <br...@ph...>]

On Sat, 8 Jan 2005, Jacques Bouchard wrote:

> But if you try to plot 2 data-files, one empty the other not, you get 
> the same answer, and that is not OK. There _is_ something to plot. 

But the plot command, as given, still is wrong.  An entire dataset is 
missing --- there'll consequently be all kinds of strange behaviour on the 
plot, which are pretty much guaranteed to make the resulting diagram at 
least hard to interpret, possibly unusable.


> That situation may arise if the data-files and the gnuplot script are
> generated automatically.

If so, then it's a grave bug in the generator that it didn't notice it
just created a datafile without any data in it.

> So I think that in plot2d.c:
> 
> int_error(c_token, "no valid data points found in specified file");
> 
> should be replaced with:
> 
> int_warn(c_token, "no valid data points found in specified file");

That would cause a new problem: gnuplot would now try to generate a plot, 
even if *none* of the files in the plot contain any data.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: gd.trm and multiple plots with png

[Hans-Bernhard B. <Han...@ph...>]

Jim Kleckner wrote:

> Would it make any sense to hack gd.trm to
> add an option to detect when a new plot is
> created and if output is to a non-pipe named
> file to auto-append a number ahead of the extension
> and close/reopen the file?

If at all, such a modification would have to be independent of the 
terminal driver.  I.e. gd.trm really shouldn't have anything to do with 
this.

> Issuing "set output" commands for every plot
> can be a tedious retrofit to something that
> works with PS or PDF.

It may not even be strictly necessary --- at least not for GIF files 
generated by gd.trm.  GIF files can, at least in principle, hold 
multiple pages.  But I suspect the GD library doesn't support this 
(admittedly rarely used) feature, so gd.trm can't do anything about that.

Re: empty data-files

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

On Thursday 13 January 2005 07:53 am, Petr Mikulik wrote:
> >
> > So I think that in plot2d.c:
> >
> > int_error(c_token, "no valid data points found in specified file");
> >
> > should be replaced with:
> >
> > int_warn(c_token, "no valid data points found in specified file");
> 
> This behviour is fine with me, just there should be an int_error("nothing to
> plot") if there was only a single (empty) file to plot. Please update your
> patch, add taking care of 3d plots.

It's more complicated that that.  The first thing that will happen
if you just change int_error into int_warn is likely to be a 
divide-by-zero error as the autoscaling fails.  Beyond that, there
is the question of consistent behaviour of the plot.
For instance, "skipping" a plot  should not change the color
assignments of the remaining plots.

So I think that to do this properly you'd have to mark the
plot empty (or just use the fact that npoints == 0), but carry it
along and test for this explicitly at every stage of the plotting
process. I think that would be straightforward, but it's a lot
more work than just changing one call.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Bug or pipe issue?

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

On Thursday 13 January 2005 07:42 am, Petr Mikulik wrote:
> > >I suppose that in principle the input stream during a
> > >plot '-' command could be copied to a temp file so that
> > >it was available for re-reading.  That might be a useful
> > >thing for more reasons than just mouse zooming.
> >
> > For doing a replot without having to re-enter the data, perhaps? :-)
> 
> It would be useful. With some associated 'set ...' to switch this caching
> on/off.

Of course, the data is already present in gnuplot's internal
arrays. 

In principle a "zoom" operation wouldn't need to reread the files.
So it might be possible to implement zoom as a partial replot
that skips the step of re-reading the data and maybe other
steps in the full plot/replot pathway.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: empty data-files

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

> But if you try to plot 2 data-files, one empty the other not, you get
> the same answer, and that is not OK. There _is_ something to plot. That
> situation may arise if the data-files and the gnuplot script are
> generated automatically.
>
> So I think that in plot2d.c:
>
> int_error(c_token, "no valid data points found in specified file");
>
> should be replaced with:
>
> int_warn(c_token, "no valid data points found in specified file");

This behviour is fine with me, just there should be an int_error("nothing to
plot") if there was only a single (empty) file to plot. Please update your
patch, add taking care of 3d plots.

What should happen here:
 plot x*x, 'empty.dat'

?? Currently it reports an empty x-range.

---
PM

Re: Bug or pipe issue?

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

> >I suppose that in principle the input stream during a
> >plot '-' command could be copied to a temp file so that
> >it was available for re-reading.  That might be a useful
> >thing for more reasons than just mouse zooming.
>
> For doing a replot without having to re-enter the data, perhaps? :-)

It would be useful. With some associated 'set ...' to switch this caching
on/off.

---
PM

[Fwd: [Fwd: no mirroring to www.gnuplot.info]]

[Clark G. <ga...@di...>]

That would be me, the phantom sysadmin for gnuplot.info. :-)  Mirroring 
was turned off when Lars moved from ucc.ie, pending further information 
regarding where it should be mirrored from.  I had set up 
preprod.gnuplot.info for this, but I don't think that has been used 
after the initial snapshot.  At this time, both www.gnuplot.info and 
ftp.gnuplot.info (same server, different application) have mirroring 
turned off.

I may have missed a notice about where it should be mirrored from after 
the cessation of the ucc.ie mirror, but I don't recall seeing one.  
Sorry if I've missed notes about it's brokenness, but that is the 
status.  I'll be happy to set up the mirror to some other staging area, 
or we can use the existing preprod (currently lhecking, ddenholm, and 
myself have access to it, but I'll be happy to set up others ... hbb and 
mikulik would be obvious candidates).

Thanks to Daniel and Lars for contacting me directly to bring this to my 
attention!

--ckg

----- Forwarded message from Petr Mikulik <mi...@ph...> -----

From: Petr Mikulik <mi...@ph...>
To: gnuplot-beta <gnu...@li...>
Subject: no mirroring to www.gnuplot.info
Errors-To: gnu...@li...
Precedence: bulk
Date: Tue, 7 Dec 2004 18:37:20 +0100 (CET)

I have posted this message several times already, but no one responded. Who
is the maintainer of www.gnuplot.info???

FWD:
Mirroring of gnuplot.sf.net to www.gnuplot.info does not work -- cf. pages
from October/November to those of May.

Who is maintaining www.gnuplot.info?
Could he restart the mirroring?

---
PM




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
gnuplot-beta mailing list
gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


----- End forwarded message -----

Re: Bug or pipe issue?

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

Ethan Merritt wrote:

>On Wednesday 12 January 2005 08:24 pm, Daniel J Sebald wrote:
>  
>
>>I just noticed that not all functions on the mouse work after doing a
>>plot from inline data.  Is this a pipe issue?
>>After, zooming can't be done.
>>    
>>
>
>It's intentional.
>In order to zoom, it needs to reread the input data.
>But if the data is in-line that is not possible.
>  
>

Oh yeah, the data needs to be re-entered. Guess I knew that and just
forgot. Maybe we should add a comment to gnuplot.doc.

>I suppose that in principle the input stream during a 
>plot '-' command could be copied to a temp file so that
>it was available for re-reading.  That might be a useful
>thing for more reasons than just mouse zooming.
>  
>

For doing a replot without having to re-enter the data, perhaps? :-)

Dan

Re: Bug or pipe issue?

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

On Wednesday 12 January 2005 08:24 pm, Daniel J Sebald wrote:
> I just noticed that not all functions on the mouse work after doing a
> plot from inline data.  Is this a pipe issue?
> After, zooming can't be done.

It's intentional.
In order to zoom, it needs to reread the input data.
But if the data is in-line that is not possible.

I suppose that in principle the input stream during a 
plot '-' command could be copied to a temp file so that
it was available for re-reading.  That might be a useful
thing for more reasons than just mouse zooming.

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

Bug or pipe issue?

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

I just noticed that not all functions on the mouse work after doing a 
plot from inline data.  Is this a pipe issue?  Try

plot '-' u 0:1
1
2
3
4
e

After, zooming can't be done.  Although, the center mouse button still 
works.

Loading the data from a file rather than inline gives not problems.

Dan