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. > > [...] > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel