Re: use of xlsread in Octave

[Sergei Steshenko]

--- On Tue, 5/14/13, PhilipNienhuis <address@hidden> wrote:

> From: PhilipNienhuis <address@hidden>
> Subject: Re: use of xlsread in Octave
> To: address@hidden
> Date: Tuesday, May 14, 2013, 12:20 PM
> Sergei Steshenko-2 wrote
> > --- On Mon, 5/13/13, Philip Nienhuis &lt;
> 
> > pr.nienhuis@
> 
> > &gt; wrote:
> > .
> > :
> > <snip>
> > :
> >> > Regarding 'xlsread'.
> >> >
> >> > There stand alone Strawberry Perl: http://strawberryperl.com/ . And
> >> there is even a
> >> portable one, e.g.:
> >> http://strawberryperl.com/download/5.16.3.1/strawberry-perl-5.16.3.1-32bit-portable.zip
> >> ,
> >> http://strawberryperl.com/download/5.16.3.1/strawberry-perl-5.16.3.1-64bit-portable.zip
> >> .
> >> >
> >> > It even comes with 'gcc'.
> >> >
> >> > There is a whole bunch of Excel related
> modules:
> >> http://search.cpan.org/search?query=excel&mode=all
> >> -> 
> >> http://search.cpan.org/~jmcnamara/Spreadsheet-ParseExcel-0.59/lib/Spreadsheet/ParseExcel.pm
> >> .
> >> >
> >> > If the modules work, translating format from
> Perl data
> >> structures into Octave struct is trivial.
> >> >
> >> > And Octave has 'system' function, i.e. this
> whole Perl
> >> stuff is neatly kept separate from Octave.
> >> >
> >> > And on UNIX(-like) boxes Perl is present by
> default.
> >> And Perl can trivially be built from source on
> UNIX(-like)
> >> boxes and can trivially be built portable - just in
> case
> >> default Perl is not new enough. I am routinely
> building
> >> portable Perl on my Linux box.
> >> 
> >> Thanks for the overview.
> >> Besides Perl there exist many more software
> environments
> >> offering 
> >> reading from Excel files. Python, Scilab, R, you
> name it.
> >> One can safely 
> >> conclude that there is great demand for that.
> >> 
> >> Anyway, have you tried your suggestions? Do you
> have:
> >> 
> >> - Any benchmarks? Are your suggestions faster?
> >> 
> >> - How flexible & robust are your suggestions?
> >>    * What happens with merged cells?
> >>    * What happens to formulas in cells (do we
> >> get the evaluated formula 
> >> results, the formulas as strings, or cached values?
> do we
> >> have any 
> >> choice at all?)
> >>    * Do they read .xls (both BIFF5 and
> >> BIFF8), .xlsx, .dbf, .xlsm, .csv, 
> >> .wk1, etc etc?
> >>    * What happens with erroneous results in
> >> cells?
> >>    * What happens in case of user error?
> >> (like requesting more data than 
> >> available in the file, or requesting reading from
> >> non-existent sheets)
> >> 
> >> - How maintainable is it? Are upstream maintainers
> >> sufficiently responsive?
> >> 
> >> - And of course, can you use Perl as a replacement
> for
> >> xlswrite?
> >> I see little use to be able to only read
> spreadsheets.
> >> There's 
> >> definitely demand for writing spreadsheets as
> well.
> >>  From my own experience I can tell you that
> implementing
> >> flexible and 
> >> robust writing to spreadsheet files gets you into
> the next
> >> levels of 
> >> complexity, not to mention trade-offs between
> flexibility
> >> and speed.
> >> 
> >> It would be nice to compare your benchmark results
> with the
> >> present io 
> >> package support for spreadsheet I/O.
> >> I'm not quite against an overhaul of xlsread and
> friends,
> >> and/or adding 
> >> another interface, yet I think alternatives should
> have at
> >> least 
> >> comparable flexibility, robustness, speed, and
> >> maintainability. Or at 
> >> least if one these assets is lacking it should be
> >> compensated for by the 
> >> others (choice, remember, that's why I offer a
> number of
> >> interfaces 
> >> rather than just one).
> >> 
> >> And last but not least, alternatives should be
> >> "Matlab-compatible". That 
> >> in itself makes for a lot of complications.
> >> 
> >> Philip
> > 
> > There also *write modules.
> > 
> > I don't use Excel data, but I know the modules exist
> for years and are
> > apparently maintained - if you look, they are pretty
> new, have a lot of
> > good reviews.
> > 
> > Yet another article on the Perl-Excel interaction:
> > http://www.thegeekstuff.com/2011/12/perl-and-excel/ .
> 
> Thanks Sergei, when I get more time I'll look into it to see
> whether it can
> somehow be incorporated in the io package. Hopefully this
> doesn't introduce
> more dependencies (especially for Windows/MinGW/MSVC
> systems).
> 
> Because I'm no Perl expert I could use some assistance when
> that time comes,
> notably with making it build when the io package is being
> installed.
> 
> Philip
> 
> 
> 
> 
> --
> View this message in context: 
> http://octave.1599824.n4.nabble.com/Re-use-of-xlsread-in-Octave-tp4652816p4652918.html
> Sent from the Octave - General mailing list archive at
> Nabble.com.
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://mailman.cae.wisc.edu/listinfo/help-octave
> 

"Hopefully this doesn't introduce more dependencies (especially for 
Windows/MinGW/MSVC systems)." - again, Strawberry Perl comes with 'gcc' and 
other stuff it has been built with. The idea is that when a CPAN module having 
"C" as part of its code needs to be built, all the tools are at hand.

Regards,
  Sergei.