The last few days I have been using a lot RcppArmadillo. I have been working on a 3D arrays convolution project. After the initial steep learning curve I managed to create some useful C++ routines using Armadillo. Kudos to Dirk.
Then suddenly RcppArmadillo started doing weird things; I kept getting this message:
Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
It is good practice to register native routines and to disable symbol
search.
This happens in Windows 10. In Linux you may receive the same message but it is quickly fixable with RcppArmadillo::RcppArmadillo.package.skeleton() or following the new instructions in Writing R Extensions - 5.4 Registering native routines. In Windows THIS WILL NOT WORK, though. Why?
To isolate the problem I started with a Virtual Machine (VM) with a fresh R (3.4.1). When you start with the demo that RcppArmadillo builds, it will build the demo without hiccups, no notes, no warning messages. As soon as you install devtools the problems with RcppArmadillo begin.
To reproduce this, you can do the following: (1) start with a fresh R and install the packages required to run only to build your-package with RcppArmadillo (a couple). (2) Build your demo package. You will get no errors. (3) Download the source of any of these packages that I tested: gckrig, GAS, abcrf, AbsFilterGSEA, Amelia, MAVE, SparseFactorAnalysis, RcppProgress, artfima, geospt. All of them use RcppArmadillo. They should build OK providing you fed them with their dependencies. (4) Now, install devtools. Immediately after you will start receiving the message:
Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
It is good practice to register native routines and to disable symbol
search
No mater what I did, I could not get rid off the note. I tried the same packages in Linux and no issue at all. This causes delay because one cannot submit a package to CRAN with that message.
(5) Now, if you uninstall devtools and dependencies and try again building any RcppArmadillo package; NO MORE message register native routines. Beautiful.
I wonder why devtools is causing this conflict. How can we get this fixed? I love devtools but have to keep it uninstalled if I have to work with RcppArmadillo. Tough choices.
EDIT
This is fully reproducible. Here are the steps to reproduce the behavior:
(1) start with a fresh R and install the packages required to build your-package with RcppArmadillo (a couple). Do not install devtools.
(2) Build your demo package. You will get no register native routines errors.
(3) Download the source of any of these packages that I have tested: gckrig, GAS, abcrf, AbsFilterGSEA, Amelia, MAVE, SparseFactorAnalysis, RcppProgress, artfima, geospt. All of them use RcppArmadillo. They should build OK providing you fed them with their dependencies.
(4) Now, install devtools. Try building again with any of the packages above. Immediately after you will start receiving the message: register native routines.
(5) Now, if you uninstall devtools and dependencies and try building again any RcppArmadillo package; no more messages related to register native routines.
EDIT
This has been tested with three Windows 10 virtual machine instances installing R 3.4.1, Rtools from scratch. In all the tests, building packages with RcppArmadillo finish with the message register native routines. If you try to build in Linux -the same package- it will pass with no notes.
Related
I have a problem with parallel estimation of random survival forest from randomForestSRC package. I have followed the this guide and tried installing it on Mac (Sierra). However, the rfsrc() function still runs on a single thread. Could you please advice what to do in order to achieve parallel execution, as the function takes ages to compute on a larger dataset. I have directly followed the steps described in the tutorial and no success.
Thanks in advance!
The guide noted in your question is from 2013 and the process for successful OpenMP parallel execution has been significantly streamlined since then. In fact, the binaries available on CRAN for the current build (2.5.1) should run in parallel on Sierra. The source code includes a ready-made configure file that is the result of the autoconf command. Thus, parallel execution is the default behaviour now. If you haven't yet upgraded to the latest build, I would recommend doing so. If the binary build provided by CRAN still does not switch on parallel execution, I would recommend upgrading your compiler to GCC using Homebrew or another package manager, and then appropriately create and massage a Makevars file as given in the instructions on our GitHub page so as to allow the CRAN package installation process to pick up the GCC compiler instead of the default Clang compiler:
https://kogalur.github.io/randomForestSRC/building.html
My end goal is to be able to use the geoR and sp packages in R on an AWS EC2 Linux instance. The first hurdle is getting an older version of R since 3.3 doesn't support TCL/TK (at least that I've found).
After unpacking R-3.2.5.tar.gz and following the instructions in the INSTALL file (along with these configure options), a search in the config.log shows the following for TCL and TK:
configure:32908: checking for tclConfig.sh
configure:32950: checking for tclConfig.sh in library (sub)directories
configure:33143: checking for tcl.h
conftest.c:228:17: fatal error: tcl.h: No such file or directory
#include <tcl.h>
config.status:1893: creating src/library/tcltk/DESCRIPTION
config.status:1893: creating src/library/tcltk/Makefile
config.status:1893: creating src/library/tcltk/src/Makefile
ac_cv_env_TCLTK_CPPFLAGS_set=
ac_cv_env_TCLTK_CPPFLAGS_value=
ac_cv_env_TCLTK_LIBS_set=
ac_cv_env_TCLTK_LIBS_value=
r_cv_header_tcl_h=no
TCLTK_CPPFLAGS=''
TCLTK_LIBS=''
TCL_CONFIG=''
use_tcltk='no'
R installs successfully, but running capabilities("tcltk") confirms that something went wrong, as it returns FALSE.
Following the hints here, I searched for tclConfig.sh and tkConfig.sh, and realized I hadn't installed the appropriate dependencies, namely tcl-devel, and tk-devel.
Running yum list available shows a package for tcl-devel.x86_64 but nothing for tk. I downloaded source files for TCL and TK from here, but couldn't find source files for any devel packages.
So now I'm at a loss on how to proceed. Has anyone been through this process that can shed some light on it?
UPDATE
After reading the comment below, I'm afraid I didn't do my due diligence in researching TCL/TK and R 3.3.
My very early efforts to troubleshoot the whole problem consisted of the following workflow- First, without even considering an older version of R, I ran install.packages("geoR") in 3.3.2. This resulted in installation of package 'geoR' had non-zero exit status, along with:
Error: package 'tcltk' does not have a namespace
ERROR: lazy loading failed for package 'geoR'
So, naturally, I ran install.packages("tcltk") which resulted in package 'tcltk' is not available (for R version 3.3.2)
As I mentioned before, this was very early on. I took the message literally and didn't think to look further into TCL/TK for 3.3, but instead started looking to get an earlier version of R, since I had been successfully running geoR and sp on another system that had R 3.2.5.
I´m developing an R package in RStudio and a set a local library to contain all my packages. After installing some updates in my Ubuntu system, it seems that my R Project have lost track of the local library and is unable to load the libraries that were associated with it. If I try to Build & Reload the package with
R CMD INSTALL --no-multiarch --with-keep.source mypackage
The program tries to install to library '/usr/local/lib/R/site-library/' which is rejected with:
ERROR: No permission to install to directory '/usr/local/lib/R/site-library/'
As far as I remember, whenever I rebuilt my package, that line pointed to my local directory, where all my libraries were localted
installing to library ‘/home/user/R/x86_64-pc-linux-gnu-library/3.2’
It is clear that somehow R have lost track of the connection between the project and the libraries.
I tried re-including the path with
.LibPaths("/home/user/R/x86_64-pc-linux-gnu-library/3.2")
but, just after I rebuild the package again, the program created a 3.3 directory in x86_64-pc-linux-gnu-library. From there, it is unable to find the libraries that are associated to my program and throws another error:
ERROR: dependencies '...', '...' are not available for package "mypackage"
Is there a way to restore the program to the way it was before so I don't have to reinstall everything and start from scratch?
By default, R adds the major-minor version numbers to the library path (?.libPaths) for a good reason, assuming that the jump from 3.2 to 3.3 introduced efficiencies or incompatibilities. It is implied that this version jump requires new installation of packages.
If you override this, packages assembled in 3.2 may not always play nicely in 3.3. (I'm not going to test this theory, please report back if you can disprove this statement, I'm honestly interested!)
BTW: your call to .libPaths seems suspect: I don't know of a capital-L version, and when calling it you should include the previous path (unless you truly mean to omit the system R library paths entirely), such as:
.libPaths("/home/user/R/x86_64-pc-linux-gnu-library/3.2", .libPaths())
If you choose to do that, any bugs you may find in others' packages are possibly due to that incompatibility and should not necessarily be reported to developers.
Another option would be to re-install all packages from your 3.2 installation into your 3.3 library path. Something like this should help automate the process:
# to reinstall packages installed in R-3.2 subdir into R-3.3
install.packages(list.files(path = "~/R/x86_64-pc-linux-gnu-library/3.2"))
Some time ago, you used to be able to install the rcom package in R to use COM scripting (eg, access to external programs.) Unfortunately, it seems to be discontinued:
Package ‘rcom’ was removed from the CRAN repository.
Formerly available versions can be obtained from the archive.
This depends on statconnDCOM, which nowadays restricts use, contrary
to the CRAN policy for a package with a FOSS licence. See
http://rcom.univie.ac.at/ and http://www.statconn.com/.
Following the archive and statconn links and installing one of the older versions in R version 3 gives the error:
“Error: package ‘rcom’ was built before R 3.0.0: please re-install
it”.
I am not very familiar with R, but there seems no way around this message - after all, it occurs when installing, so re-installing doesn't seem to be the answer. It appears as though rcom is simply not available for recent (3.0+) versions of R. I have also scanned the package list, although searching for "COM" there returns over a hundred results and it is possible I missed the right one when clicking through them.
How can I use the rcom package, or use COM from within R some other way?
(Note: I am asking this question on behalf of a colleague. I have no experience with R myself at all. Both of us, when searching for answers, could not find anything. I am sure that others are also using COM in the latest version of R, though!)
I looked at the rcom source code a few months ago. It seems I can get it to build and install OK on R3.0.1. Below is the procedure if it helps.
Get a checkout of the latest source code of rcom. I have rcom_2.2-5.tar.gz locally. I can google something at the following address, but I have no idea of the provenance, so up to you to check it is legit. http://cran.open-source-solution.org/web/packages/rcom/index.html
in R do install.packages('rscproxy')
install Rtools as per the instructions on the R web site (http://cran.r-project.org/bin/windows/Rtools),
open a Windows command prompt i.e. run "CMD"
go to the folder containing the 'rcom' folder, and at the command prompt:
set R="c:\Program Files\R\R-3.0.1\bin\i386\R.exe"
%R% CMD check --no-manual rcom
check it passes without too many complaints. Your call as to the --no-manual option (if you have MiKTeX installed you may remove it)
%R% CMD INSTALL rcom
should result in
installing to c:/Rlib/rcom/libs/i386
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
rcom requires a current version of statconnDCOM installed.
To install statconnDCOM type
installstatconnDCOM()
This will download and install the current version of statconnDCOM
You will need a working Internet connection
because installation needs to download a file.
* DONE (rcom)
in R:
library(rcom)
installstatconnDCOM()
I tried a comRegisterRegistry() ; comRegisterServer()
; x<-comGetObject("Excel.Application") but I get a NULL for x. I am not a user of rcom so while it all seems to compile fine; it may just not work anymore.
If you happen to need to access .NET code, a viable option (and yes I have a vested interest in mentioning it) may be the rClr package.
Hope this helps; I'd be interested to hear how you go.
This really should be a comment, but I don't have enough rep points yet to leave one.
I found that the above steps did not work for me, but the answer posted by Lisa Ann on this question, RExcel in R 3.0.x, did solve my problem installing rcom. Since you need rcom to run RExcel, the initial steps to install RExcel cover installing rcom on newer versions of R (such as 3.0.2).
Specifically, following the advice on statconn's wiki, http://homepage.univie.ac.at/erich.neuwirth/php/rcomwiki/doku.php?id=wiki:how_to_install
You also need to follow these instructions if you upgrade R, i.e. you install a new >release of R after you have installed RExcel.
Download the statconn DCOM server and execute the program you downloaded
Start R as administrator (on Windows 7 you need to right-click the R icon and click the >corresponding item)
In R, run the following commands (you must start R as administrator to do this)
install.packages(c("rscproxy","rcom"),repos="http://rcom.univie.ac.at/download",lib=.Library)
library(rcom)
comRegisterRegistry()
Now you have rcom installed, [instructions for installing RExcel follow...]
New versions of rcom and rscproxy (also for current versions of R) are available from a different repository. Just use http://rcom.univie.ac.at/download as the R repository to install from and you can download and install binary versions of statconn packages from there.
Hope this helps!
I'm building R packages in R 3.0.1 on a Windows machine, using Rtools30 and the 'Build' tools associated with RStudio, which I assume is tied in with devtools (which is up-to-date). My typical process to build a package is:
Load All
Reoxygenize
Build & Reload
Check
Build Source Package
If everything goes without errors or warnings, I then:
install.packages("foo.tar.gz", repos=NULL, type="source")
Since upgrading to R 3.0.1, I now get this warning:
Warning in install.packages :
foo.tar.gz is not available (for R version 3.0.1)
I also tried before installing, and it did not get rid of the warning:
options(install.packages.check.source = FALSE)
Also, I notice this warning when I open the devtools library:
WARNING: Rtools 3.0 found on the path at c:/Rtools is not compatible with R 3.0.1.
Which is weird, Rtools 3.0 is suppose to be good from R >2.15.1 to R 3.0.x
Any ideas what is going on?
This is RStudio specific, as they wrap and/or changed a lot of functions from the utils for better integration. The problem lies with a call to getDependencies() to check for dependencies. But that function will also check whether the original package exists on CRAN and throws the given warning when it doesn't. A package you just built on your own computer is obviously not on CRAN, hence the warning.
In the source of the native install.packages(), getDependencies() isn't called in case you build from source or install from a different repository respectively. RStudio on the other hand calls getDependencies() before it passes everything on to the native install.packages() function.
This has to my knowledge no further effects, apart from confusing people. I didn't find a way to conveniently get rid of this in RStudio, as suppressWarnings() doesn't work in this context due to the complex way RStudio deals with this.
In a basic R console, you shouldn't have any problem.
So for the time being, I'd just ignore this and hope the RStudio team finds time to take care of this minor glitch.