diff --git a/docs/chain.introduction.rst b/docs/chain.introduction.rst index 3e41a254..c320bee5 100644 --- a/docs/chain.introduction.rst +++ b/docs/chain.introduction.rst @@ -32,7 +32,7 @@ Populus can run two types of transient chains. * ``temp`` Runs a blockchain backed by the go-ethereum ``geth`` client. This chain - will use a temporary directory for it's chain data which will be cleaned up + will use a temporary directory for its chain data which will be cleaned up and removed when the chain shuts down. @@ -41,7 +41,7 @@ Local Chains Local chains can be setup within your ``populus.json`` file. Each local chain stores its chain data in the ``populus.Project.blockchains_dir`` -and persists it's data between runs. +and persists its data between runs. Local chains are backed by the go-ethereum ``geth`` client. @@ -147,4 +147,4 @@ Here is an example of running the ``tester`` blockchain. .. note:: The ``testrpc`` chain can be run in the same manner. -.. _Web3.py: http://web3py.readthedocs.io/en/latest/ \ No newline at end of file +.. _Web3.py: http://web3py.readthedocs.io/en/latest/ diff --git a/docs/config.rst b/docs/config.rst index 85c811b4..1dd88c99 100644 --- a/docs/config.rst +++ b/docs/config.rst @@ -199,7 +199,7 @@ primary sections, ``web3``, ``chain``, and ``contracts`` configuration settings. } The above chain configuration sets up a new local private chain within your -project. The chain above would set it's data directory to +project. The chain above would set its data directory to ``/chains/my-chain/``. To simplify configuration of chains you can use the ``ChainConfig`` object. @@ -263,7 +263,7 @@ Available options are: * ``populus.chain.LocalGethChain`` - A geth backed chain which will setup it's own data directory in the + A geth backed chain which will setup its own data directory in the ``./chains`` directory in the root of your project. * ``populus.chain.TemporaryGethChain`` diff --git a/docs/dev_cycle.intro.rst b/docs/dev_cycle.intro.rst index ae3f1874..62ef9d36 100644 --- a/docs/dev_cycle.intro.rst +++ b/docs/dev_cycle.intro.rst @@ -82,7 +82,7 @@ all the transactions in this blocks are accepted and carried out by all the node **Node**: A running instance of the blockchain. The nodes sync to one another. When there are conflicts, e.g. if two nodes suggest two different block for the next block, the nodes gets a decision by consensus. -**Consensus**: Miners get rewards when they find a valid block, and a valid block is valid only if it's built on a valid parent block, +**Consensus**: Miners get rewards when they find a valid block, and a block is valid only if it's built on a valid parent block, and *accepted by the majority of nodes on the blockchain*. So miners are incentivised to reject false blocks and false transactions. They know that if they work on a false transaction (say a cheat), then there is high probability that other nodes will reject it, and their work effort will be lost without rewards. @@ -121,6 +121,6 @@ the EVM needs the ABI in order to know how to call the bytecode. **testnet**: An Ethereum blockchain for testing. It behaves exactly as mainnet, but you don't use real Ether to send money and pay for the gas -**Local chain**: A blockchain that runs localy, has it's own blocks, and does not sync to any other blockchain. Useful for development +**Local chain**: A blockchain that runs localy, has its own blocks, and does not sync to any other blockchain. Useful for development and testing diff --git a/docs/dev_cycle.part-01.rst b/docs/dev_cycle.part-01.rst index ae6545a9..d3d1f164 100644 --- a/docs/dev_cycle.part-01.rst +++ b/docs/dev_cycle.part-01.rst @@ -214,7 +214,7 @@ with ``address.call``, and (b) when just send just Ether, in a transaction that .. note:: If a contract has a fallback function, - any transaction or sending of ether to an address with code will result in it's code being invoked. + any transaction or sending of ether to an address with code will result in its code being invoked. **Payable**: ``function donate(uint usd_rate) public payable nonZeroValue {...}`` and ``function () payable {...}`` use the *payable* diff --git a/docs/dev_cycle.part-02.rst b/docs/dev_cycle.part-02.rst index 6f645ac8..9c502dee 100644 --- a/docs/dev_cycle.part-02.rst +++ b/docs/dev_cycle.part-02.rst @@ -65,7 +65,7 @@ If you copy-pasted the ``Donator`` contract example, you will get: > stdout: -What's that? actually it's not that bad. You can ignore the Python traceback, which is just the Populus call stack until the actual +What's that? Actually it's not that bad. You can ignore the Python traceback, which is just the Populus call stack until the actual call to the compiler. To undersatnd what went wrong, just look at the compiler's output. The error message is quite clear: @@ -92,7 +92,7 @@ The fixed line should be: .. note:: Try the `online IDE `_ , which has great interactive compiler and web-form like interface - to call the contract and it's funcitons. + to call the contract and its funcitons. Try to compile again: @@ -123,8 +123,8 @@ Tester Deployment You now have two compiled contracts, ready for deployment. The first deployment step is to verify that it works on the ``tester`` chain. This is an ephemeral blockchain. -It runs localy, and resets each time is starts. The state of the chain when it runs is kept only in memory, -and cleared when done. It's a great tool for a testing. +It runs locally, and resets each time it starts. The state of the chain when it runs is kept only in memory, +and cleared when done. It's a great tool for testing. Deploy to the ``tester`` chain: @@ -158,7 +158,7 @@ Deploy to the ``tester`` chain: When you deploy a contract Populus re-compiles *all* the contracts, but deploys only those you asked for. Well, deployment works. Since the ``tester`` chain is *not* persistent, everything was deleted, but the deployment should work on persistent -chains: it's the same Ethereum protocol. Check for yourself and run the deploy again, it will re-dploy exactly the same,since +chains: it's the same Ethereum protocol. Check for yourself and run the deploy again. It will re-deploy exactly the same, since each starts from a reset state. @@ -171,4 +171,4 @@ So far you have: * Verified that deployment works, using the tester chain -In the next step we will add some tests. \ No newline at end of file +In the next step we will add some tests. diff --git a/docs/dev_cycle.part-03.rst b/docs/dev_cycle.part-03.rst index 1c4db8a7..82dce4f2 100644 --- a/docs/dev_cycle.part-03.rst +++ b/docs/dev_cycle.part-03.rst @@ -6,10 +6,9 @@ Part 3: First Test Tests and Chains ---------------- -For testing, we will use the ``tester`` chain again. It's very convenient blockchain for tests, -because it resets on each run and the state is saved only in memory and cleared after each run. -In a way, this is an idea similar to running tests against a DB, -where you create an ad-hoc temporary DB for the tests. +For testing, we will use the ``tester`` chain again. It's a very convenient blockchain for tests, +because the state is saved only in memory and cleared after each run. In a way, this is an idea +similar to running tests against a DB, where you create an ad-hoc temporary DB for the tests. You will run Populus tests with ``py.test``, which was installed when you installed Populus. @@ -22,7 +21,7 @@ Add a test file: .. note:: py.test collects all the tests that follow - it's `naming conventions `_. + its `naming conventions `_. We don't need the Greeter example for this project, so delete it: @@ -39,7 +38,7 @@ What is a Contract? ------------------- The simplest definition of a contract is a compiled program that runs on the Ethereum blockchain. -It's a bytecode of instructions, saved on the blockchain, that a blockchain node can run. +It's a set of bytecode instructions, saved on the blockchain, that a blockchain node can run. The node gives this program a sandbox, a closed environment, to execute. In a way, if the blockchain is the OS, then a contract is an executable that runs by the OS. @@ -112,8 +111,8 @@ Another bonus is the ``chain`` object, provided as an argument at ``def test_def that corresponds to a running blockchain, the ``tester`` blockchain. Reminder: The ``tester`` chain is ephemeral, saved only in memory, and will reset on every test run. -The ``chain`` argument is a py.test *fixture*: in py.test world it's a special argument that the test function can accept. -You don't have to declare or assign it, it's just ready and available for your test. +The ``chain`` argument is a py.test *fixture*: in py.test world, it's a special argument that the test function can accept. +You don't have to declare or assign it. It's just ready and available for your test. The Populus testing fixtures comes from the Populus py.test plug-in, which prepares for you several useful fixtures: ``project``, ``chain``, ``provider``, ``registrar`` and ``web3``. All these fixtures are part of the Populus API. See :ref:`populus_testing` diff --git a/docs/dev_cycle.part-04.rst b/docs/dev_cycle.part-04.rst index 1411025e..6e46abcf 100644 --- a/docs/dev_cycle.part-04.rst +++ b/docs/dev_cycle.part-04.rst @@ -55,7 +55,7 @@ object with Python methods. This object is stored in the ``donator`` variable. Reminder: we have two options to interact with a contract on the blockchain, *transactions* and *calls*. With Populus, you initiate a transaction with ``transact``, and a call with ``call``: -* *Transactions*: Send a transaction, run the contract code, transfer funds, and *change* the state of the contract and it's balance. This change will be permanent, and synced to the entire blockchain. +* *Transactions*: Send a transaction, run the contract code, transfer funds, and *change* the state of the contract and its balance. This change will be permanent, and synced to the entire blockchain. * *Call*: Behaves exactly as a transaction, but once done, everything is revert and no state is changed. A call is kinda "dry-run", and an efficient way to query the current state without expensive gas costs. @@ -88,7 +88,7 @@ Populus gives you a *Python* interface to a bytecode contract. Nice, no? **[6] Asserts**: We expect the ``donationsTotal`` to be ``500 + 650 = 1150``, the ``donationsCount`` is 2, and the ``defaultUsdRate`` to match the last update, 380. -The test gets the varaibles with ``call``, and should update instanrly because it's a local ``tester`` chain. On a distributed +The test gets the variables with ``call``, and should update instantly because it's a local ``tester`` chain. On a distributed blockchain it will take sometime until the transactions are mined and actually change the state. Run the test: diff --git a/docs/dev_cycle.part-06.rst b/docs/dev_cycle.part-06.rst index a947d25b..4971a3b4 100644 --- a/docs/dev_cycle.part-06.rst +++ b/docs/dev_cycle.part-06.rst @@ -21,7 +21,7 @@ Run this chain: $ chains/horton/./run_chain.sh -And you will see that geth starts to do it's thing: +And you will see that geth starts to do its thing: .. code-block:: shell @@ -152,7 +152,7 @@ The next line should be familiar to you by now: donator, deploy_tx_hash = chain.provider.get_or_deploy_contract('Donator') -Populus does it's magic: +Populus does its magic: **New**: If the contract was *never* deployed to a blockchain, compile the source, deploy to the chain, create a Web3 contract Python object instance, which points to the blockchain bytecode, and returns this Python object. @@ -255,7 +255,7 @@ This is how you project directory should look: The *registrar* is loaded with ``get_or_deploy_contract``, and if Populus finds an entry for a contract, it knows -that the contract already deployed, and it's address on this chain. +that the contract already deployed, and its address on this chain. Take a look at the registrar: @@ -276,7 +276,7 @@ The registrar saves a deployment reference with unique "signature" of the blockc The signature is the first block hash, which is obviously unique. It appears after the ``blockchain://`` part. Then the hash of the latest block at the time of deployment after, ``block``. The registrar uses a special URI structure designed for blockchains, which is built from a resource name (blockchain, block, etc) -and it's hash. See `BIP122 URI `_ +and its hash. See `BIP122 URI `_ To have *another* contract deployed to the *same* chain, we will greet our good ol' friend, the Greeter. Yes, you probably missed it too. @@ -529,4 +529,4 @@ Interim Summary * You deployed a persistent contract instance to a local chain * You interacted with the ``Project`` object, which is the entry point to the Populus API * You deployed the same Solidity source file on two seprated local chains, ``horton`` and ``morty`` -* Deployments are saved in the the ``registrar`` \ No newline at end of file +* Deployments are saved in the the ``registrar`` diff --git a/docs/dev_cycle.part-07.rst b/docs/dev_cycle.part-07.rst index 49ba7cef..54b5271a 100644 --- a/docs/dev_cycle.part-07.rst +++ b/docs/dev_cycle.part-07.rst @@ -15,7 +15,7 @@ and the *ABI* (application binary interface). Reminder: the contract instance is compiled, a bytecode, so the EVM (ethereum virtual machine) needs the ABI in order to call this bytecode. The ABI (application binary interface) -is essentially a JSON file with detailed description of the functions and their arguments, which tells how to call them. It's part of the +is essentially a JSON file with a detailed description of the functions and their arguments, which says how to call them. It's part of the compiler output. Populus does not ask you for the address and the ABI of the projects' contracts: it already @@ -292,7 +292,7 @@ and mine it: INFO [10-20|01:49:05] Commit new mining work number=3920 txs=1 uncles=0 elapsed=735.282µs INFO [10-20|01:49:21] Successfully sealed new block -Check the persistancy of the instance again. Stop the ``horton`` chain, press Ctrl+C in it's terminal window, +Check the persistancy of the instance again. Stop the ``horton`` chain, press Ctrl+C in its terminal window, and then re-run it with ``chains/horton/./run_chain.sh``. Run the script again: @@ -306,7 +306,7 @@ Run the script again: Total of 7.00 Ether accepted in 3 donations, an avergage of 2,333,333,333,333,333,504.00 Wei per donation. Thank you for the donation! Tx hash 0x8a595949271f17a2a57a8b2f37f409fb1ee809c209bcbcf513706afdee922323 -Oh, it's so easy to donate when a genesis block allocates you billion something. +Oh, it's so easy to donate when a genesis block allocates you billions of something. The contract instance *is* persistent, and the state is saved. With ``horton``, a local chain, it's saved to your hard-drive. On ``mainent`` and ``testnet``, to the entire blockchain nodes network. diff --git a/docs/dev_cycle.part-08.rst b/docs/dev_cycle.part-08.rst index 31dfac11..af383ebe 100644 --- a/docs/dev_cycle.part-08.rst +++ b/docs/dev_cycle.part-08.rst @@ -72,7 +72,7 @@ We can interact with a contract instance via the Python shell as well. We will d for the sake of demostration. During the regular development process, Populus does all that for you. -To get a handle to the ``Donator`` instance on ``horton`` we need (a) it's **address**, where the bytecode sits, +To get a handle to the ``Donator`` instance on ``horton`` we need (a) its **address**, where the bytecode sits, and (b) the **ABI** ,application binary interface, the detailed description of the functions and arguments of the contract interface. With the ABI the EVM knows how to call the compiled bytecode. @@ -107,7 +107,7 @@ The :ref:`populus_registrar` is where Populus holds the deployment details: } It's hard to tell which blockchain is ``horton``. Populus encodes a blockchain signature -by the *hash* of it's block 0. We only see that ``Donator`` is deployed on two blockchains. +by the *hash* of its block 0. We only see that ``Donator`` is deployed on two blockchains. But since ``Greeter`` was deployed only on ``horton``, the blockchain with two deployments is ``horton``, and the other one is ``morty``. @@ -401,7 +401,7 @@ Quit the ``horton`` chain and start a new Python shell. Mainnet with Infura.io '''''''''''''''''''''' -As an endpoint we will use ``infura.io``. It's a publicly avaialble blockchain node, by Consensys, which is great +As an endpoint we will use ``infura.io``. It's a publicly available blockchain node, by Consensys, which is great for read-only queries. Infura is a remote node, so you will use the ``HTTPProvider``. @@ -463,7 +463,7 @@ This transaction details: If you will use block number 4402735, you should get **exactly** the same output as shown above. This is the ``mainent``, which is synced accross all the nodes, and every node will return the same info. - The local chains ``horton`` or ``morty`` run a private instance, so every machine produces it's own blocks and hashes. + The local chains ``horton`` or ``morty`` run a private instance, so every machine produces its own blocks and hashes. Not so on the global, real blockchain, where all the nodes are synced (which is the crux of the whole blockchain idea). @@ -526,7 +526,7 @@ Interim Summary * Query the blockchain info on local geth nodes. Although Populus does a lot of work behind the scenes, it's recommended to have a good grasp of Web3. -See the the `Web3.py documentation `_ and +See the `Web3.py documentation `_ and the `full list of `web3.js JavaScript API `_. Most of the javascript API have a Python equivalent. diff --git a/docs/dev_cycle.part-09.rst b/docs/dev_cycle.part-09.rst index ff003335..b585469d 100644 --- a/docs/dev_cycle.part-09.rst +++ b/docs/dev_cycle.part-09.rst @@ -117,7 +117,7 @@ the ``Donator`` will just continue to hold these 113 Ether. In other words, they The blockchain "state" is not a physical property of nature. The state is a consensus among the majority of the nodes on the blockchain. If, theoreticaly, all the nodes decide to wipe out an account - balance, they can do it. A single node can't, but the entire network can. It's unlikely to happen, but it's + balance, they can do it. A single node can't, but the entire network can. It's unlikely to happen, but it's a theoretical possiblility you should be aware of. It happend once, after the DAO hack, where all the nodes agreed on a *hard fork*, a forced update of the blockchain state, which reverted the hack. See `a good discussion of the issue on Quartz `_. @@ -157,7 +157,7 @@ Withdraw is handled in one simple function: } Anyone that calls this function will get the entire Ether in the contract to his or her own -account. The contract sends it's remaining balance, ``this.balance``, to the account address +account. The contract sends its remaining balance, ``this.balance``, to the account address that sent the transaction, ``msg.sender``. The send is enclosed in a ``require`` clause, so if something failed everything is reverted. @@ -173,7 +173,7 @@ Re-entry attack '''''''''''''''' When ``Donator2`` will run ``send(this.balance)``, the beneficiary -contract gets an opportunity to run it's ``fallback`` and get the execution control. +contract gets an opportunity to run its ``fallback`` and get the execution control. In the fallback, it can call ``Donator2`` again before the ``send`` was line was completed, but the money already *sent*. This is a *re-entry* attack. To avoid it, any state changes should occur *before* the send. @@ -449,7 +449,7 @@ Unlock the account: Again, extremely naive and unsafe way to unlock and use passwords. Use only for development and testing, with dummy Ether -The new account should be ready, it's unlocked, and has the funds for the gas. +The new account should be ready. It's unlocked and has the funds for the gas. Send the withdraw transaction yet *again*: diff --git a/docs/dev_cycle.part-10.rst b/docs/dev_cycle.part-10.rst index 3e0fae97..06df495e 100644 --- a/docs/dev_cycle.part-10.rst +++ b/docs/dev_cycle.part-10.rst @@ -11,7 +11,7 @@ from other contracts, which is especially useful when you a more generic functio a basic core contract, a functionality you want to inherit and re-use in another, more specific use case. -A Contract that is Controlled by it's Owner +A Contract that is Controlled by its Owner ------------------------------------------- @@ -380,7 +380,7 @@ Run the test: Ok, all the inherited members passed: The ``Ownable`` constructor that sets ``owner`` ran when you deployed -it's subclass, ``Donator3``. The parent modifier ``onlyOwner`` works as a modifier to a subclass function, +its subclass, ``Donator3``. The parent modifier ``onlyOwner`` works as a modifier to a subclass function, and the ``transferOwnership`` parent's funcion can be called by clients via the subclass interface. .. note:: diff --git a/docs/dev_cycle.part-11.rst b/docs/dev_cycle.part-11.rst index 5619785b..bfa36b85 100644 --- a/docs/dev_cycle.part-11.rst +++ b/docs/dev_cycle.part-11.rst @@ -7,7 +7,7 @@ Part 11: Events One of the things to get used to with Ethereum platform is the feedback loop. When you work with a common Python project on your local machine, functions return in no time. When you call a remote REST API, you response takes 1-2 seconds. When you send a transaction, -it's status is "pending", and you will have to wait until a miner picks it, include it in +its status is "pending", and you will have to wait until a miner picks it, include it in a block, and the block is accepted by the blockchain. This can take a few minutes. To track when a transaction is accepted, you use an ``event``. An event is a way to to write an indexable diff --git a/docs/gotchas.rst b/docs/gotchas.rst index dba4d9bc..bdb5c2c6 100644 --- a/docs/gotchas.rst +++ b/docs/gotchas.rst @@ -15,7 +15,7 @@ There is a price for each action the EVM takes on behalf of your contract. Try t E.g., suppose you want to calculate the average donation in a contract that collects money and counts donations. The contract should only provide the total donations, and the number of donations, then calculate the average in the client code. -[2] Everything the contract **stores** in it's persistent storage costs money, the gas. +[2] Everything the contract **stores** in its persistent storage costs money, the gas. Try to minimise storage only to what absulutly positively is required for the contract to run. Data like derived calculations, caching, aggregates etc, should be handled on the client. @@ -56,10 +56,10 @@ The only option to verify is to get the Solidity source that the author of the c recompile the Source *with the same compiler version the contract on the blockchain was compiled*, and verify that this compilation matches the bytecode on the blockchain. -[13] Never **send Eth** to a contract unless you absolutely positively trust it's author, or you verified the bytecode against a source compilation +[13] Never **send Eth** to a contract unless you absolutely positively trust its author, or you verified the bytecode against a source compilation yourself. -[14] Never **call** a contract, never call a function of a contract, unless you absolutely positively trust it's author, or you verified the bytecode against a source compilation +[14] Never **call** a contract, never call a function of a contract, unless you absolutely positively trust its author, or you verified the bytecode against a source compilation yourself. [15] If you loose the ABI, you will not be able to call the contract other than the fallback function. The situation is very similar @@ -89,7 +89,7 @@ and you will not have to transfer execution control to another account. [20] Contracts are **stateful**. Once you send money to a contract, it's there. You can't reinstall, or redeploy (or restart, or patch, or fix a bug, or git pull... you get the idea). -If you didn't provide a mechanism to withdraw the funds in the first place, it's lost. If you want to update the source +If you didn't provide a mechanism to withdraw the funds in the first place, they're lost. If you want to update the source of a deployed contract, you can't. If you want to deploy a new version and didn't provide a mechanism to send the money to the new version, you are stuck with the old one. @@ -142,7 +142,7 @@ Eth you need** for these actions. [34] Anybody who has the **private key** can drain the account funds, no questions asked. -[35] Anybody who has the **wallet encrypted file and it's password** can drain the account funds, no questions asked. +[35] Anybody who has the **wallet encrypted file and its password** can drain the account funds, no questions asked. [36] If you use a password file to unlock the account, make sure the file is well protected with the **right permissions**. @@ -205,20 +205,21 @@ don't need ``this`` (*this* is kinda bonus, no?) the compiler does not copy to the derived contracts. Otherwise, from within a contract, ``private`` is the same as ``internal``. [56] ``external`` is available only for functions. ``public``, ``internal`` and ``private`` are available for both functions -and state variables. The **contract's interface** is built from it's ``external`` and ``public`` memebers. +and state variables. The **contract's interface** is built from its ``external`` and ``public`` +members. [57] The compiler will **automatically** generate an accessor ("get" function) for the ``public`` state variables. [58] ``now`` is the time stamp of the **current block** -[59] **Ethereum units** ``wei``, ``finney``, ``szabo`` or ``ether`` are reserved words, and can be used in experessions and literals. +[59] **Ethereum units** ``wei``, ``finney``, ``szabo`` or ``ether`` are reserved words, and can be used in expressions and literals. -[60] **Time units** ``seconds``, ``minutes``, ``hours``, ``days``, ``weeks`` and ``years``, are reserved words, and can be used in experessions and literals. +[60] **Time units** ``seconds``, ``minutes``, ``hours``, ``days``, ``weeks`` and ``years``, are reserved words, and can be used in expressions and literals. [61] There is **no type conversion from non-boolean** to boolean types. ``if (1) { ... }`` is not valid Solidity. [62] The ``msg``, ``block`` and ``tx`` variables always exist in the **global namespace**, and you can use -them and their members without any prior decleration or assignment +them and their members without any prior declaration or assignment Nice! You got here. diff --git a/docs/quickstart.rst b/docs/quickstart.rst index da92c635..90df5774 100644 --- a/docs/quickstart.rst +++ b/docs/quickstart.rst @@ -235,7 +235,7 @@ For compiling outside the project directory use: The build/contracts.json file contains a lot of information that the Solidity compiler produced. This is required to deploy and work with the contract. Some important info is the -application binary interface (ABI) of the contract, which will allow to call it's functions after it's compiled, +application binary interface (ABI) of the contract, which will allow to call its functions after it's compiled, and the bytecode required to deploy the contract, and the bytecode that will run once the contract sits on the blockchain. Testing your contract diff --git a/docs/release.rst b/docs/release.rst index 19fd878b..570ac0b6 100644 --- a/docs/release.rst +++ b/docs/release.rst @@ -533,7 +533,7 @@ This is the first release of populus that should be considered stable. - Significant refactor to the ``Contract`` and related ``Function`` and ``Event`` objects used to interact with contracts. - Major improvements to robustness of ``geth_node`` fixture. -- ``deployed_contracts`` testing fixture no longer provides it's own rpc server. +- ``deployed_contracts`` testing fixture no longer provides its own rpc server. Now you must either provide you own, or use the ``geth_node`` or ``rpc_server`` alongside it in tests. - ``geth_node`` fixture now writes to a logfile located in diff --git a/docs/tutorial.part-1.rst b/docs/tutorial.part-1.rst index ef27794d..4be73886 100644 --- a/docs/tutorial.part-1.rst +++ b/docs/tutorial.part-1.rst @@ -111,7 +111,7 @@ installed when you installed populus. You should see something akin to the output above with three passing tests. Behind the scenes, populus uses a pytest plugin that creates a populus project object, and then provide this object, -(and it's derived objects), to the test functions via a pytest fixture. +(and its derived objects), to the test functions via a pytest fixture. Thus, tests run for a specific project. diff --git a/docs/tutorial.part-2.rst b/docs/tutorial.part-2.rst index 68543591..c97a4a6a 100644 --- a/docs/tutorial.part-2.rst +++ b/docs/tutorial.part-2.rst @@ -15,7 +15,7 @@ to the blockchain. One of the nice things about Ethereum is the *protocol*, a protocol which specifies how to run a blockchain. Theoretically, you can use this exact protocol to run your own blockchain, which is private and totally -seprated from the mainnet Ethereum blockchain and it's nodes. +seprated from the mainnet Ethereum blockchain and its nodes. Although the private Ether you will mint in this private blockchain are not worth a lot in the outside world (but who knows?), such private, local blockchain is a great tool for development. It simulates diff --git a/populus/cli/chain_cmd.py b/populus/cli/chain_cmd.py index 74fad34e..89175070 100644 --- a/populus/cli/chain_cmd.py +++ b/populus/cli/chain_cmd.py @@ -44,7 +44,7 @@ def chain_new(ctx, chain_name): @click.pass_context def chain_reset(ctx, chain_name, confirm): """ - Reset a chain removing all chain data and resetting it to it's genesis + Reset a chain removing all chain data and resetting it to its genesis state.. """ project = ctx.obj['PROJECT'] diff --git a/populus/utils/linking.py b/populus/utils/linking.py index a9d5df61..46c54716 100644 --- a/populus/utils/linking.py +++ b/populus/utils/linking.py @@ -82,7 +82,7 @@ def expand_placeholder(placeholder, full_names): double underscore prefix and suffix. This embedded string is referred to as the `placeholder` - This expands `placeholder` to it's full reference name or raise a value + This expands `placeholder` to its full reference name or raise a value error if it is unable to find an appropriate expansion. """ if placeholder in full_names: @@ -152,7 +152,7 @@ def insert_link_value(bytecode, value, offset): def link_bytecode(bytecode, link_reference_values): """ - Given the bytecode for a contract, and it's dependencies in the form of + Given the bytecode for a contract, and its dependencies in the form of {contract_name: address} this function returns the bytecode with all of the link references replaced with the dependency addresses.