| Summary: | Tabular data imported as 0 | ||
|---|---|---|---|
| Product: | [Applications] kst | Reporter: | Toni <toni> |
| Component: | datasources | Assignee: | kst |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 1.x | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Toni
2006-01-30 17:59:53 UTC
We shouldn't error out the whole thing on a bad column Oddly, the following works fine (columns 1,2,4,6 imported ok): +123.07672 -100.98595 Roll1 -103.77522 Error1 +000.01443 +123.39128 -100.79884 Roll1 -103.59789 Error1 +000.01497 This took a while for me to track down, as it was not what I (nor George) thought. Kst is seeing the 'c' in Pitch1, and interpreting the rest of the line as a comment. Toni, for you to make this work, start kst, click on Settings->Configure Kst. Click on the Data Sources tab. Select the ASCII File Reader, and click on Configure. Remove the 'c' from the list of comment delimitors (and make any other changes you want). Apply. Now all should be well. Perhaps 'c' isn't a good choice for one of the default comment delimitors. Personally, I'd vote for just '#'. And maybe ';'. I remember this problem from the time I looked at ASCII configuration options (I even thought there was a comment in the code I wrote to warn about this, but it seems to be gone now...) The question is actually: is it wise to ignore the rest of a line just because there is somewhere a character listed in the comment indicators ? Couldn't we just ignore that particular column ? I'm also curious about fixed-width columns (like 16 characters): the way it used to be, the "bad" columns could just be ignored as the offset to read from can be computed directly and we don't have to parse the whole line... No time to check this now, though... However, it could be an alternative as it's pretty easy to reformat an ASCII file with fixed-width columns with awk/python/etc... All in all, for the short term and considering other more important changes to be made, I'd say that making the default comment indicator only "#" would be the right way to go. I think ";" is very widely used (.csv files often have those) and should not be handled as a comment indicator :-) |