-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/param integration #1
Conversation
Do you want a review or stamp? If the former can you provide context on your changes. |
/// @return true or false depending on if the key exists or not | ||
bool handle_update_parameter(const std::string &key, std::variant<bool, int, float, std::string> parameter_val) | ||
template <typename ParamType> | ||
std::optional<ParamType> get_live_parameter(const std::string &key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding documentation for this method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on my limited understand, LGTM.
It would be helpful to include comments explaining the reasoning behind the design decisions where possible. Also document your methods. This would aid future maintainers.
Also consider adding tests (if possible - not really sure how the testing suite works at the moment).
Maybe we should consider writing a code style guide and enforcing documentation styles: |
context:
I am adding in a live parameter handler to the software for use with components internal to the software.
I update the configuration (Configurable base class) handler to both handle live parameters and file-only parameters. the live parameters are loaded first from the file passed in and then are added to a cache internally that then becomes the source of truth for the parameters. this cache can then be updated at runtime by the foxglove parameter interface.
since the configurable base class will have multiple instances running in multiple threads I put the parameter cache (each configurable component has it's own cache) behind a mutex so that the parameter server thread can lock onto that mutex and update it in a thread-safe manor.
I also added a boost signal to the configurable class that gets executed on callback within the foxglove server thread and calls the user implemented signal to handle the parameter updates internally to the configurable component, this allows the "user" of the configurable class within their component to handle live updates the way that they want.
references:
https://www.boost.org/doc/libs/1_84_0/doc/html/signals2/tutorial.html