similar to: C-API: removing key-value pairs in an environment

While poking around the C++ code in the dplyr package I ran across the idiom Rf_defineVar(symbol, R_UnboundValue, environment) to [sort of] remove 'symbol' from 'environment' Using it makes the R-level functions objects(), exists(), and get() somewhat inconsistent and I was wondering if that was intended. E.g., use SHLIB to make something from the following C code that

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

The Rcpp package and some related packages such as RcppArmadillo make use of (local) wrappers around the utils::package.skeleton() function for creating (basic yet functional) packages using Rcpp or RcppArmadillo. RStudio also exposes this under the graphical menu as a nice way to construct a package. But it seems that something changed quite recently in R. I looked into this a little yesterday

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

Hello, I'm currently working on making Rcpp use the feature described here more: http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages To give more context, Rcpp has for a long time built what we called "the Rcpp user library", i.e. a library we could link against user the linker. We were then producing appropriate linker flag with

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

Hello,?I?am experiencing some difficult time with my R package. Every time I compilei it a hidden file, desktop.ini, is?being created. I am using C++ behind, linkking to Rcpp. The file is generated even when I compile it with?Linux, and in many different computers. Does anybody have any advice or ideas? [[alternative HTML version deleted]]

I have two questions about the CRAN machines that build binary packages for Mac. When a new version of a package is released, (A) Do the downstream dependencies get re-checked? (B) Do the downstream dependencies get re-built? I have heard (but do not know for sure) that the answer to (A) is no, the downstream dependencies do not get rechecked. >From publicly available information on the

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

Make a reproducible example [1][2][3], because it doesn't happen for me. Then post your example at [4] or [5], because this is the wrong list for this question. You may find that the act of browsing the directory using a GUI is what creates that file rather than the compilation itself. [1] http://stackoverflow.com/questions/5963269/how-to-make-a-great-r-reproducible-example [2]

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

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

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

> Shield<SEXP> res(Rcpp_fast_eval(Rf_lang2(asEnvironmentSym, x), R_GlobalEnv)); The call should be protected before evaluation though. So more like: Shield<SEXP> call(Rf_lang2(asEnvironmentSym, x)); return Rcpp_fast_eval(call, R_GlobalEnv); Best, Lionel On 3/23/20, Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 23 March 2020 at 17:07, Ben Bolker wrote: >

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