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

Gabor Grothendieck ggrothendieck at gmail.com
Mon Jul 9 17:10:51 CEST 2007


Note that there already is a function, read.xls, in gdata that uses Perl.

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.
>



More information about the R-help mailing list