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

Re: gnuplot segfaults on keyboard interaction

[Tatsuro M. <tma...@ya...>]

Hello

--- Ethan Merritt  wrote:

> Wait a moment.  Benjamin's original bug report said:
> > I see this on windows platform using the windows terminal 
> > and only for the 4.5.0 branch, *not* for the 4.4.0 branch
> 
> I was able to replicate this in linux, again only in the 4.5 branch.
>  
> Are you also seeing this segfault in 4.4.0?


Perhaps I have misled of the role of the SF buf tracker.  The decription of SF buf tracker is the
current gnuplot (4.4).  The 4.5 branch is development so that it is to be discussed in the beta ML.

On 4.4, as you said, we do not see the problem.

Sorry for my carelessness.

Regards

Tatsuro


--------------------------------------
VANCOUVER 2010 PARALYMPIC GAMES News
http://pr.mail.yahoo.co.jp/para/

Re: gnuplot segfaults on keyboard interaction

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

On Tuesday 16 March 2010, Jürgen Wieferink wrote:
> Am Montag, 15. März 2010 15:24:39 schrieb Benjamin Lindner:
> > 
> > But I managed to (hopefully) track it down to :
> >  event_keypress()
> >  builtin_toggle_grid()
> >  do_string_replot()
> >  replotrequest()
> >  m_capture()  <- segfault
> > 
> > Here m_capture() is called with both the parameters "start" and "end" as -1
> >  which (not surprisingly) leads to problems as the array token[] is indexed
> >  with both start and end.
> > 
> > The problem is, that at the time replotrequest() is called from within
> >  do_string_replot(), c_token is -1 and num_token is zero (Why? because
> >  do_string_and_free() calls lf_pop(), which sets c_token=-1 and
> >  num_token=0).
> > 
> > But apparently replotrequest() assumes that neither is the case, instead it
> >  tries to read tokens where there are none.
> 
> A remarkably good bug report.  As far as I can see,
> do_string_replot() should not call a function which takes a look at
> the command line.  

I think that part is OK. The idea of the "replot" command is that you can
append a string to it.  do_string_replot first executes the old plot command,
then executes the extra string.

> I am surprised that this has not produced more problems so far.

Me too. But it seems to be a simple initialization failure.
When stepping through the arguments on a command line, the program
initializes c_token if the current argument is a file name but not
if the current argument is '-'.  The first time we do an lf_push(),
it pushes the initial value of c_token.  If that value is garbage,
then trouble ensues.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff -urp gnuplot/src/plot.c gnuplot-cvs/src/plot.c
--- gnuplot/src/plot.c  2010-03-14 11:52:45.000000000 -0700
+++ gnuplot-cvs/src/plot.c      2010-03-16 20:23:31.000000000 -0700
@@ -610,6 +610,7 @@ main(int argc, char **argv)

            } else if (strcmp(*argv, "-") == 0) {
                /* DBT 10-7-98  go interactive if "-" on command line */
+               c_token = 0;

                interactive = TRUE;
                /* will this work on all platforms? */
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


Tatsuro MATSUOKA <tma...@ya...> wrote >
> I think it is a bug to be reported.
> In the release note of gnuplot-4.4.0

Wait a moment.  Benjamin's original bug report said:
> I see this on windows platform using the windows terminal 
> and only for the 4.5.0 branch, *not* for the 4.4.0 branch

I was able to replicate this in linux, again only in the 4.5 branch.
 
Are you also seeing this segfault in 4.4.0?

Re: gnuplot segfaults on keyboard interaction

[Tatsuro M. <tma...@ya...>]

Hello

I think it is a bug to be reported.
In the release note of gnuplot-4.4.0
*************
Support
-------
Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055
*******************

So please report bug to the sf bug tracker in order to trace the bug easily afterwards.
The above note do not deny discussions on the beta ML, I believe.

Regards

Tatsuro 

--- J将舐gen Wieferink wrote:

> Am Montag, 15. Mセュ璽rz 2010 15:24:39 schrieb Benjamin Lindner:
> > 
> > But I managed to (hopefully) track it down to :
> >  event_keypress()
> >  builtin_toggle_grid()
> >  do_string_replot()
> >  replotrequest()
> >  m_capture()  <- segfault
> > 
> > Here m_capture() is called with both the parameters "start" and "end" as -1
> >  which (not surprisingly) leads to problems as the array token[] is indexed
> >  with both start and end.
> > 
> > The problem is, that at the time replotrequest() is called from within
> >  do_string_replot(), c_token is -1 and num_token is zero (Why? because
> >  do_string_and_free() calls lf_pop(), which sets c_token=-1 and
> >  num_token=0).
> > 
> > But apparently replotrequest() assumes that neither is the case, instead it
> >  tries to read tokens where there are none.
> 
> A remarkably good bug report.  As far as I can see,
> do_string_replot() should not call a function which takes a look at
> the command line.  I am surprised that this has not produced more
> problems so far.  I assume that part of replotrequest() belongs into
> replot_command().  Unfortunately, I do not have time to look deeper
> into this issue.
> 
> Juergen

Tatsuro wrote
>However gnuplot 4.5 on windows hangs even if one use
>gnuplot foo.gp -
> and press any key or mouse operation on the graph window.

>I think that it is a problem.

--------------------------------------
VANCOUVER 2010 PARALYMPIC GAMES News
http://pr.mail.yahoo.co.jp/para/

Re: gnuplot segfaults on keyboard interaction

[Jürgen W. <wie...@fr...>]

Am Montag, 15. März 2010 15:24:39 schrieb Benjamin Lindner:
> 
> But I managed to (hopefully) track it down to :
>  event_keypress()
>  builtin_toggle_grid()
>  do_string_replot()
>  replotrequest()
>  m_capture()  <- segfault
> 
> Here m_capture() is called with both the parameters "start" and "end" as -1
>  which (not surprisingly) leads to problems as the array token[] is indexed
>  with both start and end.
> 
> The problem is, that at the time replotrequest() is called from within
>  do_string_replot(), c_token is -1 and num_token is zero (Why? because
>  do_string_and_free() calls lf_pop(), which sets c_token=-1 and
>  num_token=0).
> 
> But apparently replotrequest() assumes that neither is the case, instead it
>  tries to read tokens where there are none.

A remarkably good bug report.  As far as I can see,
do_string_replot() should not call a function which takes a look at
the command line.  I am surprised that this has not produced more
problems so far.  I assume that part of replotrequest() belongs into
replot_command().  Unfortunately, I do not have time to look deeper
into this issue.

Juergen

Re: gnuplot segfaults on keyboard interaction

[Tatsuro M. <tma...@ya...>]

Hello

--- Ethan Merritt  wrote:

> I honestly don't know what the windows terminal does when you say "-persist".
> On other platforms, once the gnuplot program itself exits, you obviously cannot 
> interact with the display to do "replot" or "toggle grid" or anything else that
> requires reprocessing the input file or command.
> 

What Benjamin want to do is to be done not by
gnuplot -persist foo.gp
but by 
gnuplot foo.gp -

By
gnuplot foo.gp -
gnuplot goes to interactive mode and one can use command key like 'g' on the graph window.

However gnuplot 4.5 on windows hangs even if one use
gnuplot foo.gp -
 and press any key or mouse operation on the graph window.

I think that it is a problem.

As Benjamin stated, on 4.4, the hang up does not happen.

Regards

Tatsuro 




--------------------------------------
VANCOUVER 2010 PARALYMPIC GAMES News
http://pr.mail.yahoo.co.jp/para/

Re: key error in 2D plot line with color palette by hon fui lee

[hon f. l. <ho...@gm...>]

I finally got it. Here is the command

age = "20 21 22 23 24 25 26 ...." #add in more according to your taste
set palette rgbformulae 33,13,10
set cbrange [20:30]
color_age(n) = word(age,n)
title_x(n) = word(<sometitle>, n)
plot for [age=1:20] 'datafile.dat' index age-1 using 1:2 t
title_x(age) lc palette cb color_age(age)

Regards,
hon_fui


On Mon, Mar 15, 2010 at 3:39 PM, hon fui lee <ho...@gm...> wrote:
> OK, I understand the concept of key and curve point.
>
> How can it be done in iteration?
>
> Regards,
>
> On Mon, Mar 15, 2010 at 11:27 AM, sfeam (Ethan Merritt)
> <eam...@gm...> wrote:
>> On Sunday 14 March 2010, hon fui lee wrote:
>>> Tried your suggestion. The "lc palette Z" introduces error like " line
>>> XX: ';' expected".
>>> "lc Z" is OK but not as palette, discrete color instead. Same as "lc
>>> variable" Eg. of my Z value ranges from 0.105 to 0.331.
>>
>> I was not clear enough.  Please see "help colorspec"
>>
>> The idea is that the 'Z' in "lc palette Z" stands for either
>> "frac <value>" where <value> runs from 0 to 1 and represents
>> a sample on the current palette,  or "cb <value>" where
>> <value> is drawn from the range of the current colorbox.
>>
>>> Let me give you a better example. A study on a group of university
>>> student on their age and performance.
>>> Student A: Age 21
>>> Hour attending class subject 1= 10 hours : Score=70
>>> Hour attending class subject 2= 12 hours : Score=80
>>> .
>>> .
>>> .
>>> .
>>> Student B: Age 25
>>> Hour attending class subject 1= 10 hours : Score 55
>>> Hour attending class subject 2= 20 hours : Score 60
>>> .
>>> .
>>> .
>>> .
>>>
>>> Let plot hour attending class subject (x) vs score (y). Each curve is
>>> colored according to the age to see any trend.
>>
>> Fine.  So let's assume your student's ages run from 20 to 30.
>> Then we have
>>   set cbrange [20:30]
>>   plot 'student1' using ... with lines lc cb 21,
>>        'student2' using ... with lines lc cb 25,
>>                'student3' ...
>> and so on.
>>
>>> In my earliest post, notice linespoints give correct color and symbol
>>> according to the plot/key, just like the curve itself. Only the line
>>> color is wrong.
>>> If the plot can do color palette/gradient on the curve correctly(or
>>> may be incorrectly) why not the key?
>>
>> You have asked it to color the lines by z value.
>> Each point or line segment has a z value.
>> But what is the z value of the key?  It has none.
>>
>>        Ethan
>>
>>
>>> Thanks.
>>>
>>> On Thursday 11 March 2010 23:30:28 hon fui lee wrote:
>>> > I'm trying to do a 2D lines/linespoint plot with linecolor from 3rd
>>> > column as color palette.
>>> > All are OK except the key does not proper linecolor. See sample
>>> > command file and sample output (pdf).
>>> > I'm using gnuplot version 4.5 (development) on Windows.
>>> >
>>> > Is that a bug or feature? Thanks.
>>>
>>> I think it is a mis-expectation.
>>>
>>> Your lines happen to each have a constant Z value, which you can think of
>>> as a color value, so for your particular plot each entire line is a
>>> single color and it would make sense for the sample line segment in the
>>> key to be that same color.
>>>
>>> But how is gnuplot supposed to know this?  In general each point could
>>> have a different Z value and each line would have many segments with
>>> various colors.  Which of these colors would you put in the key?
>>>
>>> If you know in advance that each line has a constant Z value, maybe
>>> you can revise the plot command so that instead of
>>>    plot 'foo' using 1:2:3 lc palette
>>> you use
>>>    Z = constant_z_for_this_line
>>>    plot 'foo' using 1:2 lc palette Z
>>>
>>> For this you would have to read in the Z values before issuing the
>>> plot command.  That may or may not be possible in your particular
>>> plotting scenario.
>>>
>>>       Ethan
>>
>
>
>
> --
> hon_fui
>



-- 
hon_fui

Re: Yay! The 4.4 ship has been launched.

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik > wrote:


> Also there is typo 'of eadh runtime' => 'of each runtime'.

I also found it. In my 4.5(cvs) distribution, the corrected README.Windows is included.
Anyway thank you for informing me it.

Regards

Tatsuro

--------------------------------------
VANCOUVER 2010 PARALYMPIC GAMES News
http://pr.mail.yahoo.co.jp/para/

Re: Yay! The 4.4 ship has been launched.

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

> The Release Announcement, source tarball, and Windows binaries for
> version 4.4.0 are now on SourceForge.

This is great! Thanks to Ethan for the push for release!


> The below remained in the Readme.Windows in gp440win32.zip
> Note that this package does not support the wxt terminal.  If you
> The above should be deleted.
> This is a packaging mistake.

Ooops, my fault. I was editing Readme.Windows from both zip files before 
the merge but copied back not the final one.
Also there is typo 'of eadh runtime' => 'of each runtime'.

---
PM

Re: gnuplot segfaults on keyboard interaction

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

On Monday 15 March 2010 07:24:39 Benjamin Lindner wrote:
> I have encountered a nasty problem, namely gnuplot segfaulting if called with a script name and the persistent option and the user then using the terminal window interactively - specifically toggling grid via keyboard 'g'.
> 
> Ok, for the details, I see this on windows platform using the windows terminal and only for the 4.5.0 branch, *not* for the 4.4.0 branch.
> 
> I am using gnuplot as follows
> /path/to/gnuplot/wgnuplot -p foo.gp
> 
> where foo.gp simply sets terminal to windows and plots something in 2d like in
> 
>   set term windows
>   plot [0:2*pi] sin(x) with linespoints, cos(x) with linespoints
> 
> Now pressing "g" crashes gnuplot. 
> And the nasty part is, it does not always crash (I love those errors...)
> [...]

> I don't know where the actual problem lies here. Is it not allowed to call replotrequest() 
> when no tokens are available?

I honestly don't know what the windows terminal does when you say "-persist".
On other platforms, once the gnuplot program itself exits, you obviously cannot 
interact with the display to do "replot" or "toggle grid" or anything else that
requires reprocessing the input file or command.

	Ethan

gnuplot segfaults on keyboard interaction

[Benjamin L. <lin...@gm...>]

Hello list,

I have encountered a nasty problem, namely gnuplot segfaulting if called with a script name and the persistent option and the user then using the terminal window interactively - specifically toggling grid via keyboard 'g'.

Ok, for the details, I see this on windows platform using the windows terminal and only for the 4.5.0 branch, *not* for the 4.4.0 branch.

I am using gnuplot as follows
/path/to/gnuplot/wgnuplot -p foo.gp

where foo.gp simply sets terminal to windows and plots something in 2d like in

  set term windows
  plot [0:2*pi] sin(x) with linespoints, cos(x) with linespoints

Now pressing "g" crashes gnuplot. 
And the nasty part is, it does not always crash (I love those errors...)

But I managed to (hopefully) track it down to :
 event_keypress()
 builtin_toggle_grid()
 do_string_replot()
 replotrequest()
 m_capture()  <- segfault

Here m_capture() is called with both the parameters "start" and "end" as -1 which (not surprisingly) leads to problems as the array token[] is indexed with both start and end.

The problem is, that at the time replotrequest() is called from within do_string_replot(), c_token is -1 and num_token is zero (Why? because do_string_and_free() calls lf_pop(), which sets c_token=-1 and num_token=0).

But apparently replotrequest() assumes that neither is the case, instead it tries to read tokens where there are none. 

I don't know where the actual problem lies here. Is it not allowed to call replotrequest() when no tokens are available? Or should replotrequest() make sure that there are tokens available instead of blindly assuming it?

Besides, already replotrequest() accesses token[last_token] (before calling m_capture()) but last_token is -1 if num_tokens is 0 ( as it is the case! ). This makes size_t newlen contain a random number....

I can work around the segfault by the following change

--- a/src/util.c
+++ b/src/util.c
@@ -318,6 +321,9 @@
 void
 m_capture(char **str, int start, int end)
 {
+    if (start<0 || end<0)
+       return;
+
     int i, e;
     char *s;

but this is (I believe) the wrong place to fix the problem, as replotrequest still accesses token[-1]...

benjamin

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: key error in 2D plot line with color palette by hon fui lee

[hon f. l. <ho...@gm...>]

OK, I understand the concept of key and curve point.

How can it be done in iteration?

Regards,

On Mon, Mar 15, 2010 at 11:27 AM, sfeam (Ethan Merritt)
<eam...@gm...> wrote:
> On Sunday 14 March 2010, hon fui lee wrote:
>> Tried your suggestion. The "lc palette Z" introduces error like " line
>> XX: ';' expected".
>> "lc Z" is OK but not as palette, discrete color instead. Same as "lc
>> variable" Eg. of my Z value ranges from 0.105 to 0.331.
>
> I was not clear enough.  Please see "help colorspec"
>
> The idea is that the 'Z' in "lc palette Z" stands for either
> "frac <value>" where <value> runs from 0 to 1 and represents
> a sample on the current palette,  or "cb <value>" where
> <value> is drawn from the range of the current colorbox.
>
>> Let me give you a better example. A study on a group of university
>> student on their age and performance.
>> Student A: Age 21
>> Hour attending class subject 1= 10 hours : Score=70
>> Hour attending class subject 2= 12 hours : Score=80
>> .
>> .
>> .
>> .
>> Student B: Age 25
>> Hour attending class subject 1= 10 hours : Score 55
>> Hour attending class subject 2= 20 hours : Score 60
>> .
>> .
>> .
>> .
>>
>> Let plot hour attending class subject (x) vs score (y). Each curve is
>> colored according to the age to see any trend.
>
> Fine.  So let's assume your student's ages run from 20 to 30.
> Then we have
>   set cbrange [20:30]
>   plot 'student1' using ... with lines lc cb 21,
>        'student2' using ... with lines lc cb 25,
>                'student3' ...
> and so on.
>
>> In my earliest post, notice linespoints give correct color and symbol
>> according to the plot/key, just like the curve itself. Only the line
>> color is wrong.
>> If the plot can do color palette/gradient on the curve correctly(or
>> may be incorrectly) why not the key?
>
> You have asked it to color the lines by z value.
> Each point or line segment has a z value.
> But what is the z value of the key?  It has none.
>
>        Ethan
>
>
>> Thanks.
>>
>> On Thursday 11 March 2010 23:30:28 hon fui lee wrote:
>> > I'm trying to do a 2D lines/linespoint plot with linecolor from 3rd
>> > column as color palette.
>> > All are OK except the key does not proper linecolor. See sample
>> > command file and sample output (pdf).
>> > I'm using gnuplot version 4.5 (development) on Windows.
>> >
>> > Is that a bug or feature? Thanks.
>>
>> I think it is a mis-expectation.
>>
>> Your lines happen to each have a constant Z value, which you can think of
>> as a color value, so for your particular plot each entire line is a
>> single color and it would make sense for the sample line segment in the
>> key to be that same color.
>>
>> But how is gnuplot supposed to know this?  In general each point could
>> have a different Z value and each line would have many segments with
>> various colors.  Which of these colors would you put in the key?
>>
>> If you know in advance that each line has a constant Z value, maybe
>> you can revise the plot command so that instead of
>>    plot 'foo' using 1:2:3 lc palette
>> you use
>>    Z = constant_z_for_this_line
>>    plot 'foo' using 1:2 lc palette Z
>>
>> For this you would have to read in the Z values before issuing the
>> plot command.  That may or may not be possible in your particular
>> plotting scenario.
>>
>>       Ethan
>



-- 
hon_fui

Re: key error in 2D plot line with color palette by hon fui lee

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday 14 March 2010, hon fui lee wrote:
> Tried your suggestion. The "lc palette Z" introduces error like " line
> XX: ';' expected".
> "lc Z" is OK but not as palette, discrete color instead. Same as "lc
> variable" Eg. of my Z value ranges from 0.105 to 0.331.

I was not clear enough.  Please see "help colorspec"

The idea is that the 'Z' in "lc palette Z" stands for either
"frac <value>" where <value> runs from 0 to 1 and represents
a sample on the current palette,  or "cb <value>" where
<value> is drawn from the range of the current colorbox.

> Let me give you a better example. A study on a group of university
> student on their age and performance.
> Student A: Age 21
> Hour attending class subject 1= 10 hours : Score=70
> Hour attending class subject 2= 12 hours : Score=80
> .
> .
> .
> .
> Student B: Age 25
> Hour attending class subject 1= 10 hours : Score 55
> Hour attending class subject 2= 20 hours : Score 60
> .
> .
> .
> .
> 
> Let plot hour attending class subject (x) vs score (y). Each curve is
> colored according to the age to see any trend.

Fine.  So let's assume your student's ages run from 20 to 30.
Then we have
   set cbrange [20:30]
   plot 'student1' using ... with lines lc cb 21,
        'student2' using ... with lines lc cb 25, 
		'student3' ...
and so on.
 
> In my earliest post, notice linespoints give correct color and symbol
> according to the plot/key, just like the curve itself. Only the line
> color is wrong.
> If the plot can do color palette/gradient on the curve correctly(or
> may be incorrectly) why not the key?
  
You have asked it to color the lines by z value.
Each point or line segment has a z value.
But what is the z value of the key?  It has none.

	Ethan

 
> Thanks.
> 
> On Thursday 11 March 2010 23:30:28 hon fui lee wrote:
> > I'm trying to do a 2D lines/linespoint plot with linecolor from 3rd
> > column as color palette.
> > All are OK except the key does not proper linecolor. See sample
> > command file and sample output (pdf).
> > I'm using gnuplot version 4.5 (development) on Windows.
> >
> > Is that a bug or feature? Thanks.
> 
> I think it is a mis-expectation.
> 
> Your lines happen to each have a constant Z value, which you can think of
> as a color value, so for your particular plot each entire line is a
> single color and it would make sense for the sample line segment in the
> key to be that same color.
> 
> But how is gnuplot supposed to know this?  In general each point could
> have a different Z value and each line would have many segments with
> various colors.  Which of these colors would you put in the key?
> 
> If you know in advance that each line has a constant Z value, maybe
> you can revise the plot command so that instead of
>    plot 'foo' using 1:2:3 lc palette
> you use
>    Z = constant_z_for_this_line
>    plot 'foo' using 1:2 lc palette Z
> 
> For this you would have to read in the Z values before issuing the
> plot command.  That may or may not be possible in your particular
> plotting scenario.
> 
> 	Ethan

screenshot link on website: une belle fille

[Tait <gnu...@t4...>]

I just noticed a link from the gnuplot screenshots page to
http://f3wm.free.fr/linux/gp_girl.html (warning: NSFW). Gnuplot is a tool I
would like to promote as suitable for use in professional and educational
environments, but links like the one above give pause to those would-be
users. In some institutions, the entire website is blocked because of the
link. I would like to encourage women to assist with gnuplot development,
but links like the one above are off-putting to those would-be developers.

If the goal is to show off gnuplot's ability to plot arbitrary curves,
I'm sure we can come up with a more suitable demo. Given some suggestions,
I'd happily do it. In the meantime, can we remove this link from gnuplot's
web page, please?

Tait

RE: key error in 2D plot line with color palette by hon fui lee

[hon f. l. <ho...@gm...>]

Tried your suggestion. The "lc palette Z" introduces error like " line
XX: ';' expected".
"lc Z" is OK but not as palette, discrete color instead. Same as "lc
variable" Eg. of my Z value ranges from 0.105 to 0.331.

Let me give you a better example. A study on a group of university
student on their age and performance.
Student A: Age 21
Hour attending class subject 1= 10 hours : Score=70
Hour attending class subject 2= 12 hours : Score=80
.
.
.
.
Student B: Age 25
Hour attending class subject 1= 10 hours : Score 55
Hour attending class subject 2= 20 hours : Score 60
.
.
.
.

Let plot hour attending class subject (x) vs score (y). Each curve is
colored according to the age to see any trend.

In my earliest post, notice linespoints give correct color and symbol
according to the plot/key, just like the curve itself. Only the line
color is wrong.
If the plot can do color palette/gradient on the curve correctly(or
may be incorrectly) why not the key?


Thanks.

On Thursday 11 March 2010 23:30:28 hon fui lee wrote:
> I'm trying to do a 2D lines/linespoint plot with linecolor from 3rd
> column as color palette.
> All are OK except the key does not proper linecolor. See sample
> command file and sample output (pdf).
> I'm using gnuplot version 4.5 (development) on Windows.
>
> Is that a bug or feature? Thanks.

I think it is a mis-expectation.

Your lines happen to each have a constant Z value, which you can think of
as a color value, so for your particular plot each entire line is a
single color and it would make sense for the sample line segment in the
key to be that same color.

But how is gnuplot supposed to know this?  In general each point could
have a different Z value and each line would have many segments with
various colors.  Which of these colors would you put in the key?

If you know in advance that each line has a constant Z value, maybe
you can revise the plot command so that instead of
   plot 'foo' using 1:2:3 lc palette
you use
   Z = constant_z_for_this_line
   plot 'foo' using 1:2 lc palette Z

For this you would have to read in the Z values before issuing the
plot command.  That may or may not be possible in your particular
plotting scenario.

	Ethan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gnuplot-beta mailing list
gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
hon_fui

Readme.Windows in gp440win32.zip

[Tatsuro M. <tma...@ya...>]

Hello


The below remained in the Readme.Windows in gp440win32.zip

********
Note that this package does not support the wxt terminal.  If you would like   to use the gnuplot with
the wxt terminal, use gp440win32wxt-diff.zip to add   the wxt terminal features. 
********
The above should be deleted.

This is a packaging mistake.
I will fix it when packaging the next version.

I post the above as a notice to users.

Regards

Tatsuro
 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: Yay! The 4.4 ship has been launched.

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

On Sat, 13 Mar 2010, sfeam (Ethan Merritt) wrote:

> The Release Announcement, source tarball, and Windows binaries for
> version 4.4.0 are now on SourceForge...

Excellent news. Thanks for all your work on this.

Allin Cottrell

Re: Yay! The 4.4 ship has been launched.

[Tatsuro M. <tma...@ya...>]

Hello Ethan

Congratulations!!!

It is quite pleasure for me that the official release of gnuplot 4.4.0 is updated.
I strongly appreciate all the staff related to gnuplot project.

Regards

Tatsuro  

--- "sfeam (Ethan Merritt)"  wrote:

> The Release Announcement, source tarball, and Windows binaries for
> version 4.4.0 are now on SourceForge.  Many thanks to everyone who
> helped to  bring this major release to fruition.  I'd particularly
> like to thank everyone who contributed to the final push to upgrade
> the Windows binaries to support not only an upgraded version of the
> old win terminal but also to include the new wxt terminal.
> 
> Pour yourself a nice beverage of your choice and make a toast to
> our joint success. 
> 
> Things were held up for a few days to squish a last-minute but serious
> bug that only made itself apparent when tested on 64-bit linux [*].
> 
> I also made a pass over the web pages, but probably missed updating
> version numbers in various places.  Let's give it a couple of days to
> propagate to mirrors before sending announcements to the world at large.
> 
> 	cheers,
> 
> 		Ethan <sf...@us...>
> 
> [*] Although I have been using 4.4 and current CVS practically every day
> all along without problems, 4.4 keeled over and died when installed as the
> back end to a production web server.  It didn't like the sanitized
> environment, and on a 64-bit system the dislike was fatal.  The cause
> turned out to be the "too simple to hurt anything" change made a week ago
> that removed look-up of GECOS information in the password file.  
> Once again I have learned that last minute changes, no matter how simple,
> are a really bad idea.  
> 
> ------------------------------------------------------------------------------
> Download Intel¢î Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: Yay! The 4.4 ship has been launched.

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

Congratulations and thanks to everyone who helped
to make this happen!

Best,

		Ph.


On Saturday 13 March 2010 03:54:03 pm sfeam (Ethan Merritt) wrote:
> The Release Announcement, source tarball, and Windows binaries for
> version 4.4.0 are now on SourceForge.  Many thanks to everyone who
> helped to  bring this major release to fruition.  I'd particularly
> like to thank everyone who contributed to the final push to upgrade
> the Windows binaries to support not only an upgraded version of the
> old win terminal but also to include the new wxt terminal.
>
> Pour yourself a nice beverage of your choice and make a toast to
> our joint success.
>
> Things were held up for a few days to squish a last-minute but serious
> bug that only made itself apparent when tested on 64-bit linux [*].
>
> I also made a pass over the web pages, but probably missed updating
> version numbers in various places.  Let's give it a couple of days to
> propagate to mirrors before sending announcements to the world at large.
>
> 	cheers,
>
> 		Ethan <sf...@us...>
>
> [*] Although I have been using 4.4 and current CVS practically every day
> all along without problems, 4.4 keeled over and died when installed as the
> back end to a production web server.  It didn't like the sanitized
> environment, and on a 64-bit system the dislike was fatal.  The cause
> turned out to be the "too simple to hurt anything" change made a week ago
> that removed look-up of GECOS information in the password file.
> Once again I have learned that last minute changes, no matter how simple,
> are a really bad idea.
>
> ---------------------------------------------------------------------------
>--- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Yay! The 4.4 ship has been launched.

[sfeam (E. Merritt) <eam...@gm...>]

The Release Announcement, source tarball, and Windows binaries for
version 4.4.0 are now on SourceForge.  Many thanks to everyone who
helped to  bring this major release to fruition.  I'd particularly
like to thank everyone who contributed to the final push to upgrade
the Windows binaries to support not only an upgraded version of the
old win terminal but also to include the new wxt terminal.

Pour yourself a nice beverage of your choice and make a toast to
our joint success. 

Things were held up for a few days to squish a last-minute but serious
bug that only made itself apparent when tested on 64-bit linux [*].

I also made a pass over the web pages, but probably missed updating
version numbers in various places.  Let's give it a couple of days to
propagate to mirrors before sending announcements to the world at large.

	cheers,

		Ethan <sf...@us...>

[*] Although I have been using 4.4 and current CVS practically every day
all along without problems, 4.4 keeled over and died when installed as the
back end to a production web server.  It didn't like the sanitized
environment, and on a 64-bit system the dislike was fatal.  The cause
turned out to be the "too simple to hurt anything" change made a week ago
that removed look-up of GECOS information in the password file.  
Once again I have learned that last minute changes, no matter how simple,
are a really bad idea.  

Re: Fwd: key error in 2D plot line with color palette

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

On Thursday 11 March 2010 23:30:28 hon fui lee wrote:
> I'm trying to do a 2D lines/linespoint plot with linecolor from 3rd
> column as color palette.
> All are OK except the key does not proper linecolor. See sample
> command file and sample output (pdf).
> I'm using gnuplot version 4.5 (development) on Windows.
> 
> Is that a bug or feature? Thanks.

I think it is a mis-expectation.

Your lines happen to each have a constant Z value, which you can think of
as a color value, so for your particular plot each entire line is a
single color and it would make sense for the sample line segment in the
key to be that same color.

But how is gnuplot supposed to know this?  In general each point could
have a different Z value and each line would have many segments with
various colors.  Which of these colors would you put in the key?

If you know in advance that each line has a constant Z value, maybe 
you can revise the plot command so that instead of
   plot 'foo' using 1:2:3 lc palette
you use
   Z = constant_z_for_this_line
   plot 'foo' using 1:2 lc palette Z

For this you would have to read in the Z values before issuing the
plot command.  That may or may not be possible in your particular
plotting scenario.

	Ethan 

Fwd: key error in 2D plot line with color palette

[hon f. l. <ho...@gm...>]

The right mailing list .. beta_gnuplot


---------- Forwarded message ----------
From: hon fui lee <ho...@gm...>
Date: Fri, Mar 12, 2010 at 2:17 PM
Subject: key error in 2D plot line with color palette
To: gnu...@li...


Hi,

I'm trying to do a 2D lines/linespoint plot with linecolor from 3rd
column as color palette.
All are OK except the key does not proper linecolor. See sample
command file and sample output (pdf).
I'm using gnuplot version 4.5 (development) on Windows.

Is that a bug or feature? Thanks.


--
hon_fui



-- 
hon_fui

Re: make dist failure

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

> Could this be because you didn't do  "cvs update -d"?
> pdffigures.tex is a new file, but it is present both in CVS and in the
> tarball that I get from "make dist" or "make distcheck".
> 
> Admittedly I've been doing these checks on the 4.4 source in preparation
> for release, but so far as I know it should work the same for 4.5.
 
 Hhm. I did run cvs update twice, in fact, but only now that I'm running
 it the third time pdffigures.tex actually appears:

...
cvs update: Updating docs
cvs update: warning: docs/pdffigures.tex was lost
U docs/pdffigures.tex
cvs update: Updating docs/latextut
cvs update: Updating docs/old
...

 All working as expected now, so please ignore my ramblings :)

Re: make dist failure

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

On Wednesday 10 March 2010 07:47:15 Lars Hecking wrote:
> 
> $ make dist
> ...
> make[1]: Entering directory `/home/user/src/cvs/gnuplot/docs'
> make[1]: *** No rule to make target `pdffigures.tex', needed by `distdir'.  Stop.
> make[1]: Leaving directory `/home/user/src/cvs/gnuplot/docs'
> $ 
> 
>  make dist must be standalone, i.e. be able to run straight after configure
>  without having to build anything first. Also, the pdffigures target needs
>  some work; going by the error message above, I should be able to
>   cd docs; make pdffigures.tex
>  but there's no such target.

Could this be because you didn't do  "cvs update -d"?
pdffigures.tex is a new file, but it is present both in CVS and in the
tarball that I get from "make dist" or "make distcheck".

Admittedly I've been doing these checks on the 4.4 source in preparation
for release, but so far as I know it should work the same for 4.5.

	Ethan

make dist failure

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

$ make dist
...
make[1]: Entering directory `/home/user/src/cvs/gnuplot/docs'
make[1]: *** No rule to make target `pdffigures.tex', needed by `distdir'.  Stop.
make[1]: Leaving directory `/home/user/src/cvs/gnuplot/docs'
$ 

 make dist must be standalone, i.e. be able to run straight after configure
 without having to build anything first. Also, the pdffigures target needs
 some work; going by the error message above, I should be able to
  cd docs; make pdffigures.tex
 but there's no such target.

Re: app-defaults installation

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

On Tuesday 09 March 2010 13:40:01 Allin Cottrell wrote:

> Yes, that fixes it. But there's still something a little odd here.
> After full updating (CVS, prepare and configure) I have
> 
> (a) in src/Makefile:
> # Location of X11 app defaults
> XAPPLRESDIR = /etc/X11/app-defaults/
> 
> (b) in share/Makefile:
> appdefaultdir = $(pkgdatadir)/$(VERSION_MAJOR)/app-defaults
> ...
> X11_APPDEFAULTS_DIR = /etc/X11/app-defaults/
> 
> "make install" in share uses the pkgdatadir path, not the one
> found for X11_APPDEFAULTS_DIR, although it's the latter that gets
> compiled into the program.


Yeah, I think it's odd also. 
But that was the best compromise I could come up with for the
conflicting complaints about installation.

It makes sense that we have to put it _somewhere_ during installation,
but the only place we can guarantee write access to is our own installation
path.  Hence the $(pkgdatadir)

But the X-server is not going to be running from there, so I don't think
it is correct for the gnuplot to use that as the default place to look
for an X configuration file.
/etc/X11/app-defaults is a standard location, although not universal.

Another thing to keep in mind is that for all these years, most
people didn't know about or pay any attention to configuring the
app-defaults file at all.  So it's not likely that many people will
notice the difference, especially if they install a packaged version
from a linux distro that has moved the file somewhere else :-)

More to the point, we should maybe add instructions on how to modify
this file to match personal preferences and place the modified version
in ~/.Xdefault or ~/.Xresources or whatever the local convention is.
The problem here is that the old, standard, instructions for X11R4
and direct successors don't seem to apply to current xorg installations.
So I don't even know what instructions to give :-(