Skip to content
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

drop type specs in RecoTracker/{DeDx,FinalTrackSelectors} #30556

Merged
merged 1 commit into from Jul 7, 2020

Conversation

jeongeun
Copy link
Contributor

@jeongeun jeongeun commented Jul 6, 2020

PR description: Update the safer syntax for existing parameter

Instead of modifying parameters with full type specs, which can be interpreted as an insertion of a new parameter, it is a safer way to protect from parameter name mistakes and will also help in possible parameter migrations.
(The references were PR#29979, PR#30147, PR#30270 , PR#30271, PR#30353)

In this PR, 9 files updated.

  • RecoTracker/{DeDx} 4 files
  • RecoTracker/{FinalTrackSelectors} 5 files

PR validation:

Event Content comparison check was also done and there is no change with these updates.
Tested in CMSSW_11_2_X, the basic test all passed in the CMSSW PR instructions.

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-30556/16792

  • This PR adds an extra 20KB to repository

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

A new Pull Request was created by @jeongeun (JeongEun Lee) for master.

It involves the following packages:

RecoTracker/DeDx
RecoTracker/FinalTrackSelectors

@perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@makortel, @felicepantaleo, @GiacomoSguazzoni, @JanFSchulte, @rovere, @VinInn, @mschrode, @gpetruc, @ebrondol, @mtosi, @dgulhan this is something you requested to watch as well.
@silviodonato, @dpiparo you are the release manager for this.

cms-bot commands are listed here

@perrotta
Copy link
Contributor

perrotta commented Jul 6, 2020

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

+1
Tested at: 6bb406b
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-eeedea/7714/summary.html
CMSSW: CMSSW_11_2_X_2020-07-06-1100
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

Comparison job queued.

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-eeedea/7714/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 4 differences found in the comparisons
  • DQMHistoTests: Total files compared: 37
  • DQMHistoTests: Total histograms compared: 2787364
  • DQMHistoTests: Total failures: 5
  • DQMHistoTests: Total nulls: 1
  • DQMHistoTests: Total successes: 2787308
  • DQMHistoTests: Total skipped: 50
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: -0.004 KiB( 36 files compared)
  • DQMHistoSizes: changed ( 10224.0 ): -0.004 KiB MessageLogger/Warnings
  • Checked 154 log files, 17 edm output root files, 37 DQM output files

@perrotta
Copy link
Contributor

perrotta commented Jul 6, 2020

+1

  • Type specification in cloned /modified python configs dropped as planned
  • Jenkins tests pass

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 6, 2020

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. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2)

@silviodonato
Copy link
Contributor

+1

@cmsbuild cmsbuild merged commit 7618222 into cms-sw:master Jul 7, 2020
Comment on lines 72 to 73
setsToMerge = cms.VPSet( cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) )
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
setsToMerge = cms.VPSet( cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) )
),
setsToMerge = [ cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) )
],

this still works.

I'd think that a nameless tuple like could still work for PSet, like [ ( tLists=cms.vint32(1), pQual=cms.bool(True) ], but this is apparently not supported.
@makortel do you think it would be practical to add?

Copy link
Contributor

@makortel makortel Jul 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think ( tLists=cms.vint32(1), pQual=cms.bool(True) ) would be legal syntax

>>> (foo=2)
  File "<stdin>", line 1
    (foo=2)
        ^
SyntaxError: invalid syntax

So using a keyword argument would require dict(foo=2), which is already used for modifying an existing PSet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dict does not really apply here because full contents of setsToMerge are replaced (we are not modifying just one of the elements of this array.

Just to reiterate, my question was, if we have support for VInputTag to be initialized from [ "a", b", ("c", "d") ] , can we also get a VPSet to be initialized without listing the element type?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With VInputTag a compact (maybe event too compact) is possible because the meaning of each element of the sequence of strings is known by its position in the sequence. In PSet the element keys are the parameter names, so dict would be a natural "shortcut". But we already use dict for something else, and I'd think anything along ("tlists", cms.vint32(1), "pQual", cms.bool(True)) would be (much) less clear than just using the cms.PSet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, I meant
instead of
cms.VPSet( cms.PSet( tLists=cms.vint32(1), pQual=cms.bool(True) ) )
to be able to say
[ ( tLists=cms.vint32(1), pQual=cms.bool(True) ) ]
this is not serving the full goal of "drop type specs", but it would at least allow to insert elements to a container of a known type (vector of cms.PSet) without need to explicitly specify the type of the element (cms.PSet)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about [ { 'tLists' : cms.vint32(1), 'pQual' : cms.bool(True) } ] ?
it would be a valid syntax, but it comes out with raise TypeError("wrong type being extended to container "+self._labelIfAny())

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The { 'tLists' : cms.vint32(1), 'pQual' : cms.bool(True) } is a dictionary equivalent to dict(tLists = cms.vint32(1), pQual = cms.bool(True)).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, syntactically , this dict( may be more transparent.
I guess from the above the point is that dict doesn't do the right thing here (yet?).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, syntactically , this dict( may be more transparent.
I guess from the above the point is that dict doesn't do the right thing here (yet?).

OTOH, the difference to type cms.PSet vs dict( is rather minor; IIRC this is also the only vector type that needs this. So, we may just live with it for now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, syntactically , this dict( may be more transparent.
I guess from the above the point is that dict doesn't do the right thing here (yet?).

We already use dict() to modify an existing PSet. I think using it to denote new PSet in one context would be confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants