Fix "note that" comma everywhere

Author: Inego

CHANGES.md

@@ -215,7 +215,7 @@ Visible consequences of include more robust exception handling for large corouti
 * Distribution no longer uses multi-version jar which is not supported on Android (see #510).
 * JS version of the library does not depend on AtomicFu anymore:
   All the atomic boxes in JS are fully erased.
-* Note, that versions 0.25.1-2 are skipped for technical reasons (they were not fully released).
+* Note that versions 0.25.1-2 are skipped for technical reasons (they were not fully released).
 
 ## Version 0.25.0
 

docs/channels.md

@@ -341,7 +341,7 @@ The output of this code is:
 
 <!--- TEST -->
 
-Note, that you can build the same pipeline using 
+Note that you can build the same pipeline using 
 [`iterator`](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/iterator.html) 
 coroutine builder from the standard library. 
 Replace `produce` with `iterator`, `send` with `yield`, `receive` with `next`, 
@@ -445,7 +445,7 @@ Processor #3 received 10
 
 <!--- TEST lines.size == 10 && lines.withIndex().all { (i, line) -> line.startsWith("Processor #") && line.endsWith(" received ${i + 1}") } -->
 
-Note, that cancelling a producer coroutine closes its channel, thus eventually terminating iteration
+Note that cancelling a producer coroutine closes its channel, thus eventually terminating iteration
 over the channel that processor coroutines are doing.
 
 Also, pay attention to how we explicitly iterate over channel with `for` loop to perform fan-out in `launchProcessor` code. 
@@ -627,7 +627,7 @@ pong Ball(hits=4)
 
 <!--- TEST -->
 
-Note, that sometimes channels may produce executions that look unfair due to the nature of the executor
+Note that sometimes channels may produce executions that look unfair due to the nature of the executor
 that is being used. See [this issue](https://github.com/Kotlin/kotlinx.coroutines/issues/111) for details.
 
 ### Ticker channels

docs/composing-suspending-functions.md

@@ -162,7 +162,7 @@ Completed in 1017 ms
 <!--- TEST ARBITRARY_TIME -->
 
 This is twice as fast, because we have concurrent execution of two coroutines. 
-Note, that concurrency with coroutines is always explicit.
+Note that concurrency with coroutines is always explicit.
 
 ### Lazily started async
 
@@ -219,7 +219,7 @@ So, here the two coroutines are defined but not executed as in the previous exam
 the programmer on when exactly to start the execution by calling [start][Job.start]. We first 
 start `one`, then start `two`, and then await for the individual coroutines to finish. 
 
-Note, that if we have called [await][Deferred.await] in `println` and omitted [start][Job.start] on individual 
+Note that if we have called [await][Deferred.await] in `println` and omitted [start][Job.start] on individual 
 coroutines, then we would have got the sequential behaviour as [await][Deferred.await] starts the coroutine 
 execution and waits for the execution to finish, which is not the intended use-case for laziness. 
 The use-case for `async(start = CoroutineStart.LAZY)` is a replacement for the 
@@ -249,7 +249,7 @@ fun somethingUsefulTwoAsync() = GlobalScope.async {
 
 </div>
 
-Note, that these `xxxAsync` functions are **not** _suspending_ functions. They can be used from anywhere.
+Note that these `xxxAsync` functions are **not** _suspending_ functions. They can be used from anywhere.
 However, their use always implies asynchronous (here meaning _concurrent_) execution of their action
 with the invoking code.
 
@@ -264,7 +264,7 @@ import kotlinx.coroutines.*
 import kotlin.system.*
 
 //sampleStart
-// note, that we don't have `runBlocking` to the right of `main` in this example
+// note that we don't have `runBlocking` to the right of `main` in this example
 fun main() {
     val time = measureTimeMillis {
         // we can initiate async actions outside of a coroutine

docs/coroutine-context-and-dispatchers.md

@@ -267,7 +267,7 @@ same coroutine as you can see in the output below:
 
 <!--- TEST -->
 
-Note, that this example also uses `use` function from the Kotlin standard library to release threads that
+Note that this example also uses `use` function from the Kotlin standard library to release threads that
 are created with [newSingleThreadContext] when they are no longer needed. 
 
 ### Job in the context
@@ -299,7 +299,7 @@ My job is "coroutine#1":BlockingCoroutine{Active}@6d311334
 
 <!--- TEST lines.size == 1 && lines[0].startsWith("My job is \"coroutine#1\":BlockingCoroutine{Active}@") -->
 
-Note, that [isActive] in [CoroutineScope] is just a convenient shortcut for
+Note that [isActive] in [CoroutineScope] is just a convenient shortcut for
 `coroutineContext[Job]?.isActive == true`.
 
 ### Children of a coroutine

docs/select-expression.md

@@ -376,7 +376,7 @@ fun CoroutineScope.asyncStringsList(): List<Deferred<String>> {
 </div>
 
 Now the main function awaits for the first of them to complete and counts the number of deferred values
-that are still active. Note, that we've used here the fact that `select` expression is a Kotlin DSL, 
+that are still active. Note that we've used here the fact that `select` expression is a Kotlin DSL, 
 so we can provide clauses for it using an arbitrary code. In this case we iterate over a list
 of deferred values to provide `onAwait` clause for each deferred value.
 

docs/shared-mutable-state-and-concurrency.md

@@ -553,7 +553,7 @@ works as a solution to the problem of shared mutable state. Indeed, actors may m
 Actor is more efficient than locking under load, because in this case it always has work to do and it does not 
 have to switch to a different context at all.
 
-> Note, that an [actor] coroutine builder is a dual of [produce] coroutine builder. An actor is associated 
+> Note that an [actor] coroutine builder is a dual of [produce] coroutine builder. An actor is associated 
   with the channel that it receives messages from, while a producer is associated with the channel that it 
   sends elements to.
 

integration/kotlinx-coroutines-guava/README.md

@@ -35,7 +35,7 @@ fun combineImagesAsync(name1: String, name2: String): ListenableFuture<Image> =
 }
 ```
 
-Note, that this module should be used only for integration with existing Java APIs based on `ListenableFuture`. 
+Note that this module should be used only for integration with existing Java APIs based on `ListenableFuture`. 
 Writing pure-Kotlin code that uses `ListenableFuture` is highly not recommended, since the resulting APIs based
 on the futures are quite error-prone. See the discussion on 
 [Asynchronous Programming Styles](https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#asynchronous-programming-styles)

integration/kotlinx-coroutines-jdk8/README.md

@@ -36,7 +36,7 @@ fun combineImagesAsync(name1: String, name2: String): CompletableFuture<Image> =
 }
 ```
 
-Note, that this module should be used only for integration with existing Java APIs based on `CompletableFuture`. 
+Note that this module should be used only for integration with existing Java APIs based on `CompletableFuture`. 
 Writing pure-Kotlin code that uses `CompletableFuture` is highly not recommended, since the resulting APIs based
 on the futures are quite error-prone. See the discussion on 
 [Asynchronous Programming Styles](https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md#asynchronous-programming-styles)

integration/kotlinx-coroutines-slf4j/src/MDCContext.kt

@@ -28,7 +28,7 @@ public typealias MDCContextMap = Map<String, String>?
  * }
  * ```
  *
- * Note, that you cannot update MDC context from inside of the coroutine simply
+ * Note that you cannot update MDC context from inside of the coroutine simply
  * using [MDC.put]. These updates are going to be lost on the next suspension and
  * reinstalled to the MDC context that was captured or explicitly specified in
  * [contextMap] when this object was created on the next resumption.

kotlinx-coroutines-core/common/src/Await.kt

@@ -109,7 +109,7 @@ private class AwaitAll<T>(private val deferreds: Array<out Deferred<T>>) {
                 }
             } else if (notCompletedCount.decrementAndGet() == 0) {
                 continuation.resume(deferreds.map { it.getCompleted() })
-                // Note, that all deferreds are complete here, so we don't need to dispose their nodes
+                // Note that all deferreds are complete here, so we don't need to dispose their nodes
             }
         }
     }