[Rd] package building problem under Windows Vista

[Prof Brian Ripley]

On Sun, 20 Apr 2008, Duncan Murdoch wrote:

> On 20/04/2008 8:43 AM, Gabor Grothendieck wrote:
>> There does seem to be some general problem associated with Sweave
>> and graphics when I try it on my Vista system with
>> [1] "R version 2.7.0 RC (2008-04-17 r45367)"

There is no evidence whatsoever of 'some general problem', and it is quite 
specific to that package.  We've tested all the CRAN and BioC packages 
with vignettes, and accounted for all the errors.

>> Using tradeCosts-article.Rnw from the tradeCosts package:
>>
>>     setwd(path.to.tradeCosts-article.Rnw)
>>     Sweave("tradeCosts-article.Rnw")
>>
>> appears to work properly; however, if we try it from the
>> command line:
>>
>>     R CMD Sweave tradeCosts-article.Rnw
>>
>> to simulate what happens when trying to build the package it
>> indicates that in chunk 2 that pdf is masked from grDevices.
>
> tradeCosts has its own pdf(), which is an S4 generic.  Once you have
> attached that package, the regular pdf() device driver is hidden.  So it
> looks as though running Sweave from the R console does the search in the
> intended way, but running it from R CMD Sweave finds the tradeCosts
> version of pdf() instead of the standard one.

Sweave does call grDevices::pdf explicitly.  But that's not the issue as

R --slave < tradeCosts-article.R

also fails at

Calls: plot ... barplot -> barplot.default -> par -> pdf -> <Anonymous>

So the issue is that pdf() is getting called because no device has been 
opened, and "pdf" is the default device.  That seems quite reasonable to 
me: if you create a function "pdf" high on the path it indicates that you 
want that to be the default device.  (And the default device is used.)

If you want grDevices::pdf to be the default device, that is what you need 
to specify (as written).

The solution is to open a device explicitly in the vignette, e.g. call
dev.new() before library(tradeCosts).

> I don't see why there's any difference here,

batch vs interactive.

> but utils (where Sweave lives) doesn't state that it depends on 
> grDevices (which is where the standard pdf() comes from). However, 
> fixing this is not enough to fix the error.

(That's intentional, as is the use of grDevices::pdf.)


> I see that tradeCosts doesn't declare any dependency on grDevices;
> fixing that also doesn't fix the problem.
>
> When tradeCosts creates the S4 generic for pdf(), it uses a signature
> that is inconsistent with the standard one; that might be the problem.
> However, I don't see how to fix it.  The docs for setGeneric suggest
> simply using
>
>  setGeneric("pdf")
>
> but that doesn't work:
>
> Loading required package: grDevices
> Loading required package: graphics
> Loading required package: stats
> Loading required package: tools
> Error in setGeneric("pdf") :
>   must supply a function skeleton, explicitly or via an existing function
>
> I don't know why setGeneric can't see pdf() in grDevices.  I think John
> Chambers is offline for a while, so this will likely have to wait.

If you did this in the package, that code is run without importing 
grDevices.  If you do, it has a different complaint (that the signatures 
differ).


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595