gnuplot-beta

gnuplot zoom not functioning anymore in octave 2.9.10

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

Thread: www.cae.wisc.edu/pipermail/help-octave/2007-April/003542.html

>Wed Apr 4 09:33:03 CDT 2007
>| until version 2.9.9, it was possible to enable zoom with the
>| "set mouse" command (e.g. in ~/.gnuplot). After changing to
>| version 2.9.10, this does not function anymore.
>
>It still works for me with gnuplot 4.0.
>
>With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots
>does not work for me when gnuplot is called from Octave.  It does work
>when I run gnuplot directly.  I don't know what the proper fix is.  In
>any case, the changes you make with the mouse will still not be
>reflected in the axes settings seen by Octave as the communication
>with gnuplot is still a simple one way pipe.

I had a look what octave 2.9.10 is doing by:

        octave> gnuplot_binary('tee a.log | gnuplot');

and there appears:

plot "-" using ($1):($2) title "" with lines linestyle 1;
-20 -20
-19 -19
-18 -18

Therefrom, octave does no longer use temporary data files but switched
to inline data. That's a nice improvement. Unfortunately, gnuplot
ignores "replot" for plots with "-", and consequently mousing+hotkeys do
not work.

Thus, it looks like a strong demand to gnuplot developers to implement
replot for "-". This matter was discussed recently, see below...

Note: 3D plots, e.g.
        octave> mesh(hilb(9))
which produces
        splot "-" using ($1):($2):($3) title "" with line palette;
        1 1 1
        1 2 2
can be rotated by mouse, because gnuplot reuses the loaded 3D data in
this case (no reload -- fast rotation); but hotkeys relying on replot do
not work again.

Does somebody know how to implement it?

---
PM

*********

Thu, 15 Mar 2007, gnuplot-beta <gnu...@li...>

> > Furthermore, it would be possible to do a more efficient job
> > of "replot" in the core code that would benefit all terminals.
> > Perhaps I am overlooking something, but I don't see any hard
> > requirement to re-read the original data from a file on each
> > replot command.  Yes, this is sometimes exactly what you want
> > because you know the data has changed.  But more often you
> > just want to redraw the plot with a different plot option,
> > or zoom or view angle.  In these cases there should be enough,
> > or almost enough, information already stored in the data structures
> > from the previous plot.  Why re-read the data file when it is
> > just storing the same information all over again?  This would in
> > particular be of  plot '-', where it is very annoying to type in
> > the same data all over again.
>
> Mousing in 3D -- rotating by mouse -- does not reread the data, but
> uses those in the memory. It would be useful for those "-" to do the
> same.
>
> Thus there could be two replots, e.g. replot and Replot, where the
> second would not reread the data from disk.
`

gnuplot zoom not functioning anymore in octave 2.9.10

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

Thread: www.cae.wisc.edu/pipermail/help-octave/2007-April/003542.html

>Wed Apr 4 09:33:03 CDT 2007
>| until version 2.9.9, it was possible to enable zoom with the
>| "set mouse" command (e.g. in ~/.gnuplot). After changing to
>| version 2.9.10, this does not function anymore.
>
>It still works for me with gnuplot 4.0.
>
>With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots
>does not work for me when gnuplot is called from Octave.  It does work
>when I run gnuplot directly.  I don't know what the proper fix is.  In
>any case, the changes you make with the mouse will still not be
>reflected in the axes settings seen by Octave as the communication
>with gnuplot is still a simple one way pipe.

I had a look what octave 2.9.10 is doing by:

        octave> gnuplot_binary('tee a.log | gnuplot');

and there appears:

plot "-" using ($1):($2) title "" with lines linestyle 1;
-20 -20
-19 -19
-18 -18

Therefrom, octave does no longer use temporary data files but switched
to inline data. That's a nice improvement. Unfortunately, gnuplot
ignores "replot" for plots with "-", and consequently mousing+hotkeys do
not work.

Thus, it looks like a strong demand to gnuplot developers to implement
replot for "-". This matter was discussed recently, see below...

Note: 3D plots, e.g.
        octave> mesh(hilb(9))
which produces
        splot "-" using ($1):($2):($3) title "" with line palette;
        1 1 1
        1 2 2
can be rotated by mouse, because gnuplot reuses the loaded 3D data in
this case (no reload -- fast rotation); but hotkeys relying on replot do
not work again.

Does somebody know how to implement it?

---
PM

*********

Thu, 15 Mar 2007, gnuplot-beta <gnu...@li...>

> > Furthermore, it would be possible to do a more efficient job
> > of "replot" in the core code that would benefit all terminals.
> > Perhaps I am overlooking something, but I don't see any hard
> > requirement to re-read the original data from a file on each
> > replot command.  Yes, this is sometimes exactly what you want
> > because you know the data has changed.  But more often you
> > just want to redraw the plot with a different plot option,
> > or zoom or view angle.  In these cases there should be enough,
> > or almost enough, information already stored in the data structures
> > from the previous plot.  Why re-read the data file when it is
> > just storing the same information all over again?  This would in
> > particular be of  plot '-', where it is very annoying to type in
> > the same data all over again.
>
> Mousing in 3D -- rotating by mouse -- does not reread the data, but
> uses those in the memory. It would be useful for those "-" to do the
> same.
>
> Thus there could be two replots, e.g. replot and Replot, where the
> second would not reread the data from disk.

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

On Sunday 08 April 2007 13:36, Petr Mikulik wrote:

> octave does no longer use temporary data files but switched 
> to inline data. That's a nice improvement. Unfortunately, gnuplot
> ignores "replot" for plots with "-", and consequently mousing+hotkeys do
> not work.
> 
> Thus, it looks like a strong demand to gnuplot developers to implement
> replot for "-". This matter was discussed recently, see below...
>
> Does somebody know how to implement it?

I am looking into it, but would appreciate help.  See below in particular.

The first thing that is needed is to change the order of allocating/freeing
the plot structures in eval_plots().  If we are to use the previously stored
data values, they must not be freed until an entirely new plot command 
replaces them.  Right now the plot structures are freed immediately after
drawing the plot.  We must change this so that they are freed only on 
re-entry to eval_plots().   There is a comment at the head of the routine
that suggests somebody tried this and ran into problems:

    /* Reset first_plot. This is usually done at the end of this function.
     * If there is an error within this function, the memory is left allocated,
     * since we cannot call cp_free if the list is incomplete. Making sure that
     * the list structure is always valid requires some rewriting */

I have prepared and attached a patch that switches the calls to cp_free()
from late in the routine to the front (where the above comment now sits).
The comment seems to warn this will break things if there is an inconvenient
int_error() from the plot command.

==>   Everyone please apply the attached patch, then try to find and
==>   document any error cases so that we can fix them.   

Once the revised code in eval_plots() is stable again, we can experiment with
adding a short-cut path that calls eval_plots() directory without re-parsing
the command line and re-reading all the data.

	Ethan




> 
> Thu, 15 Mar 2007, gnuplot-beta <gnu...@li...>
> 
> > > Furthermore, it would be possible to do a more efficient job
> > > of "replot" in the core code that would benefit all terminals.
> > > Perhaps I am overlooking something, but I don't see any hard
> > > requirement to re-read the original data from a file on each
> > > replot command.  Yes, this is sometimes exactly what you want
> > > because you know the data has changed.  But more often you
> > > just want to redraw the plot with a different plot option,
> > > or zoom or view angle.  In these cases there should be enough,
> > > or almost enough, information already stored in the data structures
> > > from the previous plot.  Why re-read the data file when it is
> > > just storing the same information all over again?  This would in
> > > particular be of  plot '-', where it is very annoying to type in
> > > the same data all over again.
> >
> > Mousing in 3D -- rotating by mouse -- does not reread the data, but
> > uses those in the memory. It would be useful for those "-" to do the
> > same.
> >
> > Thus there could be two replots, e.g. replot and Replot, where the
> > second would not reread the data from disk.
> 

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

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[<HBB...@t-...>]

Daniel J Sebald wrote:

> Will need to consider the behavior.  I think "replot" reloading regular files, 
> e.g., 'foo.dat' is sort of convenient.  

Sometimes it is.  At other times, for other usages, it may not be.  For 
mousing, e.g., it typically isn't.  For mousing in 3D, this was changed 
already, for just this reason.

Based on what kind of oracle are to decide that the "replot" issued for 
a plot with inline data isn't *meant* to require re-entry of all the 
data?  Or re-entry of only some of them, even?

Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
I'm afraid I have to insist that a command doing a different job than 
"replot" used to do, be given a different name than "replot".

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

Ethan A Merritt wrote:
> On Sunday 08 April 2007 13:36, Petr Mikulik wrote:
> 
> 
>>octave does no longer use temporary data files but switched 
>>to inline data. That's a nice improvement. Unfortunately, gnuplot
>>ignores "replot" for plots with "-", and consequently mousing+hotkeys do
>>not work.
>>
>>Thus, it looks like a strong demand to gnuplot developers to implement
>>replot for "-". This matter was discussed recently, see below...
>>
>>Does somebody know how to implement it?
> 
> 
> I am looking into it, but would appreciate help.  See below in particular.
> 

Will need to consider the behavior.  I think "replot" reloading regular files, 
e.g., 'foo.dat' is sort of convenient.  That is, a person runs some outside app 
to create a new set of data and then simply types "replot".  So, should it be 
automatic reload for disk files and no automatic reload for input streams?  If 
so, will need to have a variable indicating replot vs plot and a variable 
indicating '-' vs. 'foo.dat'.  Or should there be some new option setting for 
gnuplot "automatic reload off/on"?


> The first thing that is needed is to change the order of allocating/freeing
> the plot structures in eval_plots().  If we are to use the previously stored
> data values, they must not be freed until an entirely new plot command 
> replaces them.  Right now the plot structures are freed immediately after
> drawing the plot.  We must change this so that they are freed only on 
> re-entry to eval_plots().   There is a comment at the head of the routine
> that suggests somebody tried this and ran into problems:
> 
>     /* Reset first_plot. This is usually done at the end of this function.
>      * If there is an error within this function, the memory is left allocated,
>      * since we cannot call cp_free if the list is incomplete. Making sure that
>      * the list structure is always valid requires some rewriting */
> 
> I have prepared and attached a patch that switches the calls to cp_free()
> from late in the routine to the front (where the above comment now sits).
> The comment seems to warn this will break things if there is an inconvenient
> int_error() from the plot command.

Well, the patch could probably be moved into CVS right away as it seems like a 
memory leak and what you've done is a fairly safe way of programming.  (BTW, 
where is first_plot assigned?  I don't see that immediately.)  It's safe right 
now because there is no conditional and memory is always freed at that point if 
some was assigned.

But the issue with regard to replotting and retaining the plot structure with 
data (which isn't to be reloaded) is just what the above message says.  If there 
is a failure along the way, the plot pointer is valid, but the information in 
the structure may not be valid.

Eventually there will be a conditional along the way like "if replot don't free 
memory, but if plot then free memory".  So, I would suggest a couple pointers 
here, one a "temporary" pointer (first_plot_temp) but still static, and one a 
static global pointer (first_plot).  Something like (haven't though this through 
and I'm not really what exactly "first_plot" means, but it should get the 
concept across):

   if (first_plot && auto_reload) {
     cp_free(first_plot);
     first_plot = NULL;
   }

   if (!first_plot)

     if (first_plot_temp) {
       cp_free(first_plot_temp);
       first_plot_temp = NULL;
     }

     [snip, get_data()?]

     first_plot = first_plot_temp;
     first_plot_temp = NULL;
   }

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

On Sunday 08 April 2007 19:46, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > 
> > I have prepared and attached a patch that switches the calls to cp_free()
> > from late in the routine to the front (where the above comment now sits).
> > The comment seems to warn this will break things if there is an inconvenient
> > int_error() from the plot command.
> 
> Well, the patch could probably be moved into CVS right away as it seems like a 
> memory leak and what you've done is a fairly safe way of programming.
> It's safe right now because there is no conditional and memory is always freed
> at that point if some was assigned.

I think you are missing the worrisome point.  The routine cp_free() works
its way through a linked list of plots, freeing all dynamically allocated
space as it goes.  The comment warns that this may fail if there was a call
to int_error() while one of those dynamically allocated plot structures 
was in the process of being filled in.  That would hypothetically leave
invalid links in the linked list, or struct entries that are supposedly
pointers but contain random garbage.   This really shouldn't happen if 
everything is initialized in the correct order, but the comment suggests
that may not be the case. 
 
> But the issue with regard to replotting and retaining the plot structure with 
> data (which isn't to be reloaded) is just what the above message says.  If there 
> is a failure along the way, the plot pointer is valid, but the information in 
> the structure may not be valid.

Exactly.  But we should try to insure that cannot happen.

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

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

Ethan A Merritt wrote:

> I think you are missing the worrisome point.  The routine cp_free() works
> its way through a linked list of plots, freeing all dynamically allocated
> space as it goes.  The comment warns that this may fail if there was a call
> to int_error() while one of those dynamically allocated plot structures 
> was in the process of being filled in.  That would hypothetically leave
> invalid links in the linked list, or struct entries that are supposedly
> pointers but contain random garbage.   This really shouldn't happen if 
> everything is initialized in the correct order, but the comment suggests
> that may not be the case. 

Oh, that explains what "first_plot" means.  Also, the "first_plot" is a global. 
  Inside set.c is some strange code.  It doesn't appear to be a bug but I don't 
understand why the f_p and f_3dp had to be used.  Is there a chance cp_free() 
and sp_free() might fail?  If so, the routines shouldn't do that:

     else {
	struct curve_points *f_p = first_plot;
	struct surface_points *f_3dp = first_3dplot;

	first_plot = NULL;
	first_3dplot = NULL;
	cp_free(f_p);
	sp_free(f_3dp);

	iso_samples_1 = tsamp1;
	iso_samples_2 = tsamp2;
     }

Anyway, what I sent last time still applies but at a narrower scope.  For example:

                 if (*tp_ptr)
                     this_plot = *tp_ptr;
                 else {          /* no memory malloc()'d there yet */
                     this_plot = cp_alloc(MIN_CRV_POINTS);
                     *tp_ptr = this_plot;
                 }

"this_plot" shouldn't be moved into the list until after a success.  I.e., move 
the line *tp_ptr = this_plot to the end of the routine.  E.g. (?)

		if (this_plot)
		  cp_free(this_plot);

                 if (*tp_ptr)
                     this_plot = *tp_ptr;
                     *tp_ptr = NULL;
                 else {          /* no memory malloc()'d there yet */
                     this_plot = cp_alloc(MIN_CRV_POINTS);
                 }

		[snip]

                 *tp_ptr = this_plot;


This is a bit messy.  (Little linked-list maintenance routines are always good.) 
  But see what you can do.

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

Daniel J Sebald wrote:

>                  if (*tp_ptr)
>                      this_plot = *tp_ptr;
>                      *tp_ptr = NULL;
>                  else {          /* no memory malloc()'d there yet */

Ah, but can't just set *tp_ptr to NULL because it is in the list and taking it 
out of the list messes up the list.  (Hence linked-list management routines to 
make things a bit simpler.)

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

> >>Thus, it looks like a strong demand to gnuplot developers to implement
> >>replot for "-".
> > 
> > I am looking into it, but would appreciate help.  See below in particular.
> 
> Will need to consider the behavior.  I think "replot" reloading regular files, 
> e.g., 'foo.dat' is sort of convenient.  That is, a person runs some outside app 
> to create a new set of data and then simply types "replot".  So, should it be 
> automatic reload for disk files and no automatic reload for input streams?  If 
> so, will need to have a variable indicating replot vs plot and a variable 
> indicating '-' vs. 'foo.dat'.  Or should there be some new option setting for 
> gnuplot "automatic reload off/on"?

I would like command "Replot" to replot without reloading. This command 
would be used in the hotkey and mouse management.

There could also be "set replot {no}replot" to have command replot and 
Replot (not) equivalent.


---
PM

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>> Will need to consider the behavior.  I think "replot" reloading 
>> regular files, e.g., 'foo.dat' is sort of convenient.  
> 
> 
> Sometimes it is.  At other times, for other usages, it may not be.  For 
> mousing, e.g., it typically isn't.  For mousing in 3D, this was changed 
> already, for just this reason.
> 
> Based on what kind of oracle are to decide that the "replot" issued for 
> a plot with inline data isn't *meant* to require re-entry of all the 
> data?  Or re-entry of only some of them, even?
> 
> Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
> I'm afraid I have to insist that a command doing a different job than 
> "replot" used to do, be given a different name than "replot".

A new option "autoreload" won't fly?  E.g.,

   set autoreload off

and the default is on, i.e., the current behavior?

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

> > Based on what kind of oracle are to decide that the "replot" issued for 
> > a plot with inline data isn't *meant* to require re-entry of all the 
> > data?  Or re-entry of only some of them, even?
> > 
> > Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
> > I'm afraid I have to insist that a command doing a different job than 
> > "replot" used to do, be given a different name than "replot".

That I have proposed several times: "Replot". (Or: "redraw")

> A new option "autoreload" won't fly?  E.g.,
> 
>    set autoreload off
> 
> and the default is on, i.e., the current behavior?

set replot {reload|redraw}
or
set replot {reload|redraw} {both|pipe}

---
PM

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

Petr Mikulik wrote:
>>>Based on what kind of oracle are to decide that the "replot" issued for 
>>>a plot with inline data isn't *meant* to require re-entry of all the 
>>>data?  Or re-entry of only some of them, even?
>>>
>>>Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
>>>I'm afraid I have to insist that a command doing a different job than 
>>>"replot" used to do, be given a different name than "replot".
> 
> 
> That I have proposed several times: "Replot". (Or: "redraw")

Oh, I sort of passed the capital R in the back of my mind as a typing mistake, 
but yes gnuplot is case sensitive.  But I don't think it is a good idea to 
introduce capital letter commands as there are currently none and it just isn't 
very elegant.  (I just imagine one colleague saying to another "just type 
replot; with a capital R".)  "redraw" would work better as a whole new command.


>>A new option "autoreload" won't fly?  E.g.,
>>
>>   set autoreload off
>>
>>and the default is on, i.e., the current behavior?
> 
> 
> set replot {reload|redraw}
> or
> set replot {reload|redraw} {both|pipe}

Yes, something like that.  That's good.  But {file|pipe|all} to cover all bases. 
  (Avoid using a word like "both" because it implies two.  Who knows what the 
future might bring?)

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

It's not clear to me that we need to make this new functionality
visible from the command line at all.  The mouse zooming can call
a new internal routine with no corresponding user command.
Let's get it working first, and only then worry about whether
it is worth adding a new user command.




On Tuesday 10 April 2007 11:33, Daniel J Sebald wrote:
> Petr Mikulik wrote:
> >>>Based on what kind of oracle are to decide that the "replot" issued for 
> >>>a plot with inline data isn't *meant* to require re-entry of all the 
> >>>data?  Or re-entry of only some of them, even?
> >>>
> >>>Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
> >>>I'm afraid I have to insist that a command doing a different job than 
> >>>"replot" used to do, be given a different name than "replot".
> > 
> > 
> > That I have proposed several times: "Replot". (Or: "redraw")
> 
> Oh, I sort of passed the capital R in the back of my mind as a typing mistake, 
> but yes gnuplot is case sensitive.  But I don't think it is a good idea to 
> introduce capital letter commands as there are currently none and it just isn't 
> very elegant.  (I just imagine one colleague saying to another "just type 
> replot; with a capital R".)  "redraw" would work better as a whole new command.
> 
> 
> >>A new option "autoreload" won't fly?  E.g.,
> >>
> >>   set autoreload off
> >>
> >>and the default is on, i.e., the current behavior?
> > 
> > 
> > set replot {reload|redraw}
> > or
> > set replot {reload|redraw} {both|pipe}
> 
> Yes, something like that.  That's good.  But {file|pipe|all} to cover all bases. 
>   (Avoid using a word like "both" because it implies two.  Who knows what the 
> future might bring?)
> 
> Dan
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

I'm fine with the new command "redraw".

> It's not clear to me that we need to make this new functionality
> visible from the command line at all.  The mouse zooming can call
> a new internal routine with no corresponding user command.
> Let's get it working first, and only then worry about whether
> it is worth adding a new user command.

Yes, it is important to have it exposed to the user interface.

Octave is getting M* compatibility, where the "set"-like commands are 
written after(!) the plot command, and thus it usually needs several (fast) 
redraws with the original data.

It would be great if gnuplot can provide this.

---
PM

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[<HBB...@t-...>]

Petr Mikulik wrote:

> Octave is getting M* compatibility, where the "set"-like commands are 
> written after(!) the plot command, and thus it usually needs several (fast) 
> redraws with the original data.

I don't think that conclusion is strictly true.  The octave side of 
things could observe the command stream and hold back on the 'plot' 
command until after the stream of 'set' commands is at its end.

Re: gnuplot zoom not functioning anymore in octave 2.9.10

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

> > Octave is getting M* compatibility, where the "set"-like commands are
> > written after(!) the plot command, and thus it usually needs several (fast)
> > redraws with the original data.
> 
> I don't think that conclusion is strictly true.  The octave side of things
> could observe the command stream and hold back on the 'plot' command until
> after the stream of 'set' commands is at its end.

It does not work as you think. Plot appears after each plot command, and is 
redrawn after each "set" command which changes properties of that plot.
See
	help automatic_replot
for more details. (It should be set to 1 for M* compatibility.)

---
PM