[Kst] Further enhancements to ASCII datasource

[Barth Netterfield]

On January 30, 2005 11:21 pm, George Staikos wrote:
> On Tuesday 25 January 2005 04:06, Brisset, Nicolas wrote:
> > Once the code I sent yesterday is cleaned up and integrated (I can send
> > the complete file or generate another diff if it helps), here is what I
> > thought might be worth adding/changing:
> > - a combobox with different "formats", with the filename pattern used as
> > discriminator. You could e.g. associate "*.dat" with 0 header lines, no
> > variable names, free format and "*.csv" with 1 header line corresponding
> > to variable names, and a custom ";" separator, etc... The user could
> > then load a set of settings by just changing choices in the combobox. It
> > would also require 2 buttons to add/delete format definitions. This
> > could also be important to allow loading plots which use different file
> > formats as otherwise there is no possibility of changing datasource
> > settings while loading the .kst document.
>
I understand the goal I think...

Right now, we have a generic ascii reader.
I think we could write a separate 'csv' format reader.  It would give a higher 
ranking than the generic ascii reader would for *.cvs files.  But if the 
suffix of a .csv file was not .csv, it wouldn't and it would not read 
properly.

To get around this, we would have a combo box that appears when a file is 
supported by more than one data source.

This is a general solution, as it is likely to come up for more than just 
ascii files.

> > - a lineedit with comma-separated field names that should be read as
> > time/dates (and the datasource would not use atof() but some other
> > function to read values that look like xx:xx or xx:xx:xx or even
> > xx:xx:xx.xxx for time, and xx/xx/xx or xx/xx/xxxx for dates)
>
>    This is starting to get specialized, but I guess it would be useful too.

I think reading time/dates is important.  The trick is how.  Ideally, it would 
happen automagically, except for when you didn't want it...  
How about if all fields which could be interpreted as time get a second field 
presented in the field combo box called <field>_time and all that could be 
interpreted as date would get a field called <field>_date etc...  Then the 
user choses the desired one transparently...

> > - in the current implementation, non-numeric values are read with aotf
> > and in case it fails, values are set to 0. I don't know if that's the
> > fallback value used by atof() or rather the result of the initialization
> > to 0 with memset(). I suppose it would be better to arrange for the
> > values to be set to NaN when the characters read can't be converted to a
> > number...
>
>    I once talked to Barth about our use of atof().  He said he likes the
> behavior of atof() with respect to failure and handling of unknown data.
> Barth, any comments?  Do we have some testcases for this?

Atof is probably the fasted solution.  A parse error is not NaN.  It is a 
parse error - so baring giving some sort of warning (bad idea for speed 
reasons) 0 is probably as good/bad as NaN...