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

Re: unable to run ./prepare on branch 4.6

[Mojca M. <moj...@gm...>]

On Fri, Mar 1, 2013 at 10:34 PM, Ethan A Merritt wrote:
> On Friday, March 01, 2013 05:38:46 am Mojca Miklavec wrote:
>>
>> May I please request patching autoconf/automake files in that branch
>> to simplify testing?
>
> Perhaps you would do better to hold off using automake 1.13,
> which after all was only released last month (Jan 2013).
>
> IMHO they have made a mistake to both deprecate and remove a set of
> macros at the same time.  I suspect this has broken the existing
> build chains for many projects.
>
> Anyhow, no - I do not want to change the 4.6 configure files at this point.
> The risk of breaking things is far higher than the potential gain for the
> tiny number of people who are guinea pigs for a just-released incompatible
> version of autotools.

I'm sorry, I thought that the changes were minimal. If there's a risk
to break something, this can certainly wait.

I didn't consciously update to 1.13, it was updated automatically with
other packages, but I can probably figure out how to downgrade.
(Nevertheless, if changes are minimal and easy to explain/apply, I
would be interested in knowing the patch. I know that I have to rename
configure.in into configure.ac, but there are a couple of other macro
changes needed.)

I'll try to downgrade automake and continue testing with that one. It
is still not clear to me why exactly the same aquaterm.trm (with
clipping) works fine in trunk, but not in 4.6.1.

Mojca

Re: redirecting gnuplot's print command

[松田七美男 <ma...@fi...>]

Hi!

I noticed some conflict in colorname defined in 'table.c'.
   sea-green 46,139,87
   seagreen  193,255,193

In rgb.txt included X11, the color defined with RGB "193,255,193" is 
named 'DarkSeaGreen1'.  But in fact, this color shows no _dark_ green, 
so one may not want to use a term of 'DarkSeaGreen1' as a name for 
rather light green.

If you need _light_ green,  palegreen(152,255,152) and 
lightgreen(144,238,144) will be nice.


--------------------------
ma...@fi...

Re: unable to run ./prepare on branch 4.6

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

On Friday, March 01, 2013 05:38:46 am Mojca Miklavec wrote:
> Dear gnuplotters,
> 
> I tried to run ./prepare on branch 4.6 in order
> to exclude the (unlikely) option of autotools having unexpected
> behaviour (as it already turned out in past that a buggy version of
> autotools lead to weird problems with Booleans on Mac).
> 
> The problem is that I'm unable to compile the 4.6 branch:
> 
> > ./prepare
> aclocal: warning: autoconf input should be named 'configure.ac', not
> 'configure.in'
> configure.in:12: error: 'AM_CONFIG_HEADER': this macro is obsolete.
>     You should use the 'AC_CONFIG_HEADERS' macro instead.
> /opt/local/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is
> expanded from...
> configure.in:12: the top level
> autom4te: /opt/local/bin/gm4 failed with exit status: 1
> aclocal: error: echo failed with exit status: 1
> 
> Some part of the preparation process failed.
> Please refer to INSTALL for details.
> 
> May I please request patching autoconf/automake files in that branch
> to simplify testing?

Perhaps you would do better to hold off using automake 1.13,
which after all was only released last month (Jan 2013).

IMHO they have made a mistake to both deprecate and remove a set of
macros at the same time.  I suspect this has broken the existing
build chains for many projects.

Anyhow, no - I do not want to change the 4.6 configure files at this point.
The risk of breaking things is far higher than the potential gain for the
tiny number of people who are guinea pigs for a just-released incompatible
version of autotools.

	Ethan

unable to run ./prepare on branch 4.6

[Mojca M. <moj...@gm...>]

Dear gnuplotters,

I'm still trying to figure out what exactly goes wrong with AquaTerm's
clipping code (https://sourceforge.net/p/gnuplot/bugs/1188/).

a) trunk version of gnuplot, aquaterm.trm version A: works
b) trunk version of gnuplot, aquaterm.trm version B: doesn't work
c) gnuplot 4.6, aquaterm.trm version A: doesn't work
d) gnuplot 4.6, aquaterm.trm version B: doesn't work

I'm totally confused about (c) - I thought it would work, but I have
another request first. I tried to run ./prepare on branch 4.6 in order
to exclude the (unlikely) option of autotools having unexpected
behaviour (as it already turned out in past that a buggy version of
autotools lead to weird problems with Booleans on Mac).

The problem is that I'm unable to compile the 4.6 branch:

> ./prepare
aclocal: warning: autoconf input should be named 'configure.ac', not
'configure.in'
configure.in:12: error: 'AM_CONFIG_HEADER': this macro is obsolete.
    You should use the 'AC_CONFIG_HEADERS' macro instead.
/opt/local/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is
expanded from...
configure.in:12: the top level
autom4te: /opt/local/bin/gm4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1

Some part of the preparation process failed.
Please refer to INSTALL for details.

May I please request patching autoconf/automake files in that branch
to simplify testing?

Thank you,
Mojca

Re: legend and color

[Ben A. <bpa...@ma...>]

On Feb 27, 2013, at 4:42 AM, Petr Mikulik wrote:

> On Tue, 26 Feb 2013, Ben Abbott wrote:
> 
>> On Feb 26, 2013, at 7:38 AM, Petr Mikulik wrote:
>> 
>>>> The toolkit uses gnuplot's key box to produce the legend.  Is there a way to
>>>> change the color of the entries for the key labels in gnuplot?
>>> 
>>> It can be changed by this command:
>>>   set key textcolor rgb "#FF00FF"
>> 
>> Is it possible to specify the color of the text for each key independently?
> 
> No. You can either have the legend title and all keys of the same colour, e.g.
> 	set key textcolor rgb "black"
> 	set key textcolor rgb "#FF00FF"
> or variable, i.e. the legend title is black and all keys have colour of their linetype:
> 	set key textcolor variable
> 
> 
> I've found an old mail (by me :-) from June 2002:
> ---
>        set time ... textcolor ...
> 	set tics ... textcolor ...
>        set key ... textcolor ...
>        set key ... title ... textcolor ...
> 
> It may be further nice to implement an option for 'set key' to specify
> whether labels of particular plots are black or specified textcolor
> (all the same), or they have the same color as their linetype, e.g.
>        set key {labels {ltcolor | defcolor | textcolor ...}}
> ---
> 
> Note: The case of "set tics textcolor" has been implemented, "set time textcolor" not, "set key textcolor" only as a global option for the title and all keys, see above.
> 
> What should be the syntax? E.g.
>  plot x*x title "sqr" textcolor "blue", x title "lin" textcolor variable
>  set key textcolor ...		   --- colour for all as currently
>  set key title ... textcolor ...  --- colour for the title only

Petr,

This solution would work nicely.

Ben

Re: legend and color

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

On Tue, 26 Feb 2013, Ben Abbott wrote:
> On Feb 26, 2013, at 7:38 AM, Petr Mikulik wrote:
>
>>> The toolkit uses gnuplot's key box to produce the legend.  Is there a way to
>>> change the color of the entries for the key labels in gnuplot?
>>
>> It can be changed by this command:
>>    set key textcolor rgb "#FF00FF"
>
> Is it possible to specify the color of the text for each key independently?

No. You can either have the legend title and all keys of the same colour, e.g.
 	set key textcolor rgb "black"
 	set key textcolor rgb "#FF00FF"
or variable, i.e. the legend title is black and all keys have colour of their 
linetype:
 	set key textcolor variable


I've found an old mail (by me :-) from June 2002:
---
         set time ... textcolor ...
 	set tics ... textcolor ...
         set key ... textcolor ...
         set key ... title ... textcolor ...

It may be further nice to implement an option for 'set key' to specify
whether labels of particular plots are black or specified textcolor
(all the same), or they have the same color as their linetype, e.g.
         set key {labels {ltcolor | defcolor | textcolor ...}}
---

Note: The case of "set tics textcolor" has been implemented, "set time 
textcolor" not, "set key textcolor" only as a global option for the title and 
all keys, see above.

What should be the syntax? E.g.
   plot x*x title "sqr" textcolor "blue", x title "lin" textcolor variable
   set key textcolor ...		   --- colour for all as currently
   set key title ... textcolor ...  --- colour for the title only



Actually, the most general solution for multi-colour enhanced text would be:
   set label "colours {/#FF0000 red} and {/#00FF00 green} and {/#0000FF} blue"
However, that would require a patch to all terminal drivers (but I wonder if 
this would be technically possible) ... maybe only to allow it as the first 
word of the enhanced syntax, thus without disturbing terminals:
   set label "{/#FF0000 red label}"

---
PM

Re: False triggering of pause -1

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

On 02/14/13 13:04, Karl-Friedrich Ratzsch wrote:
> This doesn´t reproduce for me.
>
> On gp4.6pl0 official windows build, pause -1 waits until <space> or
> <enter> is hit, all other keys pressed are completely ignored.
>
> I like this behaviour (e.g. being able to proceed by pressing
> <space>), but it is also undocumented.
>
>    Karl
>
>
>
> On 14.02.2013 11:44, pl...@pi... wrote:
>> Hi,
>>
>> I have found an oddity in using pause -1
>>
>> doc says it should wait for enter key which it does. But if I hit
>> another key stroke before hitting enter, it is initially ignore but
>> when I later hit enter it executes multiple repeats.
>>
>>
>>   do for [len in "1 2 3"] { load "fit-data.gnu"; pause -1;}
>>
>> the included file does a fit then plots the result. Thus I should be
>> able to loop through a series of plots using enter key.
>>
>> If , after issuing the above command , I hit space twice then enter
>> it flashes though 1 and 2 then shows three.
>>
>>
>> I get the impression the test condition is waiting until the is a
>> #13 but then processing all the previous keystrokes as being at match.
>>
>> This does not seem to be the intended behaviour.
>>
>>   many thanks, Peter.
>>
>>


Thanks for the extra info. I'm running not-so-recent CVS on linux.

         G N U P L O T
         Version 4.7 patchlevel 0    last modified 2012-10-16
         Build System: Linux i686

I just tested and space bar does not trigger in the way you indicate on 
this build. It does behave as I described earlier: Space then Enter 
triggers two iterations, not one. Both happen after hitting Enter.

regards,  Peter.

Re: False triggering of pause -1

[Karl-Friedrich R. <mai...@gm...>]

This doesn´t reproduce for me.

On gp4.6pl0 official windows build, pause -1 waits until <space> or
<enter> is hit, all other keys pressed are completely ignored.

I like this behaviour (e.g. being able to proceed by pressing
<space>), but it is also undocumented.

  Karl



On 14.02.2013 11:44, pl...@pi... wrote:
> Hi,
> 
> I have found an oddity in using pause -1
> 
> doc says it should wait for enter key which it does. But if I hit
> another key stroke before hitting enter, it is initially ignore but
> when I later hit enter it executes multiple repeats.
> 
> 
>  do for [len in "1 2 3"] { load "fit-data.gnu"; pause -1;}
> 
> the included file does a fit then plots the result. Thus I should be
> able to loop through a series of plots using enter key.
> 
> If , after issuing the above command , I hit space twice then enter
> it flashes though 1 and 2 then shows three.
> 
> 
> I get the impression the test condition is waiting until the is a
> #13 but then processing all the previous keystrokes as being at match.
> 
> This does not seem to be the intended behaviour.
> 
>  many thanks, Peter.
> 
> 
> 
> 

False triggering of pause -1

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

Hi,

I have found an oddity in using pause -1

doc says it should wait for enter key which it does. But if I hit 
another key stroke before hitting enter, it is initially ignore but when 
I later hit enter it executes multiple repeats.


  do for [len in "1 2 3"] { load "fit-data.gnu"; pause -1;}

the included file does a fit then plots the result. Thus I should be 
able to loop through a series of plots using enter key.

If , after issuing the above command , I hit space twice then enter it 
flashes though 1 and 2 then shows three.


I get the impression the test condition is waiting until the is a #13 
but then processing all the previous keystrokes as being at match.

This does not seem to be the intended behaviour.

  many thanks, Peter.

Re: redirecting gnuplot's print command

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

On 02/13/13 22:34, Ethan A Merritt wrote:
> On Wednesday, February 13, 2013 11:06:15 am pl...@pi... wrote:
>> Hi,
>>
>> may be I''m being a bit slow or just not looking in the right place but
>> I can't see a means to redirect output of a gnuplot print command to a
>> file.
>
>    help set print
>
>>
>> I'm running series of fit and plot commands in a loop using gnuplot
>> iteration and I need to capture the output of some information (but not
>> get spammed by fit) I am printing at each step.
>>
>> I have set fit quiet and get the output I need directly in the gnuplot
>> shell , so hackwise I could just scroll back and forth and copy and
>> paste, but it's a fag to do since there's rather a lot and this could
>> lead inaccuracies and copy errors I need to avoid.
>>
>> I want to get output like to following into a file, what am I missing?
>>
>> print  sprintf("  len=%s; fitted =  %5.3fm =  %5.3fa",len,
>> p1*len,p1*len/12.);
>>
>>
>> many thanks, Peter.
>

Hi Ethan,
Many thanks, I could not believe it was not possible.

Re: redirecting gnuplot's print command

[Hans-Bernhard B. <HBB...@t-...>]

On 13.02.2013 20:06, pl...@pi... wrote:

> may be I''m being a bit slow or just not looking in the right place but
> I can't see a means to redirect output of a gnuplot print command to a
> file.

This has me baffled.  How could you possibly have missed the blatantly 
obvious "help print" while looking for this?  I mean, come on, where 
else but right there would anyone start looking for that information?

And it's not like "help print" were a 20-page section in which a single 
detail might conceivably get lost --- here's the whole thing:

> print
> The print command prints the value of <expression> to the screen. It is synonymous with pause 0. <expression> may be anything that gnuplot can evaluate that produces a number, or it can be a string.
>
> Syntax:
>
>       print <expression> {, <expression>, ...}
>
> See expressions. The output file can be set with set print.
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

How much more obvious could it be?

Re: redirecting gnuplot's print command

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

On Wednesday, February 13, 2013 11:06:15 am pl...@pi... wrote:
> Hi,
> 
> may be I''m being a bit slow or just not looking in the right place but 
> I can't see a means to redirect output of a gnuplot print command to a 
> file.

  help set print

> 
> I'm running series of fit and plot commands in a loop using gnuplot 
> iteration and I need to capture the output of some information (but not 
> get spammed by fit) I am printing at each step.
> 
> I have set fit quiet and get the output I need directly in the gnuplot 
> shell , so hackwise I could just scroll back and forth and copy and 
> paste, but it's a fag to do since there's rather a lot and this could 
> lead inaccuracies and copy errors I need to avoid.
> 
> I want to get output like to following into a file, what am I missing?
> 
> print  sprintf("  len=%s; fitted =  %5.3fm =  %5.3fa",len, 
> p1*len,p1*len/12.);
> 
> 
> many thanks, Peter.

redirecting gnuplot's print command

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

Hi,

may be I''m being a bit slow or just not looking in the right place but 
I can't see a means to redirect output of a gnuplot print command to a 
file.

I'm running series of fit and plot commands in a loop using gnuplot 
iteration and I need to capture the output of some information (but not 
get spammed by fit) I am printing at each step.

I have set fit quiet and get the output I need directly in the gnuplot 
shell , so hackwise I could just scroll back and forth and copy and 
paste, but it's a fag to do since there's rather a lot and this could 
lead inaccuracies and copy errors I need to avoid.

I want to get output like to following into a file, what am I missing?

print  sprintf("  len=%s; fitted =  %5.3fm =  %5.3fa",len, 
p1*len,p1*len/12.);


many thanks, Peter.

Re: Add support for '<&n' file descriptor filenames

[W. T. K. <wk...@tr...>]

On Sun, Feb 10, 2013 at 07:30:32PM -0800, sfeam (Ethan Merritt) wrote:
> Could you explain the motivation for the patch?
> The example you give
> 
>   cat data-1 | ./src/gnuplot -p -e "plot '<&0', '<&3', '<&4'" 3<data-2 4<data-3
> 
> seems entirely artificial since you could just as easily say
> 
>     gnuplot -p -e "plot data-1, data-2, data-3"
> 
> Alternatively you could use named pipes, which also work already.
> So what, really, is the use case for this?

I often have data-generating programs that I want to run several times
with different parameters.  I'd like to plot these with the same
gnuplot script.  The changing parameters make '<myprogram -a 1 -b 2'
impossible without script edits, and the:

  $ (cat plot.gp; myprogram -a 1 -b 2) | gnuplot

idiom scales poorly:

  $ (cat plot.gp; myprogram -a 1 -b 2; cat plot-2.gp; myprogram -a 3 -b 4) | gnuplot

where the plotting script has to be split between plot.gp and
plot-2.gp to grab the subshell-inlined data.

With named pipes, you'd have something like:

  $ mkfifo data-1
  $ mkfifo data-2
  $ gnuplot plot.gp
  $ myprogram -a 1 -b 2 > data-1
  $ myprogram -a 3 -b 4 > data-2
  $ rm -f data-1 data-2

which is also not particularly elegant.

I'm used to file descriptor redirection in the shell, and it seemed
like a natural fit:

  $ gnuplot plot.gp 3< <(myprogram -a 1 -b 2) 4< <(myprogram -a 3 -b 4)

This is basically the same as the named-pipe case, except that there
are no setup/teardown steps.

Thanks for taking a look :).

Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Re: Add support for '<&n' file descriptor filenames

[sfeam (E. Merritt) <sf...@us...>]

On Sunday, 10 February 2013, W. Trevor King wrote:
> Hello list!
> 
> About a month ago I posted a patch using SourceForge's "Tickets"
> interface [1].  I haven't heard back yet, and there appear to be a
> number of open patches in that interface.  Is that the right place to
> post patches?  Should patches be mailed to this list?  Any guidance
> would be appreciated ;).  Currently both the list [2] and
> tickets/patches appear to be suggested [3].
> 
> If it's just a question of limited mainainer time for patch review, I
> apologies for the noise, and I'll try and contain myself and cultivate
> patience ;).

Could you explain the motivation for the patch?
The example you give

  cat data-1 | ./src/gnuplot -p -e "plot '<&0', '<&3', '<&4'" 3<data-2 4<data-3

seems entirely artificial since you could just as easily say

    gnuplot -p -e "plot data-1, data-2, data-3"

Alternatively you could use named pipes, which also work already.
So what, really, is the use case for this?

	Ethan



> 
> Cheers,
> Trevor
> 
> [1]: http://sourceforge.net/p/gnuplot/patches/609/
> [2]: http://gnuplot.sourceforge.net/faq/faq.html#SECTION00022000000000000000
> [3]: http://gnuplot.sourceforge.net/faq/faq.html#SECTION00047000000000000000
> 
> 

Add support for '<&n' file descriptor filenames

[W. T. K. <wk...@tr...>]

Hello list!

About a month ago I posted a patch using SourceForge's "Tickets"
interface [1].  I haven't heard back yet, and there appear to be a
number of open patches in that interface.  Is that the right place to
post patches?  Should patches be mailed to this list?  Any guidance
would be appreciated ;).  Currently both the list [2] and
tickets/patches appear to be suggested [3].

If it's just a question of limited mainainer time for patch review, I
apologies for the noise, and I'll try and contain myself and cultivate
patience ;).

Cheers,
Trevor

[1]: http://sourceforge.net/p/gnuplot/patches/609/
[2]: http://gnuplot.sourceforge.net/faq/faq.html#SECTION00022000000000000000
[3]: http://gnuplot.sourceforge.net/faq/faq.html#SECTION00047000000000000000

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Re: assertion failure / segfault, format "%B %b"

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

On Friday, February 08, 2013 01:16:44 am Tait wrote:
> 
> Someone pointed out the other day, that:
> 
> 	set format "%B %b"
> 	plot x
> 
> ... triggers either an assertion failure and/or a segfault on 4.6p0
> and 4.6p1.
> 
> I get neither, but the resulting plot is clearly broken; the ticks are
> seemingly random combinations of letters and numbers that seem to bear
> no relation to the plotted values.

Fixed in CVS.  Thanks.

Over the default range of "plot", "%B" produces no output.
This left the output buffer unitialized, causing strlen(buffer) to
return a nonsensical value quite possibly longer than the buffer
itself.  Depending on the contents of the unitialized buffer, you'd
either get a null-terminated garbage string or a buffer overrun.
The error is not specific to "%B" but that's an easy way to trigger it.

This is the second major and very long-standing buffer problem in
gprintf() that's turned up recently.  

	Ethan

assertion failure / segfault, format "%B %b"

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

Someone pointed out the other day, that:

	set format "%B %b"
	plot x

... triggers either an assertion failure and/or a segfault on 4.6p0
and 4.6p1.

I get neither, but the resulting plot is clearly broken; the ticks are
seemingly random combinations of letters and numbers that seem to bear
no relation to the plotted values.

Fwd: replot in "do for ..." loop

[Dmitri A. S. <das...@gm...>]

CC to the list

---------- Forwarded message ----------
From: Dmitri A. Sergatskov <das...@gm...>
Date: Thu, Feb 7, 2013 at 9:26 PM
Subject: Re: replot in "do for ..." loop
To: Hans-Bernhard Bröker <HBB...@t-...>





On Thu, Feb 7, 2013 at 9:22 PM, Hans-Bernhard Bröker
<HBB...@t-...>wrote:

> On 08.02.2013 04:08, Dmitri A. Sergatskov wrote:
>
>  So I would expect the result to be the same as in
>>
>> gnuplot> plot sin(x)
>> gnuplot> replot sin(2*x)
>> gnuplot> replot sin(3*x)
>> gnuplot> replot sin(4*x)
>>
>>
> That expectation fails because you assume 'w' to be expanded during
> command construction.  It's not What you actually created was
>
>         plot sin(x)
>         replot sin(w*x)
>         replot sin(w*x)
>         replot sin(w*x)
>
> which is, not coincidentally, also indicated by the legend entries: the
> 2nd to 4th entry all say "sin(w*x)", because that's what you're plotting.
>
>
OK, but then why "w" gets expanded in
set multiplot layout 2,2 ; do for [w = 1:4] {plot sin(w*x)}; unset multiplot

?

Dmitri.
--

Re: replot in "do for ..." loop

[Hans-Bernhard B. <HBB...@t-...>]

[Forgot to CC list...]

On 08.02.2013 04:08, Dmitri A. Sergatskov wrote:

> So I would expect the result to be the same as in
>
> gnuplot> plot sin(x)
> gnuplot> replot sin(2*x)
> gnuplot> replot sin(3*x)
> gnuplot> replot sin(4*x)
>

That expectation fails because you assume 'w' to be expanded during
command construction.  It's not What you actually created was

	plot sin(x)
	replot sin(w*x)
	replot sin(w*x)
	replot sin(w*x)

which is, not coincidentally, also indicated by the legend entries: the
2nd to 4th entry all say "sin(w*x)", because that's what you're plotting.

To get what you actually wanted, you should put that loop _into_ the
plot command:

	plot sin(x), for [w = 2:4] sin(w*x)

Re: replot in "do for ..." loop

[Dmitri A. S. <das...@gm...>]

On Thu, Feb 7, 2013 at 8:55 PM, sfeam (Ethan Merritt) <
sf...@us...> wrote:

> On Thursday, 07 February 2013, Dmitri A. Sergatskov wrote:
> > plot sin(x)
> > do for [w = 2:4] {replot sin(w*x)}
> >
> > Produces two curves (sin(x) and sin(4*x) ) and four labels.
> > Is it intended behavior?
>
> Intended? probably not. But why would you issue such a command?
>
> Expected? Yes.
> Each replot command repeats the previous plot and adds
> a new sin(w*x) to it, so there is one additional curve
> each time through.
>
>
> "help replot"
>
>  Arguments specified after a `replot` command will be added onto the last
>  `plot` or `splot` command (with an implied ',' separator) before it is
>  repeated.  `replot` accepts the same arguments as the `plot` and `splot`
>  commands except that ranges cannot be specified.
>

So I would expect the result to be the same as in

gnuplot> plot sin(x)
gnuplot> replot sin(2*x)
gnuplot> replot sin(3*x)
gnuplot> replot sin(4*x)

Dmitri.

Re: replot in "do for ..." loop

[sfeam (E. Merritt) <sf...@us...>]

On Thursday, 07 February 2013, Dmitri A. Sergatskov wrote:
> plot sin(x)
> do for [w = 2:4] {replot sin(w*x)}
> 
> Produces two curves (sin(x) and sin(4*x) ) and four labels.
> Is it intended behavior?

Intended? probably not. But why would you issue such a command?

Expected? Yes.
Each replot command repeats the previous plot and adds 
a new sin(w*x) to it, so there is one additional curve
each time through.


"help replot"

 Arguments specified after a `replot` command will be added onto the last
 `plot` or `splot` command (with an implied ',' separator) before it is
 repeated.  `replot` accepts the same arguments as the `plot` and `splot`
 commands except that ranges cannot be specified.

replot in "do for ..." loop

[Dmitri A. S. <das...@gm...>]

plot sin(x)
do for [w = 2:4] {replot sin(w*x)}

Produces two curves (sin(x) and sin(4*x) ) and four labels.
Is it intended behavior?

Dmitri.
--

configure check for cross-compilation

[Andriy G. <av...@ic...>]

configure.in script contains this snippet:


if test "${build}" !="${host}"
then
	... setup compilers and flags for cross-compilation
else
	... ditto for native compilation
fi

I am not sure if the "${build}" !="${host}" check is correct.

The generated configure script seems to use set and use $cross_compiling
variable for this purpose.  And when it sets the variable it checks not only for
equality/inequality, but also if $build and $host are in fact set.

At least on FreeBSD (with a FreeBSD port gnuplot) I observe that $build is set
but $host is not set and for that reason the above check makes an incorrect
decision that a cross-compilation is done.  But $cross_compiling is set to "no",
which is correct.

Maybe the check should be changed to use $cross_compiling or to check that both
of the host/build variables are set.

A possible patch for the first approach:
--- configure.in.orig	2012-11-23 22:49:50.768450173 +0200
+++ configure.in	2012-11-23 22:52:14.986450016 +0200
@@ -33,7 +33,7 @@ AC_C_INLINE
 AC_C_STRINGIZE
 AC_PROG_LN_S

-if test "${build}" != "${host}"
+if test "${cross_compiling}" = "yes"
 then
   CC=${CC-${host_alias}-gcc}
   CFLAGS=${CFLAGS-"-g -O2"}

What do you think?

P.S. Judging from config.log the FreeBSD port runs configure with the following
arguments:
./configure --with-lasergnu --with-readline=gnu --without-linux-vga
--without-lisp-files --without-tutorial --with-bitmap-terminals
--with-gd=/usr/local --disable-h3d-quadtree --enable-h3d-gridbox
--with-pdf=/usr/local --with-plot=/usr/local --with-kpsexpand
--with-texdir=/usr/local/share/texmf/tex/latex/gnuplot --disable-thin-splines
--with-wx-config=/usr/local/bin/wxgtk2-2.8-config --x-libraries=/usr/local/lib
--x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/ --build=amd64-portbld-freebsd10.0

(On FreeBSD 10 amd64)
-- 
Andriy Gapon

Re: field lines

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

On Wednesday, January 16, 2013 10:22:34 am Judge_Dredd wrote:
> Hello. I want to plot field lines in 3d. I have googled and searched on the
> list for the subject and found no satisfactory info so i assumed that
> gnuplot isn't able to draw field lines. 

I realized that you asked about "field lines" rather "vector field",
but let me offer an option that gnuplot already supports. 

The gnuplot demo collection has an example of drawing vector fields in 2D

   http://gnuplot.sourceforge.net/demo_canvas/vector.html

The commands for drawing vectors in 3D are essentially the same except that
the syntax is
   splot 'vectors' using (x):(y):(z):(DelX):(DelY):(DelZ) with vectors

But it is true that gnuplot does not provide an auto-sampling mode for
a 3D grid, so if you wanted to fill 3-space with a vector field with a
single command you would have to iterate over 2D layers.  E.g.
   splot for [Z=0:10] '++' using (X):(Y):(Z):(DelX):(DelY):(DelZ) with vectors

Here is an example that generates a totally boring 3D uniform vector field:

   set xr [0:4]
   set yr [0:4]
   set samples 5,5
   set isosamples 5,5
   set style data vectors
   splot for [Z=1:4] '++' using ($1):($2):(Z):(.1):(.1):(.1)

If you had a set of functions that returned the X, Y, or Z component of
the field at a given point then you could replace that command by

   splot for [Z=1:4] '++' using \
      ($1) : ($2) : (Z) : (Vx($1,$2,Z)) : (Vy($1,$2,Z)) : (Vz($1,$2,Z))


> I wish to take a little part in dev
> and have already read some of the relevant gnuplot source code. I found it
> complicated to implement a standard algo for drawing field lines (it would
> have been much easier if points were on a 3d grid, but a user can define
> vectors which are placed randomly) to get a nice picture. 

Right.  The example above uses a regular grid because that is what gnuplot
can generate for you inside the plot command itself.  But there is no such
limitation if you are reading arbitrary 3D vectors from a file.


> It is not fully
> clear to me how gnuplot determines validity of the input file and how it
> plots a function (not a data file). Can I get help here in navigating in
> source code?
> I would like to thank all contributers. Gnuplot is a functional and easy to
> use tool.