I'm working on some education manuals in spanish for a course, so I'm making a Sweave document with some chunks and I'm trying to make an example of an error message. But first I need to show the souce of that error, so I'm using this code, since I don't want the code evaluating I'm using eval=FALSE:
<<eval=FALSE, error=TRUE,tidy=FALSE>>=
c(1,2 3)
#falta una coma
#
But the code is still evaluating and it's not letting me print the document, giving me this error message
(chunk 306) 5305:7: unexpected numeric constant
Your code is being parsed, not evaluated. If you have current versions of the knitr and evaluate, this should result in a warning in the knitr log, it won't stop the run. I'm using knitr 1.16 and evaluate 0.10.1 and things are fine. See knitr: knitting chunks with parsing errors for a bit more on this.
(BTW, I think you're using knitr, not Sweave. They're different. Sweave can't handle this. If you really are using Sweave, switch to knitr. The switch is not hard, and brings a lot of benefits.)
Related
I've written a knitr engine to process Maxima code (as part of a package), which works for "regular" chunks just fine, e.g.:
```{maxima}
1+1;
```
results in
(%i1) 1+1;
# (%o1) 2
However, when I try to get the output printed inline, such as
`maxima 1+1;`
It gets printed literally: maxima 1+1;
The R Markdown Cookbook explicitly says
inline: processing output from inline R expressions.
So I guess this is not meant be working (yet), but I wanted to ask here if there is a way to do this/ workaround before filing a feature request at github.
I'm writing a publication manuscript for a new R package. The author guidelines expect a self-contained Sweave (Latex+R) project with self-contained executable code within R code chunks in the Sweave document. This allows for seamless reviewing. Recommendations are to use RStudio.
All is going well. However, some of my packaged R code prints to the terminal intermediate steps; notably in the parts that setup and execute parallel code. In terms of use, this is great. However, the intermediate output is bulking out the code chunks in the compiled PDF. Not great for a scientific manuscript with a limited page count (fine elsewhere, e.g., Github wiki etc).
I'm using the code chunk options:
<<eval=T, echo=T>>=
#R code to execute AND to display code here.
#But this print all internal R print() statements to the pdf document.
#
Is there a Sweave code chunk option (not a global option, as for some code chunks the current behaviour is fine) that executes and displays the code itself but halts the printing of any internal print statements in my R package?
In answer to my own question I figured this out through a process of elimination; I could have continued scrolling through online blogs and tutorial but I'm very much pressed for time.
To suppress the output of a calculation in an R code chunk whilst displaying the R code in the compiled pdf:
<<eval=T, echo=T,results=hide>>=
eval=T -- evaluate the code
echo=T -- spits the code into the pdf (and the code output)
results=hide -- overrides echo=T to prevent the code's output whilst maintaining the code display.
The knitr language engines makes it possible to include an Rcpp chunk in your R Markdown document. This works perfectly when knitting the entire document.
However, it doesn't seem to be possible to execute (that is, compile) the Rcpp chunk interactively in RStudio (v. 1.1.364), or am I missing something?
I could keep the C++ code in a separate file and use sourceCpp in a chunk, which also works fine. However, for small examples I use in teaching it's more convenient to have everything in one document. I could then use cppFunction, but that doesn't give proper syntax highlighting.
I'm either looking for an answer that shows that I, indeed, missed how to interactively compile Rcpp chunks in RStudio, or answers that suggest good practices for i) having all code in one file, and ii) being able to execute chunks interactively.
Let's say you have an R markdown document that will not render cleanly.
I know you can set the knitr chunk option error to TRUE to request that evaluation continue, even in the presence of errors. You can do this for an individual chunk via error = TRUE or in a more global way via knitr::opts_chunk$set(error = TRUE).
But sometimes there are errors that are still fatal to the knitting process. Two examples I've recently encountered: trying to unlink() the current working directory (oops!) and calling rstudioapi::getVersion() from inline R code when RStudio is not available. Is there a general description of these sorts of errors, i.e. the ones beyond the reach of error = TRUE? Is there a way to tolerate errors in inline R code vs in chunks?
Also, are there more official ways to halt knitting early or to automate debugging in this situation?
To exit early from the knitting process, you may use the function knitr::knit_exit() anywhere in the source document (in a code chunk or inline expression). Once knit_exit() is called, knitr will ignore all the rest of the document and write out the results it has collected so far.
There is no way to tolerate errors in inline R code at the moment. You need to make sure inline R code always runs without errors1. If errors do occur, you should see the range of lines that produced the error from the knitr log in the console, of the form Quitting from lines x1-x2 (filename.Rmd). Then you can go to the file filename.Rmd and see what is wrong with the lines from x1 to x2. Same thing applies to code chunks with the chunk option error = FALSE.
Beyond the types of errors mentioned above, it may be tricky to find the source of the problem. For example, when you unintentionally unlink() the current directory, it should not stop the knitting process, because unlink() succeeded anyway. You may run into problems after the knitting process, e.g., LaTeX/HTML cannot find the output figure files. In this case, you can try to apply knit_exit() to all code chunks in the document one by one. One way to achieve this is to set up a chunk hook to run knit_exit() after a certain chunk. Below is an example of using linear search (you can improve it by using bisection instead):
#' Render an input document chunk by chunk until an error occurs
#'
#' #param input the input filename (an Rmd file in this example)
#' #param compile a function to compile the input file, e.g. knitr::knit, or
#' rmarkdown::render
knit_debug = function(input, compile = knitr::knit) {
library(knitr)
lines = readLines(input)
chunk = grep(all_patterns$md$chunk.begin, lines) # line number of chunk headers
knit_hooks$set(debug = function(before) {
if (!before) {
chunk_current <<- chunk_current + 1
if (chunk_current >= chunk_num) knit_exit()
}
})
opts_chunk$set(debug = TRUE)
# try to exit after the i-th chunk and see which chunk introduced the error
for (chunk_num in seq_along(chunk)) {
chunk_current = 0 # a chunk counter, incremented after each chunk
res = try(compile(input))
if (inherits(res, 'try-error')) {
message('The first error came from line ', chunk[chunk_num])
break
}
}
}
This is by design. I think it is a good idea to have error = TRUE for code chunks, since sometimes we want to show errors, for example, for teaching purposes. However, if I allow errors for inline code as well, authors may fail to recognize fatal errors in the inline code. Inline code is normally used to embed values inline, and I don't think it makes much sense if an inline value is an error. Imagine a sentence in a report like The P-value of my test is ERROR, and if knitr didn't signal the error, it will require the authors to read the report output very carefully to spot this issue. I think it is a bad idea to have to rely on human eyes to find such mistakes.
IMHO, difficulty debugging an Rmd document is a warning that something is wrong. I have a rule of thumb: Do the heavy lifting outside the Rmd. Do rendering inside the Rmd, and only rendering. That keeps the Rmd code simple.
My large R programs look like this.
data <- loadData()
analytics <- doAnalytics(data)
rmarkdown::render("theDoc.Rmd", envir=analytics)
(Here, doAnalytics returns a list or environment. That list or environment gets passed to the Rmd document via the envir parameter, making the results of the analytics computations available inside the document.)
The doAnalytics function does the complicated calculations. I can debug it using the regular tools, and I can easily check its output. By the time I call rmarkdown::render, I know the hard stuff is working correctly. The Rmd code is just "print this" and "format that", easy to debug.
This division of responsibility has served me well, and I can recommend it. Especially compared to the mind-bending task of debugging complicated calculations buried inside a dynamically rendered document.
I'm experimenting with using Markdown to write homework problems for a course that involves some R coding. Because these are homework sets, I intentionally write code that throws errors;. Is it possible to use Markdown to display R code in the code style without evaluating it (or to trap the errors somehow)?
If you're using R markdown, putting eval=FALSE in the chunk options should work. Or use try(). Or, if you're using knitr as well, I believe that the default chunk option error=FALSE doesn't actually stop the compilation when it encounters an error, but just proceeds to the next chunk (which sometimes drives me crazy).