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

Bug in image code ?

[V. <gae...@no...>]

    I have found a strange behaviour of the image code.=20
    Here is a minimal example :

set xrange [-10:137]
set yrange [-10:157]

unset colorbox
plot 'blutux.rgb' binary array=3D128x128 flip xy \
format=3D'%uchar%uchar%uchar' every 64:16 using ($1+$2+$3) with image


With the standard terminal drivers (x11, post, png) this works without a
flaw, but while working on the povray terminal, on the image code, I note=
d
that corner[0].x ends up being negative ! But it is a unsigned int !!
The other terminals use it by calling it "(int) corner[0].x", thus
forcing the conversion to a negativ integer. However if I put a=20
"fprintf(gpoutfile, "corner[0].x : %u\n",corner[0].x)" I get a
ridiculously high value printed. Printing it as an integer solves the
problem, and this is how I worked around this.
    I suspect this problem is lying around in other places (I think I
might have seen it elsewhere, but it is hard to trick gnuplot into
making a negative value for a coordinate). Maybe those "(int)" casts in
many of the terminal drivers are just hiding more bug.
    I just had a look at the way the post terminal calls this :
line 3777 : fprintf(gppsfile, "%d %d translate\n", corner[0].x, corner[0]=
.y);

    Why %d and not %u ?

	I am wrong or is there a problem here ? Maybe these should not
be unsigned ints, but ints ? Checking for there sign seems a bit
complicated.

--
    Ga=EBl

Re: historysize

[Robert H. <en...@no...>]

On Tue, 2005-08-16 at 10:06 -0700, Ethan Merritt wrote:
> On Tuesday 16 August 2005 09:58 am, Robert Hart wrote:
> > On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote:
> > 
> > > That works, or would if you put parens around the expression:
> > >     set pm3d
> > >     splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines
> > > 
> > 
> > Are you sure? This just gives: undefined function rgb.
> 
> I assumed that "rgb" was a user-defined function that assigned
> an rgb color on the basis of 3D coords x, y, and z.

Maybe I'm missing something really obvious here? I don't understand what
you mean by "assigned an rgb color". How could I make a function return
an rgb colour?

I want to plot my data such that the colour of each point is defined by:
r=x
g=y
b=z

Now as I understand it, rgb(some colour specifier) is the gnuplot way of
specifying an arbitrary colour as in:

plot sin(x) lc rgb("salmon")

or

plot sin(x) lc rgb("#123456")

now clearly the colorspec should support colours specified as three
colour components, as in:

plot sin(x) lc rgb(0.1, 0.2, 0.3)

although I realise it doesn't.

So to me, one of:

splot "data" using 1:2:3 lc rgb(x,y,z)

or

splot "data" using 1:2:3:(rgb($1,$2,$3)) lc variable

or some other variant should work.

To make it easy, I have calculated the hex colour value in my data file
(column 5), and am willing to accept that there maybe some way to write
a function which does some kind of string concatenation magic to acheive
the same. Whatever.


Specifically what I'm trying to do is visualise the gamut of colours
used in an image file, such as a photo. I used Imagemagick to quantise
the number of discrete colours down to a more manageable level, and then
for each unique colour count how many pixels are of each colour.

I then want to visualise this in 3D by plotting a point at
(x,y,z)=(r,g,b) with pointsize log(count) and colour (r,g,b)=(r,g,b)

err... I'm not sure how else to explain.


Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

GNUPlot frontends page (addition)

[John S. <sp...@ly...>]

Hello,

Please consider my program PlotDrop for inclusion in the list of GNUPlot
frontends.  Information about it is below.

Regards,
John

PlotDrop
========
 A minimal GNOME frontend to GNUPlot.
 jc...@ic...
 http://icculus.org/~jcspray/plotdrop/

PlotDrop is designed for quick simple visualisation of 2D
data series.  It is not intended to encompass anywhere near
the full capabilities of GNUPlot.

PlotDrop is intended to be used in tandem with an external
filesystem browser such as GNOME's nautilus or KDE's konqueror.
Files containing data are added by dragging them from the
browser to the file list.

Re: gnuplot syntax (was: historysize)

[V. <gae...@no...>]

On Tue, Aug 16, 2005 at 07:17:28PM +0200, Juergen Wieferink wrote:
> I don't feel comfortable with gnuplot syntax.

    I don't mind it, but I know many skilled computer users who don't
like gnuplot because they claim that they cannot understand its syntax,
and therefore forget it. I couldn't pin point what was wrong with it,
though.

--
    Ga=EBl

gnuplot syntax (was: historysize)

[Juergen W. <wie...@fr...>]

On Tuesday 16 August 2005 17:57 Robert Hart wrote:
> [...], I think the problem is more a case of
> how clearly we define the syntax.
>
> Option 1. Variables take precedence over keywords.
> This would seem to make sense for the "backward compatibility" point of
> view you discuss above. Once a variable with the same name has been
> defined, it is used in preference.
>
> Option 2. Keywords take precedence over variables.
>
> Option 3. Precedence is irrelevant because:
>
> Option 3a. All keywords are reserved.
> Attempts to assign to a keyword variable would fail. This would break
> existing scripts in some cases, but make it very obvious how to fix
> them. Would require the parser to have a definite list of keywords,
> which is a long way off how it works at present.
>
> Option 3b. Variables made syntactically obvious (e.g. $x instead of x
> (like perl or bash).

Nice overview.  You might want to have a look at 

  RFE #1249742 "[syntax] optional expressions".

It's my trial to implement Option 2.  It turns out to be quite a lot
of work.  Option 1 could probably be implemented by little hacks
into equals() and almost_equals().  Option 3a is simply impossible
because of all the short cuts which form valid key words.  Consider

gnuplot> p "file" u 1:2 w l

And option 3b (as option 1) would break backward compatibility at
least once.  If such a step would be done, I'd strongly suggest to
think about a complete redesign of the syntax and the parser.

I don't feel comfortable with gnuplot syntax.  A simple example:
What does an empty "set" statement do?  Consider e.g. "set output",
"set pm3d" and "set label".


Juergen

Re: historysize

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

On Tuesday 16 August 2005 09:58 am, Robert Hart wrote:
> On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote:
> 
> > That works, or would if you put parens around the expression:
> >     set pm3d
> >     splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines
> > 
> 
> Are you sure? This just gives: undefined function rgb.

I assumed that "rgb" was a user-defined function that assigned
an rgb color on the basis of 3D coords x, y, and z.

If you meant something else entirely, then please explain.


 
> I even resorted to scanning through the source, but AFAICT the colour
> for a data series is defined only once, when the plot command is parsed,
> but before the data file is read. 
> 
> e.g. I have the data below, where the columns are r,g,b,frequency, and
> colorname
> 
> I would like to plot "rgb space" such that preferably each point is
> located at (r,g,b), sized according to the frequency, and coloured to
> match the original colour.
> 
> splot "data" using 1:2:3:4 with points pointsize variable
> 
> gets me most of the way there, but the colour remains elusive.


I still don't understand what the function rgb() is expected to do,
but if you provide the function then the following command will
plot with color generated by the rgb() function and pointsize
taken from column 4   (tested; works here):

  set pm3d
  splot "data" using 1:2:3:(rgb($1,$2,$3)):4 with points lt palette ps variable







> I would 
> be willing to sacrifice the sizing of points to get the colours right
> (or overlay coloured blobs on scaled points for example)
> 
> 36, 33, 26, 47, #24211A
> 44, 32, 27, 7, #2C201B
> 53, 35, 29, 18, #35231D
> 89, 39, 27, 9, #59271B
> 80, 44, 38, 12, #502C26
> 108, 54, 42, 10, #6C362A
> 95, 58, 68, 5, #5F3A44
> 118, 68, 54, 9, #764436
> 115, 78, 76, 6, #734E4C
> 138, 54, 32, 13, #8A3620
> 144, 78, 50, 8, #904E32
> 163, 86, 42, 9, #A3562A
> 181, 110, 52, 17, #B56E34
> 153, 103, 87, 12, #996757
> 175, 116, 79, 7, #AF744F
> 194, 122, 83, 12, #C27A53
> 155, 124, 131, 4, #9B7C83
> 157, 132, 122, 5, #9D847A
> 187, 133, 84, 11, #BB8554
> 185, 139, 109, 11, #B98B6D
> 196, 134, 62, 14, #C4863E
> 201, 143, 79, 17, #C98F4F
> 203, 151, 88, 20, #CB9758
> 202, 154, 103, 16, #CA9A67
> 201, 150, 113, 13, #C99671
> 211, 162, 92, 53, #D3A25C
> 207, 163, 114, 51, #CFA372
> 213, 166, 104, 49, #D5A668
> 214, 170, 119, 45, #D6AA77
> 221, 178, 123, 64, #DDB27B
> 227, 183, 124, 40, #E3B77C
> 177, 156, 154, 13, #B19C9A
> 205, 152, 137, 14, #CD9889
> 213, 158, 161, 7, #D59EA1
> 207, 168, 142, 20, #CFA88E
> 214, 172, 133, 34, #D6AC85
> 220, 180, 135, 65, #DCB487
> 220, 182, 150, 49, #DCB696
> 216, 184, 168, 21, #D8B8A8
> 225, 174, 147, 16, #E1AE93
> 227, 186, 136, 43, #E3BA88
> 227, 188, 150, 50, #E3BC96
> 227, 189, 164, 46, #E3BDA4
> 201, 188, 194, 4, #C9BCC2
> 233, 194, 139, 56, #E9C28B
> 234, 198, 153, 73, #EAC699
> 241, 204, 156, 48, #F1CC9C
> 235, 201, 167, 52, #EBC9A7
> 240, 208, 175, 42, #F0D0AF
> 234, 203, 181, 28, #EACBB5
> 238, 210, 181, 15, #EED2B5
> 239, 215, 185, 25, #EFD7B9
> 241, 206, 167, 19, #F1CEA7
> 243, 211, 171, 84, #F3D3AB
> 245, 215, 184, 104, #F5D7B8
> 214, 202, 201, 6, #D6CAC9
> 235, 213, 202, 23, #EBD5CA
> 247, 220, 195, 51, #F7DCC3
> 250, 229, 201, 108, #FAE5C9
> 252, 235, 214, 36, #FCEBD6
> 253, 241, 220, 25, #FDF1DC
> 249, 235, 229, 19, #F9EBE5
> 254, 244, 229, 25, #FEF4E5
> 255, 255, 255, 1204, #FFFFFF
> 
> 

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

Re: historysize

[Robert H. <en...@no...>]

On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote:

> That works, or would if you put parens around the expression:
>     set pm3d
>     splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines
> 

Are you sure? This just gives: undefined function rgb.

I even resorted to scanning through the source, but AFAICT the colour
for a data series is defined only once, when the plot command is parsed,
but before the data file is read. 

e.g. I have the data below, where the columns are r,g,b,frequency, and
colorname

I would like to plot "rgb space" such that preferably each point is
located at (r,g,b), sized according to the frequency, and coloured to
match the original colour.

splot "data" using 1:2:3:4 with points pointsize variable

gets me most of the way there, but the colour remains elusive. I would
be willing to sacrifice the sizing of points to get the colours right
(or overlay coloured blobs on scaled points for example)

36, 33, 26, 47, #24211A
44, 32, 27, 7, #2C201B
53, 35, 29, 18, #35231D
89, 39, 27, 9, #59271B
80, 44, 38, 12, #502C26
108, 54, 42, 10, #6C362A
95, 58, 68, 5, #5F3A44
118, 68, 54, 9, #764436
115, 78, 76, 6, #734E4C
138, 54, 32, 13, #8A3620
144, 78, 50, 8, #904E32
163, 86, 42, 9, #A3562A
181, 110, 52, 17, #B56E34
153, 103, 87, 12, #996757
175, 116, 79, 7, #AF744F
194, 122, 83, 12, #C27A53
155, 124, 131, 4, #9B7C83
157, 132, 122, 5, #9D847A
187, 133, 84, 11, #BB8554
185, 139, 109, 11, #B98B6D
196, 134, 62, 14, #C4863E
201, 143, 79, 17, #C98F4F
203, 151, 88, 20, #CB9758
202, 154, 103, 16, #CA9A67
201, 150, 113, 13, #C99671
211, 162, 92, 53, #D3A25C
207, 163, 114, 51, #CFA372
213, 166, 104, 49, #D5A668
214, 170, 119, 45, #D6AA77
221, 178, 123, 64, #DDB27B
227, 183, 124, 40, #E3B77C
177, 156, 154, 13, #B19C9A
205, 152, 137, 14, #CD9889
213, 158, 161, 7, #D59EA1
207, 168, 142, 20, #CFA88E
214, 172, 133, 34, #D6AC85
220, 180, 135, 65, #DCB487
220, 182, 150, 49, #DCB696
216, 184, 168, 21, #D8B8A8
225, 174, 147, 16, #E1AE93
227, 186, 136, 43, #E3BA88
227, 188, 150, 50, #E3BC96
227, 189, 164, 46, #E3BDA4
201, 188, 194, 4, #C9BCC2
233, 194, 139, 56, #E9C28B
234, 198, 153, 73, #EAC699
241, 204, 156, 48, #F1CC9C
235, 201, 167, 52, #EBC9A7
240, 208, 175, 42, #F0D0AF
234, 203, 181, 28, #EACBB5
238, 210, 181, 15, #EED2B5
239, 215, 185, 25, #EFD7B9
241, 206, 167, 19, #F1CEA7
243, 211, 171, 84, #F3D3AB
245, 215, 184, 104, #F5D7B8
214, 202, 201, 6, #D6CAC9
235, 213, 202, 23, #EBD5CA
247, 220, 195, 51, #F7DCC3
250, 229, 201, 108, #FAE5C9
252, 235, 214, 36, #FCEBD6
253, 241, 220, 25, #FDF1DC
249, 235, 229, 19, #F9EBE5
254, 244, 229, 25, #FEF4E5
255, 255, 255, 1204, #FFFFFF


-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: historysize

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

Theo Hopman wrote:
> Ga=EBl Varoquaux wrote:
>=20
>> On Tue, Aug 16, 2005 at 12:31:18AM -0500, Daniel J Sebald wrote:
>>
>>> The data file "using" format is like this; 0 means point, -1 means=20
>>> line number, -2 means index number.  I find that not user friendly.
>>
>>
>>     Agreed. I prefer words. And I have often heard users of gnuplot
>> complain about such numbers that they cannot remember.
>=20
>=20
> I've no opinion on the merits of a keyword or number in setting the=20
> history size, since it seems to me that this is something that's set=20
> once (in .gnuplot or equivalent) and then forgotten.

But isn't that an argument for having a sensical keyword?  Once in a blue=
 moon the user has to set this and thinks "Hmm, I want this to be unlimit=
ed, what do I have to enter to make the history size _unlimited_?"  My po=
int is that a natural keyword is easier to understand.

> For more frequently=20
> used options (especially `using`) numbers are a good thing IMO, for the=
=20
> following reasons:
> - I personally forget keywords more easily than numbers
> - numbers are generally shorter than keywords =3D less typing

In the case of 'using':

0   or  p$oint
-1  or  l$ine
-2  or  i$ndex

'l' and 'i' are less typing than '-1' and '-2'.  AND, I'd bet on average =
that people's skill at type 'p', 'l', and 'i' are much better than type 0=
, -1, -2.

> - variables can be used in place of numbers

[Hans' point]

> Now imagine somebody who just happens to have an old gnuplot script
> that defines all of the above variables equals to 5.  Or to 1/0, for th=
at
> matter, or 1.0e300.

My first question is Why are you defining "unlimited" to mean 5?  Second =
question is how popular is the redefining of keywords?  I've not made muc=
h use of defining stuff in gnuplot...  By that thinking, gnuplot is forev=
er stuck with the current syntax and cannot add any more keywords, hence =
no new features, because someone may have defined any given keyword in th=
e past equal to 1234567.

> - numbers are the same across all languages

So people should learn just a subset of the keywords like 'using', 'with'=
, 'format' but not be expected to know 'point', 'line', 'index', 'unlimit=
ed', 'infinity'?

Dan

Re: historysize

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

On Tuesday 16 August 2005 08:57 am, Robert Hart wrote:
> 
> One thing I'd like to see is better support for using plot variables in
> other places of the plot command. e.g. I was trying to do something like
> this:
> splot "data.txt" lc rgb(x,y,z)
> or
> splot "data.txt" using 1:2:3:rgb($1,$2,$3) lc variable

That works, or would if you put parens around the expression:
    set pm3d
    splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines


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

Re: Povray terminal update

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

Daniel J Sebald wrote:
> Very good start Ga=EBl.  The "set pm3d at bstbst (funny combination, on=
ly=20
> for screen or postscript)" example is a bit off.  Also, in "image.dem" =

> your gray scale looks to be off a bit.  (Color scale looks about=20
> right.)  Take a look at "As with 3d color surfaces, a color box may be =

> added to the plot".  Your scale going from 0 to 256 appears to not have=
=20
> much white or not very light near the top end.  Furthermore, if you loo=
k=20
> at Tux, he's very light colored compared to the color box scale. =20
> Something is off I think.

That would almost certainly be a problem of gamma correction being=20
applied/reverted the wrong number of times (off by one, typically, but=20
worse things have happened...) in total.  POVray almost certainly=20
assumes linear RGB, whereas gnuplot would be used to native screen RGBs.

Re: Povray terminal update

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

Ga=EBl Varoquaux wrote:
>     I have made good progress on the povray terminal. I have updated it
> on the web :=20
> http://www.eleves.ens.fr/home/varoquau/gnuplot/povray.trm
>=20
>     You can also find an automatically generated list of demo files and
> output at :
> http://www.eleves.ens.fr/home/varoquau/gnuplot/index.html
>=20
>     This was automatically generated using a modified version of the
> webify script. My perl skills are really horrible, so some files did no=
t
> compile properly. This does not always mean that the povray terminal
> fails on them (I checked manually in certain case).

Very good start Ga=EBl.  The "set pm3d at bstbst (funny combination, only=
 for screen or postscript)" example is a bit off.  Also, in "image.dem" y=
our gray scale looks to be off a bit.  (Color scale looks about right.)  =
Take a look at "As with 3d color surfaces, a color box may be added to th=
e plot".  Your scale going from 0 to 256 appears to not have much white o=
r not very light near the top end.  Furthermore, if you look at Tux, he's=
 very light colored compared to the color box scale.  Something is off I =
think.

Looks good overall, though.

Dan

Re: historysize

[Robert H. <en...@no...>]

On Tue, 2005-08-16 at 16:31 +0200, Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> > like when negative numbers have special meaning.  The data file "using" 
> > format is like this; 0 means point, -1 means line number, -2 means index 
> > number.  I find that not user friendly.  How do others feel?
> 
> While it may appear more user-friendly to use names instead of numbers, 
> at least in the case of existing syntax, that's a risky change to make.
> 
> > I'd suggest "unlimited", "infinity", "infinite" rather than -1.
> 
> Now imagine somebody who just happens to have an old gnuplot script
> that defines all of the above variables equals to 5.  Or to 1/0, for 
> that matter, or 1.0e300.

Well, ignoring for a second the shear unlikelihood of somebody loading
an old gnuplot script that used a variable name at a position that would
be ambiguous in the new version, I think the problem is more a case of
how clearly we define the syntax.

Option 1. Variables take precedence over keywords.
This would seem to make sense for the "backward compatibility" point of
view you discuss above. Once a variable with the same name has been
defined, it is used in preference. 

Option 2. Keywords take precedence over variables. 

Option 3. Precedence is irrelevant because:

Option 3a. All keywords are reserved.
Attempts to assign to a keyword variable would fail. This would break
existing scripts in some cases, but make it very obvious how to fix
them. Would require the parser to have a definite list of keywords,
which is a long way off how it works at present. 

Option 3b. Variables made syntactically obvious (e.g. $x instead of x
(like perl or bash).


One thing I'd like to see is better support for using plot variables in
other places of the plot command. e.g. I was trying to do something like
this:
splot "data.txt" lc rgb(x,y,z)
or
splot "data.txt" using 1:2:3:rgb($1,$2,$3) lc variable

The current syntax seems to support whatever the needs were of the
person who wrote each plot type.

In general however, I'm against the introduction of new "language
features" into gnuplot. I think in many cases the better approach is to
generate gnuplot scripts programmatically.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: crash in write_history_n

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

Bastian Maerkisch wrote:
> The version of write_history_n() using gnuplot's own version
> of readline issues an int_error() when it cannot open the
> history file for saving. As it is now called at program exit
> (via atexit() or similar) it can no longer
> bail_to_command_line(), which int_error() does. This causes
> a segfault in that case. (Tested ;-) on a Win98 system without
> %GNUPLOT% env. variable set.)
> So this should be an int_warn(). 

I'm not convinced that this is the right approach to the problem.
How about we make bail_to_command_line() a no-op if the command line is 
no longer there (i.e. test a global flag)?

Re: historysize

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

Daniel J Sebald wrote:
> like when negative numbers have special meaning.  The data file "using" 
> format is like this; 0 means point, -1 means line number, -2 means index 
> number.  I find that not user friendly.  How do others feel?

While it may appear more user-friendly to use names instead of numbers, 
at least in the case of existing syntax, that's a risky change to make.

> I'd suggest "unlimited", "infinity", "infinite" rather than -1.

Now imagine somebody who just happens to have an old gnuplot script
that defines all of the above variables equals to 5.  Or to 1/0, for 
that matter, or 1.0e300.

Re: historysize

[Theo H. <th...@ph...>]

Ga=EBl Varoquaux wrote:
> On Tue, Aug 16, 2005 at 12:31:18AM -0500, Daniel J Sebald wrote:
>=20
>> The data file "using"=20
>>format is like this; 0 means point, -1 means line number, -2 means inde=
x=20
>>number.  I find that not user friendly.
>=20
>     Agreed. I prefer words. And I have often heard users of gnuplot
> complain about such numbers that they cannot remember.

I've no opinion on the merits of a keyword or number in setting the=20
history size, since it seems to me that this is something that's set=20
once (in .gnuplot or equivalent) and then forgotten. For more frequently=20
used options (especially `using`) numbers are a good thing IMO, for the=20
following reasons:
- I personally forget keywords more easily than numbers
- numbers are generally shorter than keywords =3D less typing
- variables can be used in place of numbers
- numbers are the same across all languages

THeo

Povray terminal update

[V. <gae...@no...>]

    I have made good progress on the povray terminal. I have updated it
on the web :=20
http://www.eleves.ens.fr/home/varoquau/gnuplot/povray.trm

    You can also find an automatically generated list of demo files and
output at :
http://www.eleves.ens.fr/home/varoquau/gnuplot/index.html

    This was automatically generated using a modified version of the
webify script. My perl skills are really horrible, so some files did not
compile properly. This does not always mean that the povray terminal
fails on them (I checked manually in certain case).

    As you can see the povray terminal is almost a fully featured
gnuplot terminal. I have yet add the support for 'set palette
maxcolors', nor even have I looked into that :->, but I do not think it
is a major difficulty.

    I would appreciate if other people could have a look at the code,
and report any bugs they find, I would like to move on to the 3D code.

    I will be gone on holidays and September means, unfortunately, the
start of the teaching period, so I will be quite short on time, but I
think that I will want to start hacking gnuplot's code to add 3D. Any
suggestions on the way to proceed with this are welcomed.
    I would also like some advise on how to work collectively on
gnuplot's code, as I want to be able to work closely with others (Robert
?) on that.
    This seems to me as a huge project but I think we really must go
ahead and do it.

--
    Ga=EBl

Re: historysize

[V. <gae...@no...>]

On Tue, Aug 16, 2005 at 12:31:18AM -0500, Daniel J Sebald wrote:
>  The data file "using"=20
> format is like this; 0 means point, -1 means line number, -2 means inde=
x=20
> number.  I find that not user friendly.

    Agreed. I prefer words. And I have often heard users of gnuplot
complain about such numbers that they cannot remember.

--
    Ga=EBl

crash in write_history_n

[Bastian M. <bma...@we...>]

The version of write_history_n() using gnuplot's own version
of readline issues an int_error() when it cannot open the
history file for saving. As it is now called at program exit
(via atexit() or similar) it can no longer
bail_to_command_line(), which int_error() does. This causes
a segfault in that case. (Tested ;-) on a Win98 system without
%GNUPLOT% env. variable set.)
So this should be an int_warn(). The attached patch fixes that.

Greetings, Bastian

Re: Tics, minor tics, labels...

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

Ethan A Merritt wrote:
> Two questions:
> 
> 1) The documentation says you can assign labels to minor tics
>       set xtics ("Major" x1 0, "Minor" x2 1, ...)
>    but the code explicitly ignores minor tic labels.  Was there any
>    reason why?  You can always give an empty string if you don't
>    want a label there. I propose that if the user specifies a label,
>    we should print it.

Might as well.  Why limit flexibility?  And it may be easier to have it than to disallow it.

> 2) I am inclined to apply the patchset currently listed as #1104018,
>    having worked with the original proposer, Eddie Kohler, to pare it
>    down to a very simple modification to the existing code.
>    In a nutshell, it now adds a keyword "include" to the 'set <xyz>tics'
>    command. In the presense of this keyword, the command does
>    not clear the existing list of user-specified tics (if any).
>    So
> 	set xtics auto
> 	set xtics include ("Pi" pi 0)
> 	set xtics include ("2Pi" pi*2 0)
>
>    Please speak up if you have any objections or counter-proposals.
>    Also please suggest a better name for the keyword if you can think
>    of one.  "add" is the another possibility on the table at the
>    moment.

"with" ?  e.g.,

set xtics with ("Pi" pi 0)

Dan

Re: historysize

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

Ethan A Merritt wrote:
> On Friday 12 August 2005 01:55 am, Petr Mikulik wrote:
> 
>>4. "set historysize -1" would set historysize to unlimited.

I've no strong opinions on historysize other than using "-1" as special meaning.  It probably is easy from the parser's standpoint, but I don't like when negative numbers have special meaning.  The data file "using" format is like this; 0 means point, -1 means line number, -2 means index number.  I find that not user friendly.  How do others feel?

I'd suggest "unlimited", "infinity", "infinite" rather than -1.

Dan

Re: Tics, minor tics, labels...

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

On Sunday 14 August 2005 03:38 pm, you wrote:
> On Sat, 13 Aug 2005, Ethan A Merritt wrote:
> > 	set xtics auto
> > 	set xtics include ("Pi" pi 0)
> > 	set xtics include ("2Pi" pi*2 0)
> >    will auto-generate tics and include specific labels at pi and 2pi.
>
> Similar commands are things like "set label", which IIRC behaves in a
> much different way - no extra keyword is needed. Of course, using the
> same sort of syntax as set label would break any existing scripts that
> contain multiple explicit tics statements, which I imagine are
> relatively uncommon.

Yeah. This is where the goal of backwards compatibility runs headlong
into the goal of fixing design bugs.  I think it is a bug that successive
user tic specifications are not cumulative.  But that is not nearly so 
clear for the case of switching between automatic and manual tic placement.
If we were to make the default behaviour cumulative, then we would have to
add a mechanism to explicitly turn *off* the previous tic scheme before
selecting a new one:
	set xtics auto
	plot "foo"
	set xtics noauto
	set xtics ("Manual placement" ...)
	replot

That would definitely break backwards compatibility.


> b) Is it actually the "verb" that needs to be changed, as in:
> unset xtics
> set xtics auto
> add xtics ("pi" pi 0)
> add xtics ("2pi" 2*pi 0)
> show xtics

I like that idea, but it's too radical a change to the syntax.
If we were to introduce "add" as a major command, people
would expect to be able to use it for other purposes as well.

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

Re: Tics, minor tics, labels...

[Robert H. <en...@no...>]

On Sat, 13 Aug 2005, Ethan A Merritt wrote:

> 	set xtics auto
> 	set xtics include ("Pi" pi 0)
> 	set xtics include ("2Pi" pi*2 0)
>    will auto-generate tics and include specific labels at pi and 2pi.
>    Omitting the keyword retains the current behaviour; each
>    command supersedes the previous ones.
> 
>    Please speak up if you have any objections or counter-proposals.
>    Also please suggest a better name for the keyword if you can think
>    of one.  "add" is the another possibility on the table at the
>    moment.

I suppose the other way of looking at is:

a) Is this a syntax that could consistenly be applied to other commands
should this kind of "addition" behaviour be applicable to them. 

Similar commands are things like "set label", which IIRC behaves in a much
different way - no extra keyword is needed. Of course, using the same sort
of syntax as set label would break any existing scripts that contain
multiple explicit tics statements, which I imagine are relatively
uncommon.

b) Is it actually the "verb" that needs to be changed, as in:
unset xtics
set xtics auto
add xtics ("pi" pi 0)
add xtics ("2pi" 2*pi 0)
show xtics

This is, I guess, more akin to the plot and replot case in the current
syntax. I'm guessing (although I haven't really looked at the code) that
this would be more trouble to implement.

Rob


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: historysize

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

> I am working on a patch to have gnuplot compiled with libedit from
> NETBSD. So could the #ifdef GNUPLOT_HISTORY statements be left in
> there? This would save us some very long #ifdefs ...

If you manage to make a patch for removing that #ifdef first, then there is 
no need for them.

>>> 2. By default, the history file is not read. It can be switched on in
>>>    .gnuplot by "set historysize"
>
> How would the environment variable 'GNUPLOT_HISTORY_SIZE' fit in
> there? Could this be treated like "set historysize" in .gnuplot?

Should it be set before or after reading .gnuplot?

> Wouldn't is make sense to limit the size of 'in-memory' history
> to historysize as well? But that wouldn't work with your

is this necessary?

> approach. So how about seperate commands for enabling/disabling
> saving of history? E.g. sth. like "set history on/off".

Good idea. That GNUPLOT_HISTORY could contain "no" in this case.

---
PM

Re: historysize

[Bastian M. <bma...@we...>]

Ethan A Merritt wrote:
 > On Friday 12 August 2005 01:55 am, Petr Mikulik wrote:
 >
 >>I'm bit surprised what "unset historysize" is doing. It sets historysize
 >>to unlimited, not suppressing writing the history file.
 >>
 >>I propose the following changes:
 >>1. The code for history file is always compiled in (thus no need to
 >>    --enable-history-file nor to modify dozen of files in config/).

I am working on a patch to have gnuplot compiled with libedit from
NETBSD. So could the #ifdef GNUPLOT_HISTORY statements be left in
there? This would save us some very long #ifdefs ...

 >>2. By default, the history file is not read. It can be switched on in
 >>    .gnuplot by "set historysize"

How would the environment variable 'GNUPLOT_HISTORY_SIZE' fit in
there? Could this be treated like "set historysize" in .gnuplot?

 >>3. Switching off writing/reading history file: "unset historysize"
 >>4. "set historysize -1" would set historysize to unlimited.
 >
 >
 > That all sounds reasonable.
 >
 >
 >>Ideas?
 >
 >
 > What does "set historysize 0" do?
 >

Wouldn't is make sense to limit the size of 'in-memory' history
to historysize as well? But that wouldn't work with your
approach. So how about seperate commands for enabling/disabling
saving of history? E.g. sth. like "set history on/off".

Btw. the gnuplot readline code already does use historysize to
limit the size of history in memory, whereas (as far is can tell)
the GNU readline version does not. There it's only used for saving.

Bastian

Tics, minor tics, labels...

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

Two questions:

1) The documentation says you can assign labels to minor tics
      set xtics ("Major" x1 0, "Minor" x2 1, ...)
   but the code explicitly ignores minor tic labels.  Was there any
   reason why?  You can always give an empty string if you don't
   want a label there. I propose that if the user specifies a label,
   we should print it.

2) I am inclined to apply the patchset currently listed as #1104018,
   having worked with the original proposer, Eddie Kohler, to pare it
   down to a very simple modification to the existing code.
   In a nutshell, it now adds a keyword "include" to the 'set <xyz>tics'
   command. In the presense of this keyword, the command does
   not clear the existing list of user-specified tics (if any).
   So
	set xtics auto
	set xtics include ("Pi" pi 0)
	set xtics include ("2Pi" pi*2 0)
   will auto-generate tics and include specific labels at pi and 2pi.
   Omitting the keyword retains the current behaviour; each
   command supersedes the previous ones.

   Please speak up if you have any objections or counter-proposals.
   Also please suggest a better name for the keyword if you can think
   of one.  "add" is the another possibility on the table at the
   moment.


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