When I select several lines of codes in a R script, and run it, RStudio will "smoothly" run all of the codes, even though there are some warnings and errors in the middle part. As a result, I have to carefully check the "Console" window, and to see whether there is any red lines. This is really time consuming and I may miss the errors. Are there some ways to make the running stop, when error or warning occurs?
RStudio currently works by pasting the selected text into the console. It doesn't care if there are errors in it. A better approach would be to get the text and source it.
You can get the selected text using
selected <- rstudioapi::getSourceEditorContext()$selection[[1]]$text
If you source this text instead of pasting it, it will stop at the first error. Do that using
source(exprs = parse(text = selected), echo = TRUE)
Another way to go would be to copy the text into the clipboard, then sourcing it from there. I don't think RStudio currently has a way to do that, but you can add one.
This function reads from the clipboard on Windows and MacOS; I'm not sure if pbpaste is generally available on Linux, but there should be some equivalent there:
readClipboard <- function() {
if (.Platform$OS.type == "windows")
lines <- readLines("clipboard")
else
lines <- system("pbpaste", intern=TRUE)
lines
}
This code sources the text from the clipboard:
source(exprs = parse(text = readClipboard()), echo = TRUE)
You could put either of these actions on a hot key in RStudio as an add-in. Instructions are here: https://rstudio.github.io/rstudioaddins/.
The advice above only stops on errors. If you want to also stop on warnings, use options(warn = 2) as #FransRodenburg said.
There are many ways you can force your script to stop when you encounter an error:
Save your script and run it using source(yourscript.R);
Wrap your script in a function and try and use the function;
Work in an Rmarkdown file and try and execute a chunk containing all the code you want to run (or try knitting for that matter);
If you really want to stop your script when a warning occurs, you could force warnings to be errors by using options(warn = 2) at the beginning of your script. If you just want to get rid of the red (lol), you can also suppress harmless warnings you have already checked using suppressWarnings(), or suppress all warnings for your script with options(warn = -1).
Be careful using options() outside a saved script though, lest you forget you have globally disabled warnings, or turned them into errors.
Depending on how large your script is, you may also just want to run it bit by bit using CTRL+Enter, rather than selecting lines.
Related
Sorry, but the terminology I use in the title may not be used correctly. Whenever I try to run this code, it seems like it is trying to run it but never completes the command. When I click the stop command sign (red), it doesn't do anything. I cannot close out of R. So why is this taking forever to run?
con <- file('stdin', open = 'r')
inputs <- readLines(con)
When working in RStudio, you need to use readLines(stdin()) rather than readLines(file('stdin')), though you can use either if running R in the terminal.
However, there is also an issue from not specifying the number of lines of input since you are using RStudio. When reading input from stdin, Ctrl+D signals the end of input. However, if you are doing this from RStudio rather than from the terminal Ctrl+D is unavailable, so without specifying the lines of input there is no way to terminate the reading from stdin.
So, if you are running R from the terminal, your code will work, and you signal the end of input via Ctrl+D. If you must work from RStudio, you can still use readLines(stdin()) if you know the number of lines of input; e.g.,
> readLines(stdin(), n=2)
Hello
World
[1] "Hello" "World"
An alternate workaround is to use scan(), e.g.:
> scan(,'')
1: Hello
2: World
3:
Read 2 items
[1] "Hello" "World"
(On the third line I just pressed Enter to terminate input). The advantage there is that you don't need to know the number of lines of input beforehand.
RStudio has a somewhat indirect connection to R (At least 4 years ago it redirected stdin to nowhere). It is probably, for our purposes, embedded. This is probably part of why stdin() can work when paired with readLines (It creates a terminal connection rather than a file connection). #duckmayr's scan() solution is quite nice and is documented to be the kind of thing that works in this situation...
the name of a file to read data values from. If the specified file is
"", then input is taken from the keyboard (or whatever stdin() reads
if input is redirected or R is embedded).
In case you want to consider a blank input 'okay', you can also loop over getting the data from a single line with some sentinel value, i.e. thing that makes the loop stop (here 'EOF').
input <- function() {
entry <- ''
while (!any(entry == "EOF")) {
entry <- c(readline(), entry)
}
return(entry[-1])
}
I'm using the R package 'here' to define my working directory using the following command at the start of my script:
here::set_here(path='/path/to/my_directory/', verbose = F)
Every time I run the script it prints this to the console:
here() starts at /path/to/my_directory
Is there a way to suppress this output? I tried using the invisible() function but that didn't work...
The message you’re seeing is printed when you’re attaching the ‹here› package. Simply don’t do that (it’s unnecessary anyway) to prevent it.
Otherwise, load it as follows:
suppressPackageStartupMessages(library(here))
… yeah, not exactly elegant.
I want to capture the input and output of R into a separate text file. I found that the best way to do so is a combination of sink() and source() commands (How to save all console output to file in R?).
My problem is that in some data constellations, I get error messages. The exeution of the script via source() seems to stop right after an error occurs. However, I would like to run the script to the end and simply record everything, including the errors.
How can I adapt my approach to "skip" errors?
You have to use tryCatch() for every error.
For example,
tryCatch({
print('This line works well');
stop('that line contains an error')
}, error = function(e){})
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.
When I execute commands in R, the output is printed in the console. After some threshold (I guess, some maximum number of lines), the R console no longer shows the first commands and their output. I cannot scroll up that far because it is simply no longer there.
How can I access this "early" output if it has disappeared from the console?
I care mostly about error messages and messages generated by my own script. I do use a script file and save my results to a file, if anyone wonders, but this still does not help solve my problem.
(I have tried saving the R workspace and R history and then loading it again, but did not know what to do next and was not able to find what I needed...)