[R] Writing Excel (.xls) files on non-Windows OSs using Perl
gregory.warnes at mac.com
Mon Jul 9 23:53:44 CEST 2007
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
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:
>>>> 2007/7/8, Marc Schwartz <marc_schwartz at comcast.net>:
>>>>> 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
>>>> and Kylix. Kylix would allow to port the package to Linux but as
>>>> 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
>>>> --> 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
>>>> 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
>>> 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
>>> is widely available and you are more likely to find Perl-fluent
>>> 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
>>> 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
>>> Marc Schwartz
>>> R-help at stat.math.ethz.ch mailing list
>>> PLEASE do read the posting guide http://www.R-project.org/posting-
>>> and provide commented, minimal, self-contained, reproducible code.
>> R-help at stat.math.ethz.ch mailing list
>> PLEASE do read the posting guide http://www.R-project.org/posting-
>> and provide commented, minimal, self-contained, reproducible code.
> R-help at stat.math.ethz.ch mailing list
> PLEASE do read the posting guide http://www.R-project.org/posting-
> and provide commented, minimal, self-contained, reproducible code.
More information about the R-help