Muon selector function taking enum type #21185
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks |
|
A new Pull Request was created by @peruzzim for master. It involves the following packages: DataFormats/MuonReco @perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
|
The tests are being triggered in jenkins. |
|
On 11/6/17 3:58 PM, peruzzim wrote:
Needed to call reco::Muon::passed from string parser using names defined
in the reco::Muon::Selector enum.
does the parser accept cast in syntax?
(int)reco::Muon::SelectorName?
|
|
@slava77 I have not succeeded in casting from the parser, and was not able to find any documentation for how to do so. The twiki shows an example that uses the string. |
|
@perrotta: no, the parser doesn't accepts casts, it needs the method that
takes an enum as argument to be able to work by name.
…On Mon, Nov 6, 2017 at 5:50 PM, peruzzim ***@***.***> wrote:
@slava77 <https://github.com/slava77> I have not succeeded in casting
from the parser, and was not able to find any documentation for how to do
so. The twiki shows an example that uses the string.
I also tried to navigate through the code, but I was not able to really
identify which functions are called to see if there is a workaround.
In any case, having the chance of accessing by string would be cleaner
because we are already doing it for several other methods (i.e.
pat::Muon::dB).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21185 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEbbR1hAZ5ByCl0FYO_pNCON6X0V3VVlks5szzjOgaJpZM4QTXRB>
.
|
|
-1 Tested at: d2f3a41 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: You can see the results of the tests here: I found follow errors while testing this PR Failed tests: UnitTests
I found errors in the following unit tests: ---> test runtestTqafTopEventProducers had ERRORS The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
|
Comparison job queued. |
|
error is from tau ID updates, unrelated with this PR
…On Mon, Nov 6, 2017 at 6:49 PM, cmsbuild ***@***.***> wrote:
-1
Tested at: d2f3a41
<d2f3a41>
The following merge commits were also included on top of IB + this PR
after doing git cms-merge-topic:
fcaeeab
<fcaeeab>
You can see more details here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-
request-integration/PR-21185/24204/git-log-recent-commits
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-
request-integration/PR-21185/24204/git-merge-result
You can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-
request-integration/PR-21185/24204/summary.html
I found follow errors while testing this PR
*Failed tests: UnitTests*
- *Unit Tests*:
I found errors in the following unit tests:
---> test runtestTqafTopEventProducers had ERRORS
---> test runtestTqafTopEventSelection had ERRORS
---> test runtestTqafExamples had ERRORS
The following merge commits were also included on top of IB + this PR
after doing git cms-merge-topic:
fcaeeab
<fcaeeab>
You can see more details here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-
request-integration/PR-21185/24204/git-log-recent-commits
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-
request-integration/PR-21185/24204/git-merge-result
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21185 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEbbRy_A62vQZsmUYhpTCTXYWxFZ9ANwks5sz0bAgaJpZM4QTXRB>
.
|
|
On 11/6/17 5:50 PM, peruzzim wrote:
@slava77 <https://github.com/slava77> I have not succeeded in casting
from the parser, and was not able to find any documentation for how to
do so. The twiki shows an example that uses the string.
I also tried to navigate through the code, but I was not able to really
identify which functions are called to see if there is a workaround.
In any case, having the chance of accessing by string would be cleaner
because we are already doing it for several other methods (i.e.
pat::Muon::dB).
OK, although this somewhat defeats the purpose of the method with int
argument,
which is there to allow an "OR" of many bits in one go.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21185 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbie_99jK9cBUQ79T5BLbLlj80Bosks5szzjMgaJpZM4QTXRB>.
|
We may want to have different names for the two methods to avoid confusion. Probably easier to change the name of the new method. |
|
Comparison is ready Comparison Summary:
|
|
@drkovalskyi I don't see why this should be confusing and require different names for the method. Actually I would find it confusing to have two methods, one taking the enum and one taking an integral type (each can be converted into the other either implicitly or by static_cast) that do the same thing with a different name. The possibility of testing the OR of several bits is still supported exactly as it was before, and the addition looks totally transparent to me apart from the chance of calling a single bit in a clean way from the string parser (i.e. without knowing the values defined in the enum - we clearly don't want to hardcode that somewhere else). |
|
Just a suggestion. I don't feel strongly either way. |
|
If I understand correctly, #21186 needs to be merged for the unit tests to complete successfully. |
|
+1 for #21185 d2f3a41
|
cmsbuild
added
fully-signed
reconstruction-approved
and removed
pending-signatures
reconstruction-pending
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (but tests are reportedly failing). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar (and backports should be raised in the release meeting by the corresponding L2) |
|
This will need a backport for 94X. |
|
@davidlange6 yes, it was considered. This update allows calling the method passing the selection by name from the string parser (we need to have the method taking the enum type defined, because we cannot cast there, please see the discussion above). Otherwise, yes, we would have done the cast in the calling code. |
I do not understand the comment. |
|
hi @slava77 - i mean that one can do either bool passed( unsigned int selection ) const { return (selectors_ & selection)==selection; } or change any user of "passed" that with a Selector to be i guess I miss the understanding of if this is a bug affecting current sw or something that is needed in the future? |
|
On 11/9/17 12:33 PM, David Lange wrote:
hi @slava77 <https://github.com/slava77> - i mean that one can do either
bool passed( unsigned int selection ) const { return (selectors_ &
selection)==selection; }
bool passed( Selector selection ) const { return
passed(static_cast(selection)); }
the above is the current implementation.
or change any user of "passed" that with a Selector to be
bool retVal = myMuon.passed( static_castselection);
[I'm assuming it's a "static_cast<int> (selection) " ]
I've asked about this originally
#21185 (comment)
but from #21185 (comment)
apparently
there is no way to make a cast of the argument type in the string passed
to the cut parser.
…
i guess I miss the understanding of if this is a bug affecting current
sw or something that is needed in the future?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21185 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbuNrfthHa5t-AIMKnfy2Ts0x2dovks5s0uL-gaJpZM4QTXRB>.
|
|
On Nov 9, 2017, at 12:45 PM, Slava Krutelyov ***@***.***> wrote:
On 11/9/17 12:33 PM, David Lange wrote:
> hi @slava77 <https://github.com/slava77> - i mean that one can do either
>
> bool passed( unsigned int selection ) const { return (selectors_ &
> selection)==selection; }
> bool passed( Selector selection ) const { return
> passed(static_cast(selection)); }
the above is the current implementation.
>
> or change any user of "passed" that with a Selector to be
> bool retVal = myMuon.passed( static_castselection);
[I'm assuming it's a "static_cast<int> (selection) " ]
I've asked about this originally
#21185 (comment)
but from #21185 (comment)
apparently
there is no way to make a cast of the argument type in the string passed
to the cut parser.
that is to say this function (passed) gets called via the string parser with an enum argument?
If so, then I understand the point.
Thanks
…
>
> i guess I miss the understanding of if this is a bug affecting current
> sw or something that is needed in the future?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#21185 (comment)>, or
> mute the thread
> <https://github.com/notifications/unsubscribe-auth/AEdcbuNrfthHa5t-AIMKnfy2Ts0x2dovks5s0uL-gaJpZM4QTXRB>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
On 11/9/17 12:49 PM, David Lange wrote:
that is to say this function (passed) gets called via the string parser
with an enum argument?
yes.
That is the use case that triggered this PR.
|
|
+1 |
|
merge |
Needed to call reco::Muon::passed from string parser using names defined in the reco::Muon::Selector enum.
@gpetruc @arizzi @emanueledimarco @drkovalskyi