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

Re: Should gnuplot become a programming environment?

[<pl...@pi...>]

On 10/30/14 15:41, Philipp K. Janert wrote:
>
>
> [snip]
>
>> That said, being able to add functions opens up huge possibilities
>> that avoids needing to pre-process data for trivial things like diff
>> and integration and other simple needs. Bulk data processing is still
>> better done outside of the plotting utility in tested code suites in
>> compiled code but this remains an incredibly useful feature.
>
> With huge possibilities come huge complexities.
> If not today, then eventually.
>
> Do we want them in gnuplot? Or should we keep
> scripting with scripting languages and plotting
> with gnuplot?
>
> Do we want differentiation and integration -
> in a PLOTTING program??? My answer is: hell, no!

I don't think such hard-line attitudes are helpful.

If I want to subtract the previous plot point from the current one to 
plot the first difference ( numerical approximation to the differential) 
I do not want to have to set up and external script for such a trivial 
task and then try to synchronise  the archiving of whatever external 
scripts I have with the gnuplot script I'm using to plot it.

Same with integration, it's a trivial case of successive addition of 
current point. It would be more effort to write a one-liner awk script 
to do this and then call the scritp before plotting from gnuplot, than 
to have a trivial gnuplot fn, and that would also mean duplication of 
the data file which may itself be substantial, ie an awful waste of 
effort all round.

If I want to do an FFT I would not try to do it in gnuplot script !!!!

Peter.



>
> Keep the numerical routines in Python or Octave
> or wherever. Let's keep the plotting stuff in
> gnuplot.
>
>>
>> I don't think there is a need to view this as 'taking on" other
>> languages or "loosing" to them. If I had a scripting task to do I
>
> I am not arguing from a developer's point of view,
> but from a user's one.
>
> Gnuplot's advantage over R or matlab was it's simplicity:
> just plot a file - all there is to it. Once this simplicity
> is gone, what is gnuplot's advantage (or niche)?
>
>> would use an existing tool not a plotting program, but if I need
>> manipulate or tweak  some data I'm plotting, having that ability
>> built-in is has a lot of merit. Documentation and archiving being a
>> key argument: all is in one file.
>
> [snip]
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: [offlist] Re: Newton's method in gnuplot...

[Philipp K. J. <ja...@ie...>]

Apologies for the spam - this was supposed to go
to Christoph only.

It IS clever, though! ;-)

> 
> > Zitat von "Philipp K. Janert" <ja...@ie...>:
> > > f(x) = cos(x)
> > > steps=0; x=0.5; eps=1e-6
> > >
> > > while( abs(f(x)) > 1e-10 ) {
> > > x = x - eps*f(x)/( f(x+eps) - f(x) )
> > > steps = steps + 1
> > > }
> > >
> > > print steps, x
> > 
> > g(x) = cos(x)
> > h(x) = (abs(g(x)) < 1e-10) ? x : h(x - eps*g(x)/(g(x + eps) - g(x)))
> > x=0.5; eps=1e-6
> > print h(x)
> 
> Clever, that! I didn't think of this.
> 

[offlist] Re: Newton's method in gnuplot...

[Philipp K. J. <ja...@ie...>]

On Thu, 30 Oct 2014 09:44:48 +0100
Christoph Bersch <us...@be...> wrote:

> Zitat von "Philipp K. Janert" <ja...@ie...>:
> > f(x) = cos(x)
> > steps=0; x=0.5; eps=1e-6
> >
> > while( abs(f(x)) > 1e-10 ) {
> > x = x - eps*f(x)/( f(x+eps) - f(x) )
> > steps = steps + 1
> > }
> >
> > print steps, x
> 
> g(x) = cos(x)
> h(x) = (abs(g(x)) < 1e-10) ? x : h(x - eps*g(x)/(g(x + eps) - g(x)))
> x=0.5; eps=1e-6
> print h(x)

Clever, that! I didn't think of this.

Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

[snip]

> That said, being able to add functions opens up huge possibilities
> that avoids needing to pre-process data for trivial things like diff
> and integration and other simple needs. Bulk data processing is still
> better done outside of the plotting utility in tested code suites in
> compiled code but this remains an incredibly useful feature.

With huge possibilities come huge complexities.
If not today, then eventually.

Do we want them in gnuplot? Or should we keep
scripting with scripting languages and plotting
with gnuplot?

Do we want differentiation and integration -
in a PLOTTING program??? My answer is: hell, no!

Keep the numerical routines in Python or Octave
or wherever. Let's keep the plotting stuff in
gnuplot.

> 
> I don't think there is a need to view this as 'taking on" other 
> languages or "loosing" to them. If I had a scripting task to do I

I am not arguing from a developer's point of view, 
but from a user's one.

Gnuplot's advantage over R or matlab was it's simplicity:
just plot a file - all there is to it. Once this simplicity
is gone, what is gnuplot's advantage (or niche)? 

> would use an existing tool not a plotting program, but if I need
> manipulate or tweak  some data I'm plotting, having that ability
> built-in is has a lot of merit. Documentation and archiving being a
> key argument: all is in one file.

[snip]

Re: Should gnuplot become a programming environment?

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

> And once we will have that array data
> structure, it's only a matter of time
> before someone implements an FFT in
> gnuplot.

I think you can achieve it this way:

plot "<octave --silent --eval \"a=load('a.dat'); disp(imag(fft(a)));\"" with image

I like all new features, including macros and strings.

Anyway, a nice discussion, which hilights achievements done recently.

But nobody wants to replace Octave or Python, as gnuplot is/can be used by 
them.

---
PM

Re: Newton's method in gnuplot...

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

>> f(x) = cos(x)
>> steps=0; x=0.5; eps=1e-6
>>
>> while( abs(f(x)) > 1e-10 ) {
>> x = x - eps*f(x)/( f(x+eps) - f(x) )
>> steps = steps + 1
>> }
>>
>> print steps, x
>
> g(x) = cos(x)
> h(x) = (abs(g(x)) < 1e-10) ? x : h(x - eps*g(x)/(g(x + eps) - g(x)))
> x=0.5; eps=1e-6
> print h(x)
>
> Should we now remove recursion?

newton.gp:
f(x) = cos(x)
steps=0; x=0.5; eps=1e-6
call "newton_inside.gp"
print steps, x

newton_inside.gp:
x = x - eps*f(x)/( f(x+eps) - f(x) )
steps = steps + 1
if (abs(f(x)) < 1e-10 ) exit
call "newton_inside.gp"

Should we remove if and call? :-)

I really like the current loops. They help with easy tasks a lot.

> files = system('ls *.dat')
> plot for [f in files] f
>
> That makes your script much more flexible, e.g. when dealing with a lot of
> similar measurement sets which then basically requires only a single script
> for plotting.

Gnuplot is mainly for plotting, and "for" helps a lot!

---
Petr

Re: Should gnuplot become a programming environment?

[<pl...@pi...>]

On 10/30/14 07:29, sfeam wrote:
> Yes, loops are new.
>
> The only thing new about conditionals is that the
>
> introduction of bracketed clauses means that you
>
> no longer have to stuff the entire content on a
>
> single input line.
>
> IHMO both of these are significant improvements
>
> in usability.
>

They are indeed significant improvements, many thanks for adding these 
features.

Being able to structure blocks of code properly and iterate are some of 
the most useful things since you implemented my suggestion of being able 
to assign a variable, which you remarkably did in under 24h.  Amazing 
responsiveness in gnuplot devel.

There is some sense in idea of taking a step back to look at overall 
design of these kind of scripting language features. Making it top down 
instead of growing piecemeal.

I find the loop commands useful but the rather unusual and specific 
syntax may be inconvenient at some point in the future. Also the odd 
need to use commas in place of the usual semicolon in defining functions 
seems inconsistent and could be limiting as things move forwards.

That said, being able to add functions opens up huge possibilities that 
avoids needing to pre-process data for trivial things like diff and 
integration and other simple needs. Bulk data processing is still better 
done outside of the plotting utility in tested code suites in compiled 
code but this remains an incredibly useful feature.

I don't think there is a need to view this as 'taking on" other 
languages or "loosing" to them. If I had a scripting task to do I would 
use an existing tool not a plotting program, but if I need manipulate or 
tweak  some data I'm plotting, having that ability built-in is has a lot 
of merit. Documentation and archiving being a key argument: all is in 
one file.

A number of times, I've found the lack of indexed arrays rather 
frustrating and I keep trying to use x+=1 type syntax before remembering 
it is not defined.

my2c, Peter.

Re: Newton's method in gnuplot...

[Christoph B. <us...@be...>]

Zitat von "Philipp K. Janert" <ja...@ie...>:
> f(x) = cos(x)
> steps=0; x=0.5; eps=1e-6
>
> while( abs(f(x)) > 1e-10 ) {
> x = x - eps*f(x)/( f(x+eps) - f(x) )
> steps = steps + 1
> }
>
> print steps, x

g(x) = cos(x)
h(x) = (abs(g(x)) < 1e-10) ? x : h(x - eps*g(x)/(g(x + eps) - g(x)))
x=0.5; eps=1e-6
print h(x)

Should we now remove recursion?

Don't get me wrong, I really appreciate, that you raised this discussion.

Only, in my opinion you cannot completely sort out "programming features".
Yes, the loops allow you to do some kind of programming, but it also allows
you to greatly improve your gnuplot scripts when working e.g. with many data
files:

files = system('ls *.dat')
plot for [f in files] f

That makes your script much more flexible, e.g. when dealing with a lot of
similar measurement sets which then basically requires only a single script
for plotting.

Christoph

Self-contained command files (aka: heredocs)

[Philipp K. J. <ja...@ie...>]

I get the sense that some of you are wondering why
I am making such a fuss about the whole heredoc
issue. 

Since Halloween is around the corner, I thought
I'll make my point as a little horror story. 

Tongue-in-cheek, please! 

Here we go...


"All: I just implemented heredocs. Now we can bundle data and 
commands into self-contained command files. That should help 
so much managing the demo/ folder."

"I love it - it really cuts down on clutter in my directories."

"Dick - here is the data set we talked about. I know that you 
are a gnuplot user also, so I am not sending you the data as a 
text file, but as a self-contained gnuplot command file. Just 
load it into gnuplot and off you go! It is very convenient."

"John - here is the data set I got from Jim. He sent it as a
self-contained gnuplot command file. I know that you are not
a gnuplot user, but I am sure you can figure out a way to 
extract the data regardless. You got a PhD and everything."

"Help, my name is John. Somebody sent me some data as a 
self-contained gnuplot command file. What the hell am I
supposed to do with that?"

"Hello, John, and welcome to the gnuplot-data mailing list. 
Good news - we just implemented this new terminal "raw-data".
All you need to do is start gnuplot, load the self-contained 
command file that you got with "load", then set the output 
device using "set output filename" (where filename is the 
name of the file that you would like to export the data to), 
then set the terminal to "raw-data", then run "replot" and 
you are good.

"Oh, I see, that's really easy. By the way: why does gnuplot
have this odd notion of "data files"? Isn't that redundant
with the data section in the self-contained command files?"

"Yes, John, you are right. In fact, plain data files are a
deprecated feature in gnuplot 6; starting with gnuplot 6.2
we plan to only support self-contained command files. By that
time, we should also have finished our very simple and
convenient toolkit to manage self-contained command files."

"I have begun work on gptk (gnuplot toolkit) to handle our
convenient self-contained command files but it needs more 
work. I imagine something as simple and intuitive as tar 
(tape archiver)."

"I am almost done with gptk-cut (to extract the command part)
and gptk-extract (to cut out the data part), I also have made
good progress on gptk-paste, to add a data part to an existing
command part, but I am still working on gptk-list, which shows
an inventory of all data sets contained in a file."

"Well, the release date for gnuplot 6.2 has slipped again, 
mostly because I am not done with gptk-cut-binary to extract
the command part from self-contained command files that contain
a data section in binary format. It works for binary data sets
in PNG, but it does not yet work for the arbitrary binary file
formats that have been part of gnuplot since version 3.7 or
so and that we all agreed to allow inside of self-contained
command files when we prepared gnuplot 5.9."

"All - I just discoverd this new feature in the release candidate 
for gnuplot 7. I takes a plain text file (whitespace-separated
columns) and plots it. Of course it is not as powerful as
the self-contained command files that we all know and love,
but I find it amazing that I can now simply write data into
a file and plot it. I didn't know gnuplot could do that."

Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

On Wed, 29 Oct 2014 23:29:45 -0700
sfeam <sf...@us...> wrote:

> On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> > 
> > (This started as a discussion on heredocs, but
> > is really about a bigger-picture-issue. So, I'll
> > try to restart this thread again.)
> > 
> > Recently, gnuplot has begun to acquire features
> > that are typical of a programming language:
> > 
> > - loops and conditionals
> 
>   Yes, loops are new.
> 
>   The only thing new about conditionals is that the
>   introduction of bracketed clauses means that you
>   no longer have to stuff the entire content on a
>   single input line.
> 
>   IHMO both of these are significant improvements
>   in usability.
> 
> > - structured data types
> 
>   There are no structured data types in gnuplot that I can think of
>   other than complex numbers {R, I}, and they were in gnuplot from
>   Day One.

Heredocs are a structured data type - they
are not scalars!

An iterable data type will surely follow:
otherwise the loop construct is living in
a vacuum.

> 
> > - statefulness and persistence.

Heredocs, again. You now maintain state (=data)
in the session. 

And as my (naive!) questioning shows, people
will want to persist that state (now that it
is there).

> 
>   You said this before but I do not understand what you are
>   referring to.  Could you give an example?
> 
> You don't mention the one programming-language feature added a
> while back that I do regret:  macros.

I have no problem with macros. They may be a
bad idea (I am not even sure they are), but
they are harmless - because the don't beget
more and more features.

Did you see my implementation of Newton's
method in gnuplot? Which I can do, given 
that I now have a proper looping construct?

But it relies on global variables, doesn't
it? Wouldn't it make sense to introduce 
variables that are local to the body of a
loop, a conditional (both now have bodies!)
or a function? By the way - shouldn't we
have multi-line functions?

And once we will have that array data
structure, it's only a matter of time
before someone implements an FFT in 
gnuplot.

> Since you raise the issue of backing out bad ideas, 
> could we start by deprecating macros?  

I am less concerned about killing off bad
ideas that are going to whither and die by 
themselves. I am concerned about features
that have heavy long-term effects. Again,
I come back to loops: once you have loops,
it is natural to have an iterable data 
type. Once you have loops AND an iterable
data type, you basically have a complete
programming environment, so now it makes
sense to ask for things like local scope.

Each idea by itself is useful and even
harmless - but I suggest that we also
take their long-term costs into account.

Best,

		Ph.
 

Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

On Wed, 29 Oct 2014 23:29:45 -0700
sfeam <sf...@us...> wrote:

> On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> > 
> > (This started as a discussion on heredocs, but
> > is really about a bigger-picture-issue. So, I'll
> > try to restart this thread again.)
> > 

[snip]

> > 
> > One more thing: scientists are not language
> > designers, and therefore tend to underestimate
> > the difficulties in designing a consistent
> > and maintainable language.
> 
> I'm not sure history bears you out there.

I am sorry - I really, REALLY, REALLY do not want 
to start a language war!

> 
> Some of the most successful computer languages,
> starting with Fortran, were designed by scientists.

My horror stories are scientific languages that 
were never designed, but that grew. The two 
biggest contenders are matlab and R. 

From a language point of view, everything about
them is wrong.

Re: Should gnuplot become a programming environment?

[sfeam <sf...@us...>]

On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> 
> (This started as a discussion on heredocs, but
> is really about a bigger-picture-issue. So, I'll
> try to restart this thread again.)
> 
> Recently, gnuplot has begun to acquire features
> that are typical of a programming language:
> 
> - loops and conditionals

  Yes, loops are new.

  The only thing new about conditionals is that the
  introduction of bracketed clauses means that you
  no longer have to stuff the entire content on a
  single input line.

  IHMO both of these are significant improvements
  in usability.

> - structured data types

  There are no structured data types in gnuplot that I can think of
  other than complex numbers {R, I}, and they were in gnuplot from
  Day One.

> - statefulness and persistence.

  You said this before but I do not understand what you are
  referring to.  Could you give an example?

You don't mention the one programming-language feature added a
while back that I do regret:  macros.

Macros were one of my failed attempts to implement string variables,
one that I wish had been removed when real string variables were
added later.  The poor design is even more evident now that we
have loops, since it confuses people that the macros are only
evaluated outside the loop, even if the associated string variable
is changed inside the loop.  

Since you raise the issue of backing out bad ideas, 
could we start by deprecating macros?  

	Ethan

> 
> I don't think this is a good trend, and I'd like
> to raise awareness for what's happening.
> 
> Gnuplot used to be a simple plotting tool - that
> was its weakness, but also its strength.
> 
> Now, gnuplot has begun to become a programming
> environment. This will make gnuplot more 
> complicated: more complicated to learn, but
> eventually also more complicated to develop for. 
> 
> I doubt that the benefits of turning gnuplot
> into a programming environment outweigh the
> costs. I also think that this will lead gnuplot 
> into a competition with more established
> "scientific workbenches" (R, NumPy/SciPy,
> Octave) that it will lose. 
> 
> I think gnuplot would be better off to stay
> a plotting tool, and not try to become a
> programming environment. I suggest that we 
> should evaluate each such feature very 
> carefully before accepting it into gnuplot -
> and be ready to reject certain ideas (and/or
> look for alternatives that do not require
> changes to the gnuplot main program).
> 
> I am concerned about "creeping featurism",
> where each new "simple/useful" feature drags 
> in bigger and bigger features. (Example: gnuplot 
> now has loops. It is only natural that it should
> have an iterable data structure. Once it has
> that, it will be natural to ask for vector
> operations and indexing magic - and for 
> matrix computations. At that point there will
> be demand for local variables and proper blocks,
> which will lead to subroutines. And so on.)
> 
> I don't think anybody INTENDS to turn gnuplot
> into a matlab competitor, but that - in fact -
> makes it worse: because there is no thought
> given to design upfront, stuff is just being
> kludged on. (The result will not be pretty.)
> 
> There are only ways to stop this:
> - to collectively say "No"
> - to collectively say "Yes", discuss the
>   direction, and then accept features if
>   they fit with the agreed upon direction.
> 
> One more thing: scientists are not language
> designers, and therefore tend to underestimate
> the difficulties in designing a consistent
> and maintainable language.

I'm not sure history bears you out there.

Some of the most successful computer languages,
starting with Fortran, were designed by scientists.

Conversely some of the most unmaintainable languages
(I'm looking at you, Python) were created by people or
committees that fancied themselves as language designers.

 EAM

> 
> In doing research for my book on
> open-source tools for data analysis, I have
> looked at a wide variety of "scientific"
> programming environments, and got the sense
> that most (if not all) of them struggle under
> their own weight: they were started, without
> much thought, design, or knowledge, by 
> scientists who "just wanted to do some 
> calculations", but who did not have much
> knowledge or experience in the theory of
> languages and data structures, who did not
> understand large-scale programming, and who -
> more than anything - underestimated what they 
> were in for. All these programming environments 
> (no names, to protect the guilty) are now big,
> overgrown, and unstructured monsters. I 
> don't want to see gnuplot go the same way.
> 
> What do others think?
> 
> Best,
> 
> 		Ph.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Should heredocs be included in "save"?

[Philipp K. J. <ja...@ie...>]

[snip]

> It seems to me you're missing entirely the business of creating 
> gnuplot files by programmatic means (whether C programs, perl or 
> python scripts or whatever). In that context you can now output a 
> gnuplot file with the data inline, so that the data and commands 
> will not come "unstuck". The generating program will simply print 
> the data into a "heredoc" field, with no "load" required.

You are absolutely right - this application never
occurred to me.

The way I saw gnuplot heredocs is that they are
a session variables (which they are!), which hold
a complex data set.

The use case that you and Ethan describe is more
akin to Perl's __DATA__ blocks (as opposed to 
heredocs): a block in a command file that does 
not contain further commands, but static data, 
that can be accessed from the commands (but, I 
would add, not outside of this command file!).

(One could even imagine extending the existing
"index" feature to such data blocks, and in this
way allow for multiple data sets to reside in one
file.)

My point is not that I don't understand the 
INTENDED use case - my point is that heredocs,
as currently designed, are not restricted in
any way to that use case. Moreover (as my
reaction proves), they suggest very different
uses for themselves, and will invariably morph
in that direction.

> 
> I find it difficult to imagine much use for "heredoc" data blocks 
> composed interactively, other than perhaps in trivial cases: would 
> you really trust yourself to type large amounts of data in that way? 
> Surely you'd compose the script in your favorite editor, then run it 
> and revise it as needed.

I couldn't either - hence my question on gnuplot-info
the other day.

Re: Should heredocs be included in "save"?

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

On Wed, 29 Oct 2014, Philipp K. Janert wrote:

> On Wed, 29 Oct 2014 15:59:21 -0700
> Ethan A Merritt <sf...@us...> wrote:
>
>> On Wednesday, 29 October, 2014 15:14:40 Philipp K. Janert wrote:
>>
>> [big snip to get to a discussion point]
>>
>>>> Placing it in a heredoc makes the script self-contained.
>
> I am splitting this thread into two.
>
> This one is to heredocs: My argument is
> that if heredocs stay, then they should
> be thought through and implemented in
> such a way as to present a consistent
> user experience.
>
> They can be loaded with "load" and in no
> other way. Hence, they should be written
> (or at least: be writeable) with "save".

It's not true that "heredoc" data can be loaded only with "load" 
(and also not true that the only, or even primary, practical use of 
heredoc data is in the gnuplot demo files).

The attraction of this feature is that one can efficiently construct 
an integrated plot file (gnuplot commands plus data) for use now and 
re-use later.

It seems to me you're missing entirely the business of creating 
gnuplot files by programmatic means (whether C programs, perl or 
python scripts or whatever). In that context you can now output a 
gnuplot file with the data inline, so that the data and commands 
will not come "unstuck". The generating program will simply print 
the data into a "heredoc" field, with no "load" required.

You could achieve a similar effect before, but less efficiently, 
since you'd have to use "plot '-'" plus e-terminated "stdin" blocks. 
This meant that if you wanted to plot n variables on the y-axis 
against a single x variable, you'd have to repeat the x data n 
times.

I find it difficult to imagine much use for "heredoc" data blocks 
composed interactively, other than perhaps in trivial cases: would 
you really trust yourself to type large amounts of data in that way? 
Surely you'd compose the script in your favorite editor, then run it 
and revise it as needed.

Allin Cottrell

Newton's method in gnuplot...

[Philipp K. J. <ja...@ie...>]

f(x) = cos(x)
steps=0; x=0.5; eps=1e-6

while( abs(f(x)) > 1e-10 ) {
x = x - eps*f(x)/( f(x+eps) - f(x) )
steps = steps + 1
}

print steps, x

Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

(This started as a discussion on heredocs, but
is really about a bigger-picture-issue. So, I'll
try to restart this thread again.)

Recently, gnuplot has begun to acquire features
that are typical of a programming language:

- loops and conditionals
- structured data types
- statefulness and persistence.

I don't think this is a good trend, and I'd like
to raise awareness for what's happening.

Gnuplot used to be a simple plotting tool - that
was its weakness, but also its strength.

Now, gnuplot has begun to become a programming
environment. This will make gnuplot more 
complicated: more complicated to learn, but
eventually also more complicated to develop for. 

I doubt that the benefits of turning gnuplot
into a programming environment outweigh the
costs. I also think that this will lead gnuplot 
into a competition with more established
"scientific workbenches" (R, NumPy/SciPy,
Octave) that it will lose. 

I think gnuplot would be better off to stay
a plotting tool, and not try to become a
programming environment. I suggest that we 
should evaluate each such feature very 
carefully before accepting it into gnuplot -
and be ready to reject certain ideas (and/or
look for alternatives that do not require
changes to the gnuplot main program).

I am concerned about "creeping featurism",
where each new "simple/useful" feature drags 
in bigger and bigger features. (Example: gnuplot 
now has loops. It is only natural that it should
have an iterable data structure. Once it has
that, it will be natural to ask for vector
operations and indexing magic - and for 
matrix computations. At that point there will
be demand for local variables and proper blocks,
which will lead to subroutines. And so on.)

I don't think anybody INTENDS to turn gnuplot
into a matlab competitor, but that - in fact -
makes it worse: because there is no thought
given to design upfront, stuff is just being
kludged on. (The result will not be pretty.)

There are only ways to stop this:
- to collectively say "No"
- to collectively say "Yes", discuss the
  direction, and then accept features if
  they fit with the agreed upon direction.

One more thing: scientists are not language
designers, and therefore tend to underestimate
the difficulties in designing a consistent
and maintainable language.

In doing research for my book on
open-source tools for data analysis, I have
looked at a wide variety of "scientific"
programming environments, and got the sense
that most (if not all) of them struggle under
their own weight: they were started, without
much thought, design, or knowledge, by 
scientists who "just wanted to do some 
calculations", but who did not have much
knowledge or experience in the theory of
languages and data structures, who did not
understand large-scale programming, and who -
more than anything - underestimated what they 
were in for. All these programming environments 
(no names, to protect the guilty) are now big,
overgrown, and unstructured monsters. I 
don't want to see gnuplot go the same way.

What do others think?

Best,

		Ph.

Re: Should heredocs be included in "save"?

[Philipp K. J. <ja...@ie...>]

On Wed, 29 Oct 2014 15:59:21 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 29 October, 2014 15:14:40 Philipp K. Janert wrote:
> 
> [big snip to get to a discussion point]
> 
> > > Placing it in a heredoc makes the script self-contained.    

I am splitting this thread into two.

This one is to heredocs: My argument is
that if heredocs stay, then they should
be thought through and implemented in 
such a way as to present a consistent
user experience.

They can be loaded with "load" and in no
other way. Hence, they should be written
(or at least: be writeable) with "save".

That would support your intended use case,
but also support other uses people will 
find for heredocs.

> > 
> > I totally disagree, and I wish there would be a much
> > bigger discussion: we are now breaking the distinction
> > of data and commands. Is this really a good idea? We
> > are also abandoning the idea of not maintaining data 
> > in the session state. Is this architecturally a good
> > direction? I am not at all sure - on balance, I would
> > say: it is not.
> > 
> > One of gnuplot's strong features has always been its
> > simplicity: data was in unstructured text files,
> 
>    Binary data files were introduced some time between verions 3.5
> and 3.7. So - about 20 years ago
> 
> > there was no session state,
> 
>    I am not sure what you mean here.
>    Isn't the session state exactly what you are saving in a "save"
> command? I.e. all the current settings, variable assignments,
> function defs, etc 
> > command files were separate from data.
> 
>    In-line data via plot '-'
>    has been supported at least as far back as version 3.7
> 
> > We are now breaking this. We are beginning to maintain
> > state - which means that before long, there will be 
> > a desire to "reload the session just as it was before",
> > with various preloaded data sets and all that. 
> 
>   Hasn't there all along been a current state that can be saved
>   and later reloaded?
> 
> > We are also now mixing data and commands. At what point
> > will it become habitual to save data always in command
> > files? There goes the ability to load them into Excel
> > or pipe them through sort.
> 
>  Sorry, I'm lost now. 
>  What is it that you would be loading into excel?
>  While I have taken data _out_ of excel as a *.csv file to plot
>  in gnuplot, I am sure I have never wanted to export anything
>  back in the other direction.   
> 
>  I am honestly confused at this point whether you are arguing
>  that a datablock ("heredoc") is part of the current state and
>  therefore should be included in save/restore, or whether you
>  are arguing that data should never be part of the current state
>  and therefore it should not be saved.
> 
> 	Ethan
> 
> > 
> > At the end of this process stands something like R. If
> > you know R, you'll see that it has exactly those features:
> > complicated sessions, complicated internal data models,
> > the whole shmear. 
> > 
> > But: R is a pain to learn.
> > And: if gnuplot wants to compete with R, it will lose.
> >   (In their field, their headstart is too great.)
> > 
> > Do we need to go there, just in order to simplify the
> > maintenance of the demo/ folder?
> > 
> > Sometimes one should simply say "No" to a new feature.
> > Simplicity is a virtue. It should not be abandoned
> > unnecessarily.
> > 
> > I think that heredocs (and some other recent features,
> > but heredocs in particular) take gnuplot in an unhealthy
> > direction. I don't think their consequences have been
> > properly thought through. These features add complexity, 
> > and they will invariably lead to unforeseen and undesirable
> > interactions between features - which will lead to even 
> > more complexity to fix.
> > 
> > Maybe there is a valid need for some of these (and other,
> > yet unproposed) features. But then we should try to
> > understand the ramifications, and - quite possibly -
> > reject some of these ideas, in the name of long-term
> > health and survival.
> > 
> > (To give you a sense for what I foresee: now that we
> > have loops, there is a need for an iterable data 
> > structure. (Currently there is none.) Then there will
> > be the desire to be able to iterate over the entries
> > in a heredoc. Now you pretty much have what R calls a
> > "data frame". Once you have data frames, it makes sense
> > to operate on them - things like vector addition or the
> > odd indexing magic that R and matlab delight in. At 
> > that point, it makes sense to link a matrix library
> > to do some numerics. And so on.)
> > 
> > I think the Numpy/Scipy universe is suffering from the
> > inability to say "No". This has led to a humongous,
> > impenetrable, and totally unstructured API - and
> > serious quality problems! (Adding "one more feature"
> > is easy, but working out all the edge cases and 
> > interactions is not!) 
> > 
> > Gnuplot has always been simple, but reliable. I think
> > we are at risk of abandoning them - without realizing
> > it.
> > 
> > > 
> > > For this type of application, "save" is not a normal command.
> > > If you want to regenerate a plot you just run the script again.
> > > 
> > > 	Ethan  
> > > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via:
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Should heredocs be included in "save"?

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

On Wednesday, 29 October, 2014 15:14:40 Philipp K. Janert wrote:

[big snip to get to a discussion point]

> > Placing it in a heredoc makes the script self-contained.    
> 
> I totally disagree, and I wish there would be a much
> bigger discussion: we are now breaking the distinction
> of data and commands. Is this really a good idea? We
> are also abandoning the idea of not maintaining data 
> in the session state. Is this architecturally a good
> direction? I am not at all sure - on balance, I would
> say: it is not.
> 
> One of gnuplot's strong features has always been its
> simplicity: data was in unstructured text files,

   Binary data files were introduced some time between verions 3.5 and 3.7.
   So - about 20 years ago

> there was no session state,

   I am not sure what you mean here.
   Isn't the session state exactly what you are saving in a "save" command?
   I.e. all the current settings, variable assignments, function defs, etc
  
> command files were separate from data.

   In-line data via plot '-'
   has been supported at least as far back as version 3.7

> We are now breaking this. We are beginning to maintain
> state - which means that before long, there will be 
> a desire to "reload the session just as it was before",
> with various preloaded data sets and all that. 

  Hasn't there all along been a current state that can be saved
  and later reloaded?

> We are also now mixing data and commands. At what point
> will it become habitual to save data always in command
> files? There goes the ability to load them into Excel
> or pipe them through sort.

 Sorry, I'm lost now. 
 What is it that you would be loading into excel?
 While I have taken data _out_ of excel as a *.csv file to plot
 in gnuplot, I am sure I have never wanted to export anything
 back in the other direction.   

 I am honestly confused at this point whether you are arguing
 that a datablock ("heredoc") is part of the current state and
 therefore should be included in save/restore, or whether you
 are arguing that data should never be part of the current state
 and therefore it should not be saved.

	Ethan

> 
> At the end of this process stands something like R. If
> you know R, you'll see that it has exactly those features:
> complicated sessions, complicated internal data models,
> the whole shmear. 
> 
> But: R is a pain to learn.
> And: if gnuplot wants to compete with R, it will lose.
>   (In their field, their headstart is too great.)
> 
> Do we need to go there, just in order to simplify the
> maintenance of the demo/ folder?
> 
> Sometimes one should simply say "No" to a new feature.
> Simplicity is a virtue. It should not be abandoned
> unnecessarily.
> 
> I think that heredocs (and some other recent features,
> but heredocs in particular) take gnuplot in an unhealthy
> direction. I don't think their consequences have been
> properly thought through. These features add complexity, 
> and they will invariably lead to unforeseen and undesirable
> interactions between features - which will lead to even 
> more complexity to fix.
> 
> Maybe there is a valid need for some of these (and other,
> yet unproposed) features. But then we should try to
> understand the ramifications, and - quite possibly -
> reject some of these ideas, in the name of long-term
> health and survival.
> 
> (To give you a sense for what I foresee: now that we
> have loops, there is a need for an iterable data 
> structure. (Currently there is none.) Then there will
> be the desire to be able to iterate over the entries
> in a heredoc. Now you pretty much have what R calls a
> "data frame". Once you have data frames, it makes sense
> to operate on them - things like vector addition or the
> odd indexing magic that R and matlab delight in. At 
> that point, it makes sense to link a matrix library
> to do some numerics. And so on.)
> 
> I think the Numpy/Scipy universe is suffering from the
> inability to say "No". This has led to a humongous,
> impenetrable, and totally unstructured API - and
> serious quality problems! (Adding "one more feature"
> is easy, but working out all the edge cases and 
> interactions is not!) 
> 
> Gnuplot has always been simple, but reliable. I think
> we are at risk of abandoning them - without realizing
> it.
> 
> > 
> > For this type of application, "save" is not a normal command.
> > If you want to regenerate a plot you just run the script again.
> > 
> > 	Ethan  
> > 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Should heredocs be included in "save"?

[Philipp K. J. <ja...@ie...>]

Comments below. Others please join, I think this
touches a fundamental question. (At the very end
of this email.)

> > Ethan pointed out (on gp-info) that it is usually
> > used as part of a command script. That makes me 
> > wonder whether the contents of a heredoc should be 
> > included in the information that is written to file
> > using "save".
> > 
> > My rationale is this: traditionally, "save" 
> > persisted the entire session state (excluding
> > terminal settings). Loading the resulting file
> > with "load" recreated the entire session, even
> > if gnuplot had been exited and restarted in the
> > meantime.
> > 
> > Now I imagine an interactive session, in which
> > I define a heredoc (to add some points to a graph,
> > for example). Now doing a "save", exit, and "load"
> > will NOT recreate the session, in fact the "load"
> > will fail, since the data block (=heredoc) is no
> > longer defined!
> 
> I suppose that's one way of thinking about it, but it's
> not the viewpoint that motivated heredoc originally.
> I view it as a mechanism to avoid requiring multiple
> files associated with a reusable script.  It is an
> alternate data source, not part of the session state.

Well, IF the data is presented in the command-script,
I agree. But if the data is entered at the command
prompt, then it seems to be the same as a user-defined
variable, and hence part of the session state.

> 
> "save" doesn't include the content of the last data file
> plotted, and it doesn't include the content of the last
> heredoc plotted.  If you had used in-line data via
> plot '-' then it wouldn't save that either.

Yes, but file contents are NEVER part of the session
state - that is (was?) the big distinction in gnuplot:
session state as opposed to data files. 

But heredocs appear to the user as session-variables
that are able to hold more than a single scalar. It
is odd that they are treated differently.

Let me make a symmetry argument: "save" and "load"
are complementary commands. Since heredocs can be
read with "load", it is only natural that they 
should be written with "save". 

(I actually think this symmetry/consistency argument 
is a "killer" argument.)

> 
> > I think it is undesirable that a command file
> > generated by "save" will fail to "load". Moreover,
> > I strongly think that "re-creatibility" of a plot
> > is an essential feature. But currently, plots
> > involving interactively defined heredocs are not
> > recreateable. 
> 
> That's exactly backwards to the way I see it.  If a script requires

I agree! And on some level, that's a compliment to
the feature: apparently, it has uses quite outside
of the original intent.

> a separate auxilliary data file to run, that introduces an extra
> dependency for reproducing any plot created by that script.
> By instead placing the data in a heredoc in the script itself,
> the plot can be recreated without tracking down an
> additional data file.
> 

Yes, I understand that (and I will admit to having
this problem in the past). 

At the same time, the need to create and maintain
demo scripts is not a widespread activity. I am
concerned that a paradigm-breaking feature has been
introduced only for the maintenance of the demo/
folder! 

But now that it's there, it should be made generally
useful. (Or quietly swept under the rug again, and
kept only as "undocumented maintainer feature".)

> 
> > More broadly speaking, I am wondering about the
> > strategic intent/direction for heredocs. For
> > instance, I would expect to be able to load a 
> > data file into a heredoc "variable", so that I 
> > then don't have to touch the underlying file again.
> 
> > Currently, their primary purpose seems to be to 
> > embed  data in command (demo?) files - which is 
> > not exactly a feature most users need every day.
> 
> Think of a data analysis script that takes as input a data file
> and produces a plot of the experimental data vs a reference
> curve.   If the reference curve is easily generated by an
> analytic function then probably you'd use that.  But if the
> reference curve itself is defined by observed data then
> either you need to provide a separate reference data file or
> place the reference data in a heredoc.

I disagree - if your reference model is given through
a data set, then it's a data set and should be treated
as such.

> Placing it in a heredoc makes the script self-contained.    

I totally disagree, and I wish there would be a much
bigger discussion: we are now breaking the distinction
of data and commands. Is this really a good idea? We
are also abandoning the idea of not maintaining data 
in the session state. Is this architecturally a good
direction? I am not at all sure - on balance, I would
say: it is not.

One of gnuplot's strong features has always been its
simplicity: data was in unstructured text files, there
was no session state, command files were separate from
data.

We are now breaking this. We are beginning to maintain
state - which means that before long, there will be 
a desire to "reload the session just as it was before",
with various preloaded data sets and all that. 

We are also now mixing data and commands. At what point
will it become habitual to save data always in command
files? There goes the ability to load them into Excel
or pipe them through sort.

At the end of this process stands something like R. If
you know R, you'll see that it has exactly those features:
complicated sessions, complicated internal data models,
the whole shmear. 

But: R is a pain to learn.
And: if gnuplot wants to compete with R, it will lose.
  (In their field, their headstart is too great.)

Do we need to go there, just in order to simplify the
maintenance of the demo/ folder?

Sometimes one should simply say "No" to a new feature.
Simplicity is a virtue. It should not be abandoned
unnecessarily.

I think that heredocs (and some other recent features,
but heredocs in particular) take gnuplot in an unhealthy
direction. I don't think their consequences have been
properly thought through. These features add complexity, 
and they will invariably lead to unforeseen and undesirable
interactions between features - which will lead to even 
more complexity to fix.

Maybe there is a valid need for some of these (and other,
yet unproposed) features. But then we should try to
understand the ramifications, and - quite possibly -
reject some of these ideas, in the name of long-term
health and survival.

(To give you a sense for what I foresee: now that we
have loops, there is a need for an iterable data 
structure. (Currently there is none.) Then there will
be the desire to be able to iterate over the entries
in a heredoc. Now you pretty much have what R calls a
"data frame". Once you have data frames, it makes sense
to operate on them - things like vector addition or the
odd indexing magic that R and matlab delight in. At 
that point, it makes sense to link a matrix library
to do some numerics. And so on.)

I think the Numpy/Scipy universe is suffering from the
inability to say "No". This has led to a humongous,
impenetrable, and totally unstructured API - and
serious quality problems! (Adding "one more feature"
is easy, but working out all the edge cases and 
interactions is not!) 

Gnuplot has always been simple, but reliable. I think
we are at risk of abandoning them - without realizing
it.

> 
> For this type of application, "save" is not a normal command.
> If you want to regenerate a plot you just run the script again.
> 
> 	Ethan  
> 

Re: Should heredocs be included in "save"?

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

On Wednesday, 29 October, 2014 11:59:44 Philipp K. Janert wrote:
> 
> Just a question/suggestion...
> 
> I am trying to understand the proper use of the
> new "heredoc" feature.
> 
> Ethan pointed out (on gp-info) that it is usually
> used as part of a command script. That makes me 
> wonder whether the contents of a heredoc should be 
> included in the information that is written to file
> using "save".
> 
> My rationale is this: traditionally, "save" 
> persisted the entire session state (excluding
> terminal settings). Loading the resulting file
> with "load" recreated the entire session, even
> if gnuplot had been exited and restarted in the
> meantime.
> 
> Now I imagine an interactive session, in which
> I define a heredoc (to add some points to a graph,
> for example). Now doing a "save", exit, and "load"
> will NOT recreate the session, in fact the "load"
> will fail, since the data block (=heredoc) is no
> longer defined!

I suppose that's one way of thinking about it, but it's
not the viewpoint that motivated heredoc originally.
I view it as a mechanism to avoid requiring multiple
files associated with a reusable script.  It is an
alternate data source, not part of the session state.

"save" doesn't include the content of the last data file
plotted, and it doesn't include the content of the last
heredoc plotted.  If you had used in-line data via
plot '-' then it wouldn't save that either.

> I think it is undesirable that a command file
> generated by "save" will fail to "load". Moreover,
> I strongly think that "re-creatibility" of a plot
> is an essential feature. But currently, plots
> involving interactively defined heredocs are not
> recreateable. 

That's exactly backwards to the way I see it.  If a script requires
a separate auxilliary data file to run, that introduces an extra
dependency for reproducing any plot created by that script.
By instead placing the data in a heredoc in the script itself,
the plot can be recreated without tracking down an
additional data file.


> More broadly speaking, I am wondering about the
> strategic intent/direction for heredocs. For
> instance, I would expect to be able to load a 
> data file into a heredoc "variable", so that I 
> then don't have to touch the underlying file again.

> Currently, their primary purpose seems to be to 
> embed  data in command (demo?) files - which is 
> not exactly a feature most users need every day.

Think of a data analysis script that takes as input a data file
and produces a plot of the experimental data vs a reference
curve.   If the reference curve is easily generated by an
analytic function then probably you'd use that.  But if the
reference curve itself is defined by observed data then
either you need to provide a separate reference data file or
place the reference data in a heredoc.
Placing it in a heredoc makes the script self-contained.    

For this type of application, "save" is not a normal command.
If you want to regenerate a plot you just run the script again.

	Ethan  

Should heredocs be included in "save"?

[Philipp K. J. <ja...@ie...>]

Just a question/suggestion...

I am trying to understand the proper use of the
new "heredoc" feature.

Ethan pointed out (on gp-info) that it is usually
used as part of a command script. That makes me 
wonder whether the contents of a heredoc should be 
included in the information that is written to file
using "save".

My rationale is this: traditionally, "save" 
persisted the entire session state (excluding
terminal settings). Loading the resulting file
with "load" recreated the entire session, even
if gnuplot had been exited and restarted in the
meantime.

Now I imagine an interactive session, in which
I define a heredoc (to add some points to a graph,
for example). Now doing a "save", exit, and "load"
will NOT recreate the session, in fact the "load"
will fail, since the data block (=heredoc) is no
longer defined!

I think it is undesirable that a command file
generated by "save" will fail to "load". Moreover,
I strongly think that "re-creatibility" of a plot
is an essential feature. But currently, plots
involving interactively defined heredocs are not
recreateable. 

More broadly speaking, I am wondering about the
strategic intent/direction for heredocs. For
instance, I would expect to be able to load a 
data file into a heredoc "variable", so that I 
then don't have to touch the underlying file again.
Currently, their primary purpose seems to be to 
embed  data in command (demo?) files - which is 
not exactly a feature most users need every day.

Best,

		Ph.

Re: Proposal: Saving graphs from Qt and wxt terminals

[<pl...@pi...>]

On 10/27/14 21:58, Ethan A Merritt wrote:
>
> On Monday, 27 October, 2014 21:30:04 pl...@pi... wrote:
>> On 10/27/14 19:53, Ethan A Merritt wrote:
>>> I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget.
>>>
>>> The very first time you use it, the state of the toggle button may not be
>>> reported correctly because the corresponding state variable doesn't exist
>>> in your previous saved-state file.  But once you've exited the program
>>> that first time, causing the saved-state to be updated, everything should work
>>> correcly in subsequent sessions.
>>>
>>> I also have code to add save-to-png-file to the wxt toolbar.
>>> But I haven't worked with this toolkit before and I haven't found a
>>> decent worked example to show how to embed this in a pull-down menu.
>>> So as before ...
>>>
>>>>> Patches welcome.
>>> 	Ethan
>>>
>>
>> Nice addition Ethan, thanks for putting that in. Having to hit replot
>> every time I resize wxt was always a drag but never seemed important
>> enough to mention.  I'm not sure what purpose there is in the toggle
>> option, when is it useful to have the plot temporarily not match the new
>> terminal size?
>
> If you resize a complex 3D plot (e.g. the ones in transparent_solids.dem)
> resizing the window can get really slow.  Same thing for a comutationally
> intensive 2D plot. It gets  _really_ slow in some cases.  For instance,
> I have some data-plotting scripts that take ~5 seconds to redraw the plot.
> Not so bad if the reason for redrawing is to change the data file.
> But resizing the plot triggers the redraw multiple times, so it can be
> more than a minute before the display settles down again.
> I would normally keep this option "off".
>
> A better fix would be to only refresh when the resizing operation stops.
> I'm sure that's possible, but would require bookkeeping that isn't in there
> at present.
>
> 	Ethan
>

OK, that makes a lot of sense. I use wxt almost exclusively so did not 
realise that there were multiple re-drawings being triggered in other 
terminals resize ops.

Obviously redrawing the plot while a resize is in progress is very 
wasteful.  A simple test for mouse button pressed status could prevent 
this and would seem to be a simple test rather than book-keeping  ( does 
anyone resize using keyboard? ).

This also points out the need for a means to interrupt a plot process. I 
have hit this before when I did something unintentional and it got 
locked into doing something for several minutes without any apparent 
means to stop it without using kill -9 gnuplot !

Maybe there should be some periodic check for Esc or cntl-c keypress 
during plotting.

Peter.

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On 10/27/2014 01:53 PM, Ethan A Merritt wrote:

> I also have code to add save-to-png-file to the wxt toolbar.
> But I haven't worked with this toolkit before and I haven't found a
> decent worked example to show how to embed this in a pull-down menu.
> So as before ...
>
>> Patches welcome.

I've placed a patch here:

https://sourceforge.net/p/gnuplot/patches/704/

Give that a try.  All you need to do is put your code for saving as PNG 
or whatnot in the location provided in the new switch statement.  You 
may also want to tweak things, e.g., change the filters to whatever 
files you can save as.

This is slightly different than the way Qt behaves as far as picking a 
file format.  It's done via the file dialog's filter feature.  It makes 
for a more conventional method of choosing, and in fact makes for easier 
programming versus putting a dropdown menu associated with the toolbar 
button.  I suggest adding your code and moving into the repository then 
let people compare/experiment.  If people prefer the dropdown menu, I 
can give that a try.

Note that for the file icon I simply used one of the standard stock 
icons for wxWidgets, the wxART_FILE_SAVE_AS icon (suggested size 
wxART_TOOLBAR).  So, the icon should be the same as you see in GTK, KDE 
or whatever.  I saw in the icons directory how to convert a PNG file, 
but before doing that I thought I'd give this a try.

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On 10/27/2014 01:53 PM, Ethan A Merritt wrote:
> On Friday, 24 October, 2014 22:17:19 sfeam wrote:
>> On Saturday, 25 October 2014 12:01:57 AM Daniel J Sebald wrote:
>>> On 10/24/2014 05:04 PM, Ethan A Merritt wrote:
>>>> On Friday, 24 October, 2014 15:17:01 Daniel J Sebald wrote:
>>>>> Also the WXT terminal has a fixed aspect ratio where Qt terminal does not.
>>>>
>>>> Again not true here.   The copy/paste is just a bitmap of whatever the
>>>> current display shows.  You can change the aspect ratio to anything
>>>> you like either with "set term wxt size XX,YY"  or by resizing the open
>>>> window with the mouse.
>>>
>>> When resizing the window, I'm seeing the plot change size but using the
>>> maximum size that fits within whatever is the minimum axis that
>>> maintains aspect ratio.  The rest of the screen is then grey.  I've
>>> attached a small screenshot.
>>
>> Ah, I understand.
>> See Feature Request #314
>>
>> The new aspect ratio isn't applied until the next replot.
>> The qt terminal has a tool widget to toggle whether you
>> want this to happen automatically.  The wxt should have one also.
>
> I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget.
>
> The very first time you use it, the state of the toggle button may not be
> reported correctly because the corresponding state variable doesn't exist
> in your previous saved-state file.  But once you've exited the program
> that first time, causing the saved-state to be updated, everything should work
> correcly in subsequent sessions.

Pressing the tools wrench seems to automatically change the setting of 
this toggle box without actually pressing it.  (The action does seem to 
match the setting though.)  I've exited gnuplot and tried again.  Same 
thing.

Dan

Q: Is there some way to test the whole of gnuplot, including terminals, 
without doing a system install?

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On Monday, 27 October, 2014 21:30:04 pl...@pi... wrote:
> On 10/27/14 19:53, Ethan A Merritt wrote:
> > I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget.
> >
> > The very first time you use it, the state of the toggle button may not be
> > reported correctly because the corresponding state variable doesn't exist
> > in your previous saved-state file.  But once you've exited the program
> > that first time, causing the saved-state to be updated, everything should work
> > correcly in subsequent sessions.
> >
> > I also have code to add save-to-png-file to the wxt toolbar.
> > But I haven't worked with this toolkit before and I haven't found a
> > decent worked example to show how to embed this in a pull-down menu.
> > So as before ...
> >
> >> >Patches welcome.
> > 	Ethan
> >
> 
> Nice addition Ethan, thanks for putting that in. Having to hit replot 
> every time I resize wxt was always a drag but never seemed important 
> enough to mention.  I'm not sure what purpose there is in the toggle 
> option, when is it useful to have the plot temporarily not match the new 
> terminal size?  

If you resize a complex 3D plot (e.g. the ones in transparent_solids.dem)
resizing the window can get really slow.  Same thing for a comutationally
intensive 2D plot. It gets  _really_ slow in some cases.  For instance, 
I have some data-plotting scripts that take ~5 seconds to redraw the plot.
Not so bad if the reason for redrawing is to change the data file.
But resizing the plot triggers the redraw multiple times, so it can be
more than a minute before the display settles down again.
I would normally keep this option "off".

A better fix would be to only refresh when the resizing operation stops.
I'm sure that's possible, but would require bookkeeping that isn't in there
at present.

	Ethan

> Surely if the user resizes the terminal it is with the 
> intention to resize the graph, which will happen next time anything is 
> plotted or replotted.
> 
> I'm not a hard-line GUI minimalist but this toggle seems like feature 
> clutter.
> 
> Peter.