TPC: changing uint64_t to unsigned long long for compatibility with Mac

[matthias-kleiner]

When reading in pressure objects from Mac I got a warning of type

Warning in <TStreamerInfo::BuildCheck>:
   The StreamerInfo of class o2::tpc::dcs::RobustPressure read from file pressure_ccdb_1733011394000_1735656894000.root
   has the same version (=1) as the active class but a different checksum.
   You should update the version to ClassDef(o2::tpc::dcs::RobustPressure,2).
   Do not try to write objects with the current class definition,
   the files will not be readable.

Warning in <TStreamerInfo::CompareContent>: The following data member of
the on-file layout version 1 of class 'o2::tpc::dcs::RobustPressure' differs from
the in-memory layout version 1:
   vector<unsigned long> time; //
vs
   vector<ULong64_t> time; //

A similar issue is discussed here root-project/root#17216

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[matthias-kleiner]

pinging @shahor02 to let you know about this problem. I will also make a new upload request for the default object and then all other pressure values

[shahor02]

@matthias-kleiner does not this make all these ccdb object backward incompatible?

[matthias-kleiner]

@shahor02 the problem is only for the pressure where we uploaded only one (the default) object. So I think it should be no problem. In any case, when I test it with the current (old) object, it still works.

[davidrohr]

I don't really like this to be honest. Int64_t has a defined size. Long long int does not. So in principle, int64_t is better, and it must be safe since it has a defined size.
I suppose there are only warnings. I would rather complain with root about this.

[matthias-kleiner]

@davidrohr ok, if it is not a problem then we can also leave it as is. On Mac I only got the warning, but the timestamps looked fine. @shahor02 do you have an opinion on this?

[shahor02]

@matthias-kleiner But also your generic DataPoint uses TimeStampType, does not this create problem?
Actually, I thought that root would its native prefer Long64_t. That said, most of out timestamps are using long.

[matthias-kleiner]

@matthias-kleiner But also your generic DataPoint uses TimeStampType, does not this create problem? Actually, I thought that root would its native prefer Long64_t. That said, most of out timestamps are using long.

I think the problem is when using a std::vector<uint64_t> instead of just uint64_t like in DataPoint. When I tested the writing and reading for the DataPoint I got no warning

[shahor02]

@davidrohr ok, if it is not a problem then we can also leave it as is. On Mac I only got the warning, but the timestamps looked fine. @shahor02 do you have an opinion on this?

I see that in the root-project/root#17216 suggests to use root native Uint64_t, as I expected.
If you are going to populate the CCDB with other pressure objects, then it is better to update the class (with UInt64_t) and retrofit the current single object. Just to avoid more massive retrofits if the warning turns to error in the future.
But could you check if your other DCS object work fine?

[shahor02]

PS just saw your last message...

[davidrohr]

I think MacOS implements int64_t differently. But basically, at every architecture the dictionary generation will see int64_t, i.e. 64 bit. Root just sees that one architecture uses long int and another long long int, but from the fact that both come from int64_t, they must be compatible by construction.
Of course I agree that the warning is annoying. I don't have a good idea how to suppress it though...

[matthias-kleiner]

I changed it now to ULong64_t as suggested by @shahor02 . Is it fine like this? During testing I did not see any warning or problem with this

[shahor02]

Thanks, I would use it to avoid potential large CCDB retrofits in the future.

[alibuild]

Error while checking build/O2/fullCI_slc9 for e095e78 at 2025-06-12 21:11:

## sw/BUILD/O2Physics-latest/log
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:

Full log here.

[shahor02]

fullCI seems to be broken due to the O2Phisics, merging after local test.