search for: warnpartialmatchargs

Hi all (but especially Kurt), Would it be possible to have a flag to R CMD check that warned on partial all matches, i.e. turning on: options( warnPartialMatchDollar = TRUE, warnPartialMatchArgs = TRUE, warnPartialMatchAttr = TRUE ) I think this is good practice for package code. I don't think it can currently be made part of the default (because sometimes the warnings come from other packages), but it would be really convenient to have as a switch. Hadley -- http://had.co.nz/

Hello, I'm seeing a nuisance warning when I run `R CMD check --as-cran whatever_x.y.z.tar.gz`. I generally work with these options set: options( warnPartialMatchArgs = TRUE, warnPartialMatchAttr = TRUE, warnPartialMatchDollar = TRUE ) And I see this: * checking use of SHLIB_OPENMP_*FLAGS in Makefiles ...Warning in dir("src", patt = "[.]c$") : partial argument match of 'patt' to 'pattern' Warning in dir("src"...

...efault behavior of R where it allows for partial argument names. I don't think there's much that can be done here except always using fully named arguments to the "apply" function itself as you show. You can "alert" yourself when there's a mistake by using: options(warnPartialMatchArgs = TRUE) e.g. > clusterApply(clu, x = 1:2, fun = fun, c = 1) ## Error Warning in clusterApply(clu, x = 1:2, fun = fun, c = 1) : partial argument match of 'c' to 'cl' Error in checkCluster(cl) : not a valid cluster It's still only a warning, but an informative one. /Henrik...

Hi! I recognized that the argument matching of clusterApply (and therefore parLapply) goes wrong when one of the arguments of the function is called "c". In this case, the argument "c" is used as cluster and the functions give the following error message "Error in checkCluster(cl) : not a valid cluster". Of course, "c" is for many reasons an unfortunate

...ument names. I >> don't think there's much that can be done here except always using >> fully named arguments to the "apply" function itself as you show. >> >> You can "alert" yourself when there's a mistake by using: >> >> options(warnPartialMatchArgs = TRUE) >> >> e.g. >> >>> clusterApply(clu, x = 1:2, fun = fun, c = 1) ## Error >> Warning in clusterApply(clu, x = 1:2, fun = fun, c = 1) : >> partial argument match of 'c' to 'cl' >> Error in checkCluster(cl) : not a valid cluster >&...

...rgs <- c(list(max.level = max.level, give.attr = give.attr, - digits = digits), args) + digits.d = digits), args) for(nam in x) { cat(nam, ": ") ## check missingness, e.g. inside debug(.) : Example: $ R --quiet --vanilla > options(warnPartialMatchArgs = TRUE, warn = 2) > x <- 1 > ls.str() x : Error in str.default(o, ...) : (converted from warning) partial argument match of 'digits' to 'digits.d' > traceback() 10: doWithOneRestart(return(expr), restart) 9: withOneRestart(expr, restarts[[1L]]) 8: withRestarts({...

...fault behavior of R where it allows for partial argument names. I don't think there's much that can be done here except always using fully named arguments to the "apply" function itself as you show. You can "alert" yourself when there's a mistake by using: options(warnPartialMatchArgs = TRUE) e.g. > clusterApply(clu, x = 1:2, fun = fun, c = 1) ## Error Warning in clusterApply(clu, x = 1:2, fun = fun, c = 1) : partial argument match of 'c' to 'cl' Error in checkCluster(cl) : not a valid cluster It's still only a warning, but an informative one. /Henri...

...t allows for partial argument names. I > don't think there's much that can be done here except always using > fully named arguments to the "apply" function itself as you show. > > You can "alert" yourself when there's a mistake by using: > > options(warnPartialMatchArgs = TRUE) > > e.g. > >> clusterApply(clu, x = 1:2, fun = fun, c = 1) ## Error > Warning in clusterApply(clu, x = 1:2, fun = fun, c = 1) : > partial argument match of 'c' to 'cl' > Error in checkCluster(cl) : not a valid cluster > > It's still only a w...

Hello. First, I'm thankful about your wonderful project. However, I have serious worries about the reliability of R. I found the next bug which I consider important because in my job everytime We work with datanames like next. Please see below: b=data.frame(matrix(1:9,ncol=3)) names(b)=c("q99","r88","s77") >b q99 r88 s77 1 1 4 7 2 2 5 8 3

...low an IDE, for example, to provide a dialog for > choosing the alternate package and retrying without the need to call > library() again. [...] I also think such a framework could replace some of the "legacy handlers" we currently have in place, e.g. R options 'warn', 'warnPartialMatchArgs', '...', and even 'error', and give more granular control over those use cases. For instance, instead of a warning or a partial argument match, I might want to produce an error unless it comes from one particular package, say, which is something that is a bit tricky to do today...

Hi Luke, Thank you for your response. On 6/21/19 10:56 AM, Tierney, Luke wrote: Thanks for the suggestion. However I don't think it is the right way to go. I also don't care for what install.packages() does. Signaling a warning and then an error means someone has to catch both the error and the warning, or suppress the warning, in order to handle the error programmatically. I do care

...h a change, but I'm completely out of control if one of the package I'm depending on does not provide a quick fix (with the only option to remove package tests for those dependencies). My idea is that with this option, then this can be tested at runtime locally by users and developers (cf. warnPartialMatchArgs), but also via R CMD check. It would also provide CRAN with a way to check it on incoming submissions as on the test farm - eventually all CRAN packages pass without errors. This option would only exist for a number of R releases (first default to FALSE, then TRUE) and then eventually be deprecat...

I'd like to propose that the whenever the length of condition passed to an if or a while statement differs from one, an error is produced rather than just a warning as today: > x <- 1:2 > if (x == 1) message("x == 1") x == 1 Warning message: In if (x == 1) message("x == 1") : the condition has length > 1 and only the first element will be used There are

...9;showErrorCalls' to give a concise traceback on warnings and errors. showErrorCalls=TRUE is the default for non-interactive sessions. Option 'showNCalls' controls how abbreviated the call sequence is. o New options 'warnPartialMatchDollar', 'warnPartialMatchArgs' and 'warnPartialMatchAttr' to help detect the unintended use of partial matching in $, argument matching and attr() respectively. o A device named as a character string in options(device =) is now looked for in the grDevices name space if it is no...

...9;showErrorCalls' to give a concise traceback on warnings and errors. showErrorCalls=TRUE is the default for non-interactive sessions. Option 'showNCalls' controls how abbreviated the call sequence is. o New options 'warnPartialMatchDollar', 'warnPartialMatchArgs' and 'warnPartialMatchAttr' to help detect the unintended use of partial matching in $, argument matching and attr() respectively. o A device named as a character string in options(device =) is now looked for in the grDevices name space if it is no...