From 243223fba17074244b5751c224997b10ae04b035 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 16 Nov 2023 00:33:58 +0100 Subject: [PATCH] typo: fix typos in md files (#5834) --- README.md | 2 +- data/transactions/logic/README.md | 8 ++++---- data/transactions/logic/README_in.md | 8 ++++---- data/transactions/logic/jsonspec.md | 2 +- docs/follower_node.md | 4 ++-- scripts/windows/instructions.md | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 682d884367..f1ebceceaa 100644 --- a/README.md +++ b/README.md @@ -96,7 +96,7 @@ Please refer to our [CONTRIBUTING](CONTRIBUTING.md) document. ## Project Layout -`go-algorand` is split into various subsystems containing varius packages. +`go-algorand` is split into various subsystems containing various packages. ### Core diff --git a/data/transactions/logic/README.md b/data/transactions/logic/README.md index 1ec45b6e2c..3ba9037fc1 100644 --- a/data/transactions/logic/README.md +++ b/data/transactions/logic/README.md @@ -341,7 +341,7 @@ An application transaction must indicate the action to be taken following the ex Most operations work with only one type of argument, uint64 or bytes, and fail if the wrong type value is on the stack. -Many instructions accept values to designate Accounts, Assets, or Applications. Beginning with v4, these values may be given as an _offset_ in the corresponding Txn fields (Txn.Accounts, Txn.ForeignAssets, Txn.ForeignApps) _or_ as the value itself (a byte-array address for Accounts, or a uint64 ID). The values, however, must still be present in the Txn fields. Before v4, most opcodes required the use of an offset, except for reading account local values of assets or applications, which accepted the IDs directly and did not require the ID to be present in they corresponding _Foreign_ array. (Note that beginning with v4, those IDs _are_ required to be present in their corresponding _Foreign_ array.) See individual opcodes for details. In the case of account offsets or application offsets, 0 is specially defined to Txn.Sender or the ID of the current application, respectively. +Many instructions accept values to designate Accounts, Assets, or Applications. Beginning with v4, these values may be given as an _offset_ in the corresponding Txn fields (Txn.Accounts, Txn.ForeignAssets, Txn.ForeignApps) _or_ as the value itself (a byte-array address for Accounts, or a uint64 ID). The values, however, must still be present in the Txn fields. Before v4, most opcodes required the use of an offset, except for reading account local values of assets or applications, which accepted the IDs directly and did not require the ID to be present in the corresponding _Foreign_ array. (Note that beginning with v4, those IDs _are_ required to be present in their corresponding _Foreign_ array.) See individual opcodes for details. In the case of account offsets or application offsets, 0 is specially defined to Txn.Sender or the ID of the current application, respectively. This summary is supplemented by more detail in the [opcodes document](TEAL_opcodes.md). @@ -775,7 +775,7 @@ are sure to be _available_. The following opcodes allow for "inner transactions". Inner transactions allow stateful applications to have many of the effects -of a true top-level transaction, programatically. However, they are +of a true top-level transaction, programmatically. However, they are different in significant ways. The most important differences are that they are not signed, duplicates are not rejected, and they do not appear in the block in the usual away. Instead, their effects are @@ -786,7 +786,7 @@ account that has been rekeyed to that hash. In v5, inner transactions may perform `pay`, `axfer`, `acfg`, and `afrz` effects. After executing an inner transaction with -`itxn_submit`, the effects of the transaction are visible begining +`itxn_submit`, the effects of the transaction are visible beginning with the next instruction with, for example, `balance` and `min_balance` checks. In v6, inner transactions may also perform `keyreg` and `appl` effects. Inner `appl` calls fail if they attempt @@ -806,7 +806,7 @@ setting is used when `itxn_submit` executes. For this purpose `Type` and `TypeEnum` are considered to be the same field. When using `itxn_field` to set an array field (`ApplicationArgs` `Accounts`, `Assets`, or `Applications`) each use adds an element to the end of -the the array, rather than setting the entire array at once. +the array, rather than setting the entire array at once. `itxn_field` fails immediately for unsupported fields, unsupported transaction types, or improperly typed values for a particular diff --git a/data/transactions/logic/README_in.md b/data/transactions/logic/README_in.md index ecbf2c6bbb..e98d6c2441 100644 --- a/data/transactions/logic/README_in.md +++ b/data/transactions/logic/README_in.md @@ -300,7 +300,7 @@ of (varuint, bytes) length prefixed byte strings. Most operations work with only one type of argument, uint64 or bytes, and fail if the wrong type value is on the stack. -Many instructions accept values to designate Accounts, Assets, or Applications. Beginning with v4, these values may be given as an _offset_ in the corresponding Txn fields (Txn.Accounts, Txn.ForeignAssets, Txn.ForeignApps) _or_ as the value itself (a byte-array address for Accounts, or a uint64 ID). The values, however, must still be present in the Txn fields. Before v4, most opcodes required the use of an offset, except for reading account local values of assets or applications, which accepted the IDs directly and did not require the ID to be present in they corresponding _Foreign_ array. (Note that beginning with v4, those IDs _are_ required to be present in their corresponding _Foreign_ array.) See individual opcodes for details. In the case of account offsets or application offsets, 0 is specially defined to Txn.Sender or the ID of the current application, respectively. +Many instructions accept values to designate Accounts, Assets, or Applications. Beginning with v4, these values may be given as an _offset_ in the corresponding Txn fields (Txn.Accounts, Txn.ForeignAssets, Txn.ForeignApps) _or_ as the value itself (a byte-array address for Accounts, or a uint64 ID). The values, however, must still be present in the Txn fields. Before v4, most opcodes required the use of an offset, except for reading account local values of assets or applications, which accepted the IDs directly and did not require the ID to be present in the corresponding _Foreign_ array. (Note that beginning with v4, those IDs _are_ required to be present in their corresponding _Foreign_ array.) See individual opcodes for details. In the case of account offsets or application offsets, 0 is specially defined to Txn.Sender or the ID of the current application, respectively. This summary is supplemented by more detail in the [opcodes document](TEAL_opcodes.md). @@ -422,7 +422,7 @@ are sure to be _available_. The following opcodes allow for "inner transactions". Inner transactions allow stateful applications to have many of the effects -of a true top-level transaction, programatically. However, they are +of a true top-level transaction, programmatically. However, they are different in significant ways. The most important differences are that they are not signed, duplicates are not rejected, and they do not appear in the block in the usual away. Instead, their effects are @@ -433,7 +433,7 @@ account that has been rekeyed to that hash. In v5, inner transactions may perform `pay`, `axfer`, `acfg`, and `afrz` effects. After executing an inner transaction with -`itxn_submit`, the effects of the transaction are visible begining +`itxn_submit`, the effects of the transaction are visible beginning with the next instruction with, for example, `balance` and `min_balance` checks. In v6, inner transactions may also perform `keyreg` and `appl` effects. Inner `appl` calls fail if they attempt @@ -453,7 +453,7 @@ setting is used when `itxn_submit` executes. For this purpose `Type` and `TypeEnum` are considered to be the same field. When using `itxn_field` to set an array field (`ApplicationArgs` `Accounts`, `Assets`, or `Applications`) each use adds an element to the end of -the the array, rather than setting the entire array at once. +the array, rather than setting the entire array at once. `itxn_field` fails immediately for unsupported fields, unsupported transaction types, or improperly typed values for a particular diff --git a/data/transactions/logic/jsonspec.md b/data/transactions/logic/jsonspec.md index 817c01ece4..0df95373fa 100644 --- a/data/transactions/logic/jsonspec.md +++ b/data/transactions/logic/jsonspec.md @@ -50,7 +50,7 @@ Duplicate keys at the top level result in an error; however, duplicate keys nest #### Special Values - `null`, `true`, `false` are the only accepted special values. -- other spcial values such as `NaN`,`+Inf`,`-Inf` are not accepted +- other special values such as `NaN`,`+Inf`,`-Inf` are not accepted #### Exponential Notation diff --git a/docs/follower_node.md b/docs/follower_node.md index 8df2306417..742d4efe44 100644 --- a/docs/follower_node.md +++ b/docs/follower_node.md @@ -34,7 +34,7 @@ Behavior is controlled with the `config.json` file: On startup, a follower node will be paused (synchronized) with its ledger's current round. For a new deployment configured as a follower node, the -initial sync round is 0. When a sync round is set, the node advance +initial sync round is 0. When a sync round is set, the node advances `MaxAcctLookback-1` rounds. The node is synchronized for the availability of `Ledger State Delta` data. This means the minimum sync round is provided and the node advances to cache future rounds. @@ -56,7 +56,7 @@ The follower node was stripped of all functionality not directly related to assisting with data-gathering capabilities. Since it is designed to run alongside another application, it was made as lightweight as possible. Other restrictions relate to the fact that this node is designed to be -paused. So there are no guarantees that it's internal state matches the +paused. So there are no guarantees that its internal state matches the current round of consensus. In particular, the follower node cannot participate in consensus or send diff --git a/scripts/windows/instructions.md b/scripts/windows/instructions.md index b24370bcf7..6b388d1d1e 100644 --- a/scripts/windows/instructions.md +++ b/scripts/windows/instructions.md @@ -8,7 +8,7 @@ pacman -Syu --disable-download-timeout ``` - NOTE: It is very likely MSYS2 will ask to close the window and repeat the command for furter updates. Check `MSYS2` web page for additional support. + NOTE: It is very likely MSYS2 will ask to close the window and repeat the command for further updates. Check `MSYS2` web page for additional support. 4. Install GIT on MSYS2 by executing the following command: