- Jan 21, 2020
-
-
Sergei Shulepov authored
This may solve a problem with segfaults.
-
- Jan 20, 2020
-
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Pierre Krieger authored
-
- Jan 19, 2020
-
-
By using `cfg(doc)`, we can generate docs for modules which are only available from `no_std`. This drastically improves the documentation for the developers.
-
- Jan 18, 2020
-
-
Gavin Wood authored
* Add rules and unfounding to society. * Docs and event * Extra bit of docs. * Cunningly reduce complexity * Remove candidates when unfounding. * Remove suspended candidates when unfounding, too.
-
Bastian Köcher authored
Adds a table to the rustdoc that shows how each individual type is passed between the wasm and the host side.
-
Xiliang Chen authored
-
- Jan 17, 2020
-
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Shawn Tabrizi authored
* Ensure all votes are removed after tally * Fix comment
-
Sergei Shulepov authored
-
Sergei Shulepov authored
-
Max Inden authored
* client/finality-grandpa: Reintegrate gossip validator report stream The `finality-grandpa` `GossipValidator` is called by the `GossipEngine` in a synchronous fashion on each gossip message. Its main task is to decide whether to gossip the given message on, or whether to drop it. In addition it also updates the reputation of a node's peers based on the incoming gossip messages. To do so it needs to be able to report the reputation change which it does through an unbounded channel (in order to stay synchronous). Previously the receiving side of this channel would be handled by a new task, polling the channel and forwarding the changes to a clone of the `GossipEngine` that it would own. Instead the receiver of the above mentioned channel is now being polled by the `NetworkBridge` within its `Future::poll` implementation. Reputation changes are reported through the already existing `GossipEngine` instance within `NetworkBridge`. For details on the overall goal, see d4fbb897. * client/finality-grandpa: Remove exit future from test NetworkBridges
-
Sergey Pepyakin authored
* Drive by fix of doc of `Value`. * Apply suggestions from code review Co-Authored-By: André Silva <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: André Silva <[email protected]>
-
Fedor Sakharov authored
* Expose proof generation and verifying api. * tabs to spaces * bring back license comment * Revert "tabs to spaces" This reverts commit 4c3f72f9. * Formatting and docs nits * Bump deps versions * Upadte Cargo.lock * into -> in
-
Shawn Tabrizi authored
* Add `max_members` to `found`, add society genesis for Substrate node * Update test * Use `Option<bool>` rather than `Option<()>` * Update from feedback
-
Nikolay Volf authored
-
André Silva authored
-
Max Inden authored
The `NeighborPacketWorker` within `client/finality-grandpa` does two things: 1. It receives neighbor packets from components within `client/finality-grandpa`, sends them down to the `GossipEngine` in order for neighboring nodes to receive. 2. It periodically sends out the most recent neighbor packet to the `GossipEngine`. In order to send out packets it had a clone to a `GossipEgine` within an atomic reference counter and a mutex. The `NeighborPacketWorker` was then spawned onto its own asynchronous task. Instead of running in its own task, this patch reintegrates the `NeighborPacketWorker` into the main `client/finality-grandpa` task not requiring the `NeighborPacketWorker` to own a clone of the `GossipEngine`. The greater picture This is a tiny change within a greater refactoring. The overall goal is to **simplify** how finality-grandpa interacts with the network and to **reduce** the amount of **unbounded channels** within the logic. Why no unbounded channels: Bounding channels is needed for backpressure and proper scheduling. With unbounded channels there is no way of telling the producer side to slow down for the consumer side to catch up. Rephrased, there is no way for the scheduler to know when to favour the consumer task over the producer task on a crowded channel and the other way round for an empty channel. Reducing the amount of shared ownership simplifies the logic and enables one to use async-await syntax-suggar, given that one does not need to hold a lock across poll invocations. Using async-await enables one to use bounded channels without complex logic.
-
Sergei Shulepov authored
-
Wei Tang authored
-
Sergei Shulepov authored
-
Nikolay Volf authored
-
Stanislav Tkach authored
* Add typedefs for storage types * Fix after merge
-
Xiliang Chen authored
-