To give it a spin try
docker run -it registry.gitlab.com/rirvm/rir_mirror:master /opt/rir/build/release/bin/R
Building from Source
git clone https://github.com/reactorlabs/rir cd rir cmake -DCMAKE_BUILD_TYPE=debugopt . # Fetch and build dependencies. This will build gnur from source, which takes a while. make setup make
macOS has some extra prerequisites:
- A Fortran compiler (e.g.
brew install gcc)
- Xcode Command line tools
To run the basic test, just execute
To run tests from gnur with rir enabled as a jit:
Playing with RIR
To run R with RIR use
This loads a normal R environment with RIR replacing the R bytecode compiler and interpreter. If you want to automatically compile functions when they are executed use
Functions compiled to RIR can be inspected using
To make changes to this repository please open a pull request. Ask somebody to review your changes and make sure travis is green.
Caveat: we use submodules. If you are in the habit of blindly
git commit . you are up for surprises. Please make sure that you do not by accident commit an updated submodule reference for external/custom-r.
To try out the PIR optimizer you can use
pir.compile to optimize a RIR compiled closure.
Or you can pass the environment variable PIR_ENABLE, and set it to 'on' or 'force'.
Those flags will either use the PIR optimizer for hot RIR functions, or always.
To print intermediate debug information, you have a number of options:
- Use the shorthand flags on
pir.compile, such as
- Set the
PIR_DEBUGenvironment variable to a comma separated list of flags to enable by default.
- Or for even specific debugging use the
pir.compile. Debug flags can be created using
pir.debugFlags, for example to debug the register allocator, you could use
- To change the default debug flags at runtime use
We periodically benchmark the performance of the optimizer. The documenation also contains the information for running the benchmarks locally.
You can have multiple builds at the same time. If you want to use that feature, you need to not run cmake in the main directory. Instead do this:
git clone https://github.com/reactorlabs/rir cd rir mkdir -p build/debug build/release cd build/debug cmake -DCMAKE_BUILD_TYPE=debug ../.. make setup && make cd ../release cmake -DCMAKE_BUILD_TYPE=release ../..
Building with ninja
For faster build use ninja. To generate ninja files instead of makefiles add
-GNinja to the cmake commands.
Using ninja means GCC and Clang will disable color output. To force color, run cmake with
Building on macOS with GCC 9
By default macOS will build gnuR and rir with clang, while Linux always uses GCC. There might be some differences between the 2 compilers. However, you can force macOS to use GCC via the following:
- Install GCC 9 with homebrew (
brew install gcc@9)
Making changes to gnur
R with RIR patches is a submodule under external/custom-r. This is how you edit:
# Assuming you are making changes in you local RIR branch cd external/custom-r # By default submodules are checked out headless. We use a # branch to keep track of our changes to R, that is based on # one of the R version branches. If you want to make changes # you have to make sure to be on that branch locally, before # creating commits. git checkout R-3.5.1-rir-patch git pull origin R-3.5.1-rir-patch # edit some stuff ... git commit git push origin R-3.5.1-rir-patch cd ../.. # now the updated submodule needs to be commited to rir git commit external/custom-r -m "bump R module version" git push my-rir-remote my-rir-feature-branch # Now you can create a PR with the R changes & potential RIR # changes in my-feature-branch
If you want to test your R changes on travis, before pushing to the main branch on the gnur repository you can also push to a feature branch on gnur first. E.g.:
git checkout -b my-rir-feature-branch cd external/custom-r git checkout -b my-gnur-feature-branch # edit and commit. Need to push, or travis will not be able to access the submodule reference git push origin my-gnur-feature-branch cd ../.. git commit external/custom-r -m "temp module version" git push my-rir-remote my-rir-feature-branch # Review.... # Now, with travis green, before merging, change it back: cd external/custom-r git checkout R-3.5.1-rir-patch git pull origin R-3.5.1-rir-patch git merge --fast-forward-only my-gnur-feature-branch git push origin R-3.5.1-rir-patch # delete old branch git push origin :my-gnur-feature-branch cd ../.. git commit external/custom-r -m "bump R module version" git push my-rir-remote my-rir-feature-branch # Merge PR
Fetch updated R:
git submodule update cd external/custom-r && make -j4
Debugging a Travis build
Debug mode has been enabled for our repository. To simplify the process, we have
To set up, go to your Travis-CI.org profile
(note travis-ci.org, NOT travis-ci.com) and copy your API token. Paste it in
.travis_token in the repository root.
To use the debug script, first find the job you want to debug, e.g.: https://travis-ci.org/reactorlabs/rir/jobs/
Now you can run
tools/travis-debug.sh <job id> which will POST to the API
endpoint and restart the build. Then you can go back to the job on the Travis
website and use the SSH command to access the machine.
The debug VM will be in a state before the
before_install phase runs. You will
have to manually run the build phases:
travis_run_before_install travis_run_install travis_run_before_script travis_run_script travis_run_after_success travis_run_after_failure travis_run_after_script
For more information, see: https://docs.travis-ci.com/user/running-build-in-debug-mode/