[Kst] Re: reading ASCII files / KST command line options

[Barth Netterfield]

On Mon, Jan 31, 2011 at 4:10 AM, rrebel at rfecllc.com <rrebel at rfecllc.com>wrote:

> By searching the documents I found that the
> order the options are given, matters.


Yes.  The reason we have order matter is so that we can read different
fields with different frame ranges from different data sources into
different plots.  I'll point out that order matters in the command line
usage documentation (-h).


> This is a little unusual so. First
> the datafile and then the options in the right order. (-n in front tof
> the plot definitions).
>


But on top of this you have to set the default settings for the reader
> in a way that it can read the file without error. This means you have to
> set the  delimiter, the data start line, the comment symbol's and the
> line where the headers are as the default settings. Otherwise the reader
> fails and no data are available. Unfortunately there are no command line
> options to specify all that.
>

Should be possible to add.  Can you submit a wishlist from
debug->report_bug...


> In my opinion the ASCII reader is to intollerant on the format.
>

Yes. I've though it would be cool to introduce huristics to select between
csv and white space delimeted files, except that we can also accept ',' as
the decimal point, and we can accept fixed width colums, so a file like

1,12,23,3

is ambiguous (ie, does it mean, 1, 12, 23, 3 or 1.1, 2.2, 3.3).  There might
be other formal ambiguities.

It might be good instead to use file extensions to aid in the decisions.  We
could ship with a few pre-defined (like .csv) and then let the user define
their own... thoughts?  This might also be worth a wishlist.

The ".kst" file seems to be a real bug.
>

Yes indeed it is... of the "wow! I completely forgot to add that!" category.


> Anyway for more complex automation it would be nice that onealso could
> specify a script on the command line to run. This would be the most
> powerful and flexible way for automation since the program generating
> the data could also generate the script for post processing and
> displaying the data.
>

Can you propose a use case for this?  We are thinking of diving into
scripting, and want to make sure our design is useful.



> Best Regards
>
> Reimund Rebel
>
>
Thanks for your comments!


> --
>
C. Barth Netterfield
University of Toronto
416-845-0946
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kst/attachments/20110202/ce0ce4cf/attachment.htm