Re: [R] Writing Excel (.xls) files on non-Windows OSs using Perl
Greg, You are certainly welcome to use my Perl script as the basis for a write.xls() function for gdata. You can even change the name of the script to csv2xls.pl if you wish, for consistency with the existing function. If you might want to use the script largely 'as is', I won't have time for a couple of weeks until I finish an interim analysis in progress, but I could take a look at crafting a version of write.xls() as a wrapper to the Perl script and create a .Rd file for it. For ease of use and installation, we would need to think about including the Perl modules that the script currently utilizes, which I see you do with others for gdata in the 'perl' sub-dir. It looks like you have OLE::Storage_Lite.pm there, which means that I could modify the code to use Spreadsheet::WriteExcel rather than the 'Big' version, since the former (as of version 2.17) supports .xls files 7Mb with Storage_Lite installed. These would be: http://search.cpan.org/~jmcnamara/Spreadsheet-WriteExcel http://search.cpan.org/dist/Getopt-Long/ http://search.cpan.org/~nwclark/perl-5.8.8/ext/File/Glob/Glob.pm http://search.cpan.org/~nwclark/perl-5.8.8/lib/File/Basename.pm http://search.cpan.org/~hmbrand/Text-CSV_XS-0.29/CSV_XS.pm HTH, Marc On Mon, 2007-07-09 at 17:53 -0400, Gregory Warnes wrote: 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 package. -G 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 [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,
Re: [R] Writing Excel (.xls) files on non-Windows OSs using Perl
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! -- Regards, Hans-Peter (#) at least for people who are not in principle opposed to run a package which contains a non-FOSS code part. __ 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.
Re: [R] Writing Excel (.xls) files on non-Windows OSs using Perl
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.
Re: [R] Writing Excel (.xls) files on non-Windows OSs using Perl
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 __ 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.
Re: [R] Writing Excel (.xls) files on non-Windows OSs using Perl
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.
Re: [R] Writing Excel (.xls) files on non-Windows OSs using Perl
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 package. -G 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 [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. __ 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.
