pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-30 15:11:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Some typos and misspellings in docs I found, during my studies. (#2144)

Browse Source 
* Fix stale link to overseer docs

* Some typos and mispellings in docs/comments

I found during studying how Polkadot works.
This commit is contained in:
Robert Klotzner
2020-12-19 00:31:43 +01:00
committed by GitHub
parent 2c1a78782e
commit 9ebb9015d3
3 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/node/core/backing/src/lib.rs
+1 -1
View File
@@ -140,7 +140,7 @@ struct CandidateBackingJob {
issued_statements: HashSet<CandidateHash>, issued_statements: HashSet<CandidateHash>,
/// These candidates are undergoing validation in the background. /// These candidates are undergoing validation in the background.
awaiting_validation: HashSet<CandidateHash>, awaiting_validation: HashSet<CandidateHash>,
/// `Some(h)` if this job has already issues `Seconded` statemt for some candidate with `h` hash. /// `Some(h)` if this job has already issued `Seconded` statement for some candidate with `h` hash.
seconded: Option<CandidateHash>, seconded: Option<CandidateHash>,
/// The candidates that are includable, by hash. Each entry here indicates /// The candidates that are includable, by hash. Each entry here indicates
/// that we've sent the provisioner the backed candidate. /// that we've sent the provisioner the backed candidate.
polkadot/node/overseer/src/lib.rs
+3 -3
View File
@@ -17,7 +17,7 @@
//! # Overseer //! # Overseer
//! //!
//! `overseer` implements the Overseer architecture described in the //! `overseer` implements the Overseer architecture described in the
//! [implementers-guide](https://github.com/paritytech/polkadot/blob/master/roadmap/implementers-guide/guide.md). //! [implementers-guide](https://w3f.github.io/parachain-implementers-guide/node/index.html).
//! For the motivations behind implementing the overseer itself you should //! For the motivations behind implementing the overseer itself you should
//! check out that guide, documentation in this crate will be mostly discussing //! check out that guide, documentation in this crate will be mostly discussing
//! technical stuff. //! technical stuff.
@@ -203,7 +203,7 @@ impl OverseerHandler {
self.send_and_log_error(Event::MsgToSubsystem(msg.into())).await self.send_and_log_error(Event::MsgToSubsystem(msg.into())).await
} }
/// Inform the `Overseer` that that some block was finalized. /// Inform the `Overseer` that some block was finalized.
#[tracing::instrument(level = "trace", skip(self), fields(subsystem = LOG_TARGET))] #[tracing::instrument(level = "trace", skip(self), fields(subsystem = LOG_TARGET))]
pub async fn block_finalized(&mut self, block: BlockInfo) { pub async fn block_finalized(&mut self, block: BlockInfo) {
self.send_and_log_error(Event::BlockFinalized(block)).await self.send_and_log_error(Event::BlockFinalized(block)).await
@@ -1002,7 +1002,7 @@ impl<S> Overseer<S>
where where
S: SpawnNamed, S: SpawnNamed,
{ {
/// Create a new intance of the `Overseer` with a fixed set of [`Subsystem`]s. /// Create a new instance of the `Overseer` with a fixed set of [`Subsystem`]s.
/// ///
/// ```text /// ```text
/// +------------------------------------+ /// +------------------------------------+
polkadot/roadmap/implementers-guide/src/node/README.md
+1 -1
View File
@@ -26,6 +26,6 @@ The Node-side code comes with a set of assumptions that we build upon. These ass
We assume the following constraints regarding provided basic functionality: We assume the following constraints regarding provided basic functionality:
* The underlying **consensus** algorithm, whether it is BABE or SASSAFRAS is implemented. * The underlying **consensus** algorithm, whether it is BABE or SASSAFRAS is implemented.
* There is a **chain synchronization** protocol which will search for and download the longest available chains at all times. * There is a **chain synchronization** protocol which will search for and download the longest available chains at all times.
* The **state** of all blocks at the head of the chain is available. There may be **state pruning** such that state of the last `k` blocks behind the last finalized block are is available, as well as the state of all their descendents. This assumption implies that the state of all active leaves and their last `k` ancestors are all available. The underlying implementation is expected to support `k` of a few hundred blocks, but we reduce this to a very conservative `k=5` for our purposes. * The **state** of all blocks at the head of the chain is available. There may be **state pruning** such that state of the last `k` blocks behind the last finalized block are available, as well as the state of all their descendents. This assumption implies that the state of all active leaves and their last `k` ancestors are all available. The underlying implementation is expected to support `k` of a few hundred blocks, but we reduce this to a very conservative `k=5` for our purposes.
* There is an underlying **networking** framework which provides **peer discovery** services which will provide us with peers and will not create "loopback" connections to our own node. The number of peers we will have is assumed to be bounded at 1000. * There is an underlying **networking** framework which provides **peer discovery** services which will provide us with peers and will not create "loopback" connections to our own node. The number of peers we will have is assumed to be bounded at 1000.
* There is a **transaction pool** and a **transaction propagation** mechanism which maintains a set of current transactions and distributes to connected peers. Current transactions are those which are not outdated relative to some "best" fork of the chain, which is part of the active heads, and have not been included in the best fork. * There is a **transaction pool** and a **transaction propagation** mechanism which maintains a set of current transactions and distributes to connected peers. Current transactions are those which are not outdated relative to some "best" fork of the chain, which is part of the active heads, and have not been included in the best fork.