Merge #3153

3153: Fix typos in comments and function names. r=Anviking a=rex4539



Co-authored-by: Dimitris Apostolou <[email protected]>

docs/contributing/Release-Checklist.md

@@ -8,7 +8,7 @@
 
   Verify that the content of [`stack.yaml`][] and [`cabal.project`][] correspond to the `cardano-node` version.
 
-  Verify that target repositories point to appopriate revisions for `persistent`, `cardano-addresses`, `bech32`, ...)
+  Verify that target repositories point to appropriate revisions for `persistent`, `cardano-addresses`, `bech32`, ...)
 
 - Fetch the tip of `master`:
 

docs/design/Eras.md

@@ -70,7 +70,7 @@ Cardano Mode is the default. I'm not aware of too many people using single-era m
 
 ## Specifications
 
-Formal specifications (and the actual implementations!) for each Cardano era exist in the [input-output-hk/cardano-ledger](https://github.com/input-output-hk/cardano-ledger) repo. These documents are suprisingly readable, and are our go-to source for answers about how the node operates. See the [`README.md`](https://github.com/input-output-hk/cardano-ledger/blob/master/README.md) for links to PDFs and/or build instructions.
+Formal specifications (and the actual implementations!) for each Cardano era exist in the [input-output-hk/cardano-ledger](https://github.com/input-output-hk/cardano-ledger) repo. These documents are surprisingly readable, and are our go-to source for answers about how the node operates. See the [`README.md`](https://github.com/input-output-hk/cardano-ledger/blob/master/README.md) for links to PDFs and/or build instructions.
 
 ### Decentralized Update Proposals
 

docs/design/specs/light-mode.md

@@ -40,7 +40,7 @@ As the Cardano blockchain grows in size, retrieving and verifying blocks from th
 ## Technical benefits
 
 * *Speed*. With light-mode, we expect synchronisation times of < 1 minute for a wallet with 1'000 transactions. In contrast, synchronisation of an empty wallet currently takes ~ 50 minutes by connecting to a node — assuming that the node has already synced to the chain tip and built its ledger state, which itself takes hours.
-* *Compatiblity*. Light-mode is intended to preserve the API presented to downstream software such as [Daedalus][], only *minimal* changes are expected.
+* *Compatibility*. Light-mode is intended to preserve the API presented to downstream software such as [Daedalus][], only *minimal* changes are expected.
 * *Optionality*. A wallet that was started in light-mode can be restarted in full mode without resynchronization, and vice versa. (MVP: no support yet for changing the mode dynamically while the wallet is running.)
 
 ## Limitations
@@ -100,7 +100,7 @@ flowchart TB
 ```
 :::
 
-In light-mode, `cardano-wallet` instead connects to the data source (e.g. `cardano-graphql` or [Blockfrost][]) and a transaction submission service trough the internet
+In light-mode, `cardano-wallet` instead connects to the data source (e.g. `cardano-graphql` or [Blockfrost][]) and a transaction submission service through the internet
 
 :::{.mermaid-container}
 ```mermaid
@@ -132,7 +132,7 @@ $ cardano-wallet serve --light CRED
 ```
 
 * `CRED` specifies how to connect to the less trusted blockchain data source. (MVP: Use [Blockfrost][]; `CRED` is a filepath to the secret token.)
-* The `--light` argument and the `--node-socket` arguments are mutally exclusive with each other.
+* The `--light` argument and the `--node-socket` arguments are mutually exclusive with each other.
 
 ### REST API
 

docs/developers/Building.md

@@ -120,7 +120,7 @@ The resulting executable will appear at `./result/bin/cardano-wallet`.
 Unless you have local changes in your git repo, Nix will download the
 build from the Hydra cache rather than building locally.
 
-You may also run the exectable directly with:
+You may also run the executable directly with:
 
 ```console
 $ nix run . -- <cardano wallet arguments>

docs/user-guide/cli.md

@@ -97,7 +97,7 @@ Available COMMANDS:
 :::
 
 :::{.info-block}
-:information_source: The CLI commands for `wallet`, `transaction` and `address` only output valid JSON on `stdout`. So you may redirect the output to a file with `>` or pipe it into utility softwares like `jq`!
+:information_source: The CLI commands for `wallet`, `transaction` and `address` only output valid JSON on `stdout`. So you may redirect the output to a file with `>` or pipe it into utility software like `jq`!
 :::
 
 ## Commands

docs/user-guide/faq.md

@@ -15,7 +15,7 @@ More recently, `cardano-wallet` has been using sequential derivation which follo
 
 There are two sides to this question. Either, you are referring to accounts as in Ethereum accounts, or you may refer to accounts of hierarchical deterministic wallets.
 
-In the first scenario, assets in the form of accounts are only supported in the Shelley era of Cardano and only for a specific use-case: rewards. Rewards are indeed implicitely published on the blockchain to mitigate the risk of flooding the network at the end of every epoch with rewards payouts! Hence, each core node keeps track of the current value of each reward account in a Ledger. Money can be withdrawn from this account and is then turned as a UTxO. Please note that funds can never be manually sent to a reward account. The creation of a reward account is done when registering a staking key, via a specific type of transaction.
+In the first scenario, assets in the form of accounts are only supported in the Shelley era of Cardano and only for a specific use-case: rewards. Rewards are indeed implicitly published on the blockchain to mitigate the risk of flooding the network at the end of every epoch with rewards payouts! Hence, each core node keeps track of the current value of each reward account in a Ledger. Money can be withdrawn from this account and is then turned as a UTxO. Please note that funds can never be manually sent to a reward account. The creation of a reward account is done when registering a staking key, via a specific type of transaction.
 
 In the second case, please refer to the [[hierarchical-deterministic-wallets]] section in the _Key concepts_. Cardano wallets typically follow an HD tree of derivation as described in this section.
 

lib/cli/test/unit/Cardano/CLISpec.hs

@@ -264,7 +264,7 @@ spec = do
             (\(desc, arg, tst) -> it desc (parse arg `shouldSatisfy` tst))
             [ ("valid", "{ \"42\": { \"string\": \"hi\" } }", ok (Just md))
             , ("malformed", "testing", err)
-            , ("malformed trailling", "{ \"0\": { \"string\": \"\" } } arstneio", err)
+            , ("malformed trailing", "{ \"0\": { \"string\": \"\" } } arstneio", err)
             , ("invalid", "{ \"json\": true }", err)
             , ("null 1", "{ \"0\": null }", err)
             , ("null 2", "null", ok Nothing)
@@ -284,7 +284,7 @@ spec = do
             , ("valid zero", "0s", ok 0)
             , ("invalid negative", "-1s", err)
             , ("invalid fractional", "1.5s", err)
-            , ("malformed trailling", "1ss", err)
+            , ("malformed trailing", "1ss", err)
             , ("malformed suffix", "1", err)
             , ("malformed empty", "", err)
             , ("malformed emptyish", "s", err)

lib/core-integration/src/Test/Integration/Framework/DSL.hs

@@ -204,7 +204,7 @@ module Test.Integration.Framework.DSL
     , deleteTransactionViaCLI
     , getTransactionViaCLI
 
-    -- utilites
+    -- utilities
     , getRetirementEpoch
     , replaceStakeKey
      -- * Re-exports
@@ -2476,7 +2476,7 @@ verifyMsg desc a = counterexample msg . mapM_ (a &)
 
 -- | Can be used to add context to a @HUnitFailure@.
 --
--- >>> counterexample (show reponse) (0 `shouldBe` 3)
+-- >>> counterexample (show response) (0 `shouldBe` 3)
 -- >>>  (Status {statusCode = 200, statusMessage = "OK"},Right [])
 -- >>>        expected: 3
 -- >>>         but got: 0

lib/core-integration/src/Test/Integration/Plutus.hs

@@ -254,7 +254,7 @@ mintBurn_1 =
     }|]
 
 -- The second transaction burn the token minted by the previous one. The token
--- isn't explictly listed in the inputs, as we expect the wallet to select the
+-- isn't explicitly listed in the inputs, as we expect the wallet to select the
 -- right input during balancing.
 --
 -- The template has the same three parameters as 'mintBurn_1'
@@ -325,7 +325,7 @@ withdrawScript_1 =
 -- * <https://github.com/input-output-hk/plutus-apps/blob/main/plutus-use-cases/src/Plutus/Contracts/Currency.hs>
 -- * <https://github.com/input-output-hk/plutus-apps/blob/main/plutus-use-cases/test/Spec/Currency.hs>
 --
--- The contract was serialised using the suppor code in
+-- The contract was serialised using the support code in
 -- @/extra/Plutus/CurrencyContract.hs@ in this repository.
 --
 -- Assets can be minted by spending a specific UTxO that is hard-wired into

lib/core-integration/src/Test/Integration/Scenario/API/Shared/Wallets.hs

@@ -757,7 +757,7 @@ spec = describe "SHARED_WALLETS" $ do
         expectResponseCode HTTP.status403 rPatch
         expectErrorMessage errMsg403WalletAlreadyActive rPatch
 
-    it "SHARED_WALLETS_PATCH_04 - Cannot add cosigner key when delegation script missing and cannot add already existant key to other cosigner" $ \ctx -> runResourceT $ do
+    it "SHARED_WALLETS_PATCH_04 - Cannot add cosigner key when delegation script missing and cannot add already existent key to other cosigner" $ \ctx -> runResourceT $ do
         [(_, accXPubTxt0),(_,accXPubTxt1)] <- liftIO $ genXPubs 2
         let payloadCreate = Json [json| {
                 "name": "Shared Wallet",

lib/core-integration/src/Test/Integration/Scenario/API/Shelley/StakePools.hs

@@ -408,7 +408,7 @@ spec = describe "SHELLEY_STAKE_POOLS" $ do
         let txid = getFromResponse Prelude.id rq
         let quitFeeAmt = getFromResponse #amount rq
 
-        eventually "Certificates are inserted after quiting a pool" $ do
+        eventually "Certificates are inserted after quitting a pool" $ do
             let epg = Link.getTransaction @'Shelley src txid
             rlg <- request @(ApiTransaction n) ctx epg Default Empty
             verify rlg

lib/core-integration/src/Test/Integration/Scenario/CLI/Shelley/Wallets.hs

@@ -414,7 +414,7 @@ spec = describe "SHELLEY_CLI_WALLETS" $ do
                 , ( "-1000 -> fail", "-1000", expectsErr )
                 , ( "0 -> fail", "0", expectsErr )
                 , ( "10.5 -> fail", "10.5", expectsErr )
-                , ( "arbitraty string -> fail", "string", expectsErr )
+                , ( "arbitrary string -> fail", "string", expectsErr )
                 ]
 
         forM_ matrix $ \(title, gap, expects) -> it title $ \ctx -> runResourceT $ do

lib/core/bench/db-bench.hs

@@ -473,7 +473,7 @@ mkRndAddresses numAddrs i =
 -- imagine a transaction with 1 inputs and 200 outputs because, the coin
 -- selection algorithm always try to consider output independently. So for
 -- 200 outputs, we know that 200 inputs (at least) would be necessary. There are
--- the case for other softwares of course, but we may consider the following
+-- the case for other software of course, but we may consider the following
 -- numbers as realistic benchmark higher bounds (in the worst case):
 --
 -- - 50 inputs

lib/core/src/Cardano/Pool/DB.hs

@@ -310,7 +310,7 @@ determinePoolLifeCycleStatus mReg mRet = case (mReg, mRet) of
         | regPoolId /= retPoolId ->
             differentPoolsError
         | regTime > retTime ->
-            -- A re-registration always /supercedes/ a prior retirement.
+            -- A re-registration always /supersedes/ a prior retirement.
             PoolRegistered regCert
         | regTime < retTime ->
             -- A retirement always /augments/ the latest known registration.

lib/core/src/Cardano/Pool/DB/Sqlite.hs

@@ -360,7 +360,7 @@ newDBLayer tr ti SqliteContext{runQuery} =
                         , retryAfter, "IS NULL"
                         , ")"
                     -- Important, since we have a limit, we order all results by
-                    -- earlist "retry_after", so that we are sure that all
+                    -- earliest "retry_after", so that we are sure that all
                     -- metadata gets _eventually_ processed.
                     --
                     -- Note that `NULL` is smaller than everything.

lib/core/src/Cardano/Wallet.hs

@@ -34,7 +34,7 @@
 --   values for this parameter are described in 'Cardano.Wallet.AddressDiscovery' sub-modules.
 --   For instance @SeqState@ or @Rnd State@.
 --
--- - @k@: A __k__ey derivation scheme intrisically connected to the underlying discovery
+-- - @k@: A __k__ey derivation scheme intrinsically connected to the underlying discovery
 --   state @s@. This describes how the hierarchical structure of a wallet is
 --   defined as well as the relationship between secret keys and public
 --   addresses.
@@ -967,8 +967,8 @@ in the checked exceptions or aware of them.
 Making 'chainSync' aware of the checked exception is currently
 not a good idea, because this function is used in different contexts,
 which have different checked exceptions.
-So, it would need to be polymorophic in the the undelrying monad,
-but at present, 'chainSync' is restricted to 'IO' beause some
+So, it would need to be polymorphic in the underlying monad,
+but at present, 'chainSync' is restricted to 'IO' because some
 of its constituents are also restricted to 'IO'.
 
 As a workaround / solution, we wrap the checked exception into a new type
@@ -1241,7 +1241,7 @@ manageRewardBalance _ ctx wid = db & \DBLayer{..} -> do
                     Left err -> traceWith tr $ MsgRewardBalanceNoSuchWallet err
                     Right () -> pure ()
             Left _err ->
-                -- Occasionaly failing to query is generally not fatal. It will
+                -- Occasionally failing to query is generally not fatal. It will
                 -- just update the balance next time the tip changes.
                 pure ()
     traceWith tr MsgRewardBalanceExited
@@ -1695,7 +1695,7 @@ balanceTransaction
         --
         -- A promising fix would be to replace the details of 'TransactionCtx' with
         -- a (balance, fee) based on calling the node/ledger
-        -- @evaluateTransactionBalance@ on the partial transacion.
+        -- @evaluateTransactionBalance@ on the partial transaction.
         let isReg (Cardano.StakePoolRegistrationCertificate _) = True
             isReg (Cardano.StakeAddressRegistrationCertificate _) = True
             isReg (Cardano.StakeAddressDeregistrationCertificate _) = True

lib/core/src/Cardano/Wallet/Api.hs

@@ -1112,7 +1112,7 @@ data ApiLayer s (k :: Depth -> Type -> Type)
     deriving (Generic)
 
 -- | Locks that are held by the wallet in order to enforce
--- sequential executation of some API actions.
+-- sequential execution of some API actions.
 -- Used with "Control.Concurrent.Concierge".
 data WalletLock = PostTransactionOld WalletId
     deriving (Eq, Ord, Show)

lib/core/src/Cardano/Wallet/Api/Server.hs

@@ -2188,7 +2188,7 @@ constructTransaction ctx genChange knownPools getPoolStatus (ApiT wid) body = do
             Just delegs -> do
                 -- TODO: Current limitation:
                 -- at this moment we are handling just one delegation action:
-                -- either joining pool, or rejoining or quiting
+                -- either joining pool, or rejoining or quitting
                 -- When we support multi-account this should be lifted
                 (action, deposit, refund) <- case NE.toList delegs of
                     [(Joining (ApiT pid) _)] -> do
@@ -3050,7 +3050,7 @@ getNetworkInformation st nl = liftIO $ do
     toApiEra (AnyCardanoEra AlonzoEra) = ApiAlonzo
 
     -- (network tip, next epoch)
-    -- May be unavailible if the node is still syncing.
+    -- May be unavailable if the node is still syncing.
     networkTipInfo :: RelativeTime -> MaybeT IO (ApiSlotReference, ApiEpochInfo)
     networkTipInfo now = do
         networkTipSlot <- interpretQuery ti $ ongoingSlotAt now
@@ -3453,7 +3453,7 @@ mkApiTransaction timeInterpreter setTimeReference tx = do
 
     -- (pending) when reclaim is coming we have (fee+out) - inp = deposit
     -- tx is incoming, and the wallet spent for fee and received deposit - fee as out
-    -- (inLedger) when reclaim is accomodated we have out - inp < deposit as fee was incurred
+    -- (inLedger) when reclaim is accommodated we have out - inp < deposit as fee was incurred
     -- So in order to detect this we need to have
     -- 1. deposit
     -- 2. have inpsWithoutFee of the wallet non-empty

lib/core/src/Cardano/Wallet/Api/Types.hs

@@ -1894,7 +1894,7 @@ data ApiOurStakeKey (n :: NetworkDiscriminant) = ApiOurStakeKey
      { _index :: !Natural
     , _key :: !(ApiT W.RewardAccount, Proxy n)
     , _stake :: !(Quantity "lovelace" Natural)
-      -- ^ The total ada this stake key controlls / is associated with. This
+      -- ^ The total ada this stake key controls / is associated with. This
       -- also includes the reward balance.
     , _rewardBalance :: !(Quantity "lovelace" Natural)
       -- ^ The current reward balance (not lifetime).
@@ -1909,7 +1909,7 @@ data ApiOurStakeKey (n :: NetworkDiscriminant) = ApiOurStakeKey
 data ApiForeignStakeKey (n :: NetworkDiscriminant) = ApiForeignStakeKey
     { _key :: !(ApiT W.RewardAccount, Proxy n)
     , _stake :: !(Quantity "lovelace" Natural)
-      -- ^ The total ada this stake key controlls / is associated with. This
+      -- ^ The total ada this stake key controls / is associated with. This
       -- also includes the reward balance.
     , _rewardBalance :: !(Quantity "lovelace" Natural)
       -- ^ The current reward balance (not lifetime).

lib/core/src/Cardano/Wallet/CoinSelection/Internal/Balance.hs

@@ -1545,7 +1545,7 @@ makeChange criteria
     userSpecifiedAssetIds = TokenBundle.getAssets (F.fold outputBundles)
 
     -- Identifiers and quantities of all non-user-specified assets: assets that
-    -- were not included in the orginal set of outputs, but that were
+    -- were not included in the original set of outputs, but that were
     -- nevertheless selected during the selection process.
     --
     -- Each asset is paired with the complete list of quantities of that asset
@@ -1811,7 +1811,7 @@ makeChangeForCoin = flip Coin.unsafePartition
 -- requires us to add value to the change outputs and burning tokens requires
 -- us to remove value from the change outputs.
 --
--- It's also important to note that the change bundle calcualation requires
+-- It's also important to note that the change bundle calculation requires
 -- that the change for user-specified and non-user-specified assets have the
 -- following properties:
 --

lib/core/src/Cardano/Wallet/DB.hs

@@ -96,7 +96,7 @@ data DBFactory m s k = DBFactory
     }
 
 -- | A Database interface for storing various things in a DB. In practice,
--- we'll need some extra contraints on the wallet state that allows us to
+-- we'll need some extra constraints on the wallet state that allows us to
 -- serialize and unserialize it (e.g. @forall s. (Serialize s) => ...@)
 --
 -- NOTE:

lib/core/src/Cardano/Wallet/DB/Sqlite.hs

@@ -1032,7 +1032,7 @@ mkTxInputsOutputs tx =
         , txOutTokenQuantity = quantity
         }
     ordered f = fmap (zip [0..] . f)
-    -- | Distribute `a` accross many `b`s using the given function.
+    -- | Distribute `a` across many `b`s using the given function.
     -- >>> dist TxOut (addr, [Coin 1, Coin 42, Coin 14])
     -- [TxOut addr (Coin 1), TxOut addr (Coin 42), TxOut addr (Coin 14)]
     dist :: (a -> b -> c) -> (a, [b]) -> [c]

lib/core/src/Cardano/Wallet/DB/Sqlite/Migration.hs

@@ -603,10 +603,10 @@ migrateManually tr proxy defaultFieldValues =
     -- - Fees
     -- - Total deposits if any
     --
-    -- To substract deposit values from fees, we consider that any transaction
+    -- To subtract deposit values from fees, we consider that any transaction
     -- that has one or less output and fees greater than the key deposit (or min
     -- utxo value) is a key registration transaction and the key deposit value
-    -- can be substracted from the delta to deduce the fees.
+    -- can be subtracted from the delta to deduce the fees.
     --
     -- Note that ideally, we would do this in a single `UPDATE ... FROM` query
     -- but the `FROM` syntax is only supported in SQLite >= 3.33 which is only

lib/core/src/Cardano/Wallet/Primitive/AddressDerivation/Byron.hs

@@ -301,7 +301,7 @@ changePassphraseRnd (Passphrase oldPwd) (Passphrase newPwd) key = ByronKey
 -- are any withdrawals).
 --
 -- With 'ByronKey', withdrawals will always be `0`, and the result of this
--- function shouldn't be evaluated (relying on lazyness here). If they do, then
+-- function shouldn't be evaluated (relying on laziness here). If they do, then
 -- we're doing something wrong.
 instance W.HardDerivation ByronKey where
     type AddressIndexDerivationType ByronKey = 'WholeDomain

lib/core/src/Cardano/Wallet/Primitive/AddressDiscovery.hs

@@ -154,10 +154,10 @@ class KnownAddresses s where
 coinTypeAda :: Index 'Hardened 'CoinTypeK
 coinTypeAda = toEnum 0x80000717
 
--- It is used for geting purpose for a given key.
+-- It is used for getting purpose for a given key.
 class GetPurpose (key :: Depth -> Type -> Type)  where
     getPurpose :: Index 'Hardened 'PurposeK
 
--- It is used for geting account public key for a given state.
+-- It is used for getting account public key for a given state.
 class GetAccount s (key :: Depth -> Type -> Type) | s -> key  where
     getAccount :: s -> key 'AccountK XPub