From marc_schwartz at me.com  Sun Aug  9 21:26:00 2009
From: marc_schwartz at me.com (Marc Schwartz)
Date: Sun, 09 Aug 2009 14:26:00 -0500
Subject: [Rd] odbcConnectExcel on non-Windows?
In-Reply-To: <4A7F10C5.6060300@prodsyse.com>
References: <4A7F019C.9040804@prodsyse.com>
	<19071.1082.186884.123257@ron.nulle.part>
	<4A7F10C5.6060300@prodsyse.com>
Message-ID: <85E3F003-B3B5-4D1A-86E3-471A21A1BC26@me.com>

Hi Spencer,

Unfortunately, the two Perl modules in question, Text::CSV_XS and  
Encode, are not pure Perl modules as they contain C code.

This means that the modules need to be compiled either beforehand as a  
pre-packaged binary or during installation, both for the Perl version  
that is installed on the user's system and for the operating system in  
use. The modules are binary specific to the Perl minor version being  
used (eg. 5.6 is not compatible with 5.8, which is not compatible with  
5.10), which further complicates matters.

As a consequence, I cannot include them in the package and reasonably  
expect them to work for a given Perl version/OS combination.

For folks on Windows, there are essentially two options:

1. Install the ActiveState Perl distribution, which includes all  
required modules, without having to install anything extra. That is  
the easiest method today.

2. Install Duncan's Perl distribution as included in RTools, which at  
present does not include at least Text::CSV_XS. If one could convince  
Duncan to add that module to his offering, it would make that option  
easier, so as to not require users to separately install the module  
from CPAN or to install AS Perl. I have cc'd Duncan here to solicit  
his comments on that. It might also reduce the potential for confusion  
relative to having more than one Perl installation and dealing with  
setting $PATH, but that is not an overly complicated issue and why I  
have the 'perl' argument in the functions.


For folks on OSX, there seems to be the potential for Text::CSV_XS to  
be or not to be installed, possibly depending upon when they got their  
Mac and what updates have been installed. It was installed on my  
spring 2009 unibody MBP, but not on Prof. Ripley's MB Air, for  
example. If it is not, one can install XCode Tools to install a C  
compiler and then install/compile the module from CPAN or from  
MacPorts. One can also use the AS Perl installation to achieve the  
same simple approach as on Windows.

On most recent Linux distributions, the modules are either already  
present with the default Perl install or can be easily installed via  
the distribution's package management system (eg. yum or apt-get). Of  
course, AS Perl is also available here as yet another option if for  
some reason, folks don't want to use their Linux distribution's  
existing tools.

The above information is contained in the package INSTALL file. If  
things there are unclear, I welcome comments and content that might  
help to clarify things.

Regards,

Marc


On Aug 9, 2009, at 1:09 PM, spencerg wrote:

> Dear Marc:
>
>     In spite of your efforts to help me, I still get an "F" in your  
> "WriteXLS" class.  Consider the following:
>
> > library(WriteXLS)
> > help(pac=WriteXLS)
> > testPerl()
> Perl found.
>
> The following Perl modules were not found on this system:
>
> Text::CSV_XS
>
> If you have more than one Perl installation, be sure the correct one  
> was used here.
>
> Otherwise, please install the missing modules. See the package  
> INSTALL file for more information.
>
> ##########################
>
>     Might it be feasible to include the required Perl modules with  
> the "WriteXLS" package?  Then you would not have to rely on fools  
> like me not knowing how to get the preferred copy of any required  
> Perl modules.
>
>     On my Windows platform (Vista), I got RODBC to work for  
> "writeFindFn2xls" in the "sos" package.  Unfortunately, the "daily  
> checks" on R-Forge failed on non-Windows platforms.  When I saw  
> that, I asked R-Devel for help.  Dirk suggested I try "WriteXLS";   
> see below.
>
>     What do you suggest?
>
>     If I don't hear an answer, I propose to NOT add "WriteXLS" to  
> the "DESCRIPTION" file but rather to modify the code for  
> "writeFindFn2xls" so that on non-Windows platforms, it tests to see  
> if "WriteXLS" is installed.  If no, it will issue an appropriate  
> error message.  If it finds "WriteXLS", it will try to use it.
>
>     However, if you have other suggestions, I'd be pleased to hear  
> them.
>
>     Best Wishes,
>     Spencer Graves
>
>
> > sessionInfo()
> R version 2.9.1 (2009-06-26)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States. 
> 1252;LC_MONETARY=English_United States. 
> 1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
> other attached packages:
> [1] sos_1.0-5      brew_1.0-3     WriteXLS_1.8.1
> #######################################
>
> Dirk Eddelbuettel wrote:
>> On 9 August 2009 at 12:04, spencerg wrote:
>> |       What should I do regarding code to write an Excel file in a  
>> | non-Windows platform? [...]
>> |       What would you suggest we do about this? [...] |       If  
>> there is a better way to handle this, I would like to know.
>> http://cran.r-project.org/web/packages/WriteXLS/index.html
>>
>> Portable (in the sense of used by Perl, Python, ... or other  
>> scripting
>> engines) solutions have existed for a dozen years.  We have a  
>> wrapper to Perl
>> code for a long time too (having been of the initial discussions  
>> that lead to
>> Greg's initial read.xls from the gdata package).
>>
>> Dirk
>>
>>
>



[Rd] odbcConnectExcel on non-Windows?
Marc Schwartz