I noticed that, under some, unknown to me circumstances, some functions, whether from base R (for example, gc()), or from external packages (for example, getCurlHandle() from RCurl), still produce output, even after explicitly disabling it via verbose = FALSE. I am curious about reasons for such behavior. The only workaround I found on SO is the recommendation to call invisible(), but for me it worked only for gc(), but not for getCurlHandle(). Would appreciate any comments and answers.
The command gc(verbose=TRUE):
prints some statistics and percentages,
AND prints the matrix that is returned by the function.
The command x=gc(verbose=TRUE) only prints the statistics.
The command gc(verbose=FALSE) only prints the returned matrix.
The command x=gc(verbose=FALSE)prints nothing.
While preparing a reproducible example, I figured this out. The source of the questionable output was not getCurlHandle(). It has been producing by another (next) function: curlSetOpt(). I took care of disabling its output by using invisible().
It was really not bad, comparing with the effort I've made for figuring out my previous R and RCurl problem. But, it is always fun and educational.
Related
Is there a comprehensive list somewhere of what you can pass to R CMD CHECK? I don't see anything in the manual but it's brutal to read. It'd be great if every line of this output could be run independently or if I could at least skip some things but I don't see a comprehensive list describing how to do this.
Even better would be something I could use like
check_dependencies()
check_executable_files()
check_hidden_files()
For context, I had a note about large file sizes that was hard to debug (it was plotly using it's full JS library in my vignettes) and devtools::check() took 3 minutes each time I ran it.
As rawr# points out, the "official" answer is to run R CMD check --help, which will give the most accurate results for the version of R you are running.
Still, it is surprisingly difficult to find this info online. It would be nice not to need the terminal to look this up... so I'm filing this answer with some pointers in the right direction for anyone else that manages to Google their way to this Q&A:
This permalink highlights the documentation as of this writing, but that will stale as the function evolves.
tools/R/check.R is the correct file at HEAD; search for "Usage <- function", where the contents of R CMD check --help are maintained. (in principle, this could also change, but this anchor has remained accurate for the entire 12-year history of the R implementation of R CMD check)
I'm having this weird issue where my target, which interfaces a slightly customized python module (installed with pip install --editable) through reticulate, gives different results when it's being called from an interactive session in R from when targets is being started from the command line directly, even when I make sure the other argument(s) to tar_make are identical (callr_function = NULL, which I use for interactive debugging). The function is deterministic and should be returning the exact same result but isn't.
It's tricky to provide a reproducible example but if truly necessary I'll invest the required time in it. I'd like to get tips on how to debug this and identify the exact issue. I already safeguarded against potential pointer issues; the python object is not getting passed around between different targets/environments (anymore), rather it's immediately used to compute the result of interest. I also checked that the same python version is being used by printing the result of reticulate::pyconfig() to screen. I also verified both approaches are using the same version of the customized module.
Thanks in advance..!
During a process, I need to copy a directory using fs::dir_copy(currentPath, newPath). Some of the time, I get the following error message:
Error in link_copy(links, path(new_path[[i]], path_rel(links, path[[i]])), :
all(is_link(path)) is not TRUE
This only happens some of the time, not always. What's more, if I replace my directory with a manual copy of itself (i.e. manually copy directory, delete original, rename the copy), then my code will work.
Could someone please explain why this could be happening? Is there a way I can sidestep that error once and for all?
This does not answer your question but may help you to further analyse what is going on. One of the great things of R is that you can easily inspect source code. Especially in a situation where unusual things appear to happen, looking at the code may be useful.
In your case, we can inspect the source code of fs::dir_copy and trace back to which code generates the error message. If you type fs::dir_copy (no parenthesis) into the console, R will print the R code of the function (if the function is not primitive). Doing that here will show you that the fs:dir_copy function calls the fs::link_copyfunction. Makes sense, as the error message comes from this function.
We can now print this function with fs::link_copy
This function generates the error message in this line:
stopifnot(all(is_link(path)))
From the error message we know that all(is_link(path)) returns FALSE. Next step is to have a look at the fs::is_link function. Here we see that the error may come from the call to the setNames function, which depends on the fs::file_info function: res <- file_info(path)
Here we see that setNames is called with a condition depending on what the file_infofunction returned:
setNames(!is.na(res$type) & res$type == "symlink", res$path)
This looks unusual as setNames takes an object and a character vector as formals. But then, I am not the developer of these functions ;-)
Perhaps there are issues with the file type on your machine and fs::file_info(path) returns something unexpected under some conditions.
I tried using a for loop to print out a few rows. here is the code.
Weird thing is that it doesn't work for head() function. It works if I replaced head() with print().
kw_id=c('a','b')
keyword_text=data.frame(col=c('a','b'), col2=c(1,2), row.names=(c('r1','r2')))
for (i in 1:2) {
plot_data<-subset(keyword_text,col==kw_id[i])
print(plot_data)
head(plot_data)
}
Could someone help? I suspect it has something to do with head() function.
This is a relatively common class of problem that newcomers to R run into. The issue here is that R serves two mistresses: interactive console work and "true programming".
When you type a command at the console that returns a value, the console automatically calls a print method in order to display the results. When running a script, this doesn't happen unless you tell it to.
So if you changed it to print(head(plot_data)) it should work.
These are discussed in FAQ 7.16 and 7.22
Addendum lifted from the comments:
As Josh points out, copy+pasting the for loop directly to the console also fails to print any output. What's going on in that case is that for loops (like most everything in R) is actually a function, and it's return value (NULL) is returned invisibly, which means no printing. (This is mentioned in ?Control.)
Is there a way, in R, to pop up an error message if a function uses a variable
not declared in the body of the function: i.e, i want someone to flag this type of functions
aha<-function(p){
return(p+n)
}
see; if there happens to be a "n" variable lying somewhere, aha(p=2) will give me an "answer" since R will just take "n" from that mysterious place called the "environment"
If you want to detect such potential problems during the code-writing phase and not during run-time, then the codetools package is your friend.
library(codetools)
aha<-function(p){
return(p+n)
}
#check a specific function:
checkUsage(aha)
#check all loaded functions:
checkUsageEnv(.GlobalEnv)
These will tell you that no visible binding for global variable ‘n’.
Richie's suggestion is very good.
I would just add that you should consider creating unit test cases that would run in a clean R environment. That will also eliminate the concern about global variables and ensures that your functions behave the way that they should. You might want to consider using RUnit for this. I have my test suite scheduled to run every night in a new environment using RScript, and that's very effective and catching any kind of scope issues, etc.
Writing R codes to check other R code is going to be tricky. You'd have to find a way to determine which bits of code were variable declarations, and then try and work out whether they'd already been declared within the function.
EDIT: The previous statement would have been true, but as Aniko pointed out, the hard work has already been done in the codetools package.
One related thing that may be useful to you is to force a variable to be taken from the function itself (rather than from an enclosing environment).
This modified version of your function will always fail, since n is not declared.
aha <- function(p)
{
n <- get("n", inherits=FALSE)
return(p+n)
}