-
Notifications
You must be signed in to change notification settings - Fork 80
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
Comparam subsets: add write support #96
Comparam subsets: add write support #96
Conversation
ENV_DATA is either ALL-VALUES or specifies a list of DTC-VALUES. So far, the former was implicitly assumed. Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
according to the XSD, this is a mandatory attribute for the COMPARAM-SUBSET XML tag... Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
{{- printGenericComparam(sub_cp) | indent(1, first=True) }} | ||
{%- endfor %} | ||
{%- if cp.physical_default_value is not none %} | ||
<COMPLEX-PHYSICAL-DEFAULT-VALUE>{{cp.physical_default_value}}</COMPLEX-PHYSICAL-DEFAULT-VALUE> |
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 valid
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.
hm, I see: this is one of these overcomplicated constructs again. what got me confused is that ComparamSubset physical_default_value()
folds this into physical_default_value
instead of complex_physical_default_value
. I think these two should be separated because the first is for simple parameters while the second is for complex ones?
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.
Using complex_physical_default_value seemed like an overkill, since physical_default_value can support multiple types (based on the dop physical type) and it would force users to do extra type checking for a common property
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.
If I got this right, the typing of this looks something like this:
SimpleValue = str
ComplexValue = List[Union[SimpleValue, ComplexValue]]
IMO, conflating these into the same attribute would make things quite confusing (read: I was quite confused), and also, the COMPLEX-COMPARAM
and COMPARAM
tags use different subtags for this (COMPLEX-PHYSICAL-DEFAULT-VALUE
vs PHYSICAL-DEFAULT-VALUE
). I've adapted the parameter extraction code in the latest commit, and I think the new version is easier to read. (and it also takes the default values into account...)
ok, I hopefully fixed the issues you've found. During that exercise I noticed that we should consider raising the minimum python version to 3.10 to be able to use |
0fbea5a
to
bfb449a
Compare
Too early for min version of 3.10 |
ok, let's defer this then... |
- rename the jinja2 template files to *.jinja2.xml to make some IDEs happy - move the comparam fragments shipped with the ODX standard from the directory for templates to `examples/data` Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
thanks to [at]kayoub5! Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
- the values of complex communication parameters are now always a list of strings or nested complex communication parameter values. (the helper function `_get_comparam_value` which produced a dict out of this is no more.) - the default values of communication parameters from their specification is now taken into account by the DiagLayer. - `protocol_snref` and `prot_stack_snref` are correctly internalized and written. Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
bfb449a
to
c71e1d1
Compare
alright. I've just pushed c71e1d1, and I think this is now ready to go. can you check if it still works for your files? |
(If there are no vetos, I'll merge this on Friday (Nov 25)...) |
odxtools/diaglayer.py
Outdated
|
||
return result | ||
|
||
def _get_comparam_subvalue(self, |
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.
What happens when a complex param also contains a complex?
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.
tough luck ;)
(I think for the standardized communication parameters this is never the case?)
more thanks to [at]kayoub5! Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
ok, I pushed an update: 80bc8bf |
we need it for the type checker, but we don't want to specify it as a hard dependency... Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Oliver Kopp <oliver.kopp@mbition.io>
value = comparam.physical_default_value | ||
|
||
if isinstance(comparam, Comparam): | ||
return comparam.dop.physical_type.base_data_type.from_string(value) |
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.
@andlaus original code here did take into consideration the dop physical data type
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.
yes, but that was a mightily confusing layer on top of CommunicationParameterRef.value
. I suppose that in the future, this should be moved to CommunicationParameterRef
. (which is a bit more work than it first seems, because of the writing stuff...)
value = value + [None] * (len(comparam.comparams) - len(value)) | ||
result = dict() | ||
for i, cp in enumerate(comparam.comparams): | ||
result[cp.short_name] = _get_comparam_value(cp, value[i]) |
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.
@andlaus original code here did take into account nested complex
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.
yeah, let's burn that bridge when we come to it (again)
ok. I guess it is time to get this in... |
This PR adds write support for COMPARAM-SUBSET. The main implication of this is that the communication parameters of a database written with odxtools should now always come with the correct definitions of their semantics.
Besides this, this PR fixes some minor issues which prevented me from writing back my internal diagnostics files using the pdxcopy example, and it renames all files containing Jinja2 templates to
.xml.jinja2
to make IDEs like VSCode happy.Andreas Lauser <andreas.lauser@mercedes-benz.com>, on behalf of MBition GmbH.
Provider Information