|
| From: | Markus Bergholz |
| Subject: | Re: xlsread in Octave 3.6.4 |
| Date: | Mon, 3 Jun 2013 10:35:12 +0200 |
On Sun, May 12, 2013 at 9:26 PM, Philip Nienhuis <address@hidden> wrote:
Markus Bergholz wrote:
<mailto:address@hidden>> wrote:
E4
Markus Bergholz wrote
> I haven't follow this thread and it's issue, but i've wrote a
xlsxread
> function whitch don't need java.
> but it's very very rudimentary, works just with linux and is a
quick&dirty
> write-down.
> furthermore, you have to remove the string-analyse part, if your
sheet
> don't contain strings.
> but maybe it helps someone else or someone want to improve it or
someone
> rewrite it in c/c++ as oct file, to get it even faster than
matlab (for me
> it's still faster than the java stuff atm).
>
> http://git.osuv.de/Octave/tree/functions/xlsxread.m
The Java based options are relatively slow as they offer maximum
flexibility
as regards data types.
Before venturing in COM/ActiveX and Java based solutions for the io
pkg 4
years ago I've looked at a few other solutions, similar to yours.
IIRC the
most promising one was posted in an OpenWatcom news group. All of
them (i.e.
the "free solutions") suffered from the same limitations: lack of
flexibility, lack of documentation, dependency on some very specific
development framework, and/or bound to specific .xls formats (BIFF5,
BIFF8,
OOXML, what not).
If you want I can look if your code can somehow be absorbed in the
io pkg as
a sort of fall-back option.
i don't think that this is a good idea :D as i said, it just works with
linux (i'm using sed and unzip through 'system' command. furthermore, i
made quick&dirty my own tmp-dir (mktemp -d would be better). aaaaaand so
on :)
To that end it needs a suitable license
i don't care about the licence as long as it's a free licence.
and
someone should support/maintain it (my C/C++ skills are rudimentary).
Philip
my c/c++ skills are rudimentary too :)
if you like, we could code together on github on a xlsxread function e.g..
it is not so difficult but it is extremely time-consuming to parse the
shitty ms xml format!! (i don't read any specs yet, just do some lousy
reverse engineering).
Weighing the amount of work needed to build a good, robust and fool-proof C+/C-based xlsread backend versus already having available a well-tested choice of working (albeit relatively slow [1]) solutions, I just fail to see the benefits of reinventing the wheel.
Just for the record & to emphasize an important aspect, I myself don't use xlsread (or xlswrite), I usually invoke the much more flexible xlsopen-xls2oct-[parsecell-]oct2xls-xlsclose sequences. So we'd be talking about another interface in xlsopen/xls2oct/xlsclose rather than xlsread.
Philip
[1] OpenOffice / LibreOffice are really fast for large spreadsheets, I doubt a 2-person amateur team can beat the OOo/LO devs as regards speed tuning; the only problem is start-up time of OOo/LO.
Oh and there's a currently unsolvable Java-UNO issue outlined when you use it for the first time.
BTW a while ago I had a try with Starbasic (& ActiveX) invoking LibreOffice for spreadsheet I/O. I already had some success, but I had to put it away due to lack of time. Maybe next summer I can look at it again. Maybe that can be made cross-platform too.
I've do a rewrite of my xlsxread function and push it to github https://github.com/markuman/xlsxread/it is ~10% faster now, (still faster than the java version, but still slow!)Theoretical this could work in windows now too, but the unzip command in octave don't accept the .xlsx extension:warning: unrecognized file type, .xlsxSo i have to use a system command again (see line 47-51 https://github.com/markuman/xlsxread/blob/master/xlsxread.m )strings are not recognized too atm. so it's still limited.if someone has an idea how to improve it, i'd like so see some forks :D
| [Prev in Thread] | Current Thread | [Next in Thread] |