Note that there already is a function, read.xls, in gdata that uses Perl. 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 > > ______________________________________________ > [email protected] 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. >
______________________________________________ [email protected] 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.
