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
partial technical cleanup of DQMServices/StreamerIO/plugins
#40420
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40420/33548
|
A new Pull Request was created by @missirol (Marino Missiroli) for master. It involves the following packages:
@emanueleusai, @ahmad3213, @cmsbuild, @syuvivida, @pmandrik, @micsucmed, @rvenditti can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-de3e18/29787/summary.html Comparison SummarySummary:
|
header->hltTriggerNames(tnames); | ||
|
||
pset.addParameter<Strings>("SelectEvents", hltSel_); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realised I introduced a mistake here in d3c247c. Supposedly, the original code needed this because TriggerSelector
expects a tracked vector<string>
(same goes for the relevant ctor of EventSelector
), i.e.
paths = config.getParameter<Strings>("SelectEvents"); |
: pathspecs_(config.empty() ? Strings() : initPathSpecs(config.getParameter<Strings>("SelectEvents"))), |
On the other hand, the PSet of
DQMStreamerReader
provides an untracked vector<string>
(guaranted by its fillDescriptions
, afaiu).
This will be fixed in the next push with further cleanup (rather than by reverting this incorrect change).
d3c247c
to
3de6025
Compare
eventSelector_.reset(new edm::EventSelector(pathspecs, names)); | ||
} | ||
|
||
TriggerSelector::TriggerSelector(edm::ParameterSet const& config, Strings const& triggernames, bool old_) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ctor becomes unnecessary, and is thus removed. It was only used in
void DQMStreamerReader::openFileImp_(const DQMFileIterator::LumiEntry& entry) { |
and this PR changes that to use the ctor
TriggerSelector(Strings,..)
instead.
Rationale: in the one case where TriggerSelector(ParameterSet,..)
was used
TriggerSelector::TriggerSelector(edm::ParameterSet const& config, Strings const& triggernames, bool old_) |
old_ == false
(default value of argument) and config.empty() == false
(because ofpset.addParameter<Strings>("SelectEvents", hltSel_); |
), so what is used is
cmssw/DQMServices/StreamerIO/plugins/TriggerSelector.cc
Lines 43 to 49 in 1a989c3
Strings paths; | |
paths = config.getParameter<Strings>("SelectEvents"); | |
if (!paths.empty()) { | |
useOld_ = true; | |
eventSelector_.reset(new edm::EventSelector(config, triggernames)); | |
return; | |
} |
That is effectively equivalent to the TriggerSelector(Strings,..)
ctor. There is slight difference between the two constructors: if paths.empty() == true
, the PSet-based ctor uses acceptAll_ == true
and does not create an EventSelector
; on the other hand, the behavior is the same, because TriggerSelector(Strings,..)
(the other ctor) would create an EventSelector
with an empty pathspecs
eventSelector_.reset(new edm::EventSelector(pathspecs, names)); |
and in that case
EventSelector
will accept all events anyway (as one would naively expect)cmssw/FWCore/Framework/src/EventSelector.cc
Lines 49 to 51 in 1a989c3
: pathspecs_(initPathSpecs(pathspecs)), | |
results_from_current_process_(true), | |
accept_all_(initAcceptAll()), |
cmssw/FWCore/Framework/src/EventSelector.cc
Lines 100 to 103 in 1a989c3
bool EventSelector::initAcceptAll() { | |
if (pathspecs_.empty()) { | |
return true; | |
} |
The added value of this cleanup is that (1) TriggerSelector
becomes independent of ParameterSet
, and (2) two static-analyzer warnings (use of catch(...)
) are removed.
try { | ||
std::string myPath = trim(config.getParameter<std::string>("TriggerSelector")); | ||
if (!myPath.empty()) { | ||
init(myPath, triggernames); | ||
return; | ||
} | ||
} catch (...) { | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A string configuration-parameter named TriggerSelector
is not used anywhere in CMSSW, as far as I can see. Not sure if I need to worry about client code outside CMSSW in this case.
: EventSelector( | ||
[&config]() { | ||
auto const& pset = config.getUntrackedParameterSet("SelectEvents"); | ||
return (pset.empty() ? Strings() : pset.getParameter<Strings>("SelectEvents")); | ||
}(), | ||
pathNames) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tentatively added ecb204a, because I noticed that the PSet-based constructor of EventSelector
is somewhat inconsistent with its fillDescription
method (the latter defines SelectEvents.SelectEvents
, while the ctor expects SelectEvents
). This required small changes to 3 FWCore
unit tests. With this PR, the PSet-based ctor of EventSelector
would not be used anywhere, I think (outside those unit tests), so it could even be removed. To be clear, ecb204a is not necessary for this PR, so I could remove it if preferred.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a quick look I agree that with this PR the PSet-based constructor of EventSelector
becomes unused (besides the unit tests). My preference would be to just remove it (probably cleaner to do in a separate PR). Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I will remove ecb204a from this PR, to keep it 'DQM only' (although I could use review comments on this PR too, e.g. #40420 (comment)), and I'll open a separate PR for the small changes in FWCore
.
Edit: done in #40432.
} catch (...) { | ||
// pass | ||
} catch (std::exception const& exc) { | ||
LogDebug("DQMMonitoringService") << "Exception thrown in outputUpdate method: " << exc.what(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more static-analyzer warning (catch(...)
) is coming from here, but I'm not sure how to fix this one. The change in 3de6025 is tentative, and I welcome feedback.
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40420/33565
|
Pull request #40420 was updated. @smuzaffar, @Dr15Jones, @makortel, @emanueleusai, @ahmad3213, @cmsbuild, @syuvivida, @pmandrik, @micsucmed, @rvenditti can you please check and sign again. |
3de6025
to
5f0af33
Compare
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40420/33570
|
Pull request #40420 was updated. @emanueleusai, @ahmad3213, @cmsbuild, @syuvivida, @pmandrik, @micsucmed, @rvenditti can you please check and sign again. |
@cms-sw/dqm-l2, could you please review this PR? Thanks! |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-de3e18/29956/summary.html Comparison SummarySummary:
|
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This PR applies a partial technical cleanup of the classes in
DQMServices/StreamerIO/plugins
.The initial goal was to remove unused class members (e.g.
cmssw/DQMServices/StreamerIO/plugins/DQMStreamerReader.cc
Lines 27 to 28 in 9eb6ddb
); then, further technical changes were also included, mainly to clean up
#include <header>
directives, introduce someconst
correctness, simplify/modernise small portions of code, and limit (ab)use ofusing namespace
calls.Merely technical. No changes expected.
PR validation:
None.
If this PR is a backport, please specify the original PR and why you need to backport that PR. If this PR will be backported, please specify to which release cycle the backport is meant for:
N/A