[R] Writing Excel (.xls) files on non-Windows OSs using Perl
Uwe Ligges
ligges at statistik.uni-dortmund.de
Mon Jul 9 18:15:41 CEST 2007
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.
More information about the R-help
mailing list