gnuplot-beta

Re: save "|gpsavediff >a.gp"

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

On Mon, 20 Oct 2003, Petr Mikulik wrote:

> I wanted to let the "save" command to save to file only differences wrt
> "reset"  status of gnuplot, so I've patched save_command() + surrounding
> routines to allow write to pipe. In the attached file, there is that
> patch + my favourite script "gpsavediff".

I'm somewhat surprised it doesn't already support the "| command" syntax
already.  Given that, I'm all for integrating this patch ASAP.

> Do you do such a diff-save in a similar way?

Yes.  I salvaged a script similar to yours ages ago, from a mail to
info-gnuplot IIRC.  It's called 'reduce-gnuplot-output', it's a
csh script (of all things), and it only works for named files.

A better approach to the whole task would almost certainly be to integrate
it into gnuplot itself.  But for that to become feasible, we'ld need a
massive refactoring of the whole internal status stuff:

*) organize the set/show/save/unset/reset implementations by variable, not
   by command, i.e. the set, show, save, unset and reset (default status)
   for a given setting should all be in *one* place, not scattered over
   4 files (set.c,show.c,unset.c,misc.c).  This would make things a
   lot more OO-ish.

*) Add a new method, or a flag to the 'save-variable' method of each
   setting, so it saves only the state different from the default.

*) Add an option to 'save', or a new command 'savediffs' to call that
   new method.

This would be a ton of work, unfortunately.  I.e. I'd advise to delay this
until after the 4.0 release we all still agree should happen soon ---
right?

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

Re: save "|gpsavediff >a.gp"

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

> > I wanted to let the "save" command to save to file only differences wrt
> > "reset"  status of gnuplot, so I've patched save_command() + surrounding
> > routines to allow write to pipe. In the attached file, there is that
> > patch + my favourite script "gpsavediff".
>
> I'm somewhat surprised it doesn't already support the "| command" syntax
> already.  Given that, I'm all for integrating this patch ASAP.

I've commited the patch.

> > Do you do such a diff-save in a similar way?
>
> Yes.  I salvaged a script similar to yours ages ago, from a mail to
> info-gnuplot IIRC.  It's called 'reduce-gnuplot-output', it's a
> csh script (of all things), and it only works for named files.

I've been using that mine script for years using REXX, and just recently
rewritten it into shell. BTW, yesterday I've even managed to replace
the pipe "grep | grep -v | sed" into a single sed invocation .. how cool...


> A better approach to the whole task would almost certainly be to integrate
> it into gnuplot itself.  But for that to become feasible, we'ld need a
> massive refactoring of the whole internal status stuff:
>
> *) organize the set/show/save/unset/reset implementations by variable, not
>    by command, i.e. the set, show, save, unset and reset (default status)
>    for a given setting should all be in *one* place, not scattered over
>    4 files (set.c,show.c,unset.c,misc.c).  This would make things a
>    lot more OO-ish.

That'll be a long file then. Currently, one has to edit all the 3 files
simultaneously.

> *) Add a new method, or a flag to the 'save-variable' method of each
>    setting, so it saves only the state different from the default.

Would that mean most variables need to have this_variable_default_value =
{...}?

> *) Add an option to 'save', or a new command 'savediffs' to call that
>    new method.
>
> This would be a ton of work, unfortunately.  I.e. I'd advise to delay this
> until after the 4.0 release we all still agree should happen soon ---
> right?

Yes.

Another method of the "diff" save would be to write the output into an array
of strings, then the same for invoking internally "reset", and write out
only diff's, and finally re-read internally the status before reset. That'd
emulate the need for external "diff" command, but require many sprintf's
instead of fprintf's.

---
Petr Mikulik

Re: save "|gpsavediff >a.gp"

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

On Tue, 21 Oct 2003, Petr Mikulik wrote:

> > *) organize the set/show/save/unset/reset implementations by variable, not
> >    by command, i.e. the set, show, save, unset and reset (default status)
> >    for a given setting should all be in *one* place, not scattered over
> >    4 files (set.c,show.c,unset.c,misc.c).  This would make things a
> >    lot more OO-ish.
>
> That'll be a long file then.

No, it won't --- because it'll still be split up into several files, but
along different lines.

> Currently, one has to edit all the 3 files simultaneously.

Exactly, and that's a pain in the lower back we don't need.  The plan is
to have all code handling a given setting in *one* place.  Be that the
module that implements the effect of that setting, too (pm3d.c for 'set
pm3d', hidden3d.c for 'set hidden3d', etc.), or a special user interface
module for an existing core functionality module (e.g. a setaxis.c to go
with axis.c).

> > *) Add a new method, or a flag to the 'save-variable' method of each
> >    setting, so it saves only the state different from the default.
>
> Would that mean most variables need to have this_variable_default_value =
> {...}?

Yes.  But you need that info for the 'reset' command, anyway, so it's not
exactly a new requirement.

> Another method of the "diff" save would be to write the output into an array
> of strings, then the same for invoking internally "reset", and write out
> only diff's, and finally re-read internally the status before reset.

Overly complicated.  If at all, create an in-memory dump of all settings
immediately after start-up initialization (before reading ~/.gnuplotrc,
that is), and keep that dump around for the whole session.

The sprintf() vs. fprintf() could be relayed to a common s_or_f_printf()
utility routine to be used by all save_foo() functions --- but we'ld
then need vs[n]printf() and vfprintf() on all platforms ;-(

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

Re: save "|gpsavediff >a.gp"

[Lars H. <lhe...@us...>]

> Exactly, and that's a pain in the lower back we don't need.  The plan is
> to have all code handling a given setting in *one* place.  Be that the

 That was the idea behind variable.c, but I'm not sure whether the
 implementation could serve aas a model for the otehr variables.