- Add OpenCV and stdexec dependencies - ImageRPC type bridging OpenCV and RPC layers - Stereo rectification boilerplate - get-available-methods RPC method with get_count/get_method_name_by_id/get_method_names - Tests for remote method retrieval - CPU/GPU stereo matcher interfaces with SGBM implementation - Documentation consistency pass across impl and docs TG-5 #ready-for-test TG-2 #in-progress
4.9 KiB
Cloud Point RPC Agent Guide
This repository contains a C++20 implementation of a JSON RPC protocol for communicating with a Unity Scene. Agents working on this codebase must adhere to the following guidelines and conventions.
1. Build, Lint, and Test
The project uses the Meson build system.
Build Commands
- Setup Build Directory:
meson setup build - Compile:
meson compile -C build - Clean:
meson compile --clean -C build
Testing
-
Run All Tests:
meson test -C build -
Run Specific Test: To run a single test suite or case, use the test name defined in
meson.build:meson test -C build <test_name>Example:
meson test -C build unit_tests -
Verbose Output:
meson test -C build -v
Linting & Formatting
- Format Code:
Use
clang-formatwith the project's configuration (assumed Google style if not present).ninja -C build clang-format # OR manual execution find src include tests -name "*.cpp" -o -name "*.hpp" | xargs clang-format -i - Static Analysis:
If configured, run clang-tidy:
ninja -C build clang-tidy
2. Code Style & Conventions
Adhere strictly to Modern C++20 standards.
General Guidelines
- Standard: C++20. Use concepts, ranges, and smart pointers. Avoid raw
new/delete. - Memory Management: Use
std::unique_ptrandstd::shared_ptr. - Const Correctness: Use
const(andconstexpr/consteval) whenever possible. - Includes: Use absolute paths for project headers (e.g.,
#include "rpc/server.hpp"). - Auto: Use
autowhen the type is obvious from the right-hand side or is a complex template type.
Naming Conventions
- Files:
snake_case.cpp,snake_case.hpp. - Classes/Structs:
PascalCase. - Functions/Methods:
snake_case. - Variables:
snake_case. - Private Members:
snake_case_(trailing underscore). - Constants:
kPascalCaseorALL_CAPSfor macros. - Namespaces:
score(primary project namespace). - Interfaces:
IPascalCase.
Project Structure
include/cloud_point_rpc/: Public header files.src/: Implementation files.tests/: Unit and integration tests.subprojects/: Meson wrap files for dependencies.meson.build: Build configuration.
Error Handling
- Use Exceptions (
std::runtime_error,std::invalid_argument) for invariant violations and logical errors. - Use
std::optionalorstd::expectedfor recoverable runtime errors. - JSON RPC Errors: Ensure all RPC handlers catch exceptions and return valid JSON-RPC error objects containing
code,message, anddata.
Documentation
- Use Doxygen style comments for public APIs.
- Document thread safety guarantees.
Example Class
namespace score {
/// @brief Manages camera parameters.
class CameraController {
public:
struct Config {
int width;
int height;
};
explicit CameraController(const Config& config);
/// @brief Retrieves current intrinsic parameters.
/// @return A 3x3 matrix.
[[nodiscard]] std::vector<double> get_intrinsic_params() const;
private:
Config config_;
mutable std::mutex mutex_;
std::vector<double> cached_intrinsics_;
};
} // namespace score
Implementation Details
- JSON Library: Use
nlohmann/json(likely viasubprojects/nlohmann_json.wrap). - Concurrency: Use
std::jthread(auto-joining) overstd::thread. - RPC Methods:
- Implement handlers for:
get-cloud-point,get-intrinsic-params,get-extrinsic-params. - Ensure thread safety if the RPC server is multi-threaded.
- Implement handlers for:
3. Workflow & Git
Commit Messages
- Use conventional commits format:
<type>(<scope>): <subject>- Types:
feat,fix,docs,style,refactor,test,chore. - Example:
feat(rpc): add handler for get-cloud-point
- Types:
Pull Requests
- Ensure
meson test -C buildpasses before requesting review. - Keep PRs small and focused on a single logical change.
4. Cursor & Copilot Rules
(No specific rules found in .cursor/rules/ or .github/copilot-instructions.md.)
- Context: Always read related header files before modifying source files.
- Verification: Write unit tests for new features in
tests/. - Refactoring: When refactoring, ensure existing behavior is preserved via tests.
- Dependencies: Do not introduce new dependencies without updating
meson.buildandsubprojects/.
OpenWiki
This repository has documentation located in the /openwiki directory.
Start here:
OpenWiki includes repository overview, architecture notes, workflows, domain concepts, operations, integrations, testing guidance, and source maps.
When working in this repository, read the OpenWiki quickstart first, then follow its links to the relevant architecture, workflow, domain, operation, and testing notes.