Skip to content
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

Allow to specify units #445

Merged
merged 10 commits into from
Aug 22, 2023
Merged

Allow to specify units #445

merged 10 commits into from
Aug 22, 2023

Conversation

hegner
Copy link
Collaborator

@hegner hegner commented Jul 12, 2023

BEGINRELEASENOTES

  • Allow to specify units as part of the datamodel definition

ENDRELEASENOTES

This WIP is to allow the explicit inclusion of units into the datamodel definition.

  • Extend the regular expressions/parsing to allow a unit description
  • Documentation

@hegner
Copy link
Collaborator Author

hegner commented Jul 13, 2023

@tmadlener - can you let me know whether you'd agree with this? I needed some break from genreflex work and did this long-standing item on my wish list.

Copy link
Collaborator

@tmadlener tmadlener left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good idea. It is not yet clear to me if/how this will affect the generated code. That might have quite an impact on the size of this feature.

Would it mainly be an addition in the docstring, or would it actually enter in the generated c++ code. If the latter, which base units do we use, or do we leave that choice to the users (and if so, how)? Would we try to make this rather strict and introduce a proper units library to do all the conversions for us (there is a propoal for c++29 to have this in the standard library)?

python/podio/test_MemberParser.py Show resolved Hide resolved
@hegner
Copy link
Collaborator Author

hegner commented Jul 13, 2023

For the moment it is for documentation purposes. And I want to have a detection in the schema evolution in case it changes. I do not think we should use a units library unless being asked for explicitly.

@tmadlener
Copy link
Collaborator

OK. That sounds reasonable to achieve then. Then the main comment/question I have is whether we also need this for the components?

@hegner
Copy link
Collaborator Author

hegner commented Jul 13, 2023

Obviously :-)

@hegner hegner changed the title [WIP] allow to specify units Allow to specify units Jul 13, 2023
@tmadlener
Copy link
Collaborator

Just for completeness, could we add this to the generated code (docstring), so that it also shows up in some way in the c++ code.

def __str__(self):
"""string representation"""
# Make sure to include scope-operator if necessary
if self.namespace:
scoped_type = f'::{self.namespace}::{self.bare_type}'
else:
scoped_type = self.full_type
if self.default_val:
definition = rf'{scoped_type} {self.name}{{{self.default_val}}};'
else:
definition = rf'{scoped_type} {self.name}{{}};'
if self.description:
definition += rf' ///< {self.description}'
return definition

@tmadlener
Copy link
Collaborator

tmadlener commented Jul 20, 2023

Does this already work for components as well? If so, I think this could be merged.

@hegner
Copy link
Collaborator Author

hegner commented Jul 20, 2023

Yes it does. The test case covers NotSoSimpleStruct (component) and ExampleHit (datatype).

@tmadlener
Copy link
Collaborator

Ah right, sorry I missed that because it also has a description. Then more specifically does this also work with components that do not have a description, e.g. the SimpleStruct?

@hegner
Copy link
Collaborator Author

hegner commented Jul 27, 2023

Sure. The description is default initialized as empty string (""), thus there is no special case to handle

@tmadlener
Copy link
Collaborator

I was wondering more about the yaml parsing side here. IIRC I special cased the components there to not require a description, and I am not sure if this already covers that special case

@hegner
Copy link
Collaborator Author

hegner commented Jul 27, 2023

The combined regex would give a None for that part and we are back to default handling later. That's the nice thing of having unified the syntax of components and datatypes.

@tmadlener
Copy link
Collaborator

OK. IIUC, everything should work from the parsing side and nothing breaks if I add units, e.g. here:

Members:
- int x
- int y
- int z
- std::array<int, 4> p

However, I think in the current implementation these units would also not end up in a docstring, because they are never passed to the MemberVariable in this case, right? (The bare_<xyz> regexes do not have the unit_str yet, and so the unit is also not passed to the MemberVariable constructor in the end).

@hegner
Copy link
Collaborator Author

hegner commented Aug 21, 2023

@tmadlener - I addressed your comment with a fix. Indeed units were not handled correctly there.

@tmadlener
Copy link
Collaborator

It looks like the clang12 based workflows are failing due to not having root in their environment. I suspect that these are transient issues in the LCG nightlies and they should be safe to ignore. The key4hep (release) based one is failing due to an unsuitable ROOT version, so failure there is also expected.

@andresailer
Copy link
Member

The clang12 nightlies no longer exist

@tmadlener
Copy link
Collaborator

@hegner could you rebase this onto the latest master (or merge that in), so that we pick up a completely working CI again. After that finishes successfully, I would merge this.

@hegner
Copy link
Collaborator Author

hegner commented Aug 22, 2023

@tmadlener - seems all green now :-)

@tmadlener tmadlener merged commit 60dcd12 into AIDASoft:master Aug 22, 2023
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants