GNU Octave - Tasks: task #15419, Implement Table I/O
You are not allowed to post comments on this tracker with your current authentication level.
task #15419: Implement Table I/O
Submitter: | Philip Nienhuis <philipnienhuis> | ||
Submitted: | Sat 19 Oct 2019 12:42:32 PM UTC | ||
Should Start On: | Fri 18 Oct 2019 10:00:00 PM UTC | Should be Finished on: | Fri 30 Dec 2022 11:00:00 PM UTC |
Category: | None | Priority: | 5 - Normal |
Status: | In Progress | Privacy: | Public |
Assigned to: | None | Originator Name: | Philip Nienhuis |
Open/Closed: | Open | Fixed Release: | None |
Planned Release: | None |
Jump to the original submission
Wed 29 Apr 2020 07:09:18 AM UTC, comment #9: |
Philip Nienhuis <philipnienhuis> |
Fri 31 Jan 2020 04:56:51 PM UTC, comment #8: Fine by me. I'm just going to have Tablicious take a dependency on the io package, and thus io's requirements for Excel interop. That'll mean Tablicious has to stay as a package instead of being merged into core Octave (at least the I/O parts) but I think that's fine; table I/O is important enough that it's worth taking the dependency. |
Andrew Janke <apjanke> |
Fri 31 Jan 2020 04:53:49 PM UTC, comment #7: I suppose there's little harm in already starting with the current io repo. Any mods can easily be merged.
|
Philip Nienhuis <philipnienhuis> |
Fri 31 Jan 2020 04:22:50 PM UTC, comment #6: Great. I've made a new start on Table I/O here: https://github.com/apjanke/octave-tablicious/commits/table-io. I'll pick up your 2.6.0 as soon as it's out and target that. |
Andrew Janke <apjanke> |
Fri 31 Jan 2020 04:13:29 PM UTC, comment #5: A few minutes ago I just pushed the fixes to clean up the io package code redundancy w.r.t. ods and xls spreadsheet functions.
|
Philip Nienhuis <philipnienhuis> |
Sun 19 Jan 2020 12:38:19 PM UTC, comment #4: During last Xmas holiday I've cleaned up & simplified the spreadsheet I/O in the io package. After a bit more testing I'll push it and upload io-2.6.0 to the release tracker.
|
Philip Nienhuis <philipnienhuis> |
Sun 20 Oct 2019 01:39:53 PM UTC, comment #3: Sounds like a good initial plan.
|
Andrew Janke <apjanke> |
Sun 20 Oct 2019 12:46:09 PM UTC, comment #2: Just a first throw at what is needed for the io package to support Tablicious.
|
Philip Nienhuis <philipnienhuis> |
Sat 19 Oct 2019 06:27:08 PM UTC, comment #1: The io package already has the basics that Tablicious needs. The main thing we need to add is support for exposing cell types and formats so that the Tablicious client can detect (or guess at) which cells contain date values, and should be converted to @datetime objects. |
Andrew Janke <apjanke> |
Sat 19 Oct 2019 12:42:32 PM UTC, original submission:
Aim:
|
Philip Nienhuis <philipnienhuis> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2024-04-15 | philipnienhuis | Assigned to | philipnienhuis | None |
Powered by Savane 3.13-caa5.
Corresponding source code
io-2.6.0 and 2.6.1 (bug-fix) have been released and received some testing. I suppose it'll get much more "testing" once a new Octave-6.1.0 mxe-octave installer is released.
There are always more bugs to fix and improvements to make but I think the basic work on
the io package side has been done now.
Some notes about data representation and I/O:
As to date and time formats, that's one of the very difficult things to get together in spreadsheet I/O. The challenge is that:
All of this is the reason that in the io package I didn't really bother to chase maximum Matlab compatibility as regards date and time. I tried to return dates as much as possible in the form of Matlab-compatible datenums (epoch 0000-00-0 or is it Dec 31, -1?).
While there, additional issues may be that the spreadsheet formats out there support an interesting mix of supported data types. E.g.,
- Excel .xls supports just double, boolean and text. Only when using jJava and/or ActiveX/COM there's a way to also "support" date and time;
- .xlsx does a little better and does support datetime (IIRC even without epoch, it's just text);
- .ods internally has boolean but AFAIK in LibreOffice there's no API to distinguish it from numerical 0 and 1. Some Java-based libraries (ODF Toolkit and jOpenDocument) do support it, luckily;
- .ods does supports datetime, date, time, currency, percentages, double, boolean, string;
- not all spreadsheet formats "cache" results of spreadsheet formulas (e.g., Gnumeric doesn't), but more tricky is that many others do but only if the spreadsheet was "calculated" first. Yet even more tricky is that even if there are cached formula results they may be outdated or even stale.
This isn't all meant as a rant (admittedly it looks like it, sorry) but merely to motivate this opinion:
The message is that it may be wise to concentrate on just one, maybe two, spreadsheet formats at first.