[R] Writing Excel (.xls) files on non-Windows OSs using Perl

[Marc Schwartz]

Greg,

You are certainly welcome to use my Perl script as the basis for a
write.xls() function for gdata.  You can even change the name of the
script to csv2xls.pl if you wish, for consistency with the existing
function.

If you might want to use the script largely 'as is', I won't have time
for a couple of weeks until I finish an interim analysis in progress,
but I could take a look at crafting a version of write.xls() as a
wrapper to the Perl script and create a .Rd file for it.

For ease of use and installation, we would need to think about including
the Perl modules that the script currently utilizes, which I see you do
with others for gdata in the 'perl' sub-dir. It looks like you have
OLE::Storage_Lite.pm there, which means that I could modify the code to
use Spreadsheet::WriteExcel rather than the 'Big' version, since the
former (as of version 2.17) supports .xls files > 7Mb with Storage_Lite
installed.

These would be:

http://search.cpan.org/~jmcnamara/Spreadsheet-WriteExcel
http://search.cpan.org/dist/Getopt-Long/
http://search.cpan.org/~nwclark/perl-5.8.8/ext/File/Glob/Glob.pm
http://search.cpan.org/~nwclark/perl-5.8.8/lib/File/Basename.pm
http://search.cpan.org/~hmbrand/Text-CSV_XS-0.29/CSV_XS.pm


HTH,

Marc

On Mon, 2007-07-09 at 17:53 -0400, Gregory Warnes wrote:
> Since I wrote the xls2csv.pl and read.xls() code for gdata, a perl  
> module for writing MS-Excel files has come on the scene.  I don't  
> have the time at the moment to create an csv2xls.pl file, but it  
> should be straightforward, and I would gladly add it to the gdata  
> package.
> 
> -G
> 
> 
> On Jul 9, 2007, at 12:15PM , Uwe Ligges wrote:
> 
> >
> >
> > Gabor Grothendieck wrote:
> >> Note that there already is a function, read.xls, in gdata that  
> >> uses Perl.
> >
> > Note that Marc talked about *writing* in his original message.
> >
> > Uwe Ligges
> >
> >
> >> On 7/9/07, Marc Schwartz <marc_schwartz at comcast.net> wrote:
> >>> On Mon, 2007-07-09 at 16:42 +0300, Hans-Peter wrote:
> >>>> Hi,
> >>>>
> >>>> 2007/7/8, Marc Schwartz <marc_schwartz at comcast.net>:
> >>>>> [snip]
> >>>>> There exists the xlsReadWrite package on CRAN by Hans-Peter  
> >>>>> Suter, which
> >>>>> is restricted to Windows, since it utilizes the non-FOSS MS  
> >>>>> Office API
> >>>>> to write the Excel formats.
> >>>> The non-FOSS API is not the problem(#) but its implementation is:
> >>>>
> >>>> The 3rd party library I use is written in Pascal and supports  
> >>>> Delphi
> >>>> and Kylix. Kylix would allow to port the package to Linux but as  
> >>>> Kylix
> >>>> has unfortunately been abandoned by CodeGear (Borland) I am not
> >>>> ready/interested to spend my time on this dead road. Though it
> >>>> probably could be done quickly.
> >>>>
> >>>> A much more interesting way is to port the package using  
> >>>> FreePascal.
> >>>> --> I plan to do this since long but...
> >>>> --> Maybe someone fluent on Linux and FreePascal could have a  
> >>>> look at
> >>>> the pascal header files (treetron.googlepages.com) and make the  
> >>>> demos
> >>>> run on Linux..., that would be great and speed up an eventual
> >>>> xlsReadWrite port!
> >>> Thanks for the clarification.
> >>>
> >>> However, I think that if you are going to pursue a cross-platform
> >>> solution, providing source code requiring compilation (as opposed  
> >>> to a
> >>> pre-compiled Windows binary), you should consider what the  
> >>> installation
> >>> requirements for your package would then be.
> >>>
> >>> If you are going to take the step of requiring a prospective end- 
> >>> user to
> >>> have a particular Pascal compiler in place, you may as well have the
> >>> requirement for a Perl interpreter and associated packages. Since  
> >>> Perl
> >>> is widely available and you are more likely to find Perl-fluent  
> >>> coders
> >>> as opposed to Pascal-fluent coders (eg. I have not used Pascal  
> >>> since the
> >>> late 80's), I would urge you to consider Perl as a future  
> >>> substrate for
> >>> your functions.
> >>>
> >>> While compiled code will run faster than interpreted code, for these
> >>> types of file I/O functions, I am not sure that you lose much  
> >>> with Perl
> >>> from a performance standpoint and you certainly gain the eyes of  
> >>> a wider
> >>> audience with respect to use, debugging and enhancements.
> >>>
> >>> To that end, you (or any other interested parties) are free to  
> >>> utilize
> >>> my code in any way you deem appropriate. I did not state this in my
> >>> original post, but I make the code available under GPL(v2),  
> >>> freeing you
> >>> from any restrictions in its use, including your "Pro" version,  
> >>> as long
> >>> as you make the source available in a fashion consistent with the  
> >>> GPL
> >>> requirements.
> >>>
> >>> Regards,
> >>>
> >>> Marc Schwartz
> >>>
> >>> ______________________________________________
> >>> R-help at stat.math.ethz.ch mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-help
> >>> PLEASE do read the posting guide http://www.R-project.org/posting- 
> >>> guide.html
> >>> and provide commented, minimal, self-contained, reproducible code.
> >>>
> >>
> >> ______________________________________________
> >> R-help at stat.math.ethz.ch mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-help
> >> PLEASE do read the posting guide http://www.R-project.org/posting- 
> >> guide.html
> >> and provide commented, minimal, self-contained, reproducible code.
> >
> > ______________________________________________
> > R-help at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide http://www.R-project.org/posting- 
> > guide.html
> > and provide commented, minimal, self-contained, reproducible code.
>