Improve message of the expression parser if type information is missing.
- Suggest to provide missing type information to property of the top level algorithm sequence, in case no type information is available for a certain variable.
- Distinguish between missing type information and missing inheritance information.
Merge request reports
Activity
added 22.0 Analysis review-pending-level-1 labels
CI Result SUCCESS (hash 2fe7ea1a)Athena externals cmake make tests Full details available on this CI monitor view. Check the JIRA CI status board for known problems
Athena: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 73445]added review-approved label and removed review-pending-level-1 label
Is this really meant for 22.0?
Hey I wanted to ask the same if this is really 22 ?
ping @jcatmore and @nstyles . I assume this is due to targetting "Analysis" or "Derivation" release .
But I think we have switched those to 24.2.X and are build from main/master ?
The 22.2.X I think were build from main/master also, but before we did the 23.0 branch.
Hi,
this should go to 23.0 since under our current guidelines it is core derivation code that we want to keep in synch with the T0, since it is used for the special formats (this is particularly true for the ExpressionEvalution).
So @goetz , please could you re-direct this to 23.0, and then it will get swept into master later.
Cheers,
James.
The reason for this MR is people working in 22.0.102. This particular patch is not really necessary to resolve the problems. But, since it only changes a error message it is also harmless. But, if people consider this too delicate for 22. I am fine with targeting only later releases.
@aleopold is there any particular reason why you are trying to run the ID-luminosity analysis in release 22, rather than in release 23?
Release 23 is extremely similiar to Release 22. There may not even by any code migration needed at all - especially if you are already using Component Accumulator.
It would be appreciated if this could at least be considered and looked at before we start making releases in older series again.
Edited by Nicholas StylesI'd hope that it isn't too much work to migrate the code even though no component accumulator migration has happened when the Rel22 version of the track counting code was put in place. But we'd have to run anyways extensive validation if we want to base lumi measurements on this still.
Since pixel cluster counting is less critical now I'd be fine with getting it in Rel23 if we can then also move MR 63947 there so that we can start looking into implementing the tool that we want using the expression parser.
I opened a new MR !64164 (merged) for 23.0.
added review-user-action-required label and removed review-approved label
mentioned in merge request !64164 (merged)
removed review-user-action-required label
added review-approved label
added review-pending-level-1 label and removed review-approved label