Rcpp: R_NewHashedEnv should not be in Rcpp?

Created on 14 Nov 2017  路  9Comments  路  Source: RcppCore/Rcpp

I am using the following code in my package:

...
Environment e = new_env();
...

I get the following:

* checking compiled code ... NOTE
File 'RxODE/libs/x64/RxODE.dll':
  Found non-API call to R: 'R_NewHashedEnv'

Compiled code should not call non-API entry points in R.

Apparantly, this isn't allowed for CRAN packages...?

This is called in the following file

https://github.com/RcppCore/Rcpp/blob/8f2a101789b29e572bf3abe5115d9ddb48c1b0c7/inst/include/Rcpp/Environment.h#L405

Hopefully this is reproducable enough for a bug report.

Most helpful comment

No problem from my end.

For me the following work-around suppressed the message:

      Environment base = R_BaseEnv;
      Function newEnv = as<Function>(base["new.env"]);
      Environment e = newEnv(_["parent"] = R_EmptyEnv);

Now I need to clean up the other messages.

All 9 comments

Here's my sessionInfo()

R version 3.4.2 (2017-09-28)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 14393)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C                          
[5] LC_TIME=English_United States.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] RxODE_0.6-3     devtools_1.13.3

loaded via a namespace (and not attached):
 [1] rex_1.1.2                 Rcpp_0.12.13             
 [3] xml2_1.1.1                magrittr_1.5             
 [5] roxygen2_6.0.1            lattice_0.20-35          
 [7] R6_2.2.2                  brew_1.0-6               
 [9] RcppArmadillo_0.8.100.1.0 dparser_0.1.8            
[11] stringr_1.2.0             tools_3.4.2              
[13] grid_3.4.2                R.oo_1.21.0              
[15] withr_2.1.0               commonmark_1.4           
[17] rprojroot_1.2             assertthat_0.2.0         
[19] lazyeval_0.2.1            digest_0.6.12            
[21] crayon_1.3.4              Matrix_1.2-11            
[23] R.utils_2.6.0             testthat_1.0.2           
[25] mvnfast_0.2.2             memoise_1.1.0            
[27] inline_0.3.14             stringi_1.1.5            
[29] compiler_3.4.2            backports_1.1.1          
[31] desc_1.1.1                PreciseSums_0.1          
[33] R.methodsS3_1.7.1        
> 

I don't know if you can petition to add something to the API; Otherwise the work-around is to use the R function directly, which isn't quite as efficient...

From a _very_ first glance (am at work ...) it seems as if

  • you call an API point we provide
  • R calls that point "verboten" and does not want you to use it.

There is no inherent conflict. CRAN controls what they allow, maybe what you did results in something that triggers this... I would start with the unit tests for environments and see if they get you by the warnings.

Thank you. That is how I read the situation too. I could provide a pull request to use the "R" base function, but hopefully there is a better solution (and I know you are quite capable of this too).

Sorry that I am rushed now. I am sure we do use environments in some places, some poking around should reveal that. We'll get this sorted out. Just not this evening unless someone else steps up :)

I agree that we should generally endeavor to make sure that the API provided by Rcpp uses the subset of the R API allowed by CRAN. Since R_NewHashedEnv() is disallowed we should consider calling new.env() directly.

No problem from my end.

For me the following work-around suppressed the message:

      Environment base = R_BaseEnv;
      Function newEnv = as<Function>(base["new.env"]);
      Environment e = newEnv(_["parent"] = R_EmptyEnv);

Now I need to clean up the other messages.

Agreed. No need to provide rope for others to stumble over.

Thanks.

Thanks for the report!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jgellar picture jgellar  路  8Comments

eddelbuettel picture eddelbuettel  路  3Comments

sgsokol picture sgsokol  路  7Comments

epipping picture epipping  路  7Comments

nettoyoussef picture nettoyoussef  路  6Comments