HYPED 2024

 

 

Dependencies

• clang
• clang-format
• CMake >= 3.12
• eigen3
• boost
• rapidjson
• ncurses
• Paho MQTT C++

Install instructions for Paho can be found here. Due to the convoluted install process, we strongly recommend developing using Docker.

Usage

To pepare your project:

./scripts/setup

To create the build files:

mkdir build
cd build
cmake ..

To build all the binaries (in ./build):

make -j

To run tests (in ./build):

ctest

Docker

Install Docker Desktop from here, and make sure the Docker Engine is running.

Run ./docker.sh -r, which will build the Docker image. This may take a few minutes.

Then run ./docker.sh --dev or ./docker.sh -d to enter the development environment inside the Docker container. This will add the Hyped code as a volume, so you can edit the code inside the container.

You can follow the same build instructions as the previous section in the container, or run ./docker.sh --build or ./docker.sh -b from outside the development container to build.

Run ./docker.sh --help for the complete list of commands.

Telemetry

Note: The following should be run in the telemetry directory.

To run the telemetry system, run the following command:

./telemetry.sh <pnpm_script> -m

where <pnpm_script> is one of the scripts defined in package.json. E.g. dev or build. For a full list of possible arguments, run ./telemetry.sh --help.

The GUI will now be available on http://localhost:5173

Contributing

C++

All the C++ code should follow the Google C++ Style Guide.

Further, we aim to maintain the following rules which are based on the NASA's Ten Rules for Safety Critical Coding.

1. All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
2. Do not use dynamic memory allocation after initialisation.
3. No function should be longer than 60 lines of code.
4. The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule. (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements.)
5. Data objects must be declared at the smallest possible level of scope.
6. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
7. The use of the preprocessor must be limited to the inclusion of header files and compile time arguments. (e.g. operating system and architecture)
8. The use of pointers should be restricted. In particular, the keywords new and delete shall never be used and raw pointers shall only be viable as an alternative to std::optional<T&>, which is ambiguous and therefore an illegal type.
9. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.

TypeScript

TypeScript code is linted using ESLint and formatted using Prettier. The configuration for these tools can be found in the eslint-config package and the .prettierrc file respectively. You can also find our global TypeScript configuration in the tsconfig package.

To run the linter and formatter, use the following commands:

• pnpm lint to check for lint errors, or pnpm lint:fix to automatically fix some issues.
• pnpm format to format the code, or pnpm format:check to check for formatting errors but not format.

Additionally, all TypeScript code should follow the Google TypeScript Style Guide.