Re: Octave-3.6.1 for Windows (VS2008/VS2010) available

[Philip Nienhuis]

Hi Michael,


(Sorry bed time here, & I have little time left for Octave experiments 
until next Wednesday.
But I'll come back at MSVC2008 version asap.)

Some comments below:

Michael Goffioul wrote:
> On Sat, Mar 3, 2012 at 9:28 PM, Philip Nienhuis<address@hidden>  wrote:
> > > > 4. Do you have plans to include the java spreadsheet .jar files with your
> > > > > binary package? AFAICS all of them are covered under Apache or GPL
> > > > > license.
> > >
> > > Maybe. It depends the additional size to the installer. If it adds
> > > megs to the installer, I think I'll prefer to keep it separate,
> > > especially if it's not mandatory for the io package normal usage.
> >
> >
> > Around 18 MB.
>
> That's quite large indeed.

Sure.

Nitzan's MinGW binaries together constitute an almost 210 MB download; 
but as MinGW is free, a complete MinGW environment incl. compilers & rt 
libs could be included. 18 MB of jars don't matter much then.

OTOH your MSVC binary is beautifully small, but I suppose that is mainly 
because it doesn't need much OS emulators and obviously you can't supply 
a proprietary compiler with it. So users of your binary would have to do 
more work anyway to get a complete Octave "environment".

> > For 10 % of the io functions no jars are needed. As to spreadsheet I/O (the
> > remaining 90 %):
> > - For .xls/.xlsx I/O the Windows package would be sufficient. If no Excel is
> > installed however, some Java jars become required.
> > - For .ods I/O some jars are needed.
> > If the user has OpenOffice or LibreOffice installed, again no jars are
> > needed - they're contained in OOo/LO itself. But: the UNO-Java/Octave
> > communication is still delicate if not unstable.
> >
> > FYI, an overview of disk size of Java jars for the respective interfaces +
> > my personal impression as developer is here:
> >
> > .xls:
> > POI: 9 MB  (probably the best Java-based .xsl/.xlsx option, not superfast)
> > JXL: 1 MB  (tricky for writing, fairly fast reading, can read Excel95)
> > OXS: 2 MB  (fastest for reading, absolutely unusable for writing)
> > UNO: -     (tricky, but can read ANY format OOo itself can read)
> >
> > .ods:
> > OTK: 5 MB  (a bit of a dinosaur, works good, sometimes keeps files locked)
> > JOD: 3 MB  (fast, not very versatile, but it Just Works)
> > UNO: -  see above. UNO is fairly inefficient for small files, for large ones
> > (>  10 MB) it becomes indispensable.
>
> Looking at it, it seems there's no good solution, exception having
> Excel installed and using the COM interface... :)
> I could add support for each type of file, but I'm not gonna add all
> of them. So what would be your advised solution?

Oh I think this needs a bit of "ripening" in our minds. Some ripening 
written out below:

Personally I'd prefer POI (.xls) and OTK (.ods) as these offer the most 
versatility. But yes that is still 14 MB.
The smallest are JXL and JOD, resp. (little over 3 MB for just two jars 
and they're about the fastest too). Most users will have Excel (COM) 
anyway (and there's always UNO for if they've got OpenOffice.org or 
LibreOffice installed).
Moreover, JXL can also read Excel95/BIFF5 and JOD can read (perhaps 
write) .sxc (old OOo format).

Note: JXL is tricky as during writing to an existing file there is a 
moment, after reading the disk file but before actual new data transfer 
from Octave to the spreadsheet-in-memory, that the file on disk is reset 
to empty (with all info only left in memory). As the JVM has limited 
memory space and thus can bail out unexpectedly with big data transfers 
this will surely affect unwary users at some time.... (and backfire on 
Octave).
Other interfaces (e.g., POI) leave the disk file untouched until the 
spreadsheet is really written out to disk.

Thanks,

Philip