Add a retarget_snrefs() utility function
#374
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The problem is that accessing object specified via short name
reference always requires a context that is specific to the path via
the object is accessed to; IOW, strictly speaking, resolving SNREFs
cannot be done ahead of time (without copying everything for each
possible context). Since odxtools is build on the assumption that all
references can be resolved when a database is loaded and copying
everything for each possible context would be quickly running into RAM
limitations, we provide `retarget_snrefs()`, a utility function that
re-resolves the SNREFs reachable by a specified diagnostic layer using
that diagnostic layer. While this is not a "100% solution" because
sometimes contexts of SNREFs are more fine-grained than the diagnostic
layer that contains them, it should be a workable solution for about
95% of people who run into this issue.
Usage:
```python
import odxtools
from odxtools.utils import retarget_snrefs
db = odxtools.load_file("MyEcu.pdx")
retarget_snrefs(db, db.ecu_variants.Variant2)
```
After this, all objects specified via SNREFs reachable by the
diagnostic layer "Variant2" will be resolved using the point of view
of Variant2. Be aware that only a single variant can be "active" for a
given database, i.e., in the example above, accessing a resolved
object via a diagnostic layer other than "Variant2" will still yield
the same result as for Variant2...
Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com>
Signed-off-by: Gerrit Ecke <gerrit.ecke@mercedes-benz.com>
|
@mafei1982: does retargeting the SNREFs to the ECU of interest fix the problem for you? |
kayoub5
reviewed
Dec 13, 2024
kayoub5
reviewed
Dec 13, 2024
thanks to [at]kayoub5 for the nudge! Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com>
andlaus
force-pushed
the
retarget_snrefs
branch
from
3e146bd to
09d80a5
Compare
While it does not make much sense to do so (the idea is if the `SnRefContext` is created internally in the toplevel call to the function, the `.database` and `.diaglayer` attributes are assigned automatically), doing it separately makes the code slightly easier to understand. thanks to [at]kayoub5 for the catch! Signed-off-by: Andreas Lauser <andreas.lauser@mercedes-benz.com>
|
@kayoub5: do you see any issues which prevents merging this one? |
(Actually I don't really see the point of the long names in addition to descriptions, but that's a different matter...) Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io>
I don't see code issues, but the concept itself feels.... wrong |
If you mean the concept of short name refs, I agree ;). Anyway, since it is okay with you and this functionality comes with zero side effects for people who don't have "Schrödinger's cat in a box"-type ECUs, I'll merge this... |
This was referenced Jan 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem is that accessing objects specified via short name reference always requires a context that is specific to the path via these objects are accessed; IOW, strictly speaking, resolving SNREFs cannot be done ahead of time (without copying everything for each possible context). Since odxtools is build on the assumption that all references can be resolved when a database is loaded (i.e., ahead of time) and copying everything for each possible context would be quickly running into RAM limitations, we provide
retarget_snrefs(), a utility function that re-resolves the SNREFs reachable by a specified diagnostic layer using that diagnostic layer. While this is not a "100% solution" because sometimes contexts of SNREFs are more fine-grained than the diagnostic layer that contains them, it should be a workable solution for about 95% of people who run into this issue.Usage:
After this, all objects specified via SNREFs reachable by the diagnostic layer "Variant2" will be resolved using the point of view of Variant2. Be aware that only a single variant can be "active" for a given database, i.e., in the example above, accessing a resolved object via a diagnostic layer other than "Variant2" will still yield the same result as for Variant2...
Andreas Lauser <andreas.lauser@mercedes-benz.com>, on behalf of MBition GmbH.
Provider Information