Skip to content

Commit ff620b0

Browse files
authored
chore(docs): fix minor typos (#12824)
1 parent b3a6572 commit ff620b0

File tree

3 files changed

+7
-7
lines changed

3 files changed

+7
-7
lines changed

documentation/en/WIP-arch-complementary-notes.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -86,7 +86,7 @@ These edited extracts from the `BlockHeader` show how it's treated as an IPFS bl
8686

8787
This duality permeates the code (and the Filecoin spec for that matter) but it is usually clear within the context to which block we are referring to. Normally the unqualified *block* is reserved for the Filecoin block and we won't usually refer to the IPFS one but only implicitly through the concept of its CID. With enough understanding of both stack's architecture the two definitions can coexist without much confusion as we will abstract away the IPFS layer and just use the CID as an identifier that we know is unique for two sequences of different *raw* byte strings.
8888

89-
(FIXME: We use to do this presentation when talking about `gossipsub` topics and incoming blocks, and had to deal with, besides the block ambiguity, a similar confusion with the *message* term, used in libp2p to name anything that comes through the network, needing to present the extremely confusing hierarchy of a libp2p message containing a Filecoin block, identified by a IPFS block CID, containing Filecoin messages.)
89+
(FIXME: We use to do this presentation when talking about `gossipsub` topics and incoming blocks, and had to deal with, besides the block ambiguity, a similar confusion with the *message* term, used in libp2p to name anything that comes through the network, needing to present the extremely confusing hierarchy of a libp2p message containing a Filecoin block, identified by an IPFS block CID, containing Filecoin messages.)
9090

9191
FIXME: Move the following tipset definition to sync or wherever is most needed, to avoid making this more confusing.
9292

@@ -124,7 +124,7 @@ nc -v -z 127.0.0.1 1234
124124
# Start daemon and turn off the logs to not clutter the command line.
125125
bash -c "lotus daemon &" &&
126126
lotus wait-api &&
127-
lotus log set-level error # Or a env.var in the daemon command.
127+
lotus log set-level error # Or an env.var in the daemon command.
128128

129129
nc -v -z 127.0.0.1 1234
130130
# Connection to 127.0.0.1 1234 port [tcp/*] succeeded!

documentation/en/architecture/mpool.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -70,7 +70,7 @@ This should be used with extreme care and only in the case of errors during head
7070
would leave the mpool in an inconsistent state.
7171

7272

73-
## Command Line Interfae
73+
## Command Line Interface
7474

7575
The lotus command line interface defines an `mpool` command which
7676
allows a user to interact with the mpool.
@@ -111,7 +111,7 @@ Gets or sets the current mpool configuration.
111111
Unconditionally clears pending messages from the mpool.
112112
If the `--local` flag is passed, then local messages are also cleared; otherwise local messages are retained.
113113

114-
*Warning*: this command should only be used in the case of head change errors leaving the mpool in an state.
114+
*Warning*: this command should only be used in the case of head change errors leaving the mpool in a state.
115115

116116
## Configuration
117117

@@ -172,5 +172,5 @@ selection algorithm is used instead that simply picks dependent chains of
172172
maximum reward. Note that pending message chains from priority addresses
173173
are always selected, regardless of their profitability.
174174

175-
For algorithm details, please prefer to the implementation in
175+
For algorithm details, please refer to the implementation in
176176
`chain/messagepool/selection.go`.

documentation/misc/Building_a_network_skeleton.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ The table below gives an overview of how Lotus and its critical dependencies rel
7171
There is a network skeleton in Lotus, which bubbles up all the other dependencies, and allows one to run a 2k-network and see that it switches network version from nv(XX-1) --> nvXX
7272
7373
## Notes
74-
1. This is the overarching tracking issue for the network skeleton update, but thare are tasks that needed to be completed in other repos as well. All PRs for this effort can reference this issue.
74+
1. This is the overarching tracking issue for the network skeleton update, but there are tasks that need to be completed in other repos as well. All PRs for this effort can reference this issue.
7575
2. How to create a skeleton in Lotus is documented here: https://github.com/filecoin-project/lotus/blob/master/documentation/misc/Building_a_network_skeleton.md
7676
7777
```[tasklist]
@@ -179,7 +179,7 @@ You can take a look at [this PR as a reference](https://github.com/filecoin-proj
179179

180180
👉 You can take a look at this [Filecoin-FFI PR as a reference](https://github.com/filecoin-project/filecoin-ffi/pull/481), which was for network version 24.
181181

182-
Note: one only needs to update `filecion-ffi`'s dependency on `go-state-types` when a network upgrade is introducing new types in `go-state-types` (see [below](#new-types-in-go-state-types)). Otherwise, `filecion-ffi`'s dependency on `go-state-types` is just updated when doing final releases before the network upgrade.
182+
Note: one only needs to update `filecoin-ffi`'s dependency on `go-state-types` when a network upgrade is introducing new types in `go-state-types` (see [below](#new-types-in-go-state-types)). Otherwise, `filecoin-ffi`'s dependency on `go-state-types` is just updated when doing final releases before the network upgrade.
183183

184184
## Lotus Checklist
185185

0 commit comments

Comments
 (0)