-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
derive context settings from configuration file #12432
Conversation
auto it = _values.find(key); | ||
return it != _values.end(); | ||
auto it = _j.find(key); | ||
return it != _j.end() && it->is_string(); |
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.
Why check for string? Don't we support other values?
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.
Because, at least in rs-config, and in this PR, I didn't want to change any existing functionality: tools will keep behaving the same.
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.
My main goal was to make rs-config compatible with raw json -- before, it couldn't even load -- and able to keep non-string content intact.
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.
So in the next PR this is about to change?
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.
No, I'm not touching it again without a good reason.
std::map<std::string, std::string> _defaults; | ||
std::string _filename; | ||
nlohmann::json _j; |
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.
_j
does not imply the member meaning, just the type. _config
?
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.
It's the underlying json object. I can name it _json, but I don't know if that adds much...
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.
The name should not change if we decide to switch from JSON to XML or other.
The meaning of this variable is to hold the configuration in memory.
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.
_data? _map? _key_value? Anything you pick is meaningless. :)
Let's be realistic. It's a file with an extension of .json
.
std::map<std::string, std::string> _defaults; | ||
std::string _filename; | ||
nlohmann::json _j; | ||
}; | ||
} |
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.
Newline needed?
src/context.cpp
Outdated
namespace librealsense { | ||
|
||
|
||
static nlohmann::json load_config() |
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.
I think it might be useful to have a load/save_json( filename )
utility. I know that Noa has a task concerning saving and parsing json content.
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.
Not quite sure why, it's very straightforward as you see...
src/context.cpp
Outdated
// Take the global 'context' settings out of the configuration | ||
nlohmann::json settings; | ||
if( auto global_context = rsutils::json::nested( config, "context" ) ) | ||
merge_settings( settings, global_context, "global config-file/context" ); |
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.
I thought that the parameter order should be switched.
As I understand specified context_settings
should override executable settings that in turn override global setting
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.
That's exactly what it does
Here it take empty settings and "merges" the global, so we get global.
if( only_sw_arg.getValue() ) | ||
{ | ||
settings["dds"]["enabled"] = true; // override global dds:false or dds/enabled:false, if any |
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.
I think this should be true only if BUILD_WITH_DDS is set
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.
Doesn't hurt, but OK.
Do you think it makes sense to enable DDS automatically if we see "sw-only" device-mask (i.e., override enabled=false if device-mask is sw-only)?
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.
No, could be playback or future type devices. If settings set to disable then leave disabled
@@ -58,10 +60,67 @@ topics::device_info rs2_device_to_info( rs2::device const & dev ) | |||
} | |||
|
|||
|
|||
static nlohmann::json load_config() |
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.
This makes my point about a utility stronger :-)
The 3 static functions should probably all be in rsutils
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.
Two. I thought the same but I don't think it belongs in rsutils.
Load config shouldn't know about RS2_CONFIG_FILENAME. It can get the filename. But then what're we adding? The exception handling? The error would be different, I could make it "failed to load json file: ..." but then I just don't feel the function adds much.
Same with merge_settings: it's just a wrapper around merge_patch
with error handling.
In the end I decided to just keep as is. You think I should make rsutils::json::load_file()
and rsutils::json::merge
?
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.
load_file
in rsutils makes less and less sense to me (no filename generation; if would have to return bool to denote if the file was there, so you'd have to handle it in the caller). I prefer to just embed directly in load_settings.
merge_patch
is a weird name and I can see introducing rsutils::json::merge()
or json::patch
with maybe an optional name for error handling.
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.
Anyway:
- added
rsutils::json::patch()
- added
rsutils::json::load_settings
that does the basic global+app merge
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.
LGTM
Continuation (2/3) of previous PR for persistent DDS settings.
RS2_CONFIG_FILENAME
common/rs-config
now can read non-string JSON valuescontext
key, merged with:"inherit":false
E.g.:
Tracked on [LRS-963]