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
             }
         }
     }

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

@@ -127,7 +127,7 @@ private class LazyDeferredCoroutine<T>(
  *
  * This function uses dispatcher from the new context, shifting execution of the [block] into the
  * different thread if a new dispatcher is specified, and back to the original dispatcher
- * when it completes. Note, that the result of `withContext` invocation is
+ * when it completes. Note that the result of `withContext` invocation is
  * dispatched into the original context in a cancellable way, which means that if the original [coroutineContext],
  * in which `withContext` was invoked, is cancelled by the time its dispatcher starts to execute the code,
  * it discards the result of `withContext` and throws [CancellationException].

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

@@ -10,7 +10,7 @@ import kotlinx.coroutines.selects.*
 /**
  * A [Deferred] that can be completed via public functions [complete] or [cancel][Job.cancel].
  *
- * Note, that [complete] functions returns `false` when this deferred value is already complete or completing,
+ * Note that [complete] functions returns `false` when this deferred value is already complete or completing,
  * while [cancel][Job.cancel] returns `true` as long the deferred is still _cancelling_ and the corresponding
  * exception is incorporated into the final [completion exception][getCompletionExceptionOrNull].
  *

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

@@ -26,7 +26,7 @@ public enum class CoroutineStart {
      * function as most dispatchers do, then the coroutine code is dispatched for execution later, while the code that
      * invoked the coroutine builder continues execution.
      *
-     * Note, that [Dispatchers.Unconfined] always returns `false` from its [CoroutineDispatcher.isDispatchNeeded]
+     * Note that [Dispatchers.Unconfined] always returns `false` from its [CoroutineDispatcher.isDispatchNeeded]
      * function, so starting coroutine with [Dispatchers.Unconfined] by [DEFAULT] is the same as using [UNDISPATCHED].
      *
      * If coroutine [Job] is cancelled before it even had a chance to start executing, then it will not start its

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

@@ -16,7 +16,7 @@ import kotlinx.coroutines.selects.*
  * successful or failed result of the computation that was carried out. The result of the deferred is
  * available when it is [completed][isCompleted] and can be retrieved by [await] method, which throws
  * exception if the deferred had failed.
- * Note, that a _cancelled_ deferred is also considered to be completed.
+ * Note that a _cancelled_ deferred is also considered to be completed.
  * The corresponding exception can be retrieved via [getCompletionExceptionOrNull] from a completed instance of deferred.
  *
  * Usually, a deferred value is created in _active_ state (it is created and started).

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

@@ -63,7 +63,7 @@ public interface Delay {
  * If the [Job] of the current coroutine is cancelled or completed while this suspending function is waiting, this function
  * immediately resumes with [CancellationException].
  *
- * Note, that delay can be used in [select] invocation with [onTimeout][SelectBuilder.onTimeout] clause.
+ * Note that delay can be used in [select] invocation with [onTimeout][SelectBuilder.onTimeout] clause.
  *
  * Implementation note: how exactly time is tracked is an implementation detail of [CoroutineDispatcher] in the context.
  * @param timeMillis time in milliseconds.

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

@@ -66,7 +66,7 @@ public expect object Dispatchers {
      * Can print both "1 2 3" and "1 3 2", this is an implementation detail that can be changed.
      * But it is guaranteed that "Done" will be printed only when both `withContext` are completed.
      *
-     * Note, that if you need your coroutine to be confined to a particular thread or a thread-pool after resumption,
+     * Note that if you need your coroutine to be confined to a particular thread or a thread-pool after resumption,
      * but still want to execute it in the current call-frame until its first suspension, then you can use
      * an optional [CoroutineStart] parameter in coroutine builders like
      * [launch][CoroutineScope.launch] and [async][CoroutineScope.async] setting it to the

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

@@ -69,7 +69,7 @@ import kotlin.jvm.*
  *
  * A job can have a _parent_ job. A job with a parent is cancelled when its parent is cancelled.
  * Parent job waits in _completing_ or _cancelling_ state for all its children to complete before finishing.
- * Note, that _completing_ state is purely internal to the job. For an outside observer a _completing_ job is still
+ * Note that _completing_ state is purely internal to the job. For an outside observer a _completing_ job is still
  * active, while internally it is waiting for its children.
  *
  * Normal cancellation of a job is distinguished from its failure by the type of its cancellation exception cause.
@@ -190,7 +190,7 @@ public interface Job : CoroutineContext.Element {
      * * Parent cannot complete until all its children are complete. Parent waits for all its children to
      *   complete in _completing_ or _cancelling_ state.
      * * Uncaught exception in a child, by default, cancels parent. In particular, this applies to
-     *   children created with [launch][CoroutineScope.launch] coroutine builder. Note, that
+     *   children created with [launch][CoroutineScope.launch] coroutine builder. Note that
      *   [async][CoroutineScope.async] and other future-like
      *   coroutine builders do not have uncaught exceptions by definition, since all their exceptions are
      *   caught and are encapsulated in their result.
@@ -227,7 +227,7 @@ public interface Job : CoroutineContext.Element {
      * when the job is complete for any reason and the [Job] of the invoking coroutine is still [active][isActive].
      * This function also [starts][Job.start] the corresponding coroutine if the [Job] was still in _new_ state.
      *
-     * Note, that the job becomes complete only when all its children are complete.
+     * Note that the job becomes complete only when all its children are complete.
      *
      * This suspending function is cancellable and **always** checks for the cancellation of invoking coroutine's Job.
      * If the [Job] of the invoking coroutine is cancelled or completed when this

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

@@ -81,7 +81,7 @@ public open class JobSupport constructor(active: Boolean) : Job, ChildJob, Paren
        successfully without children (in this case it directly goes from EMPTY_A or SINGLE state to FINAL_R
        state without going to COMPLETING state)
 
-       Note, that the actual `_state` variable can also be a reference to atomic operation descriptor `OpDescriptor`
+       Note that the actual `_state` variable can also be a reference to atomic operation descriptor `OpDescriptor`
 
        ---------- TIMELINE of state changes and notification in Job lifecycle ----------
 
@@ -909,7 +909,7 @@ public open class JobSupport constructor(active: Boolean) : Job, ChildJob, Paren
 
     /**
      * When this function returns `true` the parent is cancelled on cancellation of this job.
-     * Note, that [CancellationException] is considered "normal" and parent is not cancelled when child produces it.
+     * Note that [CancellationException] is considered "normal" and parent is not cancelled when child produces it.
      * This allows parent to cancel its children (normally) without being cancelled itself, unless
      * child crashes and produce some other exception during its completion.
      *

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

@@ -19,7 +19,7 @@ import kotlin.jvm.*
  * cancellable suspending function inside the block throws [TimeoutCancellationException].
  *
  * The sibling function that does not throw exception on timeout is [withTimeoutOrNull].
- * Note, that timeout action can be specified for [select] invocation with [onTimeout][SelectBuilder.onTimeout] clause.
+ * Note that timeout action can be specified for [select] invocation with [onTimeout][SelectBuilder.onTimeout] clause.
  *
  * Implementation note: how exactly time is tracked is an implementation detail of [CoroutineDispatcher] in the context.
  *
@@ -40,7 +40,7 @@ public suspend fun <T> withTimeout(timeMillis: Long, block: suspend CoroutineSco
  * cancellable suspending function inside the block throws [TimeoutCancellationException].
  *
  * The sibling function that throws exception on timeout is [withTimeout].
- * Note, that timeout action can be specified for [select] invocation with [onTimeout][SelectBuilder.onTimeout] clause.
+ * Note that timeout action can be specified for [select] invocation with [onTimeout][SelectBuilder.onTimeout] clause.
  *
  * Implementation note: how exactly time is tracked is an implementation detail of [CoroutineDispatcher] in the context.
  *