A Reactor-Oriented Programming Framework in C++

While reactor-cpp can be used as a standalone framework, it is designed to work in conjunction with Lingua Franca, a polyglot metaprogramming language. Read the Lingua Franca handbook to get an overview of the reactor model.

Build

mkdir build
cd build
cmake ..
make

The examples need to be built explicitly. Alternatively, take a look at the CONTRIBUTING.md for building with nix package manager.

Extras

reactor-cpp can be built with tracing support. This provides a powerful tool for analyzing and debugging reactor applications.

Contributing

For general guidelines about contributing, see CONTRIBUTING.md.

Publications

• Phd Thesis: Christian Menard, “Deterministic Reactive Programming for Cyber-physical Systems”, PhD thesis, TU Dresden, 205 pp., Jun 2024.
• TACO’23: Christian Menard, Marten Lohstroh, Soroush Bateni, Matthew Chorlian, Arthur Deng, Peter Donovan, Clément Fournier, Shaokai Lin, Felix Suchert, Tassilo Tanneberger, Hokeun Kim, Jeronimo Castrillon, and Edward A. Lee. 2023. “High-performance Deterministic Concurrency Using Lingua Franca”. ACM Transaction on Architecure and Code Optimization, Volume 20, Issue 4, Article 48 (December 2023), 29 pages.
• DATE’20: Christian Menard, Andrés Goens, Marten Lohstroh, Jeronimo Castrillon, “Achieving Determinism in Adaptive AUTOSAR”, 2020 Design, Automation & Test in Europe Conference & Exhibition (DATE), Grenoble, France, 2020, pp. 822-827.

More related publications are available on the Lingua Franca publication page.

Contributing

Contact: christian.menard@tu-dresden.de or tassilo.tanneberger@tu-dresden.de

Programming Style

The project is currently implemented in C++17 and follows primarily the C++ Core Guidelines Please make sure your submitted code follows the .clang-tidy and .clang-format files.

Testing

There are CI Tests that automatically check your code. If you want to perform the tests manually take a look at this guide.

Building and Testing with Nix

List Compilers

    $ nix run .#packages.x86_64-linux.list-compilers

List all available Tests

    $  nix run .#packages.x86_64-linux.list-tests

List Benchmarks

    $ nix run .#packages.x86_64-linux.list-benchmarks

Building a special Package

    $ nix build .#packages.x86_64-linux.ActionDelay-gcc-wrapper-10-3-0 --override-input reactor-cpp github:lf-lang/reactor-cpp/<revision - branch>

The important thing to note is that the --override-input flag can take literally any source. In this example, it takes the cpp-core-guidleines branch but you maybe also want to use your fork then the argument would look like this --override-input reactor-cpp github:revol-xut/reactor-cpp.

Building and Running all Packages

    $ nix run .#packages.x86_64-linux.all-tests

This will build and run every tests.

Building and Running all Benchmarks

    $ nix run .#packages.x86_64-linux.all-benchmarks

Local integration testing Let’s assume you have the following folder structure:

• reactor-cpp/
• lingua-franca/
  • build/your_lfc_build.tar.gz folder that contains your local build of lfc

    $ nix run .#packages.x86_64-linux.all-tests --override-input reactor-cpp "./." lingua-franca-src "../lingua-franca/build/your_lfc_build.tar.gz"

Building lfc with nix is a work in progress until then you have to sadly build lfc yourself and specify it this way.

Running all Benchmarks and collect results

    $ nix build .\#packages.x86_64-linux.make-benchmark

This will generate a data/result.csv with all the measurements of all benchmarks.

Analysing Benchmarks and Tests for Memory Leaks

This will run valgrind on that test and create $out/data/Test-memtest.out which contains the requested debug information.

    nix build .\#packages.x86_64-linux.MLeaks-FullyConnected-gcc-wrapper-10-3-0

Cachegrind Analyse your benchmark for cache misses.

    nix build .\#packages.x86_64-linux.cachegrind-SleepingBarber-gcc-wrapper-10-3-0

Callgrind Profile and analyze your benchmarks call chain.

    nix build .\#packages.x86_64-linux.callgrind-SleepingBarber-gcc-wrapper-10-3-0

Benchmarking

If your changes are performance-critical it is advised to run the test from here

Git

There are no strict conventions on how your git messages need to be formatted just know they should be informative and summersing on your changes.