From 4529fd67870edf8e51cb9d418f762b9519156bfd Mon Sep 17 00:00:00 2001 From: George Ornbo Date: Fri, 26 Jan 2018 14:44:48 +0000 Subject: [PATCH] Fix documentation typos --- docs/deploy-testnets.rst | 4 ++-- docs/ecosystem.rst | 2 +- docs/getting-started.rst | 4 ++-- docs/install.rst | 2 +- docs/introduction.rst | 2 +- docs/using-tendermint.rst | 24 ++++++++++++------------ 6 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/deploy-testnets.rst b/docs/deploy-testnets.rst index 89fa4b799..a872c90f9 100644 --- a/docs/deploy-testnets.rst +++ b/docs/deploy-testnets.rst @@ -32,7 +32,7 @@ Here are the steps to setting up a testnet manually: would look like: ``tendermint node --p2p.seeds=192.168.0.1:46656,192.168.0.2:46656,192.168.0.3:46656,192.168.0.4:46656``. -After a few seconds, all the nodes should connect to eachother and start +After a few seconds, all the nodes should connect to each other and start making blocks! For more information, see the Tendermint Networks section of `the guide to using Tendermint `__. @@ -48,7 +48,7 @@ Automated Deployment using Kubernetes The `mintnet-kubernetes tool `__ allows automating the deployment of a Tendermint network on an already -provisioned kubernetes cluster. For simple provisioning of a kubernetes +provisioned Kubernetes cluster. For simple provisioning of a Kubernetes cluster, check out the `Google Cloud Platform `__. Automated Deployment using Terraform and Ansible diff --git a/docs/ecosystem.rst b/docs/ecosystem.rst index 30ab9a35d..80dd663e2 100644 --- a/docs/ecosystem.rst +++ b/docs/ecosystem.rst @@ -44,7 +44,7 @@ Immutable AVL+ tree with Merkle proofs, Written in Go, `authored by Tendermint < Lotion ^^^^^^ -A Javascript microframework for building blockchain applications with Tendermint, written in Javascript, `authored by Judd Keppel of Tendermint `__. See also `lotion-chat `__ and `lotion-coin `__ apps written using Lotion. +A JavaScript microframework for building blockchain applications with Tendermint, written in JavaScript, `authored by Judd Keppel of Tendermint `__. See also `lotion-chat `__ and `lotion-coin `__ apps written using Lotion. MerkleTree ^^^^^^^^^^ diff --git a/docs/getting-started.rst b/docs/getting-started.rst index 26f6b7897..b85e61cdf 100644 --- a/docs/getting-started.rst +++ b/docs/getting-started.rst @@ -40,7 +40,7 @@ dependencies: Now you should have the ``abci-cli`` installed; you'll see a couple of commands (``counter`` and ``dummy``) that are example applications written in Go. See below for an application -written in Javascript. +written in JavaScript. Now, let's run some apps! @@ -49,7 +49,7 @@ Dummy - A First Example The dummy app is a `Merkle tree `__ that just stores all -transactions. If the transaction contains an ``=``, eg. ``key=value``, +transactions. If the transaction contains an ``=``, e.g. ``key=value``, then the ``value`` is stored under the ``key`` in the Merkle tree. Otherwise, the full transaction bytes are stored as the key and the value. diff --git a/docs/install.rst b/docs/install.rst index 64fae4cdc..734be1629 100644 --- a/docs/install.rst +++ b/docs/install.rst @@ -9,7 +9,7 @@ To download pre-built binaries, see the `Download page `__) have had a monolithic design. That is, each blockchain stack is a single program that handles all the concerns of a decentralized ledger; this includes P2P connectivity, the "mempool" broadcasting of transactions, consensus on the most recent block, account balances, Turing-complete contracts, user-level permissions, etc. Using a monolithic architecture is typically bad practice in computer science. -It makes it difficult to reuse components of the code, and attempts to do so result in complex maintanence procedures for forks of the codebase. +It makes it difficult to reuse components of the code, and attempts to do so result in complex maintenance procedures for forks of the codebase. This is especially true when the codebase is not modular in design and suffers from "spaghetti code". Another problem with monolithic design is that it limits you to the language of the blockchain stack (or vice versa). In the case of Ethereum which supports a Turing-complete bytecode virtual-machine, it limits you to languages that compile down to that bytecode; today, those are Serpent and Solidity. diff --git a/docs/using-tendermint.rst b/docs/using-tendermint.rst index 9076230ea..d0bdc9db4 100644 --- a/docs/using-tendermint.rst +++ b/docs/using-tendermint.rst @@ -33,7 +33,7 @@ tool `__. Run --- -To run a tendermint node, use +To run a Tendermint node, use :: @@ -41,7 +41,7 @@ To run a tendermint node, use By default, Tendermint will try to connect to an ABCI application on `127.0.0.1:46658 <127.0.0.1:46658>`__. If you have the ``dummy`` ABCI -app installed, run it in another window. If you don't, kill tendermint +app installed, run it in another window. If you don't, kill Tendermint and run an in-process version with :: @@ -54,7 +54,7 @@ blocks are produced regularly, even if there are no transactions. See *No Empty Tendermint supports in-process versions of the dummy, counter, and nil apps that ship as examples in the `ABCI repository `__. It's easy to compile -your own app in-process with tendermint if it's written in Go. If your +your own app in-process with Tendermint if it's written in Go. If your app is not written in Go, simply run it in another process, and use the ``--proxy_app`` flag to specify the address of the socket it is listening on, for instance: @@ -118,8 +118,8 @@ Tendermint uses a ``config.toml`` for configuration. For details, see `the config specification <./specification/configuration.html>`__. Notable options include the socket address of the application -(``proxy_app``), the listenting address of the tendermint peer -(``p2p.laddr``), and the listening address of the rpc server +(``proxy_app``), the listening address of the Tendermint peer +(``p2p.laddr``), and the listening address of the RPC server (``rpc.laddr``). Some fields from the config file can be overwritten with flags. @@ -129,8 +129,8 @@ No Empty Blocks This much requested feature was implemented in version 0.10.3. While the default behaviour of ``tendermint`` is still to create blocks approximately once per second, it is possible to disable empty blocks or set a block creation interval. In the former case, blocks will be created when there are new transactions or when the AppHash changes. -To configure tendermint to not produce empty blocks unless there are txs or the app hash changes, -run tendermint with this additional flag: +To configure Tendermint to not produce empty blocks unless there are txs or the app hash changes, +run Tendermint with this additional flag: :: @@ -160,7 +160,7 @@ Broadcast API ------------- Earlier, we used the ``broadcast_tx_commit`` endpoint to send a -transaction. When a transaction is sent to a tendermint node, it will +transaction. When a transaction is sent to a Tendermint node, it will run via ``CheckTx`` against the application. If it passes ``CheckTx``, it will be included in the mempool, broadcast to other peers, and eventually included in a block. @@ -187,7 +187,7 @@ value for ``broadcast_tx_commit`` includes two fields, ``check_tx`` and through those ABCI messages. The benefit of using ``broadcast_tx_commit`` is that the request returns -after the transaction is committed (ie. included in a block), but that +after the transaction is committed (i.e. included in a block), but that can take on the order of a second. For a quick result, use ``broadcast_tx_sync``, but the transaction will not be committed until later, and by that point its effect on the state may change. @@ -248,10 +248,10 @@ Note also that the ``pub_key`` (the public key) in the The genesis file contains the list of public keys which may participate in the consensus, and their corresponding voting power. Greater than 2/3 -of the voting power must be active (ie. the corresponding private keys +of the voting power must be active (i.e. the corresponding private keys must be producing signatures) for the consensus to make progress. In our case, the genesis file contains the public key of our -``priv_validator.json``, so a tendermint node started with the default +``priv_validator.json``, so a Tendermint node started with the default root directory will be able to make new blocks, as we've already seen. If we want to add more nodes to the network, we have two choices: we can @@ -388,7 +388,7 @@ connections to peers with the same IP address. Upgrading ~~~~~~~~~ -The tendermint development cycle includes a lot of breaking changes. Upgrading from +The Tendermint development cycle includes a lot of breaking changes. Upgrading from an old version to a new version usually means throwing away the chain data. Try out the `tm-migrate `__ tool written by @hxqlh if you are keen to preserve the state of your chain when upgrading to newer versions.