I use RStudio, it's fantastic. Recent adjustments to my BLAS installation, however, require me to start R with the command
taskset 0xffff R
To get parallel processing to work. Is there a way tell RStudio to start it's R session with this command so I can use RStudio with parallel?
(I know parallel and GUI's don't play that nice)
Thanks.
EDIT: I'm running kUbuntu.
You should be able to do this by customizing your Rprofile.site file, as described here:
http://www.statmethods.net/interface/customizing.html
Related
I am developing R packages for an internal use applications at work. Unfortunately, not everybody is on the same version of R. I want to build Windows binaries of my package to support multiple versions, for example, 3.6.x and 4.0.x R.
I can easily do this by building the package (I use devtools::build(binary = TRUE)), and then change the R version in RStudio, restart, and run again. But this gets very tedious.
Is there a way to streamline this (e.g., my own custom function to build both at once)? I imagine some CI/CD thing is probably best, but this solution would have to be limited to what I can run locally.
Don't do it in RStudio, write a script to do it. It would have commands like these:
/path/to/R3.6.3/R CMD INSTALL --build /path/to/yourpackage
mv yourpackage.*.zip /path/for/R3.6users
/path/to/R4.0.3/R CMD INSTALL --build /path/to/yourpackage
mv yourpackage.*.zip /path/for/R4.0users
You don't need a lot of builds; only the first two parts of the version number (e.g. 3.6 or 4.0) need to match the target system.
You could implement this script in R using system() calls, but it's probably simpler to do it using one of the Windows script languages (.bat or .cmd or whatever).
I can only find information on how to install a ready-made R extension package, but it is nowhere mentioned which commands a developer of an extension package has to use during daily development. I am using Rcpp and I am on Windows.
If this were a typical C++ project, it would go like this:
edit
make # oops, typo
edit # fix typo
make # oops, forgot an #include
edit
make # good; updates header dependencies for subsequent 'make' automatically
./fooreader # test it
make install # only now I'm ready
Which commands do I need for daily development of an Rcpp package project?
I've allocated a skeleton project using these commands from the R command line:
library(Rcpp)
Rcpp.package.skeleton("FooReader", example_code=FALSE,
author="My Name", email="my.email#example.com")
This allocated 3 files:
DESCRIPTION
NAMESPACE
man/FooReader-package.Rd
Now I dropped source code into
src/readfoo.cpp
with these contents:
#include <Rcpp.h>
#error here
I know I can run this from the R command line:
Rcpp::sourceCpp("D:/Projects/FooReader/src/readfoo.cpp")
(this does run the compiler and indicates the #error).
But I want to develop a package ultimately.
There is no universal answer for everybody, I guess.
For some people, RStudio is everything, and with some reason. One can use the package creation facility to create an Rcpp package, then edit and just hit the buttons (or keyboard shortcuts) to compile and re-load and test.
I also work a lot on a shell, so I do a fair amount of editing in Emacs/ESS along with R CMD INSTALL (where thanks to ccache recompilation of unchanged code is immediate) with command-line use via r of the littler package -- this allows me to write compact expressions loading the new package and evaluating: r -lnewpackage -esomeFunc(somearg) to test newpackage::someFunc() with somearg.
You can also launch the build and test from Emacs. As I said, it all depends.
Both those answers are for package, where I do real work. When I just test something in a single file, I do that in one Emacs buffer and sourceCpp() in an R session in another buffer of the same Emacs. Or sometimes I edit in Emacs and run sourceCpp() in RStudio.
There is no one answer. Find what works for you.
Also, the first part of your question describes the initial setup of a package. That is not part of the edit/compile/link/test cycle as it is a one off. And for that too do we have different approaches many of which have been discussed here.
Edit: The other main misunderstanding of your question is that once you have package you generally do not use sourceCpp() anymore.
In order to test an R package, it has to be installed into a (temporary) library such that it can be attached to a running R process. So you will typically need:
R CMD build . to build package_version.tar.gz
R CMD check <package_version.tar.gz> to test your package, including tests placed into the testsfolder
R CMD INSTALL <package_version.tar.gz> to install it into a library
After that you can attach the package and test it. Quite often I try to use a more TTD approach, which means I do not have to INSTALL the package. Running the unit tests (e.g. via R CMD check) is enough.
All that is independent of Rcpp. For a package using Rcpp you need to call Rcpp::compileAttributes() before these steps, e.g. with Rscript -e 'Rcpp::compileAttributes()'.
If you use RStudio for package development, it offers a lot of automation via the devtools package. I still find it useful to know what has to go on under the hood and it is by no means required.
Is it possible to determine - from within the script - whether the script is running in the R-GUI (specifically R.app on OS X) or whether it has been called from Terminal/command line (i.e. R --vanilla -f script.R)? If so, how is this possible?
I'm asking because I have a script that can run parallelized (using the doMC library), which should not be used from the GUI. Sometimes I need to further process the data calculated in the script, so I'd like to call the script from the GUI on these occasions.
Perhaps you are looking for interactive()?
In C, you would use the isatty function. If you could find an equivalent function in R (probably in a UNIX or file system library), that should help.
I am trying to use gdb to debug compiled code in an R package in the same way as specified in the video: https://vimeo.com/11937905 and Writing R Extensions section 4.4.
These sources say to use the command
R -d gdb when starting R. However, whenever I try to do this I get a message saying WARNING: unknown option '-d' and R is started under normal conditions.
Why isn't R recognizing the -d flag? I am using Windows 10.
As #MatthewLueder has found out himself finally debugging on Windows does not work as on Linux.
A how-to is described in the R for Windows FAQ
The main reason for the missing -d argument in R seems to be that Windows cannot send a signal to a process to interrupt the execution and pass the control to the (gdb) debugger:
Without interrupting R you cannot set a breakpoint.
Without starting R into the R console you cannot load libraries to be debugged (without making your hands dirty).
Therefore R on Windows offers a work-around using RGui instead of R:
gdb /path/to/R-3.x.x/bin/x64/Rgui.exe
(gdb) run
After starting the RGui you are in an R shell and can load your packages
that contain the DLLs to be debugged.
To set breakpoints for debugging you can interrupt R to break into the debugger via a menu item that is only visible if RGui was started with gdb:
Now you can set breakpoints in your code via b a_function_name, enter c to continue R, call the function in R and voilà: gdb shows the breakpoint hit and
you can debug (stepping through the code and printing variable values).
PS: I am currently developing an R package to improve the debugging of C++ code in R packages since it is quite difficult to view the current values of R variables or Rcpp data types in gdb: https://github.com/aryoda/R_CppDebugHelper
I am interested in providing a command line interface to an R package called Slidify that I am authoring. It uses Rscript and I think that would make it cross-platform. The scripts are stored in the subdirectory inst/slidify. In order to use the script from any directory, I added its path to my .bash_profile as I am on a Mac.
My question is
How should I handle installation of the script in an automated cross-platform way?
How can I make sure that the file permissions are retained in this process?
What should the shebang line for the script be? I am currently using
#!/usr/bin/Rscript --vanilla --slave
I would appreciate pointers on how to handle this and any examples of R packages that already do it. Just to make sure, I am clear on how this would work, a user would be able to generate a slide deck from slides.Rmd by just running slidify generate slides.Rmd from the command line.
UPDATE:
Here is how I install it on a Mac from the command line. I use the excellent sub library by 37 signals to create the scripts.
echo "$(path/to/clidir/slidify init -)" >> ~/.bash_profile
exec bash
Two follow up questions
Can I package these commands into an R function install_slidify_cli?
How can I mirror these commands for Windows users?
Lovin' slidify so would be glad to help.
But in short, you can't.
R packages simply cannot install outside of $R_HOME or the chosen library folder. Ship the script in the package, and tell users to copy it. If there was a better way, out littler package with predecessor / alternative to Rscript would long have used it, and roxygen / roxygen2 would also have shipped something.