I have a question re: the issue that Rcpp modules are not easily exported as regular R objects. In particular, my code is object-oriented and uses an instance of a class exported to R. The issue has been documented here.
A possible workaround is to load a few things into the environment upon loading but I don't quite understand how to hold back my zzz.R which gets executed prematurely (build vs. load time) which results in an error because the modules called in zzz.R only become available AFTER compilation and installation.
Related
I am developing an R-package in one R-session (within R-Studio) while testing the package in another R-session (within a second instance of R-Studio). The package ("P") contains an R-function "foo".
In the test session all calls to foo are made by explicit qualification P::f(...).
When a new version is ready, the old library is uninstalled (checked that it is really gone from all locations in .libPaths()), newly built and reinstalled (with a new version number).
After some iterations of this, a bizarre phenomenon started: an old version of P::foo
executes even though it should not exist anywhere. I even check in the test session via
R> P:foo
the source code and it displays the latest version. However this is not the code that is executing. I can tell by the way the log file is written and there is simply no doubt about it. It is an old version that is executing.
What could I do to analyse this situation?
I have a application that calls some R code and some supporting C++ code that is called in my R code via Rcpp.
Currently, I am using sourceCpp() when I start my R session and this fine for now (e.g., sourceCpp('path/code.cpp')). But, this compiles the C++ each time the session starts and there is some overhead in doing so that makes the app slower to start. Of course, I could create an R package that precompiles the c++ code and I could load the package each time.
However, I'm curious if there is a way to source c++ code into an R session that is pre-compiled in a manner other than creating an R package?
The benefit of creating the R package makes is faster to load the code that is already compiled, but requires the work associated with creating that package. The sourceCpp() avoids having to create the package, but is slow when sourcing in the code. So looking to learn if there is an option that provides the convenience of sourcing in the c++ code like sourceCpp(), but would source in code that as been compiled.
Thank you
I have been trying to create an R library dynamically loading a dependency using Intel OpenMP. When the library is loaded, there is a clash with OpenMP library.
Using KMP_DUPLICATE_LIB_OK=TRUE gets me past the loading error but the program crashes once it is in a parallel section.
Unfortunately, neither compiling R using intel OpenMP or the dependency using GNU OpenMP is an option (because I want it to work with the standard R distribution and some external dependencies linked statically have to use Intel OpenMP).
However, I can recompile the dependency with some compatibility flags or modify how linking is done (but in the end, it has to be loaded dynamically from the R library). Setting environment variables is also an option (I am thinking about https://software.intel.com/en-us/node/522775 but none of the options seems to help so far).
The R library is written in C and I doubt that the fact it is R which will load it in the end really matters.
Any idea how to handle this?
I have developed a big library of functions in R.
For the moment I just load ("source") the functions at the beginning of all my scripts.
I have seen that I can create packages.
My question is: Will that improve the execution time of my functions? (by transforming interpreter code into machine language?)
What does the package creation does? Does it creates binaries?
Thanks
fred
There isn't an R compiler yet Packaging your R code won't improve its execution time massively. It also won't create binaries for you - you need to build those from the package tarball (or get CRAN or similar to build them for you). There is now a byte compiler for R and R's packages are now by default byte compiled. Speed improvements are in general modest - don't expect C-like speed.
Packaging R code just does exactly that; it packages the R code, code to be compiled (C Fortran etc), man pages, documentation, tests etc into a standard format that can be distributed to users and installed/built on multiple architectures.
Packages can take advantage of things like lazy loading such that R objects (your functions say) are only loaded when needed, whereas source loads them all into the global environment (by default).
If you don't intend to distribute your code then there are few benefits of packaging just for your own use, but if you do package and write documentation and examples/tests, you might be alerted to changes in the package code that break examples or cause tests to fail. That way you are better informed as to the reliability of your code, even if it is only you using it!
I've included a library called blotter in my R script which has a bug in it. Is there an easy way for me to edit the source to try and debug the issue?
Look up the trace and browser functions, they are the basic tools in R for debugging. Say you want to edit the source of function foo, then saying
trace("foo",edit=TRUE)
will open up the source of foo in the editor for you to change. However, this is for interactive debugging; the source files in the packages are not changed. So once you have found the bug, you need to change the package source files for the change to be permanent.
Such a feature is implemented in the development version of R (Jul 16, 2010):
A new facility has been added to r-devel for experimenting by authors of
packages.
The idea is to insert modified code from the package source into the
running package without re-installing. So one can change, test, change,
etc in a quick loop.
The mechanism is to evaluate some files of source code, returning an
environment object which is a snapshot of the code. From this
environment, functions and methods can be inserted into the environment
of the package in the current session. The insertion uses the trace()
mechanism, so the original code can be restored.
The one-step version is:
insertSource("mySourceFile.R", package = "myPackage", functions = "foo")
See this post for further details: Inserting and testing revised functions in a package
Your question of Is there an easy way for me to edit the source to try and debug the issue? has the obvious answer: Use the source, Luke!
blotter is a package on R-Forge from where you can get blotter sources here. That is the standard way of looking at Open Source and possibly helping it along with a bug fix.