gnuplot development

On Wednesday, February 13, 2013 11:06:15 am plotter@... 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.

On 13.02.2013 20:06, plotter@... 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?

On 02/13/13 22:34, Ethan A Merritt wrote:
> On Wednesday, February 13, 2013 11:06:15 am plotter@... 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.

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.

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, plotter@... 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.
> 
> 
> 
>

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, plotter@... 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.

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.


--------------------------
matuda@...

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

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

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
> 
>

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

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

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.

On Thu, Feb 7, 2013 at 8:55 PM, sfeam (Ethan Merritt) <
sfeam@...> 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.

CC to the list

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





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

> 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.
--