similar to: Spurious warning when calling data() ?

Hi, I just stumbled on the following apparent oddity: the package "datasets" does not appear to export anything out of its namespace: > ns_datasets <- getNamespace('datasets') > getNamespaceExports(ns_datasets) character(0) Not the case with other packages (example here with "utils"): > ns_utils <- getNamespace('utils') >

Hello, I don't see why you say that the documentation seems to be wrong: class(args(`+`)) #[1] "function" args() on a primitive does return a closure. At least in this case it does. Rui Barradas ?s 14:05 de 07/10/2018, Peter Dalgaard escreveu: > There is more "fun" afoot here, but I don't recall what the point may be: > >> args(get("+"))

Hi, A short code example showing the warning might the only thing needed here: ``` > formals(args(`[`)) NULL *Warning message:In formals(fun) : argument is not a function* > is.function(`[`) [1] TRUE > is.primitive(`[`) [1] TRUE ``` Now with an other primitive: ``` > formals(args(`sum`)) $... $na.rm [1] FALSE > is.function(`sum`) [1] TRUE > is.primitive(`sum`) [1] TRUE

Hi again, Beside R_ParseVector()'s possible inconsistent behavior, R's handling of zero-length named elements does not seem consistent either: ``` > lst <- list() > lst[[""]] <- 1 > names(lst) [1] "" > list("" = 1) Error: attempt to use zero-length variable name ``` Should the parser be made to accept as valid what is otherwise possible

Thanks for the quick response Tomas. The same error is indeed happening when trying to have a zero-length variable name in an environment. The surprising bit is then "why is this happening during parsing" (that is why are variables assigned to an environment) ? We are otherwise aware that the error is not occurring in the R console, but can be traced to a call to R_ParseVector() in

Le lun. 9 d?c. 2019 ? 09:57, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/9/19 2:54 PM, Laurent Gautier wrote: > > > > Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a > ?crit : > >> On 12/7/19 10:32 PM, Laurent Gautier wrote: >> >> Thanks for the quick response Tomas. >> >> The same error

Hi Simon, Widespread errors would have caught my earlier as the way that code is using only one initialization of the embedded R, is used quite a bit, and is covered by quite a few unit tests. This is the only situation I am aware of in which an error occurs. What is a "correct context", or initial context, the code should from ? Searching for "context" in the R-exts manual

Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/7/19 10:32 PM, Laurent Gautier wrote: > > Thanks for the quick response Tomas. > > The same error is indeed happening when trying to have a zero-length > variable name in an environment. The surprising bit is then "why is this > happening during parsing" (that is why

Hi, The behavior of ``` SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP); ``` defined in `src/include/R_ext/Parse.h` appears to be inconsistent depending on the string to be parsed. Trying to parse a string such as `"list(''=1+"` sets the `ParseStatus` to incomplete parsing error but trying to parse `"list(''=123"` will result in R sending a message to the

Hi, I was recently pointed out that a definition in Rinterface.h can be conflicting with a definition in stdint.h: /usr/include/R/Rinterface.h has: typedef unsigned long uintptr_t; /usr/include/stdint.h has: typedef unsigned int uintptr_t; (when 32bit platform complete definition is: #if __WORDSIZE == 64 # ifndef __intptr_t_defined typedef long int intptr_t; # define

> On Jan 1, 2017, at 5:12 PM, Laurent Gautier <lgautier at gmail.com> wrote: > > > > 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <ripley at stats.ox.ac.uk>: > On 29/12/2016 15:55, Simon Urbanek wrote: > The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now

On 29/12/2016 15:55, Simon Urbanek wrote: > The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now fixed in R-devel - please check if that works for you. Rconfig.h would be appropriate if Rinterface.h is being included from C code using the same compiler as used for R. But as Rinterface.h

Hi, When starting an embedded R I encounter the following issue under certain conditions: ``` Error: package or namespace load failed for ?utils? in if (.identC(class1, class2) || .identC(class2, "ANY")) TRUE else {: missing value where TRUE/FALSE needed ``` (more such errors for grDevices, graphics, and stats) And in the end: ``` Warning messages: 1: package ?utils? in

rPython appears to provide an interface from R to Python by embedding Python and I'd think that it can safely assume that R has been initialized, but might not be the point here. The issue is that a Python package embedding itself R (here rpy2) appears to have no way to know that earlier in the life of the process R was initialized. 2015-05-03 19:48 GMT-04:00 Duncan Murdoch

Dear list, Please consider the following call of sort > sort(c("a","f")) [1] "a" "f" > sort(c("f","a")) [1] "a" "f" > > sort(c("aa","ff")) [1] "ff" "aa" > sort(c("ff","aa")) [1] "ff" "aa" The last two results look strange

Dear List, Would anyone know how to perform prepared queries with ROBC ? I had a shot with some of the internal (non-exported) functions of the package but ended up with a segfault, so I prefer asking around before experimenting further... Thanks, Laurent

Dear list, When calling R from C, what appears like a spurious error can be triggered during the execution of chisq.test(x, y). This is happening when the following conditions are met: - x and y are "anonymous" C-level R vectors (they do not have a symbol), but they are protected from garbage collection - x and y are "not too small" (it was experienced as soon as they are

Hello, This is because args(`[`) returns NULL and class(NULL) is NULL. So the question would be why is the return value of args(`[`) NULL? Rui Barradas ?s 15:14 de 07/10/2018, Peter Dalgaard escreveu: > > >> On 7 Oct 2018, at 16:04 , Rui Barradas <ruipbarradas at sapo.pt> wrote: >> >> Hello, >> >> I don't see why you say that the documentation

? Sun, 23 Apr 2023 13:33:16 -0400 Laurent Gautier <lgautier at gmail.com> ?????: > When tracing what happens during an error I found that > verrorcall_dflt() in src/main/errors.c calls PrintWarnings(). That > function is not part of R's C-API though. I've tried reading the source code and came to a similar conclusion. PrintWarnings() is required for warnings() to work

Hi, Thanks for the note. How would explain the following snippet taken from `formals` doc page (the code comment is also from that doc) ? ## formals returns NULL for primitive functions. Use it in combination with ## args for this case. is.primitive(`+`) formals(`+`) formals(args(`+`)) Le sam. 6 oct. 2018 ? 13:42, Rui Barradas <ruipbarradas at sapo.pt> a ?crit :