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

Re: way to find out if variable has been defined

[Juhász P. <pet...@gm...>]

On Tue, 2012-01-31 at 18:18 +0100, pl...@pi... wrote:
> Hi,
> 
> I have a number of gnuplot scripts that have various options set. I 
> would like to set a default value in the script and optionally determine 
> the value from the calling script or command.
> 
> This does not seem to be possible.
> 
> eg.
> 
> if (doPNG) { set terminal png; set output pngfile}
> else { set terminal wxt }
> 
> plot ....
> 
> 
> called as :
> 
> (echo 'doPNG=1;'  && cat cos_fit.gnu) | gnuplot
> 
> 
> Some kind of  isdefined() function would be a solution or simply if the 
> interpreter could return some kind of NaN value that could then be 
> tested instead of triggering an error and breaking out.
> 
> Alternatively kind of error trapping mechanism but that may be going 
> beyond what is needed for this simple test.
> 
> Do you think this would be a useful feature?
> 
> Regards,. Peter.
> 

It's such a useful feature that it has been implemented already:

if (exists("doPNG")) { # whatever...

Look at "help exists". You'll see that, well, help exists. (Sorry, I
couldn't resist...)

There is also "defined", but that's deprecated.

Péter Juhász

way to find out if variable has been defined

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

Hi,

I have a number of gnuplot scripts that have various options set. I 
would like to set a default value in the script and optionally determine 
the value from the calling script or command.

This does not seem to be possible.

eg.

if (doPNG) { set terminal png; set output pngfile}
else { set terminal wxt }

plot ....


called as :

(echo 'doPNG=1;'  && cat cos_fit.gnu) | gnuplot


Some kind of  isdefined() function would be a solution or simply if the 
interpreter could return some kind of NaN value that could then be 
tested instead of triggering an error and breaking out.

Alternatively kind of error trapping mechanism but that may be going 
beyond what is needed for this simple test.

Do you think this would be a useful feature?

Regards,. Peter.

Re: (gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", (on Ubuntu)

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

Hello


>   According to Google, the answer is
> 
>          install gtk2-engines-pixbuf
> 
 Solved! Thanks!

Regards

Tatsuro

Re: (gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", (on Ubuntu)

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

On Sunday, 22 January 2012, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have challenge to build gnuplot-4.6rc1 on Ubuntu 11.10 (32 bit).
> 
> I have downloaded the dependencies using synaptic package manager.
> The build seemed to be successful and make check went well.
> 
> However,
> 
> >From the gnuplot prompt (wxt terminal),
> ***************************************
> Terminal type set to 'wxt'
> gnuplot> plot sin(x)
> 
> (gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
> 
> (gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
> 
> (gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
> 
> (gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
> ***************************
> 
> The error did not occur usinf x11 terminal.
> Perhaps something was missing for wxt terminal.

  According to Google, the answer is

 		install gtk2-engines-pixbuf


> 
> Any suggestions?
> 
> Regards
> 
> Tatsuro
> 
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

(gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", (on Ubuntu)

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

Hello

I have challenge to build gnuplot-4.6rc1 on Ubuntu 11.10 (32 bit).

I have downloaded the dependencies using synaptic package manager.
The build seemed to be successful and make check went well.

However,

From the gnuplot prompt (wxt terminal),
***************************************
Terminal type set to 'wxt'
gnuplot> plot sin(x)

(gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",

(gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",

(gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",

(gnuplot:19214): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
***************************

The error did not occur usinf x11 terminal.
Perhaps something was missing for wxt terminal.

Any suggestions?

Regards

Tatsuro

directory structure of "share" in mingw and cygwin

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

Hello

I have noticed another difference.
(For example, Ver. 4.6)
mingw
 gnuplot/share/
  - js
  - lua
  - PostScript
  - texmf

Cygwin
 usr/local/share
 - gnuplot/4.5/js
 - gnuplot/4.5/lua
 - gnuplot/4.5/Postscript
 - gnuplot/4.5/colors_default.gp
 - gnuplot/4.5/colors_mono.gp
 - gnuplot/4.5/colors_podo.gp
 - gnuplot/4.5/gnuplot.gih
 - gnuplot/4.5/gnuplotrc
 - info
 - man
 - texmf

For gnuplot.gih and gnuplotrc are the Cygwin (perhaps Linux also have them) specific.
And also info and man seems to be OK.

Recently I have been used the PC working on the Ubuntu.
 I will check the directory structure using gnuplot-4.6-rc1.

Regards

Tatsuro


--- On Mon, 2012/1/23, Ethan Merritt  wrote:

> On Sunday, 22 January 2012, Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have noticed that the directory structure of  share/texmf of mingw is different from that of cygwin.
> > 
> > mingw
> > share/texmf/tex/
> > - context/gnuplot/t-gnuplot-lua-tikz.tex
> > - generic/gnuplot/gnuplot-lua-tikz-common.tex
> > - latex/gnuplot/gnuplot.cfg
> > - latex/gnuplot/gnuplot-lua-tikz.sty
> > - latex/gnuplot/README
> > - plain/gnuplot/gnuplot-lua-tikz.tex
> > 
> > cygwin
> > share/texmf/latex/gnuplot
> > - gnuplot.cfg
> > - gnuplot-lua-tikz.sty
> > - gnuplot-lua-tikz.tex
> > - gnuplot-lua-tikz-common.tex
> > - t-gnuplot-lua-tikz.tex
> > 
> > I do not know other platform (Linux or Mac OS) but I guess that they are the same as the cygwin.
> > 
> > I think that it is better to directory structure is consistent one another.
> 
> The configure script determines the LaTeX installation directory
> by running 
>    kpsexpand $TEXMFLOCAL
> 
> But it is true that not everything TeX-related is installed in this
> same place.  I have it on my TODO list to make the installation 
> of TeX files more consistent.
> 
>     Ethan
> 
> > Regards
> > 
> > Tatsuro
> > 
> > 
> > ------------------------------------------------------------------------------
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 

Re: directory structure of share/texmf in mingw and cygwin

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

On Sun, Jan 22, 2012 at 23:20, Tatsuro MATSUOKA wrote:
> Hello
>
> I have noticed that the directory structure of  share/texmf of mingw is different from that of cygwin.
>
> mingw
> share/texmf/tex/
> - context/gnuplot/t-gnuplot-lua-tikz.tex
> - generic/gnuplot/gnuplot-lua-tikz-common.tex
> - latex/gnuplot/gnuplot.cfg
> - latex/gnuplot/gnuplot-lua-tikz.sty
> - latex/gnuplot/README
> - plain/gnuplot/gnuplot-lua-tikz.tex
>
> cygwin
> share/texmf/latex/gnuplot
> - gnuplot.cfg
> - gnuplot-lua-tikz.sty
> - gnuplot-lua-tikz.tex
> - gnuplot-lua-tikz-common.tex
> - t-gnuplot-lua-tikz.tex
>
> I do not know other platform (Linux or Mac OS) but I guess that they are the same as the cygwin.

They are probably indeed the same as on cygwin, but the structure on
cygwin (and everywhere else) is wrong. The one on MinGW is right
(there could be slight improvements even on that one, but that is not
too important).

Still, the exact structure doesn't help much as long as the tex user
doesn't add those folders to his TeX distribution.

Mojca

Re: directory structure of share/texmf in mingw and cygwin

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

On Sunday, 22 January 2012, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have noticed that the directory structure of  share/texmf of mingw is different from that of cygwin.
> 
> mingw
> share/texmf/tex/
> - context/gnuplot/t-gnuplot-lua-tikz.tex
> - generic/gnuplot/gnuplot-lua-tikz-common.tex
> - latex/gnuplot/gnuplot.cfg
> - latex/gnuplot/gnuplot-lua-tikz.sty
> - latex/gnuplot/README
> - plain/gnuplot/gnuplot-lua-tikz.tex
> 
> cygwin
> share/texmf/latex/gnuplot
> - gnuplot.cfg
> - gnuplot-lua-tikz.sty
> - gnuplot-lua-tikz.tex
> - gnuplot-lua-tikz-common.tex
> - t-gnuplot-lua-tikz.tex
> 
> I do not know other platform (Linux or Mac OS) but I guess that they are the same as the cygwin.
> 
> I think that it is better to directory structure is consistent one another.

The configure script determines the LaTeX installation directory
by running 
   kpsexpand $TEXMFLOCAL

But it is true that not everything TeX-related is installed in this
same place.  I have it on my TODO list to make the installation 
of TeX files more consistent.

	Ethan

> Regards
> 
> Tatsuro
> 
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

directory structure of share/texmf in mingw and cygwin

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

Hello

I have noticed that the directory structure of  share/texmf of mingw is different from that of cygwin.

mingw
share/texmf/tex/
- context/gnuplot/t-gnuplot-lua-tikz.tex
- generic/gnuplot/gnuplot-lua-tikz-common.tex
- latex/gnuplot/gnuplot.cfg
- latex/gnuplot/gnuplot-lua-tikz.sty
- latex/gnuplot/README
- plain/gnuplot/gnuplot-lua-tikz.tex

cygwin
share/texmf/latex/gnuplot
- gnuplot.cfg
- gnuplot-lua-tikz.sty
- gnuplot-lua-tikz.tex
- gnuplot-lua-tikz-common.tex
- t-gnuplot-lua-tikz.tex

I do not know other platform (Linux or Mac OS) but I guess that they are the same as the cygwin.

I think that it is better to directory structure is consistent one another.

Regards

Tatsuro

Re: further issues with iteration

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

On Saturday, 21 January 2012, pl...@pi... wrote:
> > AFAIK the "Bad data on line x" message tells you that there is bad data
> > *in your data file*.
> >
> > Now if you were making the point that it would be helpful if the program
> > told you which file contained the bad data, you'd be right.
> 
> Yes , that's exactly my point. I know it's a data error but I don't know 
> where to look.

OK. That much is easy to improve.  We can easily report the name of the
current data file as well as the current line.
I'll add this to 4.5 CVS.

	Ethan   

Re: further issues with iteration

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

On 01/21/12 11:53, Juhász Péter wrote:
> On Sat, 2012-01-21 at 09:49 +0100, pl...@pi... wrote:
>> Hi,
>>
>> a further manifestation of the way iteration substitutions can be unhelpful.
>>
>>    plot for [date in "1894 1802"] "dataset-".date."+.hFFT.dat"
>>
>>             ^
>>      Bad data on line 2
>>
>>
>> in case that does not display consistently on various formats please
>> note that the caret is aligned under the double-quote following .date.
>> end before the plus sign.
>>
>> It is clearly unhelpful that we don't know which manifestation  of [date
>> in "1894 1802"]  causes the problem.
>>
>> Since messing with display of the caret and the command line may lead to
>> further confusion and may even be counter productive, perhaps it would
>> be useful for the error message to append information of the value of
>> the iteration value when iteration is present.
>>
>> eg.
>>
>>      Bad data on line 2 , during iteration : date = "1894"
>>
>> best regards, Peter.
>>
>
> Actually, this error message would not be helpful at all.
>
> AFAIK the "Bad data on line x" message tells you that there is bad data
> *in your data file*.
>
> Now if you were making the point that it would be helpful if the program
> told you *which file* contained the bad data, you'd be right.
>

Yes , that's exactly my point. I know it's a data error but I don't know 
where to look.


> So perhaps a special provision could be made that in case of iteration
> (where a single using spec can specify multiple plots, and a caret under
> the line won't tell you which of them is at fault), the error message
> should include the (expanded, evaluated) file name, e.g.
>
>        Bad data on line 2 , in file "dataset-1894+.hFFT.dat"
>
> But even this would be tricky, because it's not only file names that you
> can iterate over. Consider
>
> plot for [i=0:10] "file.dat" index i
>
> where file.dat has less than 11 blocks.
> In this case including the file name in the error message would be
> superfluous.

Which is why I suggest outputting the iteration variable's value at that 
point rather than the expanded filename.

review my last post:
eg.

    Bad data on line 2 , during iteration : date = "1894"


>
> Anyway, the way iteration is currently implemented makes it hard to make
> any of these proposed changes. The way it works: when the code that
> parses the "plot" command senses the iteration construct (for [...]), it
> initializes the iteration variable to its first possible value, then
> goes on processing the plot command as usual. Then it jumps back to the
> start of the plot command, increments the iteration variable and
> processes the plot command again - and again, until it exhausts the list
> of possible values for the iterator. The point is that from the
> standpoint of the plot command (or any other part of the code) there is
> nothing special about the iteration variable.

Thanks for the explanation. It helps to see what is happening.

This could easily be got around by storing a tmp variable that could be 
accessible to any error trapping code that indicates, first of all if an 
iteration is active (by its not being null), second the variable in 
question and finally its value.

Then any and all error trapping could be made to output such a value as 
I suggested in the case where an iteration is under way.


>
> Péter Juhász
>
>
Thanks

Re: further issues with iteration

[Juhász P. <pet...@gm...>]

On Sat, 2012-01-21 at 09:49 +0100, pl...@pi... wrote:
> Hi,
> 
> a further manifestation of the way iteration substitutions can be unhelpful.
> 
>   plot for [date in "1894 1802"] "dataset-".date."+.hFFT.dat"
>  
>            ^
>     Bad data on line 2
> 
> 
> in case that does not display consistently on various formats please 
> note that the caret is aligned under the double-quote following .date. 
> end before the plus sign.
> 
> It is clearly unhelpful that we don't know which manifestation  of [date 
> in "1894 1802"]  causes the problem.
> 
> Since messing with display of the caret and the command line may lead to 
> further confusion and may even be counter productive, perhaps it would 
> be useful for the error message to append information of the value of 
> the iteration value when iteration is present.
> 
> eg.
> 
>     Bad data on line 2 , during iteration : date = "1894"
> 
> best regards, Peter.
> 

Actually, this error message would not be helpful at all.

AFAIK the "Bad data on line x" message tells you that there is bad data
*in your data file*.

Now if you were making the point that it would be helpful if the program
told you *which file* contained the bad data, you'd be right.

So perhaps a special provision could be made that in case of iteration
(where a single using spec can specify multiple plots, and a caret under
the line won't tell you which of them is at fault), the error message
should include the (expanded, evaluated) file name, e.g.

      Bad data on line 2 , in file "dataset-1894+.hFFT.dat"

But even this would be tricky, because it's not only file names that you
can iterate over. Consider

plot for [i=0:10] "file.dat" index i

where file.dat has less than 11 blocks. 
In this case including the file name in the error message would be
superfluous.

Anyway, the way iteration is currently implemented makes it hard to make
any of these proposed changes. The way it works: when the code that
parses the "plot" command senses the iteration construct (for [...]), it
initializes the iteration variable to its first possible value, then
goes on processing the plot command as usual. Then it jumps back to the
start of the plot command, increments the iteration variable and
processes the plot command again - and again, until it exhausts the list
of possible values for the iterator. The point is that from the
standpoint of the plot command (or any other part of the code) there is
nothing special about the iteration variable.

Péter Juhász

Re: iteration not applied to title

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

On 01/20/12 21:15, Ethan Merritt wrote:
> On Friday, 20 January 2012, pl...@pi... wrote:
>> On 01/20/12 20:29, Ethan Merritt wrote:
>>> I gave two examples where this is (I think) the correct thing
>>> to do, but I can easily imagine that there are other cases where
>>> it is not necessarily the best thing to do.  Perhaps being
>>> inside an iteration loop is one of these cases.
>>
>> The two examples you gave make sense. this has been the case previously
>> and works well.
>>
>> The iteration loop would probably create equally unexpected results if
>> it started doing full evaluation. All I was suggesting is that the
>> substitutions that are made by iteration are also applied to the title
>>
>> plot "datafile1", "datafile2" , "datafile3"
>>
>> creates a legend
>>
>> datafile1 -------
>> datafile2 -------
>> datafile3 -------
>>
>> I am suggesting that
>>
>> plot for [i in "1 2 3"] "datefile".i
>>
>> does the same instead of:
>>
>> "datefile".i ------
>> "datefile".i ------
>> "datefile".i ------
>
> But how do you suggest that the program would do this partial
> evaluation?   There is no mechanism for saying "evaluate this
> expression only to the extent of terms that involve a particular
> variable".
>
> I understand the issue you are raising, but I still don't think
> it has anything in particular to do with iteration.
> If you say (no iteration)
>     i = 3
>     plot "datafile.".i
> then the autogenerated title is not 'datafile.3',
> it is '"datafile.".i'.
>
> That's probably not what you want, but how is the program to
> guess this?  In the equally plausible case
>     File(x) = "datafile.".x
>     plot File(3)
> then the autogenerated title "File(3)" _is_ what you probably want.
> So in one case you want evaluation but in the other case you do not.
> How can the program distinguish the two cases automatically?
>
> 	Ethan
>

I don't intend to participate in another interminable discussion. I have 
raised the issue, if you don't wish to fix it or regard it as a 
"feature", fine. It's not preventing me from working or enjoying life.

I just posted another instance where iteration error reports are unhelpful.

I think as more people use this new feature other aspects of the problem 
will arise and maybe it will be seen as useful to see whether iteration 
requires special treatment.

Until then, I'm off to get on with plotting.

Peter.

further issues with iteration

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

Hi,

a further manifestation of the way iteration substitutions can be unhelpful.

  plot for [date in "1894 1802"] "dataset-".date."+.hFFT.dat"
 
           ^
    Bad data on line 2


in case that does not display consistently on various formats please 
note that the caret is aligned under the double-quote following .date. 
end before the plus sign.

It is clearly unhelpful that we don't know which manifestation  of [date 
in "1894 1802"]  causes the problem.

Since messing with display of the caret and the command line may lead to 
further confusion and may even be counter productive, perhaps it would 
be useful for the error message to append information of the value of 
the iteration value when iteration is present.

eg.

    Bad data on line 2 , during iteration : date = "1894"

best regards, Peter.

Re: iteration not applied to title

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

On 01/20/12 20:29, Ethan Merritt wrote:
> I gave two examples where this is (I think) the correct thing
> to do, but I can easily imagine that there are other cases where
> it is not necessarily the best thing to do.  Perhaps being
> inside an iteration loop is one of these cases.

The two examples you gave make sense. this has been the case previously 
and works well.

The iteration loop would probably create equally unexpected results if 
it started doing full evaluation. All I was suggesting is that the 
substitutions that are made by iteration are also applied to the title

plot "datafile1", "datafile2" , "datafile3"

creates a legend

datafile1 -------
datafile2 -------
datafile3 -------

I am suggesting that

plot for [i in "1 2 3"] "datefile".i

does the same instead of:

"datefile".i ------
"datefile".i ------
"datefile".i ------

Peter.

Re: iteration not applied to title

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

On Friday, 20 January 2012, pl...@pi... wrote:
> On 01/20/12 20:29, Ethan Merritt wrote:
> > I gave two examples where this is (I think) the correct thing
> > to do, but I can easily imagine that there are other cases where
> > it is not necessarily the best thing to do.  Perhaps being
> > inside an iteration loop is one of these cases.
> 
> The two examples you gave make sense. this has been the case previously 
> and works well.
> 
> The iteration loop would probably create equally unexpected results if 
> it started doing full evaluation. All I was suggesting is that the 
> substitutions that are made by iteration are also applied to the title
> 
> plot "datafile1", "datafile2" , "datafile3"
> 
> creates a legend
> 
> datafile1 -------
> datafile2 -------
> datafile3 -------
> 
> I am suggesting that
> 
> plot for [i in "1 2 3"] "datefile".i
> 
> does the same instead of:
> 
> "datefile".i ------
> "datefile".i ------
> "datefile".i ------

But how do you suggest that the program would do this partial 
evaluation?   There is no mechanism for saying "evaluate this
expression only to the extent of terms that involve a particular
variable".

I understand the issue you are raising, but I still don't think
it has anything in particular to do with iteration.
If you say (no iteration)
   i = 3
   plot "datafile.".i
then the autogenerated title is not 'datafile.3',
it is '"datafile.".i'.

That's probably not what you want, but how is the program to
guess this?  In the equally plausible case
   File(x) = "datafile.".x
   plot File(3)
then the autogenerated title "File(3)" _is_ what you probably want.
So in one case you want evaluation but in the other case you do not.
How can the program distinguish the two cases automatically?

	Ethan

Re: iteration not applied to title

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

On Friday, 20 January 2012, pl...@pi... wrote:
> On 01/20/12 18:32, Ethan Merritt wrote:
> > On Friday, 20 January 2012, pl...@pi... wrote:
> >> Hi,
> >>
> >> in experiment with new iteration feature I found it does not seem to be
> >> applied correctly (ie usefully) to the automatic title in the key
> >>
> >>
> 
> >>
> >> unless I explicitly set a title both plots get an identical entry in the
> >> legend :  "dataset-".date.".dat"
> >>
> >> This would seem to render the legend key entries somewhat useless. It
> >> also seems illogical that it expands the filename to be plotted but does
> >> not expand the entry in the legend.
> >>
> >> Is this an oversight or am I missing some cunningly useful feature?
> >
> > I can see arguments either way.
> >
> > Take the very simple case
> >        x = 5
> >        plot sin(x)/x
> > Do you expect the plot key to show  "sin(x)/x" or "-0.19178"?
> >
> > Or, closer to your example,
> >        Data(year) = "dataset-".date.".dat"
> >        plot Data(1881)
> > Do you expect the plot key to show "dataset-1881.dat" or "Data(1881)"?
> >
> >
> >
> >>
> >> Best regards, Peter.
> >
> 
> Ethan , I don't think you understood what I was reporting.
> 
> None of those examples seems to have anything to do with iteration.

Correct.  But the behaviour you were reporting is not specific
to iteration.  The point is that in order to generate the key 
title, the program takes the expression being plotted as a literal
string, _without evaluation_.

I gave two examples where this is (I think) the correct thing
to do, but I can easily imagine that there are other cases where
it is not necessarily the best thing to do.  Perhaps being 
inside an iteration loop is one of these cases.

> What I was expecting to see was that the substitution done by for [...] 
> would be applied to the file name and each file name would be used as 
> the default title , as is usually the case without iteration.

Can you give an example?  
I can't think of a case where such substitution is done in the 
case without iteration.  E.g.
   A = "filename.dat"
   plot A

This will use "A" as the plot title, not "filename.dat".

	Ethan




> 
> 
> having a legend that looks like:
> 
> "dataset-".date.".dat"
> "dataset-".date.".dat"
> "dataset-".date.".dat"
> "dataset-".date.".dat"
> 
> is certainly of no use , so one is obliged to set it explicitly .
> 
> plot for [date in "1881 1883"]  "dataset-".date.".dat" tit 
> "dataset-".date.".dat"
> 
> No harm done but its a bit messy.
> 
> regards.
> 
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: iteration not applied to title

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

On 01/20/12 18:32, Ethan Merritt wrote:
> On Friday, 20 January 2012, pl...@pi... wrote:
>> Hi,
>>
>> in experiment with new iteration feature I found it does not seem to be
>> applied correctly (ie usefully) to the automatic title in the key
>>
>>

>>
>> unless I explicitly set a title both plots get an identical entry in the
>> legend :  "dataset-".date.".dat"
>>
>> This would seem to render the legend key entries somewhat useless. It
>> also seems illogical that it expands the filename to be plotted but does
>> not expand the entry in the legend.
>>
>> Is this an oversight or am I missing some cunningly useful feature?
>
> I can see arguments either way.
>
> Take the very simple case
>        x = 5
>        plot sin(x)/x
> Do you expect the plot key to show  "sin(x)/x" or "-0.19178"?
>
> Or, closer to your example,
>        Data(year) = "dataset-".date.".dat"
>        plot Data(1881)
> Do you expect the plot key to show "dataset-1881.dat" or "Data(1881)"?
>
>
>
>>
>> Best regards, Peter.
>

Ethan , I don't think you understood what I was reporting.

None of those examples seems to have anything to do with iteration.

What I was expecting to see was that the substitution done by for [...] 
would be applied to the file name and each file name would be used as 
the default title , as is usually the case without iteration.


having a legend that looks like:

"dataset-".date.".dat"
"dataset-".date.".dat"
"dataset-".date.".dat"
"dataset-".date.".dat"

is certainly of no use , so one is obliged to set it explicitly .

plot for [date in "1881 1883"]  "dataset-".date.".dat" tit 
"dataset-".date.".dat"

No harm done but its a bit messy.

regards.

Re: iteration not applied to title

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

On 01/20/12 13:24, Peter Juhasz wrote:
> On Fri, Jan 20, 2012 at 10:40 AM,<pl...@pi...>  wrote:
>> Hi,
>>
>> in experiment with new iteration feature I found it does not seem to be
>> applied correctly (ie usefully) to the automatic title in the key
>>
>>   plot for [date in "1881 1883"] "dataset-".date.".dat"
>>
>> unless I explicitly set a title both plots get an identical entry in the
>> legend :  "dataset-".date.".dat"
>>
>> This would seem to render the legend key entries somewhat useless. It
>> also seems illogical that it expands the filename to be plotted but does
>> not expand the entry in the legend.
>>
>> Is this an oversight or am I missing some cunningly useful feature?
>>
>> Best regards, Peter.
>
> The automatic title for data files is the file name plus the using
> spec, as a string.
> Perhaps it could be arranged that the iteration variable(s) (but not
> other variables) are substituted in, but for now, you have to set the
> title explicitly.
> See the bright side of it: you are free to set a more informative
> title, e.g. "Data for the year ".date". A.D.". I'd say that's useful,
> even if not cunningly.
>
> Péter Juhász
>

Thanks, so bug rather than feature. Not a major problem but I thought 
I'd flag it.

Oddly if I put the same thing as title it does get expanded.

  plot for [date in "1881 1883"] "dataset-".date.".dat" tit 
"dataset-".date.".dat"

Just seems rather pointless (and verbose) repetition to achieve what it 
standard behaviour without iteration. Probably a detail that got missed.

regards.

Re: iteration not applied to title

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

On Friday, 20 January 2012, pl...@pi... wrote:
> Hi,
> 
> in experiment with new iteration feature I found it does not seem to be 
> applied correctly (ie usefully) to the automatic title in the key
> 
>   plot for [date in "1881 1883"] "dataset-".date.".dat"
> 
> unless I explicitly set a title both plots get an identical entry in the 
> legend :  "dataset-".date.".dat"
> 
> This would seem to render the legend key entries somewhat useless. It 
> also seems illogical that it expands the filename to be plotted but does 
> not expand the entry in the legend.
> 
> Is this an oversight or am I missing some cunningly useful feature?

I can see arguments either way.

Take the very simple case
      x = 5
      plot sin(x)/x
Do you expect the plot key to show  "sin(x)/x" or "-0.19178"?

Or, closer to your example,
      Data(year) = "dataset-".date.".dat"
      plot Data(1881)
Do you expect the plot key to show "dataset-1881.dat" or "Data(1881)"?



> 
> Best regards, Peter.

iteration not applied to title

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

Hi,

in experiment with new iteration feature I found it does not seem to be 
applied correctly (ie usefully) to the automatic title in the key

  plot for [date in "1881 1883"] "dataset-".date.".dat"

unless I explicitly set a title both plots get an identical entry in the 
legend :  "dataset-".date.".dat"

This would seem to render the legend key entries somewhat useless. It 
also seems illogical that it expands the filename to be plotted but does 
not expand the entry in the legend.

Is this an oversight or am I missing some cunningly useful feature?

Best regards, Peter.

AS_HELP_STRING in configure.in

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

Hello,

I'm trying to patch some parts of configure.in for better handling of
AquaTerm and came accross AS_HELP_STRING macro:
    http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.68/html_node/Pretty-Help-Strings.html

Is there any reason why it is not being used inside AC_ARG_WITH macros?

./configure --help output looks everything but nicely aligned. Of
course that can be changed by adjusting spaces in configure.in, but
maybe AS_HELP_STRING could help with that.

./configure --help
  ...
  --disable-x11-mbfonts   disable multi-byte font support for x11
  --disable-x11-external        disable drawing to windows belonging
to external apps
  --enable-thin-splines   enable thin plate splines
  --disable-volatile-data        disable zooming of volatile data
  --disable-raise-console        spacebar in plot window does not raise console
  --disable-objects       disable rectangles and other objects
  --disable-macros        disable command line macros
  --disable-h3d-quadtree   disable quadtree optimization in hidden3d code
  --enable-h3d-gridbox    enable gridbox optimization in hidden3d code
  --disable-wxwidgets      wxWidgets terminal (default enabled)
  --enable-backwards-compatibility       enable deprecated syntax
  --enable-stats          Include command to generate statistical
summary of data
  --enable-qt             Qt terminal (default disabled)

(not sure if it is visible here - one probably needs a fixed width
font to see it)

Thank you,
    Mojca

Re: snapshot of windows, cygwin and djgpp binaries of version 4.6 from cvs source (was Getting ready to put out a 4.6 release candidate)

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

Hello

I have forgotten to write the url:
http://www.tatsuromatsuoka.com/gnuplot/Eng/gp46/

Regards

Tatsuro

--- On Thu, 2012/1/19, Tatsuro MATSUOKA wrote:

> Hello
> 
> I have made windows, cygwin and djgpp binaries of version 4.6 from cvs source.
> I have upload them for checking purpose.
> 
> Regards
> 
> Tatsuro
>  
> --- On Tue, 2012/1/17, Tatsuro MATSUOKA <tma...@ya...> wrote:
> 
> > Hello
> > 
> > I have checked out the recent 4.6 cvs source.
> > I have confirmed the windows installer can be made using this source tree.
> > 
> > I will check cygwin and djgpp.
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > 
> > --- On Sat, 2012/1/7, Tatsuro MATSUOKA 
> > 
> > > Hello
> > > 
> > > --- On Fri, 2012/1/6, Bastian Märkisch  wrote:
> > > 
> > > > Please note that it is possible to include extra files in the binary 
> > > > distribution by specifying an EXTRADIST directory in Makefile.
> > > 
> > > Oops! I have overlooked. Thank you for your pointing.
> > > 
> > > Regards
> > > 
> > > Tatsuro 
> > > 
> > > ------------------------------------------------------------------------------
> > > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > > infrastructure or vast IT resources to deliver seamless, secure access to
> > > virtual desktops. With this all-in-one solution, easily deploy virtual 
> > > desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> > > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > 
> > 
> > ------------------------------------------------------------------------------
> > Keep Your Developer Skills Current with LearnDevNow!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-d2d
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 

snapshot of windows, cygwin and djgpp binaries of version 4.6 from cvs source (was Getting ready to put out a 4.6 release candidate)

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

Hello

I have made windows, cygwin and djgpp binaries of version 4.6 from cvs source.
I have upload them for checking purpose.

Regards

Tatsuro
 
--- On Tue, 2012/1/17, Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello
> 
> I have checked out the recent 4.6 cvs source.
> I have confirmed the windows installer can be made using this source tree.
> 
> I will check cygwin and djgpp.
> 
> Regards
> 
> Tatsuro
> 
> 
> --- On Sat, 2012/1/7, Tatsuro MATSUOKA 
> 
> > Hello
> > 
> > --- On Fri, 2012/1/6, Bastian Märkisch  wrote:
> > 
> > > Please note that it is possible to include extra files in the binary 
> > > distribution by specifying an EXTRADIST directory in Makefile.
> > 
> > Oops! I have overlooked. Thank you for your pointing.
> > 
> > Regards
> > 
> > Tatsuro 
> > 
> > ------------------------------------------------------------------------------
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > infrastructure or vast IT resources to deliver seamless, secure access to
> > virtual desktops. With this all-in-one solution, easily deploy virtual 
> > desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Lua/tikz terminal for DJGPP binary (Re: Getting ready to put out a 4.6 release candidate)

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

Hello



--- On Wed, 2012/1/18, Ethan A Merritt wrote:

> > Hello
> > 
> > Current dggpp binary from cvs source that I have been distributed experimentally includes the lua/tikz terminal.
> > 
> > For the official 4.6 release, will the lua/tikz be included?
> 
>   So far as I know, yes.
>   Is there some reason not to include it?
> 
>     Ethan

OK.  I will prepare the dggpp binary with lua/tikz for version 4.6.

Regards

Tatsuro