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

Encode Geometry Tag w/in DB macros #422

Merged

Conversation

klendathu2k
Copy link
Contributor

The Geometry.{tag}.C "database" macros establish the connection between the geometry tag (defined by the BFC chain options and/or timestamp) and the code which instantiates the geometry model. The macro is loaded / executed by St_db_Maker whenever GetDataBase("VmcGeometry") is called.

This PR encodes the geometry tag inside of each database macro, rather than using the ROOT interpreter's introspection capabilities to read the tag from the filename of the currently executing macro. This works well under ROOT 5 / CINT. But I think the way that we load macros in St_db_Maker confuses ROOT 6 / CINT.

The simplest solution is to encode the geometry tag within each database macro.

…en the

geoemtry tag (defined by the BFC chain options and/or timestamp)
and the code which instantiates the geometry model.  The macro
is loaded / executed by St_db_Maker whenever GetDataBase("VmcGeometry")
is called.

This PR encodes the geometry tag inside of each database macro, rather than
using the ROOT interpreter's introspection capabilities to read
the tag from the filename of the currently executing macro.
This works well under ROOT 5 / CINT.  But I think the way that we
load macros in St_db_Maker confuses ROOT 6 / CINT.

The simplest solution is to encode the geometry tag within each
database macro.
@plexoos
Copy link
Member

plexoos commented Oct 26, 2022

diff stat: +178 −2,759 ❤️ Perfect refactoring assuming the functionality is not affected.

I think the next step is just to converge to a single macro accepting one parameter "tag"

@klendathu2k
Copy link
Contributor Author

diff stat: +178 −2,759 heart Perfect refactoring assuming the functionality is not affected.

I think the next step is just to converge to a single macro accepting one parameter "tag"

Each of these files is considered to be a "database table". In this case it is a trivial table whose title just corresponds to the geometry tag. But it is being exercised through the general DB macro API, which expects there to be one table specified per file.

@klendathu2k klendathu2k assigned klendathu2k and genevb and unassigned klendathu2k Oct 27, 2022
Copy link
Contributor

@genevb genevb left a comment

Choose a reason for hiding this comment

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

Reduced redundancy, fewer lines of code to "get right" for each new geometry.... LGTM.

@klendathu2k klendathu2k merged commit fd02555 into star-bnl:main Oct 28, 2022
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