I'm using cachesweave, but I don't think I get how everything works. I've tried to separate the code into simulation chunks and the plotting chunks, but some of the code is very long and written before I started the sweave document, so I instead use something like
<<foo,cache=TRUE>>
source("mainScript.R")
#
<<plot,fig=TRUE>>
a<- print(str(F1))
plot(F1)
#
The thing is mainScript.R is somewhat convoluted simulation code including plot functions and so on. I've read in cacheSweave vignette "cacheSweave doesn't cache side-effects" and plots are not cached, so I was wondering if the plotting functions in mainScript.R effect how the expressions are evaluated?
This might be an obvious question. Let's say I have another chunk after the two above. all of the results of the expressions in both "foo" and "plot" can be used in this new chunk, right? For example,
<<post-chunk>>
print(a)
print(str(F1))
#
See Wikipedia for a full explanation. Some common side-effects in R include: print() objects, draw plots, write files and load packages.
The cacheSweave package only enables you to skip computation, and you have to lose all side-effects. As Dason commented, the knitr package is much more natural in terms of caching -- what you see in an uncached chunk will be seen in the cached chunk. The caching of side-effects in knitr is explained in its manual and the cache page in the website.
BTW, knitr keeps compatibility with Sweave and cacheSweave, so hopefully you do not need to do anything for the transition; just call library(knitr); knit('file.Rnw').
Related
I have a bookdown rmd looking like...
Further introductory materials are offered when the package is loaded:
```{r dt-startup, echo=-1, message=TRUE, verbose=TRUE, hide=FALSE}
if ("data.table" %in% .packages()) detach("package:data.table")
library(data.table)
```
My intention was to show the reader the package's startup messages. However, they don't print. Is there some other chunk option to use here?
As you can see, I just threw several maybe-relevant chunk options at it to no good result. I'm not terribly familiar with management of output streams, so that's as far as I knew to go. I also tried calling directly with data.table:::.onAttach(), but no dice.
I'm not sure what else would be relevant here, but ...
Currently the package has not been loaded before this chunk. I just added the first line for robustness in case I rearrange the document.
My before_chapter_script contains nothing but knitr::opts_chunk$set(comment="#").
My knit header value is bookdown::render_book and the output is bookdown::html_book.
Don't. Anything hacked in for this would be fragile and arguably not terribly useful.
Yihui Xie (knitr's author) makes a good case. My synopsis:
This is not useful. You're writing a tutorial, so why include dynamic content (that may change when the package changes)? Moreover, why not point to resources directly rather than to the list of resources printed there?
This is very hard. It is not just a matter of output streams. The messages don't print because they are walled behind an interactive() check. It's not obvious how this should be overridden and, supposing it could be done, what weird side effects that might introduce.
Is there any way to compile knitr subfiles separately? What I have in mind is something like the package subfiles for latex just in combination with R/knitr/Sweave?
This would be great in case one has two exercises a first exercise with heavy computations and
don't want to compile the entire exercise always while working and testing the second one.
The patchDVI package does this for Sweave. I imagine it would be possible (maybe even easy) to modify it to do the same for knitr.
For example, in Sweave, you define variables in a chunk like so:
<<>>=
.TexRoot <- "main.tex"
.SweaveFiles <- c("subfile1.Rnw", "subfile2.Rnw")
#
and after Sweave is finished running that file, patchDVI will check whether the files subfile1.Rnw and subfile2.Rnw also need to be run, then will run LaTeX on the main.tex file once everything is up to date.
You don't need to do anything difficult, just use the cache options. Lots of details here, but it's probably as simple as specifying cache = T in the chunk options of your first exercise.
This is a terribly simple request, and I can't believe I haven't found the solution to this yet, but I've been searching for it far and wide without luck.
I have an .Rnw file loaded up in Emacs, I use M-n s to compile it.
Everything works well, and it even opens an R buffer. Great. But that buffer
is entirely useless: it doesn't contain the objects that I just sourced!
Example minimal .Rnw file:
\documentclass{article}
\begin{document}
<<>>=
foo <- "bar"
#
\end{document}
Using M-n s, I now have a new R-buffer with a session loaded up, but:
> foo
Error: object 'foo' not found
That is disappointing. I would like to play around with the data interactively.
How do I achieve that? I don't want to be sourcing the file line-by-line, or
region-by-region with C-c C-c or something similar every time I change my code.
Ideally, it should be just like RStudio's source function, that leaves me with
a fully prepared R session.
I haven't tried this with sweave yet, only with knitr.
EDIT: the eval=TRUE chunk option does not seem to result in the correct behaviour.
This behaviour was recently changed in ESS. Now sweave and knitr are executed directly in the global environment, as if when you write it yourself at command line. So wait for a couple of more weeks till ESSv13.09 is out or use the development version.
Alternatively, you can also set ess-swv-processing-command to "%s(%s)" and you will get the same result, except automatic library loading.
For the record, knitr (in contrast to sweave) evaluates everything in it's own environment unless you instruct it otherwise.
[edit: Something went wrong. I don't see the correct .ess_weave any more. Probably some git commit messup again. So it is not fixed in 13.09. Fixing it now. Sorry.]
Open an interactive R session, and then call Sweave directly, I believe like this (untested though). knitr works in the same way, though you need to load the knitr library first.
> Sweave("yourfile.Rnw")
There is some potential for peril here, though. If you call Sweave in a session after doing other things, your code can use things previously in the workspace, thus making your results unreproducible.
I'm loading optmatch in a Sweave document as follows:
<<myCodeBlock, echo=FALSE>>=
library(optmatch, quietly=TRUE)
#
You're loading optmatch, by Ben Hansen, a package for flexible
and optimal matching. Important license information:
The optmatch package makes essential use of D. P. Bertsekas
and P. Tseng's RELAX-IV algorithm and code, as well as
Bertsekas' AUCTION algorithm and code.
Bertsekas and Tseng freely permit their software to be used for
research purposes, but non-research uses, including the use of it
to 'satisfy in any part commercial delivery requirements to
government or industry,' require a special agreement with them.
By extension, this requirement applies to any use of the
fullmatch() function. (If you are using another package that has
loaded optmatch, then you will probably be using fullmatch indirectly.)
For more information, enter relaxinfo() at the command line
As you can see, I've tried every way I can think of to silence the package load message, to no avail. I assume this is because they just used a straight-up cat() or something like that, but it's mighty annoying. Any thoughts on how to silence this so that those reading my final, beautiful, LaTeXified PDF don't have to read about RELAX-IV?
Other things that don't seem to work (take from Andrie's pointer to a related thread):
suppressMessages(library(optmatch))
suppressPackageStartupMessages(require("optmatch"))
I should note this is pretty obviously an R problem not a Sweave problem, as the messages pop up in R also.
Try loading the package in a hide results chunk:
<<packages,results=hide>>=
require(optmatch)
#
If you use the knitr package, you need to quote hide:
<<packages,results='hide'>>=
require(optmatch)
#
Here is an R solution to your problem. The package author uses cat to print the messages to the console, rather than using standard message statements. You can intercept these messages by using sink to divert console output to a temporary file:
<<myCodeBlock, echo=FALSE>>=
zz <- tempfile()
sink(file=zz)
library(optmatch, quietly=TRUE))
unlink(zz)
#
PS. The solution by #XuWang uses only SWeave, so is clearly much more suitable in your case.
I keep R and Rnw files separate, then load the R data/plots with load("file.R") in the first Sweave chunk. Is there a way that I can print the sourced R file to an appendix without executing all of the code? (i.e., the code is slow enough that I don't want to source() it in an echo=TRUE chunk).
Thanks!
Update -- actually, I don't think my source() idea works.
How about using a Latex package?
Add into your header
\usepackage{fancyvrb}
Then
\VerbatimInput{yourRfile.R}
You can use highlight package to output nicely formatted, colorful code:
highlight("myRfile.R", renderer = renderer_latex(document = F))
But don't forget to put in your latex doc the lengthy preamble which you get with document=T.
You can experiment with code directly:
highlight(output="test.tex",
parser.output = parser(text = deparse(lm)),
renderer = renderer_latex(document = T))
And get
I usually solve this by:
\begin{appendix}
\section{Appendix A}
\subsection{R session information}
<<SessionInforamtaion,echo=F,eval=T,results=tex>>=
toLatex(sessionInfo())
#
\subsection{The simulation's source code}
<<SourceCode,echo=F,eval=T>>=
Stangle(file.path("Projectpath","RnwFile.Rnw"))
SourceCode <- readLines(file.path("Projectpath","Codefile.R"))
writeLines(SourceCode)
#
\end{appendix}
Using this you have to think of a maximum numbers of characters per line.
Separating R and Rnw files sort of defeats the purpose of literate programming. My own approach is to include the code chunks at the appropriate place in the text. If my audience isn't interested in the code, then I might mark it as
<<foo, echo=FALSE>>=
x <- 1:10
#
I might assemble the code in an appendix as
<<appendix-foo, eval=FALSE>>=
<<foo>>
#
which I admit is a bit of a kludge and error prone (forgotten chunks). One quickly wants to bundle the document with supporting material (data sets, useful helper functions, non-R scripts) into an R package, and these are not difficult to create. Building the package automatically creates the pdf and Stangle'd R file, which is exactly what you want. Package building can be a slow process, but installing the package does not require that the vignettes be rebuilt and so is fast and convenient for whomever you're giving the package to.
For twiddling with formatting / text, I use a global option \SweaveOpts{eval=FALSE}.