Hi,
At my employer's office we use Matlab intensively and many, many data
are kept & handled in Excel spreadsheet files. So to be able to use
octave there I've made xlsread / xlswrite / xlsfinfo scripts as
octave drop-in replacements for use in procedures otherwise done with
Matlab. Presently it consists of a collection of a dozen scripts.
My xlsread.m & xlswrite.m (written from scratch) do mainly pre- and
post-processing and for the rest are mere wrappers for COM (i.e. Excel
itself) & Java /Apache POI interfaces and the existing csvread stuff, in
that order of preference, to do the actual reading/writing.
I've taken care to make sure that adding other interfaces should be
fairly easy.
I've made it all a bit more versatile than Matlab's counterparts. E.g.,
using my stuff, for each and every call Excel /Java don't need to be
started and .xls files need not be read/written again; this may speed up
processing significantly.
It all seems to work OK, both under WinXP and Mandriva Linux 2009.0, and
I'd like to contribute the scripts collection very soon now (just some
more testing needed on non-Windows platforms + little buglet fixing).
But I might first need a bit of advice on contribution:
1. License issues: (IANAL)
------------------
- Is it actually allowed to interface directly to Excel through COM in
Octave's (octave-forge's) license terms? If not, is there an alternative
way to contribute the relevant scripts? LGPL?
(I somewhat suppose that just running octave on Windows already might
boil down to more or less the same issue)
- The Apache POI Java libs have an Apache license. Is that sufficiently
compatible with octave's GPL license?
(The jars do not have to be distributed, users can d/l & install them)
2. Technical issues:
--------------------
- I'd like to add some documentation too (README file or so). Are there
any standards for that on octave-forge?
- Apache POI only supports .xls files from Excel 97 and up (BIFF8 and
OOXML). Matlab in "basic" mode only supports .xls files type Excel '95
(BIFF5). So Matlab compatibility (in the sense of smooth file
interchange) is not complete on systems w/o Excel. (But OpenOffice.org
can be used for xls conversion).
- Octave (& octave-forge) itself has small issues:
* javaclasspath still uses split.m instead of strsplit.m leading to a
classpath split up into cell array with wrong dimensions (e.g.,
(1,1), (2,1), ... rather than (1,1), (1,2), ...
A workaround is probably easy but I'd rather see the java stuff
fixed. I can send a fixed javaclasspath.m separately.
* The windows package (1.0.8) as distributed is not up-to-date;
the latest fixes in svn should have been applied to have the
COM interfaces work properly.
3. Place to live in issue
-------------------------
My current idea is to put all the files in the IO package (licenses
permitting?). It doesn't really hurt if neither COM nor Java/ POI are
installed; xls stuff won't read .xls files then but at least xlsread.m
will still function as it did before (= read .csv files).
Q:
1. Any objections to this?
2. Would a maintainer be so kind to copy files into place, or should I
really do it myself? I know package index scripts have to be updated
too, I'll prepare them happily.
Many years ago I had access as octave-forge developer when I made the
Windows FAQ, but that access is probably outdated now.
(Oh and before you ask: yes I know, .xls and friends ARE a proprietary
format. But so is Matlab's .mat, for which octave has an interface - in
core octave, for that matter.
And xls files are indeed widely used out there....)
Philip
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
