Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a few typos in docs/ folder. #1585

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/build_system.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,7 +174,7 @@ using.
#### Adding tests to a suite
#### Running individual tests

## Modifying the buid system
## Modifying the build system
### What is SCons?
#### `SConstruct` and `SConscripts`
#### `Environments `and their `Clone`s
Expand Down
2 changes: 1 addition & 1 deletion docs/evergreen-testing/configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ section of the Evergreen wiki.
### `mongodb-mongo-master`
The main project for testing MongoDB's dev environments with a number build variants,
each one corresponding to a particular compile or testing environment to support development.
Each build variant runs a set of tasks; each task ususally runs one or more tests.
Each build variant runs a set of tasks; each task usually runs one or more tests.

### `mongodb-mongo-master-nightly
Tracks the same branch as `mongodb-mongo-master`, each build variant corresponds to a
Expand Down
4 changes: 2 additions & 2 deletions docs/futures_and_promises.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ a high level, but we've left out some important details about how they work.
### How Are Futures Fulfilled With Values?
In our example, we looked at how some code that needs to wait for results can use `Future`s to be
written in an asynchronous, performant way. But some thread running elsewhere needs to actually
"fulfill" those futures with a value or error. Threads can fulfull the core "promise" of a
"fulfill" those futures with a value or error. Threads can fulfill the core "promise" of a
`Future<T>` - that it will eventually contain a `T` or an error - by using the appropriately named
`Promise<T>` type. Every pending `Future<T>` is associated with exactly one corresponding
`Promise<T>` that can be used to ready the `Future<T>`, providing it with a value. (Note that a
Expand Down Expand Up @@ -266,7 +266,7 @@ continuation-chaining member functions in [future.h][future], starting above the
At some point, we may have no more continuations to add to a future chain, and will want to either
synchronously extract the value or error held in the last future of the chain, or add a callback to
asynchronously consume this value. The `.get()` and `.getAsync()` members of future-like types
provide these facilities for terminating a future chain by extracting or asynchronouslyunsly
provide these facilities for terminating a future chain by extracting or asynchronously
consuming the result of the chain. The `.getAsync()` function works much like `.onCompletion()`,
taking a `Status` or `StatusWith<T>` and running regardless of whether or not the previous link in
the chain resolved with error or success, and running asynchronously when the previous results are
Expand Down
4 changes: 2 additions & 2 deletions docs/golden_data_test_framework.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,8 +61,8 @@ be included in the diff.
* When resolving merge conflicts on the expected output files, one of the approaches below SHOULD be
used:
* "Accept theirs", rerun the tests and verify new outputs. This doesn't require knowledge of
production/test code changes in "theirs" branch, but requires re-review and re-acceptance of c
hanges done by local branch.
production/test code changes in "theirs" branch, but requires re-review and re-acceptance of
changes done by local branch.
* "Accept yours", rerun the tests and verify the new outputs. This approach requires knowledge of
production/test code changes in "theirs" branch. However, if such changes resulted in
straightforward and repetitive output changes, like due to printing code change or fixture change,
Expand Down
2 changes: 1 addition & 1 deletion docs/load_balancer_support.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ protocol standard.
e.g., when connecting to a local `mongos` instance, if the `loadBalancerPort` server parameter was set to 20100, the
connection string must be of the form `"mongodb://localhost:20100/?loadBalanced=true"`.

`mongos` will emit appropiate error messages on connection attempts if these requirements are not
`mongos` will emit appropriate error messages on connection attempts if these requirements are not
met.

There are some subtle behavioral differences that these configuration options enable, chief of
Expand Down
4 changes: 2 additions & 2 deletions docs/logging.md
Original file line number Diff line number Diff line change
Expand Up @@ -222,7 +222,7 @@ Fatal level log statements using `LOGV2_FATAL` perform `fassert` after logging,
using the provided ID as assert id. `LOGV2_FATAL_NOTRACE` perform
`fassertNoTrace` and `LOGV2_FATAL_CONTINUE` does not `fassert` allowing for
continued execution. `LOGV2_FATAL_CONTINUE` is meant to be used when a fatal
error has occured but a different way of halting execution is desired such as
error has occurred but a different way of halting execution is desired such as
`std::terminate` or `fassertFailedWithStatus`.

`LOGV2_FATAL_OPTIONS` performs `fassert` by default like `LOGV2_FATAL` but this
Expand Down Expand Up @@ -520,7 +520,7 @@ implemented as a friend function in a class with the following signature:

In some cases a loggable type might be composed as a hierarchy in the C++ type
system which would lead to a very verbose structured log output as every level
in the hierarcy needs a name when outputted as JSON. The attribute naming
in the hierarchy needs a name when outputted as JSON. The attribute naming
abstraction system can also be used to collapse such hierarchies. Instead of
making a type loggable it can instead return one or more attributes from its
members by using `multipleAttrs` in `logAttrs` functions.
Expand Down
2 changes: 1 addition & 1 deletion docs/thread_pools.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ A thread pool ([Wikipedia][thread_pools_wikipedia]) accepts and executes
lightweight work items called "tasks", using a carefully managed group
of dedicated long-running worker threads. The worker threads perform
the work items in parallel without forcing each work item to assume the
burden of starting and destroying a dedicated thead.
burden of starting and destroying a dedicated thread.

## Classes

Expand Down