similar to: Warning when calling formals() for `[`.

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("+"))

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

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 :

Note that having "function" in its class attribute does not make an object a primitive. For example: > class(`[`) [1] "function" > is.primitive(`[`) [1] TRUE > class(`rnorm`) [1] "function" > is.primitive(`rnorm`) [1] FALSE Le dim. 7 oct. 2018 ? 10:04, Rui Barradas <ruipbarradas at sapo.pt> a ?crit : > Hello, > > I don't see why you

> 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 seems to be wrong: > > > class(args(`+`)) > #[1] "function" > > > args() on a primitive does return a closure. At least in this case it does. But in this case it doesn't: >

There is more "fun" afoot here, but I don't recall what the point may be: > args(get("+")) function (e1, e2) NULL > args(get("[")) NULL > get("[") .Primitive("[") > get("+") function (e1, e2) .Primitive("+") The other index operators, "[[", "[<-", "[[<-" are similar The

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

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

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, 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 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

> 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

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

? 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

2008/5/19 Prof Brian Ripley <ripley at stats.ox.ac.uk>: > Where is the bug here? It also does on a Unix-alike. Then "R CMD config --help" could at least spit out an error stating what should be installed (rather than die with an execution error straight from the DOS). Setting an "sh" in the %Path% (sh coming from cygwin) does not seem to lead to something working

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