You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some things I don't like about the current architecture:
the if sig.byte_order block in _get_masks_shifts() is pretty repetitive. We're really just mapping a byte order string to a function. This can be more direct with a dictionary with string keys and function values. the current code is more obvious, don't change this
cantools also guarantees that the byteorder is valid so we don't need an explicit check
we create the Jinja environment multiple times (twice per bus). This should be abstracted out and only run once. Maybe it gets made in generate_can_from_dbc and passed into generate_code? Would be nice to have a function that creates and returns the environment with all filters set
after the last bullet, is there still value in the generate_from_jinja_template function? Should it be inlined into generate_code? It's a bit of a strange function given how many parameters it requires and how little it does. Maybe the two calls to this function could be replaced by a loop over (CAN_MESSAGES_TEMPLATE_FILENAME, MSG_REGISTRY_TEMPLATE_FILENAME)or something simila
i'm not a huge fan of variables/ return types that look like Dict[str, Dict[str, Tuple[List[int], List[int]]]]: This is really hard to understand. We should at least use dataclasses to bundle some of this information into a named type.
Log levels: since cangen can be used standalone, we shouldn't require the user to know cmake logging levels to use it. We should have two mutually exclusive arguments: a --verbose aka -v flag and --cmake-log-level=### option, the latter of which replaces the current --log-level. The parse() function should figure out which was passed and convert that to a python logging level. You can then set args.loglevel to this value and directly pass args.level to `logger.setLevel
this will require you to store and manipulate the value from parser.parse_args() before returning it
the current functions names aren't great. Renaming them may also help decide how to organize the behaviour
if you rename the cangen entry point, make sure to update pyproject.toml.
The text was updated successfully, but these errors were encountered:
Some things I don't like about the current architecture:
thethe current code is more obvious, don't change thisif sig.byte_order
block in_get_masks_shifts()
is pretty repetitive. We're really just mapping a byte order string to a function. This can be more direct with a dictionary with string keys and function values.generate_can_from_dbc
and passed intogenerate_code
? Would be nice to have a function that creates and returns the environment with all filters setgenerate_from_jinja_template
function? Should it be inlined intogenerate_code
? It's a bit of a strange function given how many parameters it requires and how little it does. Maybe the two calls to this function could be replaced by a loop over(CAN_MESSAGES_TEMPLATE_FILENAME, MSG_REGISTRY_TEMPLATE_FILENAME)
or something similaDict[str, Dict[str, Tuple[List[int], List[int]]]]:
This is really hard to understand. We should at least use dataclasses to bundle some of this information into a named type.cangen
can be used standalone, we shouldn't require the user to know cmake logging levels to use it. We should have two mutually exclusive arguments: a--verbose
aka-v
flag and--cmake-log-level=###
option, the latter of which replaces the current--log-level
. Theparse()
function should figure out which was passed and convert that to a python logging level. You can then setargs.loglevel
to this value and directly passargs.level
to `logger.setLevelparser.parse_args()
before returning itpyproject.toml
.The text was updated successfully, but these errors were encountered: