David Bateman wrote: > 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).
... Especially reliable Excel formula evaluation through Java is a problem :-( I'm just trying JExcelAPI too, hopefully that's more robust with Excel formulas, but it's a little less versatile then Apache POI. > 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 > [email protected] would get a clearer answer though I'll try to ask there. My scripts don't actually "link" to COM/ActiveX, they just invoke it. I think if any trespassing has ever occurred, it's probably in the (compiled) Windows package itself. But... AINAL <snip> > >> 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. Hmmm, texinfo proficiency is not my greatest virtue :-) I did add texinfo-like stanzas in the m-file themselves, those 4 or 5 codes I found in other m-files were at least comprehensible and it looks OK in octave when using "help <script>". Could WinTexmacs help here? >> - 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.. He already committed a patch from me. Hopefully the next windows binary has an up-to-date octave-forge. That's the binary used mainly by folks who don't do svn... >> 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). Well, dependency... the way I made it work is this: 1. <My xls stuff> first checks for ActiveX/COM. If not found, too bad, try next .xls interface. So having the Windows package is helpful, but it doesn't really depend on it. 2. If no ActiveX/COM is found it tries Java. If Java doesn't work it reverts to csvread stuff, so IMO there's no real dependency on Java either. 3. If Java is found to be working (by a try/catch on javaclasspath) the classpath is checked for the Apache/POI classes. If not all of them found, again csvread looms. And so on. Some interface method will eventually work, but the more options you got installed the better the Excel file interface you might get. Al sorted out by the scripts w/o much user intervention. All in all, that's why IMO it won't hurt to put it in the IO package. But I'll happily accept better suggestions. I know java can be a bit troublesome (see the various threads on java installation in this forum), I had my share as well. But in most linux distros that has all been sorted out for users. E.g. on Mandriva 2009.0, octave-3.2.3 can be installed easily by .rpm, including octave-forge (an older release with java-1.2.5 but that *does* work with Apache POI). I only had to add a symbolic link in /usr/lib/jvm (as at Mandriva they seemingly like to complicate their system layout beyond conventional comprehension of mere mortal users like me). >> 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. I think it is prnienhuis -a-t- users.sf.net BTW When I reactivated it last summer, I was immediately drowned in spam with that very sourceforge email address forged as sender, so I'm a bit wary here. Apparently the sourceforge security system is a bit leaky. Only thing I need to sort out is how ssl (putty?) works on Windows (I already got the octave-forge svn on harddisk). I rarely use linux these days but I might give svn/ssl a try there. I'll await more concrete directions on where to put all the xls scripts. Thanks, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
