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 <[EMAIL PROTECTED]> wrote: >> On Mon, 2007-07-09 at 16:42 +0300, Hans-Peter wrote: >>> Hi, >>> >>> 2007/7/8, Marc Schwartz <[EMAIL PROTECTED]>: >>>> [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@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@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@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.