[Rd] package building problem under Windows Vista

Duncan Murdoch murdoch at stats.uwo.ca
Mon Apr 21 01:07:13 CEST 2008


On 20/04/2008 5:00 PM, Prof Brian Ripley wrote:
> On Sun, 20 Apr 2008, Duncan Murdoch wrote:
> 
>> 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".
> 
> That's equally true of the example used in example(Sweave), and that puts 
> up a graphics device, just as this one does.
> 
> fig=TRUE asks for *additional* runs with devices set -- see the code in 
> makeRweaveLatexCodeRunner.  If options$eval is true
> 
>                  if(options$eval) err <- evalFunc(ce, options)
> 
> is run (and if it isn't options$eps and options$pdf are not reached).

Thanks, that explains it.

Duncan Murdoch

> Or look at ?RweaveLatex which says
> 
>       eval: logical ('TRUE'). If 'FALSE', the code chunk is not
>            evaluated, and hence no text or graphical output produced.
> 
> Try
> 
> options(device="pdf")
> example(Sweave)
> 
> and see what gets generated.
> 
> Or (as I had done), put options(device=grDevice::pdf) in the first chunk 
> of the tradeCosts example, and see what gets plotted in Rplots.pdf.
> 
> [...]
> 
>



More information about the R-devel mailing list