[Rd] package building problem under Windows Vista

[Duncan Murdoch]

On 20/04/2008 1:21 PM, Prof Brian Ripley wrote:
> 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.)

I think there may be another problem.  Running R on the Stangle output 
is different than running Sweave, because Sweave knows that certain 
chunks have fig=TRUE, and so it should set up the graphics device for 
them.  I don't think there's a chunk in that file that does graphics 
without declaring fig=TRUE, so the original Sweave run should succeed, 
even if the run above fails.

So I still don't understand why in chunk 17 "pdf" is being used instead 
of "grDevices::pdf".

> 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).

I did this by adding grDevices to the Depends line in the package 
DESCRIPTION.

I think we need to simplify this stuff. I was under the impression that 
Depends implied Imports, and seeing the "Loading required" messages 
makes me think that at the time setGeneric("pdf") was called (I put it 
in the AllGenerics.R file), grDevices would at least be on the search 
path.  I later put an explicit "library(grDevices)" ahead of the call to 
setGeneric("pdf"), and that still didn't work.

So the problem is that our search strategy is too complicated.  I'd 
expect if a function was visible to be executed (as pdf() was at that 
point), then it should be visible to be used in setGeneric().  It 
shouldn't matter if it is imported, or just on the search path:  we 
should consistently see it or consistently not see it.  (I would 
actually prefer the latter.  If you don't explicitly import it, then you 
shouldn't be able to use it in package code.)

Duncan Murdoch

> 
>