The config file is created in commit 000e3be, which is in the master branch.
In the v3-patches branch, the formatting check is enabled in the CI in 05702ff and the formatting is applied to the source files in 8ab96ea. This has been tagged in v3r6.
The application of the formatting in master will happen after the timedep-branch is merged.

Commit 8ab96ea5c5ed in branch v3-patches closes this revision

The implementation in D101 has caused problems with being able to run the python example GenFit3pi.py because to be able to use our classes in python they need to have dictionaries generated.
As such, I'm going to revert the changes from landing D101 and make new commits that only apply the following parts of those changes:

• Removal of the deprecated ClassImp macro in all source files
• The improvements to the CMake modules to avoid using old-style CMake stuff like file-level include_directories, etc.

The updated formatting looks good. This is ready to be merged for the new release.

Hi @jback, just a quick note to explain the new changes.

• Updates to clang-format style for clang 16
• Modify clang-format style to 4-space indentation
• Fix missing newline in README
• Scripts to fix indentation of Doxygen comment blocks
• Further improve formatting style
• Re-apply formatting to source files

Formatting and CI check look OK.

Yes, this is OK.

• Apply formatting in v3-patches branch

@jback, does this look ok? It's the same as the code we now have in #evtgen.

• Add warning if requested C++ standard is too old

Thanks John!

Clang formatting and CI check looks OK, so proceed with organising the appropriate branches.

It looks like it is going to be a nightmare to merge timedep-branch into master if we apply this formatting first (even after applying the same formatting there first).
So what I'd propose is to merge the last actual code changes into master - will create the differential for that shortly - then create a new v3-patches branch, to which this formatting can then be applied, and release v3r6 from that branch. This Differential can be updated to accomplish that part.
The formatting can then be applied to master after merging in timedep-branch - will require a separate Differential at a later date.
Does that sound reasonable?

Thanks to D101, this is now in master but needs to also be propagated to the time-dependent branch, so not yet closing this.

Closed by rLAURA9dffea19ce7b
(not sure why this didn't happen automatically)

In parallel I need to check what happens if I apply the same formatting in the timedep branch and then try and merge the branches! If that doesn’t go so well we might have to postpone this change untill after merging timedep into master.

Since this is purely formatting changes, I think the main thing to review is that the formatting style looks reasonable and that the CI check looks ok. Up to you if you want to look through all the files!!

Remove unused member variable from LauKMatrixPropagator

Many thanks for checking through this. I’ve reply to your K-matrix related question inline.

All of the changes look OK. Just have a query about some K-matrix code that is commented out. Otherwise this can be merged.

@jback - just to provide you with a bit more context. This is the first of three Differentials that I would like to get merged before releasing v3r6 from the master branch:

• This one, which addresses T213, solving an issue with and generally improving the ROOT dictionary generation
• One that will address T111 by creating a clang-format style file, applying it to the code, and adding a corresponding CI check
• One that will address T227 by creating new functions in the fit models to access the amplitude and likelihood as a function of the DP position

Fix typo in release notes

• Further tweaks and added release notes, example usage removed from GenFitDpipi

Please also add an entry in the release notes, which should reference either this Differential revision or the corresponding Maniphest task

Just a few trivial tidy-ups

• Missed one issue

• Address review comments

Many thanks Mark, this looks great. Just a few small suggestions here and there.

• Add documentation and fix a bug from loop updates

• Updates to move some functionality to LauFitObject
• Update code after move to LauFitObject and extend to LauSimFitCoordinator

The new updates using the mass ranges look OK.

Update revision following review discussion

Hi John,

1. Yes, increasing the safety factor to 10% is sensible.

Thanks for checking it through John.

This clever solution for finding ASqMax looks OK overall, so I am approving these changes.

Hi John,

Another option for the data format and parser would be JSON and nlohmann_json as the parser.
While I slightly prefer the look of YAML files, the nlohmann_json parser looks to be more fully featured that either json-cpp or yaml-cpp.
Will look at the various use-cases and see which would work better.

Should also take the opportunity to sort out the naming conventions, particularly for the resonances.

Thanks Mark, looks good, I'll merge it.

• Address comments from Tom

Many thanks for putting this together Mark, it's great to have an example that uses the MIPW.
I haven't yet tried running it but will try and do so later on, so these are just from a read through and all quite minor stuff.
(For one I've tried out the new "Suggest edit" feature, so hopefully it will be clear what I mean!)

Thank you for these improvements, Tom. I think this is uncontroversial.

This is mainly a fix of Doxygen warnings but I have taken the opportunity to streamline very slightly the arguments to LauKMatrixPropagator::calcGamma, hence the request for review.

That sounds great, thanks Tom. Let me know when you're ready for me to take a look (there is no urgency - the code above is working locally for me)

Thanks for this @johndan. I'm not (yet) very familiar with RDataFrame, so bear with me while I look at that part.
I'm thinking that we could use YAML for the config file for this, which should make it more obvious what the various fields are, make it easier to deal with missing fields, etc.
I've been looking into YAML a little bit already in the context of T48 and this is actually a nicer case in which to try it out for the first time, so I'll have a bit of a play with it.

Thanks for this @johndan. I'm not (yet) very familiar with RDataFrame, so bear with me while I look at that part.
I'm thinking that we could use YAML for the config file for this, which should make it more obvious what the various fields are, make it easier to deal with missing fields, etc.
I've been looking into YAML a little bit already in the context of T48 and this is actually a nicer case in which to try it out for the first time, so I'll have a bit of a play with it.

Looking into using YAML for the data format and the yaml-cpp package for parsing it.