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

Re: right-click doing line toggle on QT

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

On 25/01/16 19:07, Ethan A Merritt wrote:
> On Monday, 25 January, 2016 13:21:55 pl...@pi... wrote:
>
>  > Hi,
>
>  >
>
>  > a minor but persistently annoying bug on gnuplot-qt ( as provided by
>
>  > Fedora 23 ) :
>
>  > On the qt build a right mouse click in the plot area to select a zoom
>
>  > area is also triggering the line visibility toggle if it happens on the
>
>  > legend part of the graph. This is very annoying since it hides the line
>
>  > you may be trying to zoom on making it impossible to accurately choose
>
>  > the zoom area.
>
>  >
>
>  > Clearly this feature should be restricted to left-mouse clicks. This is
>
>  > the case in wxt , so I presume that it's an error.
>
> Good point. (Easy to fix, too :-)
>
>  > In passing I also report that when qt terminal toggles a line the legend
>
>  > gets a mid-grey background colour that is very ugly. Presumably someone
>
>  > thought it could indicated a non-visible line.
>
>  >
>
>  > I would submit that it just makes a visual mess of the graph and is not
>
>  > even helpful since it renders the legend pretty much visible anyway.
>
> Did you mean to say "invisible"?
>
> It looks OK to me, but I suppose tastes and computer displays vary.

Yes: invisible, sorry.

As I said it looks more reasonable in wxt.  QT is way too dark and makes 
it illegible ( on my monitor ) and an ugly dark block.    Colour 
inconsistencies between terminals is already a bit of a problem.
>
>  > Same on wxt but legible.. Probably grey too dark on qt.
>
>  >
>
>  > I seem to recall that it was the line sample in the legend that got
>
>  > turned off along with the line. This communicates the same information
>
>  > in an aesthetically more acceptable manner, IMO.
>
> Yeah, but if you toggle off the line sample there is nothing to
>
> click on any more. How would you toggle it back on again?
>
> There would have to be some other clickable placeholder.


No, the legend text itself is also clickable. It may make more sense if 
the line in the legend went 'hidden' as well ;)   IIRC that's what the 
SVG terminal mouse action  does.

Peter

>
> Ethan
>

"set term wxt font" still has a problem

[Jun T. <tak...@kb...>]

With the CVS HEAD (since the 'fix' of Bug#1713), I can't set
the font and font size simultaneously for wxt terminal.
The following sets the font but the font size is ignored:

gnuplot>set term wxt font 'Times,20'

In wxt.trm, line 183,

            if (s[sep] == ',')

is not satisfied if sep>0, because s[sep] has been
already set to null at line 181.

A possible simple patch is attached.

Re: right-click doing line toggle on QT

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

On Monday, 25 January, 2016 13:21:55 pl...@pi... wrote:
> Hi,
> 
> a minor but persistently annoying bug on gnuplot-qt ( as provided by 
> Fedora 23 ) :

> On the qt build a right mouse click in the plot area to select a zoom 
> area is also triggering the line visibility toggle if it happens on the 
> legend part of the graph. This is very annoying since it hides the line 
> you may be trying to zoom on making it impossible to accurately choose 
> the zoom area.
> 
> Clearly this feature should be restricted to left-mouse clicks. This is 
> the case in wxt , so I presume that it's an error.

Good point.  (Easy to fix, too :-)

> In passing I also report that when qt terminal toggles a line the legend 
> gets a mid-grey background colour that is very ugly.  Presumably someone 
> thought it could indicated a non-visible line.
> 
> I would submit that it just makes a visual mess of the graph and is not 
> even helpful since it renders the legend pretty much visible anyway.

Did you mean to say "invisible"? 
It looks OK to me, but I suppose tastes and computer displays vary.

> Same on wxt but legible.. Probably grey too dark on qt.
> 
> I seem to recall that it was the line sample in the legend that got 
> turned off along with the line. This communicates the same information 
> in an aesthetically more acceptable manner, IMO.

Yeah, but if you toggle off the line sample there is nothing to 
click on any more.  How would you toggle it back on again?
There would have to be some other clickable placeholder.  

	Ethan

right-click doing line toggle on QT

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

Hi,

a minor but persistently annoying bug on gnuplot-qt ( as provided by 
Fedora 23 ) :

Fedora provide separate builds for gnuplot  ( aka gnuplot-qt ) and 
gnuplot-wx


	G N U P L O T
	Version 5.0 patchlevel 1    last modified 2015-06-07


On the qt build a right mouse click in the plot area to select a zoom 
area is also triggering the line visibility toggle if it happens on the 
legend part of the graph. This is very annoying since it hides the line 
you may be trying to zoom on making it impossible to accurately choose 
the zoom area.

Clearly this feature should be restricted to left-mouse clicks. This is 
the case in wxt , so I presume that it's an error.




In passing I also report that when qt terminal toggles a line the legend 
gets a mid-grey background colour that is very ugly.  Presumably someone 
thought it could indicated a non-visible line.

I would submit that it just makes a visual mess of the graph and is not 
even helpful since it renders the legend pretty much visible anyway.

Same on wxt but legible.. Probably grey too dark on qt.

I seem to recall that it was the line sample in the legend that got 
turned off along with the line. This communicates the same information 
in an aesthetically more acceptable manner, IMO.


Best regards, Peter.

Re: vrml/povray output ("terminal")

[folkert <fo...@va...>]

On Fri, Jan 22, 2016 at 10:35:45AM -0800, Ethan A Merritt wrote:
[gnuplot draws in layer 3, gets 2d coordinates from layer 2, the patch
hacks into layer 2, very uncleanly]

Ok thanks for the elaborate reply!
I'm going to find an other solution.


Folkert van Heusden

-- 
Multi tail barnamaj mowahib li mora9abat attasjilat wa nataij awamir
al 7asoub. damj, talwin, mora9abat attarchi7 wa ila akhirih.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Re: vrml/povray output ("terminal")

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

On Friday, 22 January, 2016 12:41:39 folkert wrote:
> > >At http://t-kita.net/gnuplot_povrml/ I found a patch for gnuplot to add
> > >povray and/or vrml output. Especially the last one I think is useful
> > >because it allows one to easily view for example an splot from all
> > >kinds of directions.
> > >Now I'm wondering: what does it take to get it to be included in the
> > >main gnuplot distribution?
> > 
> > That looks like code outside the project, no license infringement
> > technically or otherwise.  Patch and compile.
> 
> Yes but what does it take to get it integrated in the main gnuplot
> distribution?

I do not think that this patch is suitable for inclusion in gnuplot.

The web page you link to gives a misleading impression of what the patch
actually does. Let me explain.

Gnuplot can be viewed as having 3 layers.

(1) An input layer in which data enters the program.  Currently the
program can read ascii files (include csv format files), binary files,
and some specific image formats. Once the data enters the program it is
manipulated by ...

(2) A data-processing layer. This is primarily the "plot" and "splot"
commands, but also "fit" and "stats".  These latter two options output
analysis results and stop. The two plotting commands feed their output
though ...

(3) A third layer consisting of various "terminals" that format the
composed plot for a specific output device.  It is important to note
that the interface from layer 2 to layer 3 passes only 2D coordinates.
This is a historical artifact.  Gnuplot was originally designed in the
days of of pen plotters and character cell terminals.  Today we just
assume that graphics is done in 3D, but that was not true 40 years ago. 

The important thing is that all of the various plot styles
(lines, dots, boxes, surfaces, histograms, etc) are implemented in 
layer 2.  You can mix-and-match any choice of plot style (layer 2)
with any output device (layer 3).  Of course a hidden-surface plot
displayed to "set term dumb" won't look very good, but you can do it
if you want.

OK, now to the vrml/povray patch.
Although the patch claims to provide new terminals (vrml and povray),
this is not true and would not be possible because a gnuplot
terminal only knows about 2D coordinates.  Instead it inserts a 
new chunk of code into layer 2 that dumps a bunch of vrml or povray
header text, a formatted version of selected coordinates that were
previously read in by layer 1, a trailing bunch of vrml text,
and that's it.  It mostly ignores all the gnuplot plot styles.

I won't say this is useless.  As the web page shows, you can create
certain 3D plots this way.  But I will say that if this is what you
want to do, there are better ways to do it. Most of those better
ways don't involve gnuplot at all, but if for whatever reason you
want the solution to be based on gnuplot then a better approach would
be to write a separate script (your choice of scripting languages)
that dumps
- the vrml/povray header lines
- tabular output from gnuplot run as a separate process
- the vrml/povray trailing lines

This would have many advantages, not least that you could tweak
the script without having to patch and recompile gnuplot.

It would still be tricky to dump 3D coordinates, but I think it might
be possible using the plot style "with table" in version 5.  If not,
perhaps a patch to extend that capability would be appropriate.
If this works at all it would be useful for more things than just
the hypothetical vrml script.

		Ethan


> 
> 
> Folkert van Heusden
> 
> 

Re: vrml/povray output ("terminal")

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

On 01/22/2016 05:41 AM, folkert wrote:
>>> At http://t-kita.net/gnuplot_povrml/ I found a patch for gnuplot to add
>>> povray and/or vrml output. Especially the last one I think is useful
>>> because it allows one to easily view for example an splot from all
>>> kinds of directions.
>>> Now I'm wondering: what does it take to get it to be included in the
>>> main gnuplot distribution?
>>
>> That looks like code outside the project, no license infringement
>> technically or otherwise.  Patch and compile.
>
> Yes but what does it take to get it integrated in the main gnuplot
> distribution?

The author of the code needs to grant approval for its inclusion in 
gnuplot before it can be considered.  Someone submitting a patch to this 
list or to bug/patch tracker does so inherently.  Coders who create a 
patch that they maintain are simply following the patch-and-compile rule 
of the license.  There is nothing in the license that implies all 
compatible code becomes part of the project.

Dan

Re: vrml/povray output ("terminal")

[folkert <fo...@va...>]

I can imagine that you don't want code for each and every output-format
but then at least provide one from which one can convert to others?

On Fri, Jan 22, 2016 at 12:41:39PM +0100, folkert wrote:
> > >At http://t-kita.net/gnuplot_povrml/ I found a patch for gnuplot to add
> > >povray and/or vrml output. Especially the last one I think is useful
> > >because it allows one to easily view for example an splot from all
> > >kinds of directions.
> > >Now I'm wondering: what does it take to get it to be included in the
> > >main gnuplot distribution?
> > 
> > That looks like code outside the project, no license infringement
> > technically or otherwise.  Patch and compile.
> 
> Yes but what does it take to get it integrated in the main gnuplot
> distribution?
> 
> 
> Folkert van Heusden
> 
> -- 
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com


Folkert van Heusden

-- 
Afraid of irssi? Scared of bitchx? Does xchat gives you bad shivers?
In all these cases take a look at http://www.vanheusden.com/fi/ maybe
even try it or use it for all your day-to-day IRC conversations!
-----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Re: vrml/povray output ("terminal")

[folkert <fo...@va...>]

> >At http://t-kita.net/gnuplot_povrml/ I found a patch for gnuplot to add
> >povray and/or vrml output. Especially the last one I think is useful
> >because it allows one to easily view for example an splot from all
> >kinds of directions.
> >Now I'm wondering: what does it take to get it to be included in the
> >main gnuplot distribution?
> 
> That looks like code outside the project, no license infringement
> technically or otherwise.  Patch and compile.

Yes but what does it take to get it integrated in the main gnuplot
distribution?


Folkert van Heusden

-- 
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Re: vrml/povray output ("terminal")

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

On 21.01.2016 09:55, folkert wrote:
>
> At http://t-kita.net/gnuplot_povrml/ I found a patch for gnuplot to add
> povray and/or vrml output. Especially the last one I think is useful
> because it allows one to easily view for example an splot from all
> kinds of directions.
> Now I'm wondering: what does it take to get it to be included in the
> main gnuplot distribution?

That patch was build upon gnuplot 4.0, 11 years ago, and doesn't apply 
to the current version. After fixing two small rejected hunks in 
plot2d.c and plot3d.c I could compile it, but it gave me a segfault 
error when doing a rather simple splot...

Additionally, those two terminals 'povray' and 'vrml' do their whole 
work of creating the output files directly inside plot3d.c, 
circumventing the usual terminal working mechanisms. I guess those 
terminals would need a complete rewrite before considering their 
inclusion in the main source.

Best,
Christoph

Re: vrml/povray output ("terminal")

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

On 01/21/2016 02:55 AM, folkert wrote:
> Hi,
>
> At http://t-kita.net/gnuplot_povrml/ I found a patch for gnuplot to add
> povray and/or vrml output. Especially the last one I think is useful
> because it allows one to easily view for example an splot from all
> kinds of directions.
> Now I'm wondering: what does it take to get it to be included in the
> main gnuplot distribution?

Folkert,

That looks like code outside the project, no license infringement 
technically or otherwise.  Patch and compile.

Dan

Re: please update .cvsignore

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

On Wednesday, 20 January, 2016 17:33:23 Jun T. wrote:
> [1] Please consider the attached patch for .cvsignore's.
> 
> If BeOS is still supported, please add src/beos/.cvsignore also
> (I guess only 'Makefile' need be listed in the file).
> 
> [2] docs/pdffigures.tex is created by 'make' and removed by
> 'make clean'. So I think it need not be tracked by CVS.

Got it.

	thanks

		Ethan

vrml/povray output ("terminal")

[folkert <fo...@va...>]

Hi,

At http://t-kita.net/gnuplot_povrml/ I found a patch for gnuplot to add
povray and/or vrml output. Especially the last one I think is useful
because it allows one to easily view for example an splot from all
kinds of directions.
Now I'm wondering: what does it take to get it to be included in the
main gnuplot distribution?


regards


Folkert van Heusden

-- 
MultiTail is a versatile tool for watching logfiles and output of
commands. Filtering, coloring, merging, diff-view, etc.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

please update .cvsignore

[Jun T. <tak...@kb...>]

[1] Please consider the attached patch for .cvsignore's.

If BeOS is still supported, please add src/beos/.cvsignore also
(I guess only 'Makefile' need be listed in the file).

[2] docs/pdffigures.tex is created by 'make' and removed by
'make clean'. So I think it need not be tracked by CVS.

Re: typo injected an undeclared function into the name space ?

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

On 15/01/16 18:38, Ethan A Merritt wrote:
> On Friday, 15 January, 2016 17:54:37 pl...@pi... wrote:
>
>  > On 15/01/16 17:40, Ethan A Merritt wrote:
>
>  > > On Friday, 15 January, 2016 11:38:01 pl...@pi... wrote:
>
>  > >
>
>  > > > Hi ,
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > I accidentally forgot a * operator when plotting a function. This
> seems
>
>  > >
>
>  > > > to have injected an udefined fn into the name space
>
>  > >
>
>  > > >
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > twopi=2*pi
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > gnuplot> plot datafile" u ($1/365.25+1970):2 w l, cos
> (twopi(x)/p3) +0.05
>
>  > >
>
>  > > > undefined function: twopi
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > User-Defined Functions:
>
>  > >
>
>  > > > cos1(x)=a1*cos(twopi*(x-phi1)/p1)
>
>  > >
>
>  > > > cos2(x)=a2*cos(twopi*(x-phi2)/p2)
>
>  > >
>
>  > > > cos3(x)=a3*cos(twopi*(x-phi3)/p3)
>
>  > >
>
>  > > > triple(x)=c+cos3(x)
>
>  > >
>
>  > > > twopi is undefined
>
>  > >
>
>  > > >
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > gnuplot> print twopi
>
>  > >
>
>  > > > 6.28318530717959
>
>  > >
>
>  > > >
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > Now it won't stop crapping on about "twopi is undefined", even
> though I
>
>  > >
>
>  > > > have plotted something else and make no reference to it.
>
>  > >
>
>  > > >
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > All I can find to clear it is to quit gnuplot.
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > Has this , as it seems, injected an undeclared function into the name
>
>  > >
>
>  > > > space ?
>
>  > >
>
>  > > >
>
>  > >
>
>  > > > How to clear it more elegantly, is this a bug?
>
>  > >
>
>  > > There is currently no way to clear or delete any user-provided
> function.
>
>  > >
>
>  > > That is true for your well-defined functions as well as your undefined
>
>  > >
>
>  > > function. The "undefine FOO" command only looks for FOO as a variable
>
>  > >
>
>  > > name not as a function name.
>
>  > >
>
>  > > If you want to reset the entire namespace you can use "reset session".
>
>  > >
>
>  > > Of course that will clear everything, not just the undefined function.
>
>  > >
>
>  > > Ethan
>
>  > >
>
>  >
>
>  > Thanks Ethan,
>
>  >
>
>  > the main point was, is this a bug?
>
>  >
>
>  > how did I manage to register an undefined function simply by trying to (
>
>  > accidentally ) use it in a plot command?
>
>  >
>
>  > How does that become a function definition, right or wrong ?
>
> gnuplot allows you to refer to a function before you define it.
>
> Consider:
>
> g(x) = f1(x) + f2(x)
>
> In order to store the evaluation template for g(x) it has to reserve
>
> slots for f1() and f2() even if they have not been defined yet.
>
> If you say "show fun" at this point you will see
>
> User-Defined Functions:
>
> g(x) = f1(x) + f2(x)
>
> f1 is undefined
>
> f2 is undefined
>
> Issuing a plot command triggers the same thing implicitly.
>
> The program constructs a template for how to evaluate the values
>
> being plotted, reserving a slot for any functions that are invoked.
>
> If it turns out that one of those functions is not yet defined then
>
> the plot will fail, but just as in the above example it leaves
>
> an entry in the table of functions that can be filled in later.
>
> You can see this at work in the following admittedly bizarre
>
> plot command that plots f(x) twice but redefines it in between:
>
> plot f(x)=sin(x) f(x), f(x)=cos(x) f(x)
>
> That works because both curves in the plot are evaluated using
>
> the template "f(x)" but the definition of "f()" has changed
>
> between the two evaluations of the same template.
>
> So - not a bug.
>
>
> Ethan
>

Thanks for giving a good understanding of what is happening.

Not a bug?  Well it must be feature then.

I can see the point of inserting a place holder when defining functions.
I can see no useful purpose in the same thing happening during a failed 
plot command. When that pollutes the namespace afterwards, it is not a 
very useful feature.

The solution of resetting the session is essentially just like quitting 
and restarting gnuplot. This can be quite a time waster if the user has 
defined several function , constants, string constants for axis labels, 
arrows and graph labels and has to start again.

It looks more  like an unintended side effect than a designed feature. 
Maybe the real problem is that there is no way of removing such zombies 
from the name space as can be done with variables.


I have a numeric constant  twopi that I can remove with undef , maybe 
what is needed is an equivalent fro function definitions.

regards, Peter.

Re: typo injected an undeclared function into the name space ?

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

On Friday, 15 January, 2016 17:54:37 pl...@pi... wrote:
> On 15/01/16 17:40, Ethan A Merritt wrote:
> > On Friday, 15 January, 2016 11:38:01 pl...@pi... wrote:
> >
> >  > Hi ,
> >
> >  >
> >
> >  > I accidentally forgot a * operator when plotting a function. This seems
> >
> >  > to have injected an udefined fn into the name space
> >
> >  >
> >
> >  >
> >
> >  > twopi=2*pi
> >
> >  >
> >
> >  > gnuplot> plot datafile" u ($1/365.25+1970):2 w l, cos (twopi(x)/p3) +0.05
> >
> >  > undefined function: twopi
> >
> >  >
> >
> >  > User-Defined Functions:
> >
> >  > cos1(x)=a1*cos(twopi*(x-phi1)/p1)
> >
> >  > cos2(x)=a2*cos(twopi*(x-phi2)/p2)
> >
> >  > cos3(x)=a3*cos(twopi*(x-phi3)/p3)
> >
> >  > triple(x)=c+cos3(x)
> >
> >  > twopi is undefined
> >
> >  >
> >
> >  >
> >
> >  > gnuplot> print twopi
> >
> >  > 6.28318530717959
> >
> >  >
> >
> >  >
> >
> >  > Now it won't stop crapping on about "twopi is undefined", even though I
> >
> >  > have plotted something else and make no reference to it.
> >
> >  >
> >
> >  >
> >
> >  > All I can find to clear it is to quit gnuplot.
> >
> >  >
> >
> >  > Has this , as it seems, injected an undeclared function into the name
> >
> >  > space ?
> >
> >  >
> >
> >  > How to clear it more elegantly, is this a bug?
> >
> > There is currently no way to clear or delete any user-provided function.
> >
> > That is true for your well-defined functions as well as your undefined
> >
> > function. The "undefine FOO" command only looks for FOO as a variable
> >
> > name not as a function name.
> >
> > If you want to reset the entire namespace you can use "reset session".
> >
> > Of course that will clear everything, not just the undefined function.
> >
> > Ethan
> >
> 
> Thanks Ethan,
> 
> the main point was, is this a bug?
> 
> how did I manage to register an undefined function simply by trying to ( 
> accidentally ) use it in a plot command?
> 
> How does that become a function definition, right or wrong ?

gnuplot allows you to refer to a function before you define it.
Consider:

  g(x) = f1(x) + f2(x)

In order to store the evaluation template for g(x) it has to reserve
slots for f1() and f2() even if they have not been defined yet.
If you say "show fun" at this point you will see
        User-Defined Functions:
        g(x) = f1(x) + f2(x)
        f1 is undefined
        f2 is undefined

Issuing a plot command triggers the same thing implicitly.
The program constructs a template for how to evaluate the values
being plotted, reserving a slot for any functions that are invoked.
If it turns out that one of those functions is not yet defined then
the plot will fail, but just as in the above example it leaves
an entry in the table of functions that can be filled in later.

You can see this at work in the following admittedly bizarre
plot command that plots f(x) twice but redefines it in between:

  plot f(x)=sin(x) f(x), f(x)=cos(x) f(x)

That works because both curves in the plot are evaluated using
the template "f(x)" but the definition of "f()" has changed
between the two evaluations of the same template.

So - not a bug.


	Ethan

 

Re: "make distclean" fails with cvs HEAD

[Jun T. <tak...@kb...>]

2015/06/06 03:02, Hans-Bernhard Bröker <HBB...@t-...> wrote:

> Am 05.06.2015 um 11:50 schrieb Jun T.:
>> With the latest cvs HEAD, "make distclean" fails as follows:
> 
> This is known, and a bug report about it has been sent to the automake maintainers.  No reaction yet, though.

Even if it is a automake's bug, I guess chances are rather low that
it will be fixed anytime soon. And anyway, interdependence among
subdirectories (src and docs) may better be avoided if possible.

Another problem in the current build system is that the version
number is specified in three different files:

VERSION           5.1
configure.ac      AC_INIT([gnuplot],[5.1])
src/version.c     const char gnuplot_version[] = "5.1";

The attached patch is an *example* of how to fix these two problems.

With the patch, the version number need be specified only in the
file VERSION. The argument of AC_INIT() is set by using 
m4_esyscmd_s([cat VERSION])).
# Another possibility is to specify the version number directly in 
# configure.ac and discard the file VERSION.

The version number is then passed to src/version.c and
docs/windows/doc2html.c by adding
    -DGNUPLOT_VERSION='"$(VERSION)"'
to CPPFLAGS in the {src,docs}/Makefile.am.
Another possibility is to add a template file "version.h.in" containing
    #define GNUPLOT_VERSION "@VERSION@"
and generate version.h by configure. Then version.c and doc2html.c can
#include the generated header file.

Or there may be still more possibilities.

Re: typo injected an undeclared function into the name space ?

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

On 15/01/16 17:40, Ethan A Merritt wrote:
> On Friday, 15 January, 2016 11:38:01 pl...@pi... wrote:
>
>  > Hi ,
>
>  >
>
>  > I accidentally forgot a * operator when plotting a function. This seems
>
>  > to have injected an udefined fn into the name space
>
>  >
>
>  >
>
>  > twopi=2*pi
>
>  >
>
>  > gnuplot> plot datafile" u ($1/365.25+1970):2 w l, cos (twopi(x)/p3) +0.05
>
>  > undefined function: twopi
>
>  >
>
>  > User-Defined Functions:
>
>  > cos1(x)=a1*cos(twopi*(x-phi1)/p1)
>
>  > cos2(x)=a2*cos(twopi*(x-phi2)/p2)
>
>  > cos3(x)=a3*cos(twopi*(x-phi3)/p3)
>
>  > triple(x)=c+cos3(x)
>
>  > twopi is undefined
>
>  >
>
>  >
>
>  > gnuplot> print twopi
>
>  > 6.28318530717959
>
>  >
>
>  >
>
>  > Now it won't stop crapping on about "twopi is undefined", even though I
>
>  > have plotted something else and make no reference to it.
>
>  >
>
>  >
>
>  > All I can find to clear it is to quit gnuplot.
>
>  >
>
>  > Has this , as it seems, injected an undeclared function into the name
>
>  > space ?
>
>  >
>
>  > How to clear it more elegantly, is this a bug?
>
> There is currently no way to clear or delete any user-provided function.
>
> That is true for your well-defined functions as well as your undefined
>
> function. The "undefine FOO" command only looks for FOO as a variable
>
> name not as a function name.
>
> If you want to reset the entire namespace you can use "reset session".
>
> Of course that will clear everything, not just the undefined function.
>
> Ethan
>

Thanks Ethan,

the main point was, is this a bug?

how did I manage to register an undefined function simply by trying to ( 
accidentally ) use it in a plot command?

How does that become a function definition, right or wrong ?

Thanks.

Re: typo injected an undeclared function into the name space ?

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

On Friday, 15 January, 2016 11:38:01 pl...@pi... wrote:
> Hi ,
> 
> I accidentally forgot a * operator when plotting a function. This seems 
> to have injected an udefined fn into the name space
> 
> 
> twopi=2*pi
> 
> gnuplot> plot datafile" u ($1/365.25+1970):2 w l, cos (twopi(x)/p3) +0.05
>           undefined function: twopi
> 
> 	User-Defined Functions:
> 	cos1(x)=a1*cos(twopi*(x-phi1)/p1)
> 	cos2(x)=a2*cos(twopi*(x-phi2)/p2)
> 	cos3(x)=a3*cos(twopi*(x-phi3)/p3)
> 	triple(x)=c+cos3(x)
> 	twopi is undefined
> 
> 
> gnuplot>  print twopi
> 6.28318530717959
> 
> 
> Now it won't stop crapping on about "twopi is undefined", even though I 
> have plotted something else and make no reference to it.
> 
> 
> All I can find to clear it is to quit gnuplot.
> 
> Has this , as it seems, injected an undeclared function into the name 
> space ?
> 
> How to clear it more elegantly, is this a bug?

There is currently no way to clear or delete any user-provided function.
That is true for your well-defined functions as well as your undefined
function. The "undefine FOO" command only looks for FOO as a variable
name not as a function name.

If you want to reset the entire namespace you can use "reset session".
Of course that will clear everything, not just the undefined function.

	Ethan

typo injected an undeclared function into the name space ?

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

Hi ,

I accidentally forgot a * operator when plotting a function. This seems 
to have injected an udefined fn into the name space


twopi=2*pi

gnuplot> plot datafile" u ($1/365.25+1970):2 w l, cos (twopi(x)/p3) +0.05
          undefined function: twopi

	User-Defined Functions:
	cos1(x)=a1*cos(twopi*(x-phi1)/p1)
	cos2(x)=a2*cos(twopi*(x-phi2)/p2)
	cos3(x)=a3*cos(twopi*(x-phi3)/p3)
	triple(x)=c+cos3(x)
	twopi is undefined


gnuplot>  print twopi
6.28318530717959


Now it won't stop crapping on about "twopi is undefined", even though I 
have plotted something else and make no reference to it.


All I can find to clear it is to quit gnuplot.

Has this , as it seems, injected an undeclared function into the name 
space ?

How to clear it more elegantly, is this a bug?

Peter.

Re: version 5.0.2 release and other news (aquaterm dashes; arrays)

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

On 13/01/16 21:13, Ethan A Merritt wrote:
> 5.0.2 Release
>
> ---------------
>
> Patchlevel 2 of gnuplot version 5.0 is now available as a tarball
>
> download from SourceForge.
>
> Windows binaries for the new version are not yet available.
>
> Please continue to use the 5.0.1 binaries for now.
>
> Aquaterm
>
> ---------
>
> Jun Takimoto has modified aquaterm to support custon dashtypes.
>
> This brings it into line with other terminals in version 5.
>
> Unfortunately the fix came just a bit too late for the 5.0.2
>
> release but is now in CVS for both 5.0 and 5.1
>
> Arrays
>
> -------
>
> Please check out and test patch #724 on SourceForge
>
> <https://sourceforge.net/p/gnuplot/patches/724/>
>
> It adds support for arrays, which has been a recurring request.
>
> I have been using it myself for a while, but I think it is
>
> ready for more widespread testing. Basic use is like this:
>
> # An array element can be an integer, a real, or a string
>
> # just as if it were an individual named variable
>
> array A[3]
>
> A[1] = 123.45
>
> A[2] = " some string"
>
> print A[1]**2, A[2]
>
>  > 15239.9025 some string
>
> print A[3]
>
>  > <undefined>
>
> print A[4]
>
>  > array index out of range
>
> show var A
>
>  > A = <2 element array>
>
> # Plot a non-contiguous selection of columns
>
> array COL[5] = [ 2,3, 5,6, 9]
>
> plot for [i=1:5] 'data' using 0:(column(COL[i])) title columnhead(COL[i])
>
> Ethan
>
>

Wow arrays !!

That was the biggest thing still missing from gnuplot since variable 
assignment was introduced years ago.

I'm still amazed that Ethan added the initial version of that feature to 
CVS barely 24h after I suggested it. One of my favourite stories about 
how great gnuplot project is.

Now arrays too. How cool is that?


;)

version 5.0.2 release and other news (aquaterm dashes; arrays)

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

5.0.2 Release
---------------
Patchlevel 2 of gnuplot version 5.0 is now available as a tarball
download from SourceForge.

Windows binaries for the new version are not yet available.
Please continue to use the 5.0.1 binaries for now.

Aquaterm
---------
Jun Takimoto has modified aquaterm to support custon dashtypes.
This brings it into line with other terminals in version 5.
Unfortunately the fix came just a bit too late for the 5.0.2
release but is now in CVS for both 5.0 and 5.1

Arrays
-------
Please check out and test patch #724 on SourceForge
 <https://sourceforge.net/p/gnuplot/patches/724/>
It adds support for arrays, which has been a recurring request.
I have been using it myself for a while, but I think it is
ready for more widespread testing.  Basic use is like this:

 # An array element can be an integer, a real, or a string
 # just as if it were an individual named variable 
 array A[3]
 A[1] = 123.45
 A[2] = " some string"
 print A[1]**2, A[2]
>                       15239.9025 some string
 print A[3]
>                       <undefined>
 print A[4]
>                       array index out of range
 show var A
>                       A = <2 element array>

 # Plot a non-contiguous selection of columns
 array COL[5] = [ 2,3, 5,6, 9]
 plot for [i=1:5] 'data' using 0:(column(COL[i])) title columnhead(COL[i])

		Ethan

Re: Why remove NeXT support code?

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

On 01/10/2016 07:56 PM, sfeam wrote:
> On Sunday, 10 January 2016 02:56:46 PM Daniel J Sebald wrote:
>> I noticed that the subdirectory for the NeXT code has been removed.  I
>> wouldn't classify NeXT computers as obsolete.  There is still a bit of
>> activity surrounding them:
>>
>> http://www.nextcomputers.org/
>> http://www.nextcomputers.org/forums/
>>
>> Plus, NeXT is a classic.
>
> Sure.  And MSDOS was a classic.  And Version 7 unix was a classic.
> And Atari and Amiga were classics.   But it's a good bet that no one is
> running the CVS development version of gnuplot on them.

Not in the sense NeXT was.  Has to be a bit of an overachiever.  NeXT 
was a true operating system, with tons of tools like DisplayPostScript, 
color wheels, DSP co-processor, laser-jet printer, networking 
connections.  Save for a slow optical drive, it was the start of the 
personal workstation, albeit pricey.  Some of the first WWW code was 
written on a NeXT.


>> I can understand not wanting to have bits of "ifdef NEXT" in the main
>> code, though.
>
> The NeXT conditionals in the core code were work-arounds for NeXT
> compiler (gcc 3.2) and library deficiencies at that time.   From the comments,
> I bet they were already unneeded by 2003 (gcc 3.3) at the very latest.
>
>> Looking at what was removed, I see there is this
>> init_terminal() routine that has me wondering why there are so many
>> pre-process conditionals.
>> For example:
>>
>> #ifdef X11
>> #ifdef QTTERM
>> #ifdef WXWIDGETS
>>> are not operating systems, they are basically terminals.
>> Can't these bits of code be placed in the associated terminal files?
>
> Um, no.  This is the routine that determines the default terminal
> when the program is first entered.  Obviously you can't call into that
> terminal before you have figured out what it is.  And certainly you
> cannot call into it if it wasn't configured into the current binary.

OK, I see.

Dan

Re: Why remove NeXT support code?

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

On Sunday, 10 January 2016 02:56:46 PM Daniel J Sebald wrote:
> I noticed that the subdirectory for the NeXT code has been removed.  I 
> wouldn't classify NeXT computers as obsolete.  There is still a bit of 
> activity surrounding them:
> 
> http://www.nextcomputers.org/
> http://www.nextcomputers.org/forums/
> 
> Plus, NeXT is a classic.

Sure.  And MSDOS was a classic.  And Version 7 unix was a classic.
And Atari and Amiga were classics.   But it's a good bet that no one is
running the CVS development version of gnuplot on them.

> I can understand not wanting to have bits of "ifdef NEXT" in the main 
> code, though.  

The NeXT conditionals in the core code were work-arounds for NeXT
compiler (gcc 3.2) and library deficiencies at that time.   From the comments,
I bet they were already unneeded by 2003 (gcc 3.3) at the very latest.   

> Looking at what was removed, I see there is this 
> init_terminal() routine that has me wondering why there are so many 
> pre-process conditionals.  
> For example:
> 
> #ifdef X11
> #ifdef QTTERM
> #ifdef WXWIDGETS
> > are not operating systems, they are basically terminals.
> Can't these bits of code be placed in the associated terminal files?

Um, no.  This is the routine that determines the default terminal
when the program is first entered.  Obviously you can't call into that
terminal before you have figured out what it is.  And certainly you
cannot call into it if it wasn't configured into the current binary.

	Ethan



> All it would 
> take is to change the name of of init_terminal() to 
> init_terminal_common() and then each of the terminals would have
> 
> init_terminal()
> {
>      if (term_name == (char *) NULL)
>          term_name = "qt";
> 
>      init_terminal_common();
> }
> 
> or something similar.  That's the same as an inheritance OOP concept.
> 
> Dan

Why remove NeXT support code?

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

I noticed that the subdirectory for the NeXT code has been removed.  I 
wouldn't classify NeXT computers as obsolete.  There is still a bit of 
activity surrounding them:

http://www.nextcomputers.org/
http://www.nextcomputers.org/forums/

Plus, NeXT is a classic.

I can understand not wanting to have bits of "ifdef NEXT" in the main 
code, though.  Looking at what was removed, I see there is this 
init_terminal() routine that has me wondering why there are so many 
pre-process conditionals.  For example:

#ifdef X11
#ifdef QTTERM
#ifdef WXWIDGETS

are not operating systems, they are basically terminals.  Can't these 
bits of code be placed in the associated terminal files?  All it would 
take is to change the name of of init_terminal() to 
init_terminal_common() and then each of the terminals would have

init_terminal()
{
     if (term_name == (char *) NULL)
         term_name = "qt";

     init_terminal_common();
}

or something similar.  That's the same as an inheritance OOP concept.

Dan