On 01/21/12 11:53, Juhász Péter wrote:
> On Sat, 2012-01-21 at 09:49 +0100, plotter@... wrote:
>> 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.
>> 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
Which is why I suggest outputting the iteration variable's value at that
point rather than the expanded filename.
review my last post:
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