From 68b518c9d21865a2d76e3704d5bf3e0ca6fade29 Mon Sep 17 00:00:00 2001 From: John Eismeier Date: Fri, 27 Apr 2018 14:45:14 -0400 Subject: [PATCH] Propose fix some typos and rm trailing whitespace --- _overviews/FAQ/yield.md | 2 +- _overviews/core/futures.md | 10 +++++----- _overviews/plugins/index.md | 4 ++-- _overviews/quasiquotes/unlifting.md | 2 +- _sips/sips/2016-01-11-static-members.md | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/_overviews/FAQ/yield.md b/_overviews/FAQ/yield.md index 44a839882f..795fc6d375 100644 --- a/_overviews/FAQ/yield.md +++ b/_overviews/FAQ/yield.md @@ -116,7 +116,7 @@ returning a list of odds -- since `found` is `false`. Only then `foreach` is executed, but, by this time, changing `found` is meaningless, as `filter` has already executed. -In the case of `Stream`, the condition is not immediatelly applied. Instead, as +In the case of `Stream`, the condition is not immediately applied. Instead, as each element is requested by `foreach`, `filter` tests the condition, which enables `foreach` to influence it through `found`. Just to make it clear, here is the equivalent for-comprehension code: diff --git a/_overviews/core/futures.md b/_overviews/core/futures.md index 6fcfc7b698..b8ac14a754 100644 --- a/_overviews/core/futures.md +++ b/_overviews/core/futures.md @@ -56,7 +56,7 @@ Or with the more idiomatic: Both code snippets delegate the execution of `fatMatrix.inverse()` to an `ExecutionContext` and embody the result of the computation in `inverseFuture`. -## Execution Context +## Execution Context Future and Promises revolve around [`ExecutionContext`s](http://www.scala-lang.org/api/current/index.html#scala.concurrent.ExecutionContext), responsible for executing computations. @@ -144,7 +144,7 @@ To give you an idea, the following code will use 32000 threads: for( i <- 1 to 32000 ) { Future { blocking { - Thread.sleep(999999) + Thread.sleep(999999) } } } @@ -155,7 +155,7 @@ If you need to wrap long lasting blocking operations we recommend using a dedica ### Adapting a Java Executor -Using the `ExecutionContext.fromExecutor` method you can wrap a Java `Executor` into an `ExecutionContext`. +Using the `ExecutionContext.fromExecutor` method you can wrap a Java `Executor` into an `ExecutionContext`. For instance: ExecutionContext.fromExecutor(new ThreadPoolExecutor( /* your configuration */ )) @@ -333,7 +333,7 @@ a `List[String]`-- a list of recent textual posts: f onComplete { case Success(posts) => for (post <- posts) println(post) - case Failure(t) => println("An error has occured: " + t.getMessage) + case Failure(t) => println("An error has occurred: " + t.getMessage) } The `onComplete` method is general in the sense that it allows the @@ -356,7 +356,7 @@ To handle failed results, the `onFailure` callback is used: } f onFailure { - case t => println("An error has occured: " + t.getMessage) + case t => println("An error has occurred: " + t.getMessage) } f onSuccess { diff --git a/_overviews/plugins/index.md b/_overviews/plugins/index.md index d6cdde9ee3..16a44644ba 100644 --- a/_overviews/plugins/index.md +++ b/_overviews/plugins/index.md @@ -5,7 +5,7 @@ title: Scala Compiler Plugins discourse: true --- -**Lex Spoon (2008)** +**Lex Spoon (2008)** **Seth Tisue (2018)** ## Introduction @@ -158,7 +158,7 @@ aspects of note. The `runsAfter` method gives the plugin author control over when the phase is executed. As seen above, it is expected to return a list of phase names. This makes it possible to specify multiple phase names to -preceed the plugin. It is also possible, but optional, to specify a +precede the plugin. It is also possible, but optional, to specify a `runsBefore` constraint of phase names that this phase should precede. And it is also possible, but again optional, to specify a `runsRightAfter` constraint to run immediately after a specific diff --git a/_overviews/quasiquotes/unlifting.md b/_overviews/quasiquotes/unlifting.md index 364dd77d97..4f14f267d3 100644 --- a/_overviews/quasiquotes/unlifting.md +++ b/_overviews/quasiquotes/unlifting.md @@ -19,7 +19,7 @@ Unlifting is the reverse operation to [lifting](lifting.html): it takes a tree a def unapply(tree: Tree): Option[T] } -Due to the fact that the tree may not be a represention of our data type, the return type of unapply is `Option[T]` rather than just `T`. This signature makes it easy to use `Unliftable` instances as extractors. +Due to the fact that the tree may not be a representation of our data type, the return type of unapply is `Option[T]` rather than just `T`. This signature makes it easy to use `Unliftable` instances as extractors. Whenever an implicit instance of `Unliftable` is available for a given data type you can use it for pattern matching with the help of an ascription syntax: diff --git a/_sips/sips/2016-01-11-static-members.md b/_sips/sips/2016-01-11-static-members.md index 15f04ffe01..e9c3395d11 100644 --- a/_sips/sips/2016-01-11-static-members.md +++ b/_sips/sips/2016-01-11-static-members.md @@ -148,7 +148,7 @@ It also does not address the question of `@static` members in inner objects and ## Initialization order discussion ## In general, emission of static fields could affect the initialization order and change semantics. -This SIP solves this by enforcing (rule `2`) that `@static` fields and expressions preceed non-static fields. +This SIP solves this by enforcing (rule `2`) that `@static` fields and expressions precede non-static fields. This means that no code precedes the `@static` field initialization which makes it hard to observe the difference between if the field is initialized statically or not, since fields are initialized in the order `as written`, similar to how normal fields are initialized.