Trying to figure out why I am getting this error (never seen it before, google is no help):
Error in check_dots_used(action = warn) : unused argument (action = warn)
I am getting the error for the very basic trial below, but also for group_by/count, but not filter or select.
x <- c(1, 2, 3, 4, 5)
y <- runif(5)
tibble(x, y)
Error in check_dots_used(action = warn) : unused argument (action = warn)
I had the same problem: urganmax's solution to update to ellipsis-0.3.1 in a comment did it for me. Moving this as an answer so it is easier to find.
I had to update/re-install tidyverse and the ellipsis package explicitly:
install.packages("tidyverse")
install.packages("ellipsis")
Then restart your session and library your packages (or unload and reload your packages).
I'm pretty certain that your version of the ellipsis package (part of the tidyverse) is out of sync with the other tidyverse packages you have. update.packages() should work ... (if you want to live dangerously, update.packages(ask=FALSE) to update all packages without asking for confirmation for each one).
From the tidyverse NEWS file:
All functions that take ... have been instrumented with functions from the ellipsis package to warn if you’ve supplied arguments that are ignored (typically because you’ve misspelled an argument name) (#573).
Related
Everytime I load the dplyr package the console shows a warning message.
warning message Some objetcs are masked from other packages. I think this is because the objects have the same name. For example:
Filter has this usage in dplyr packagefilter(.data, ..., .preserve = FALSE)
Filter has this usage in stats package filter(x, filter, method = c("convolution", "recursive"), sides = 2, circular = FALSE, init)
How can I unmask the filter object from stats package if I need to use it?
Regards
You are correct that they are simply packages that share the same name. The comments above basically answer the question already. Theoretically if you have a conflict of functions you want to avoid, you can also select which you prefer, like so:
library(conflicted)
conflict_prefer("slice", # the function
"dplyr") # the package
And R will tell you which it will use as your primary:
[conflicted] Will prefer dplyr::slice over any other package
However that is an extra step and I prefer usually to name it explicitly like dplyr::slice as mentioned in the comments instead.
I sometimes load multiple packages that export functions of the same name. For example, both Hmisc and dplyr have a summarize function, and I sometimes load both packages. I then call summarize, thinking that I am calling dplyr::summarize when I am really calling Hmisc::summarize. When that happens, I get an error message like this:
Error in summarize(., mean = mean(instRating)) :
argument "by" is missing, with no default
The message is initially hard to understand, because my code contains no errors. It takes me a minute to realize that I've called a function in the wrong package. The error message would be easier to understand if its first line included the name of the relevant package:
Error in Hmisc::summarize(., mean = mean(instRating)) :
Is there a way to force R to display the package name in these error messages?
I know that I can get around the problem by typing out dplyr::summarize or by changing the order in which I load packages. But my interest lies with adding detail to R's error messages.
From the documentation of the base option error:
'error': either a function or an expression governing the handling
of non-catastrophic errors such as those generated by 'stop'
as well as by signals and internally detected errors. If the
option is a function, a call to that function, with no
arguments, is generated as the expression. By default the
option is not set: see 'stop' for the behaviour in that case.
The functions 'dump.frames' and 'recover' provide
alternatives that allow post-mortem debugging. Note that
these need to specified as e.g. 'options(error =
utils::recover)' in startup files such as '.Rprofile'.
So it should be possible to define a function that returns the name of the package where the function that’s throwing the error lives. For example:
library(dplyr)
library(Hmisc)
data(mtcars)
print_package <- function() {
calls <- sys.calls()
call <- calls[[length(calls) - 1]]
fun.name <- as.character(call)[1]
pkg.name <- sub("package:", "", getAnywhere(fun.name)$where[1], fixed = TRUE)
message (paste0("In ", pkg.name))
}
options(error = print_package)
summarize(mtcars$mpg)
Returns:
Error in summarize(mtcars$mpg) :
argument "by" is missing, with no default
In Hmisc
Edit (using rlang::trace_back)
It turns out that there is a much cleaner way of doing this (credit goes to Hadley Wickham and his "Advanced R, Second edition"):
library(dplyr)
library(Hmisc)
data(mtcars)
print_trace_back <- function() {
print(rlang::trace_back(bottom = sys.frame(-1)))
}
options(error = print_trace_back)
Seems to handle errors gracefully:
> summarize(mtcars$mpg)
Error in summarize(mtcars$mpg) :
argument "by" is missing, with no default
█
1. └─Hmisc::summarize(mtcars$mpg)
>
> Hmisc::summarize(mtcars$mpg)
Error in Hmisc::summarize(mtcars$mpg) :
argument "by" is missing, with no default
█
1. └─Hmisc::summarize(mtcars$mpg)
>
> summarize(mtcars$mpg, as.character(mtcars$apa), mean)
Error in tapply(X, INDEX, FUN, ..., simplify = simplify) :
arguments must have same length
█
1. └─Hmisc::summarize(mtcars$mpg, as.character(mtcars$apa), mean)
2. └─Hmisc::mApply(X, byc, FUN, ..., keepmatrix = nc > 1)
3. └─base::tapply(X, INDEX, FUN, ..., simplify = simplify)
4. └─base::stop("arguments must have same length")
>
> (function() stop("Error"))()
Error in (function() stop("Error"))() : Error
█
1. └─(function() stop("Error"))()
2. └─base::stop("Error")
You can try conflict_prefer("summarize", "dplyr") from conflicted package by Hadley Wickham. One drawback is that you need to identify winner for every conflict.
I want to use mice function to handle the missing data that I have in (data). I installed the package and I called the library. However, when I am trying to apply the function to my data it gives me error as below:
(Error in mice(data[, 5:9], m = 3, seed = 123) :
could not find function "mice")
I have a normal data frame that includes NAs
install.packages('mice')
library(mice)
library(VIM)
md.pattern(data)
md.pairs(data)
My_New_Data <- mice(data[,5:9], m=3, seed=123)
I am expecting the function to solve the problem and replace the NAs with reasonable values. It did not work at all!
Edit (incorporating comment suggestion)
In the comments the running mice::mice(data[, 5:9], m = 3, seed = 123). I ran this and the following error was returned.
Error in get(Info[i, 1], envir = env):
lazy-load database 'C:/Users/MUSTAFA KAMAL/Documents/R/win-library/3.5/broom/R/broom.rdb' is corrupt
In addition:
Warning message: In get(Info[i, 1], envir = env) : internal error -3 in R_decompress1
In order to incorporate an answer to this question, I will rewrite my comment which resolved the problem, in the form of a short answer.
From the comments executing mice::mice(data[, 5:9], m = 3, seed = 123) resulted in an error message, showing the directory ~/Documents/R/win-library/**3.5**/broom/R/broom.rdb being corrupt.
From the corrupted directory path, one can see that OP was running R-3.5.x, while the newest version is R-3.6.x. Some packages updated since the most recent R-update has experienced similar problems, as such a first step towards solving these types of issues is updating R. The installr contains the function updateR which can help smooth over such updates, while also updating any outdated packages.
As a side note, an update sometimes fails to update the actual packages or results in other packages being corrupted, as such if an error persists one solution is to simply delete and re-install the package (or the entire ~/Documents/R/win-library/3.z/ directory). In the question from OP the corrupt package is the broom package, as such one could re-install this package by running
remove.packages("broom")
install.packages("broom")
which should resolve any leftover issues. Note however multiple packages might be corrupt, and likely only one will be shown every time the function is executed. In such cases a full package clear will do the trick, but requires re-installing all packages. For this one can export all installed packages prior to removing them all, by noting that a full list of installed packages is contained in installed.packages(), which can then be exported to a file with for example write.table or write.csv.
Preamble
I commonly use dplyr in my packages. Prior to 0.7.0, I was using the underscored versions of dplyr verbs to avoid NOTEs during R CMD CHECK. For example, the code:
x <- tibble::tibble(v = 1:3, w = 2)
y <- dplyr::filter(x, v > w)
would have yielded the R CMD CHECK NOTE:
* checking R code for possible problems ... NOTE
no visible binding for global variable ‘v’
By comparison, using the standard evaluation version:
y <- dplyr::filter_(x, ~v > w)
yielded no such NOTE.
However, in dplyr 0.7.0, the vignette Programming with dplyr says that the appropriate syntax for including dplyr functions in packages (to avoid NOTEs) is:
y <- dplyr::filter(x, .data$v > .data$w)
Consequently, the news file says that "the underscored version of each main verb is no longer needed, and so these functions have been deprecated (but remain around for backward compatibility)."
Question
The vignette says that the above new syntax will not yield R CMD check NOTES, "provided that you’ve also imported rlang::.data with #importFrom rlang .data." However, when I run the code:
y <- dplyr::filter(x, rlang::.data$v > rlang::.data$w)
Evaluation error: Object `From` not found in data.
Is this error similar to the following?
y <- dplyr::filter(x, v == dplyr::n())
Evaluation error: This function should not be called directly.
Namely, for some functions, calling them prefixed with the package yields errors? (Something to do with whether or not they've been exported, perhaps?)
Comment
As an aside, is there a less verbose way of writing package-friendly dplyr functions with the new syntax in 0.7.0? In particular, the syntax for dplyr >=0.7.0:
y <- dplyr::filter(x, .data$v > .data$w)
is more verbose than the syntax for dplyr <0.7.0:
y <- dplyr::filter_(x, ~v > w)
and the verbosity increases as more variables are referenced. However, I don't want to use the less verbose syntax with the underscored version, as it is deprecated.
for some functions, calling them prefixed with the package yields errors?
That's right, but we could make them work to make things more predictable. You can file a github issue for this feature.
is there a less verbose way of writing package-friendly dplyr functions with the new syntax in 0.7.0?
The alternative is to declare all your column symbols to R, e.g. within a globalVariables(c("v", "w")) statement somewhere in your package.
Ideally, R should know about NSE functions and never warn for unknown symbols in those cases.
Another work-around is to add lines such as
v <- NULL; # mark as not an unbound global reference
just above your expressions that are generating CRAN checks. It is no less accurate (column names are not in fact global variables) and has somewhat limited scope.
I have written the Boggler package which includes a Play.Boggle() function that calls, on line 87, a progress bar script using shell:
shell(cmd = sprintf('Rscript.exe R/progress_bar.R "%i"', time.limit + 1), wait=FALSE)
Everything works fine when sourcing the files individually and then calling the main Play.Boggle() function, but when I try to check/build the package (under Win7-64 using RStudio), I get a failure message -- here's what the 00install.out reports:
** preparing package for lazy loading
Warning in eval(expr, envir, enclos) : NAs introduced by coercion
Error in time.limit:0 : NA/NaN argument
To make sure the argument "%i" (time.limit + 1) was correctly passed to the progress_bar.R, I added a cat(time.limit) to the script (commenting the rest out to make sure the package would build without any errors) and directed its output to a log file like this:
'Rscript.exe R/progress_bar.R "%i" > out.log'
Conclusion: the time limit is indeed passed along as expected. So I can't figure out why I get this "NA/NaN argument" error message. It must have something to do with lazy loading, concept that I haven't fully got my head around yet.
So my question is: what can I do to successfully check/build this package with full functionality (including progress_bar.R)?
Note: On github, the progress_bar.R script is there but all its content is commented out so that the package can successfully be installed. The shell(...) function call is still active, doing nothing but executing an empty script.
So the problem arises when trying to build or check, in which case all R scripts are executed, as pointed out by Roland. A simple workaround allows the package to check/build without any problems. The fix is just to add to the progress_bar.R the following lines after it tries to recuperate the commandargs (lines 10-11):
if(time.limit %in% c(NA, NaN))
time.limit <- 10 # or any minimal number
There's surely other ways to go about this. But this being a game programmed for fun, I'll happily go with that patch. Hopefully this can be of help to someone down the road and I won't have wasted 50 precious rep points in vain for that bounty! :D