Philip Nienhuis wrote: > 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). >
Cool... > 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) > It depends... From what I see COM can be considered as a system library that then calls excel, word etc if they are installed. If so then the section on "System Libraries" in the GPL probably holds and linking a GPL program to the COM interface should be ok.. Maybe ask on licens...@fsf.org would get a clearer answer though > - 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) > Here is what http://www.gnu.org/licenses/license-list.html <quote> Apache License, Version 2.0 <http://www.apache.org/licenses/LICENSE-2.0> This is a free software license, compatible with version 3 of the GPL. Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in the older version. These include certain patent termination and indemnification provisions. </quote> so probably no problems.. > 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). > I tend to use texinfo so that help pages appear correctly and I can include all of the documentation in a *.info in the directory with the functions and "doc <func>" can give more complete documentation including examples and context than the help file can. > - 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. > Michael should probably respond to that, the java code is his.. > * 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. > Michael again, though I'm sure he'd welcome help maintaining the package.. > 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). > Not sure that is the best idea, as you'll be adding a dependency on the java package (that has been troublesome in the past). > 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. > Better if you send your sourceforge username and get you added to the maintainers and you commit the code yourself.. That's pretty much the octave-forge way, with the only bar being some code sent to the list so as to keep the maintainers and package owners to those that actually commit code. Though as you've already committed to octave-forge perhaps that condition should be dropped in your case. > Many years ago I had access as octave-forge developer when I made the > Windows FAQ, but that access is probably outdated now. > In fact the developer list hasn't been cleaned up for at least a year or probably 18 months, with the criteria that a commit in the last 12 months kept the developer status.... Though yes it appears that you aren't listed as a developer D. ------------------------------------------------------------------------------ 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
