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

Share code in parsers of committee commands #816

Merged
merged 6 commits into from
Jul 4, 2024

Conversation

smelc
Copy link
Contributor

@smelc smelc commented Jul 3, 2024

Changelog

- description: |
    Share code in parsers of committee commands. This doesn't share the CLI's behavior.
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  # - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  - refactoring    # QoL changes
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context

  • While doing PRs recently in this part of the codebase, I realized that some places had code duplicated, without a good reason. Sharing will also fixes to affect multiple commands at once in the future, and also helps keeping different commands consistent.
  • Fixes Use pHexHash more often #811

More sharing is possible (e.g. hot VS cold), but I don't want to stack too much in one PR.

How to trust this PR

  • Golden files are not changed
  • The tight types means that if the code still compiles, and the types didn't change; then probably the runtime behavior didn't change either.
  • Each commit is standalone and makes sense on his own, to ease review. So it's advised to review commit per commit.
  • It's twice more deletions than additions

Checklist

  • Commit sequence broadly makes sense and commits have useful messages
  • Self-reviewed the diff

. deserialiseFromRawBytesHex (AsHash a)
. BSC.pack
where
errPrefix = maybe "" ((<>) ": ") mErrPrefix

Check notice

Code scanning / HLint

Use section Note

cardano-cli/src/Cardano/CLI/EraBased/Options/Common.hs:540:26-36: Suggestion: Use section
  
Found:
  ((<>) ": ")
  
Perhaps:
  (": " <>)
@smelc smelc force-pushed the smelc/share-code-in-comittee-parsers branch from 36bb1a8 to e8e94d3 Compare July 3, 2024 12:26
Copy link
Contributor

@palas palas left a comment

Choose a reason for hiding this comment

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

Nice refactoring. Just some ideas to bring it even further

]
deserialiseHotCCKeyHashFromHex :: ReadM (Hash CommitteeHotKey)
deserialiseHotCCKeyHashFromHex =
pHexHash AsCommitteeHotKey (Just "Invalid Consitutional Committee hot key hash")
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
pHexHash AsCommitteeHotKey (Just "Invalid Consitutional Committee hot key hash")
pHexHash AsCommitteeHotKey (Just "Invalid Constituional Committee hot key hash")

Consitutional -> Constitutional

The typo was already there before the PR, but it would be good to do a search and replace since you are at it

:: SerialiseAsRawBytes (Hash a) => AsType a -> ReadM (Hash a)
pHexHash a =
:: SerialiseAsRawBytes (Hash a) => AsType a -> Maybe String -> ReadM (Hash a)
pHexHash a mErrPrefix =
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice, you could also use this function in:
pAddCommitteeColdVerificationKeyHash, pGenesisVerificationKeyHash, pGenesisDelegateVerificationKeyHash, pVrfVerificationKeyHash, and pStakePoolMetadataHash, I think.

. BSC.pack

deserialiseColdCCKeyFromHex :: String -> Either String (VerificationKey CommitteeColdKey)
deserialiseColdCCKeyFromHex =
Copy link
Contributor

Choose a reason for hiding this comment

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

Would also be nice to have also something like pHexHash for verification keys (or even generalize it further, not sure if it is possble), and that could also be used in several places in this file: pGenesisDelegateVerificationKey, pAddCommitteeColdVerificationKey, deserialiseColdCCKeyFromHex, deserialiseHotCCKeyFromHex, and pGenesisVerificationKey.

@smelc
Copy link
Contributor Author

smelc commented Jul 4, 2024

Thanks @palas, I'll look at your suggestions in another PR, I don't like big PRs 😉

@smelc smelc force-pushed the smelc/share-code-in-comittee-parsers branch from e8e94d3 to a11c529 Compare July 4, 2024 09:29
@smelc smelc enabled auto-merge July 4, 2024 09:30
@smelc smelc mentioned this pull request Jul 4, 2024
2 tasks
pHexHash
:: SerialiseAsRawBytes (Hash a) => AsType a -> ReadM (Hash a)
pHexHash a =
:: SerialiseAsRawBytes (Hash a) => AsType a -> Maybe String -> ReadM (Hash a)
Copy link
Contributor

Choose a reason for hiding this comment

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

can you add a haddock for Maybe String. It takes a moment to understand its purpose.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was a top-level haddock, changed to be attached to the parameter 👍

@@ -8,6 +8,7 @@
{- HLINT ignore "Move brackets to avoid $" -}
{- HLINT ignore "Use <$>" -}
{- HLINT ignore "Move brackets to avoid $" -}
{- HLINT ignore "Use section" -}
Copy link
Contributor

Choose a reason for hiding this comment

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

what's wrong with sections?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It yields this suggestion:

cardano-cli/src/Cardano/CLI/EraBased/Options/Common.hs:538:26-36: Suggestion: Use section
Found:
  ((<>) ": ")
Perhaps:
  (": " <>)

which I personally don't find a really good change. But no strong opinion. I can leave it back if you prefer.

Copy link
Contributor

Choose a reason for hiding this comment

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

They're fine imo. My problem is with per-module level hlint rules. I think we should agree together on a set of them, put them into the top level config and enforce those rules everywhere.

@smelc smelc added this pull request to the merge queue Jul 4, 2024
@smelc smelc removed this pull request from the merge queue due to a manual request Jul 4, 2024
@smelc smelc force-pushed the smelc/share-code-in-comittee-parsers branch from a11c529 to daddf0d Compare July 4, 2024 11:55
@smelc smelc enabled auto-merge July 4, 2024 11:56
@smelc smelc disabled auto-merge July 4, 2024 12:34
@smelc smelc merged commit a1dc1a7 into main Jul 4, 2024
14 of 15 checks passed
@smelc smelc deleted the smelc/share-code-in-comittee-parsers branch July 4, 2024 12:34
@smelc smelc mentioned this pull request Jul 4, 2024
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use pHexHash more often
3 participants