From df41329df94261a4efc756faea08925e2c402315 Mon Sep 17 00:00:00 2001 From: Tom Ritchford Date: Thu, 26 Feb 2015 13:04:01 -0500 Subject: [PATCH] Replace "it's" with "its" in several places. --- src/ripple/app/paths/README.md | 7 +------ src/ripple/core/impl/JobQueue.cpp | 4 ++-- src/ripple/peerfinder/sim/WrappedSink.h | 2 +- src/ripple/protocol/tests/STObject.test.cpp | 2 +- test/freeze-test.coffee | 22 ++++++++++----------- 5 files changed, 16 insertions(+), 21 deletions(-) diff --git a/src/ripple/app/paths/README.md b/src/ripple/app/paths/README.md index e783a0dd01..9387441293 100644 --- a/src/ripple/app/paths/README.md +++ b/src/ripple/app/paths/README.md @@ -21,7 +21,7 @@ This is the **rippled** implementation; there are many other possible implementa * When searching, limit our search to the rippled cache. 2. Six degrees of separation. * If sending value through individual's account, expect no path to have more than six hops. - * According to [Facebook studies](https://www.facebook.com/notes/facebook-data-team/anatomy-of-facebook/10150388519243859) as of late 2011, it's users are separated by fewer than five steps. + * According to [Facebook studies](https://www.facebook.com/notes/facebook-data-team/anatomy-of-facebook/10150388519243859) as of late 2011, its users are separated by fewer than five steps. * By using XRP for bridging the most complicated path expected is usually: * source -> gateway -> XRP -> gateway -> destination 3. Pareto principle. @@ -135,8 +135,3 @@ If you can compute a path already yourself or know one, you don't need to do ste * very little time, can't afford to do a search. * that's why we do the path building before the payment is due. * The routine used to compute liquidity and ledger change is also called RippleCalc::rippleCalc. - - - - - diff --git a/src/ripple/core/impl/JobQueue.cpp b/src/ripple/core/impl/JobQueue.cpp index 4070c0920a..0343bd02d3 100644 --- a/src/ripple/core/impl/JobQueue.cpp +++ b/src/ripple/core/impl/JobQueue.cpp @@ -424,8 +424,8 @@ private: // Post-conditions: // job is a valid Job object. // job is removed from mJobQueue. - // Waiting job count of it's type is decremented - // Running job count of it's type is incremented + // Waiting job count of its type is decremented + // Running job count of its type is incremented // // Invariants: // The calling thread owns the JobLock diff --git a/src/ripple/peerfinder/sim/WrappedSink.h b/src/ripple/peerfinder/sim/WrappedSink.h index 96dd0a362a..e49896380c 100644 --- a/src/ripple/peerfinder/sim/WrappedSink.h +++ b/src/ripple/peerfinder/sim/WrappedSink.h @@ -23,7 +23,7 @@ namespace ripple { namespace PeerFinder { -/** Wraps a Journal::Sink to prefix it's output. */ +/** Wraps a Journal::Sink to prefix its output. */ class WrappedSink : public beast::Journal::Sink { public: diff --git a/src/ripple/protocol/tests/STObject.test.cpp b/src/ripple/protocol/tests/STObject.test.cpp index 7e03e6982f..52d768ca02 100644 --- a/src/ripple/protocol/tests/STObject.test.cpp +++ b/src/ripple/protocol/tests/STObject.test.cpp @@ -60,7 +60,7 @@ public: arrays/objects. STObject is an associative container, mapping fields to value, but - an STObject may also have a Field as it's name, stored outside the + an STObject may also have a Field as its name, stored outside the associative structure. The name is important, so to maintain fidelity, it will take TWO json objects to represent them. diff --git a/test/freeze-test.coffee b/test/freeze-test.coffee index fdd69f24a0..333b466165 100644 --- a/test/freeze-test.coffee +++ b/test/freeze-test.coffee @@ -46,7 +46,7 @@ GlobalFreeze ------------ There is also, a global freeze, toggled by a bit in the AccountRoot Flags, which -freezes ALL trust lines for an account. +freezes ALL trust lines for an account. Offers can not be created to buy or sell assets issued by an account with GlobalFreeze set. @@ -56,7 +56,7 @@ Use cases (via (David (JoelKatz) Schwartz)): There are two basic cases. One is a case where some kind of bug or flaw causes a large amount of an asset to somehow be created and the gateway hasn't yet decided how it's going to handle it. - + The other is a reissue where one asset is replaced by another. In a community credit case, say someone tricks you into issuing a huge amount of an asset, but you set the no freeze flag. You can still set global freeze to protect @@ -70,7 +70,7 @@ NoFreeze NoFreeze, is a set only flag bit in the account root. When this bit is set: - An account may not freeze it's side of a trustline + An account may not freeze its side of a trustline The NoFreeze bit can not be cleared @@ -84,7 +84,7 @@ LedgerEntry flags ----------------- RippleState - + LowFreeze 0x00400000 HighFreeze 0x00800000 @@ -128,7 +128,7 @@ request.book_offers ------------------- All offers selling assets from a frozen line/acount (offers created before a -freeze) will be filtered, except where in a global freeze situation where: +freeze) will be filtered, except where in a global freeze situation where: TakerGets.issuer == Account ($frozen_account) @@ -298,11 +298,11 @@ book_offers_factory = (remote) -> suite_setup = (state) -> ''' - + @state - + The ledger state to setup, after starting the server - + ''' opts = setup_func: suiteSetup @@ -557,7 +557,7 @@ execute_if_enabled (suite, enforced) -> done() - suite 'it\'s assets can be', -> + suite 'its assets can be', -> test 'bought on the market', (next) -> h.create_offer 'A3', '1/BTC/G1', '1.0', (m) -> @@ -603,7 +603,7 @@ execute_if_enabled (suite, enforced) -> done() - suite 'it\'s assets can\'t be', -> + suite 'its assets can\'t be', -> test_if enforced, 'bought on the market', (next) -> h.create_offer 'A3', '1/BTC/G1', '1.0', (m) -> assert.equal m.engine_result, 'tecFROZEN' @@ -614,7 +614,7 @@ execute_if_enabled (suite, enforced) -> assert.equal m.engine_result, 'tecFROZEN' next() - suite 'it\'s offers are filtered', -> + suite 'its offers are filtered', -> test_if enforced, 'account_offers always '+ 'shows their own offers', (done) -> {remote} = h = get_helpers()