Fix a few typos in akka-stream docs

This commit is contained in:
Sören Brunk 2016-01-15 11:48:29 +01:00
parent ecc916abfd
commit a39078d450
8 changed files with 12 additions and 12 deletions

View file

@ -389,8 +389,8 @@ replaced with a single method: ``Sink.asPublisher(fanout: Boolean)``.
Update procedure
----------------
1. Replace all occurences of ``Sink.publisher`` with ``Sink.asPublisher(false)``
2. Replace all occurences of ``Sink.fanoutPublisher`` with ``Sink.asPublisher(true)``
1. Replace all occurrences of ``Sink.publisher`` with ``Sink.asPublisher(false)``
2. Replace all occurrences of ``Sink.fanoutPublisher`` with ``Sink.asPublisher(true)``
Example
^^^^^^^

View file

@ -54,7 +54,7 @@ collection itself, so we can just call ``mapConcat(l -> l)``.
Draining a stream to a strict collection
----------------------------------------
**Situation:** A finite sequence of elements is given as a stream, but a scala collection is needed instead.
**Situation:** A finite sequence of elements is given as a stream, but a Scala collection is needed instead.
In this recipe we will use the ``grouped`` stream operation that groups incoming elements into a stream of limited
size collections (it can be seen as the almost opposite version of the "Flattening a stream of sequences" recipe
@ -294,7 +294,7 @@ We introduce a boolean variable ``waitingFirstValue`` to denote whether the firs
a null can be used with the same purpose). In the downstream ``onPull()`` handler the difference from the previous
version is that we call ``holdDownstream()`` if the first element is not yet available and thus blocking our downstream. The
upstream ``onPush()`` handler sets ``waitingFirstValue`` to false, and after checking if ``holdDownstream()`` has been called it
either releaves the upstream producer, or both the upstream producer and downstream consumer by calling ``pushAndPull()``
either relieves the upstream producer, or both the upstream producer and downstream consumer by calling ``pushAndPull()``
.. includecode:: ../code/docs/stream/javadsl/cookbook/RecipeHold.java#hold-version-2

View file

@ -99,7 +99,7 @@ The following operations are available for *input* ports:
The events corresponding to an *input* port can be received in an :class:`AbstractInHandler` instance registered to the
input port using ``setHandler(in, handler)``. This handler has three callbacks:
* ``onPush()`` is called when the output port has now a new element. Now it is possible to aquire this element using
* ``onPush()`` is called when the output port has now a new element. Now it is possible to acquire this element using
``grab(in)`` and/or call ``pull(in)`` on the port to request the next element. It is not mandatory to grab the
element, but if it is pulled while the element has not been grabbed it will drop the buffered element.
* ``onUpstreamFinish()`` is called once the upstream has completed and no longer can be pulled for new elements.

View file

@ -121,7 +121,7 @@ The runnable graph can then be ``run()`` to materialize a stream out of it.
Both :class:`Graph` and :class:`RunnableGraph` are *immutable, thread-safe, and freely shareable*.
A graph can also have one of several other shapes, with one or more unconnected ports. Having unconnected ports
expresses a grapth that is a *partial graph*. Concepts around composing and nesting graphs in large structures are
expresses a graph that is a *partial graph*. Concepts around composing and nesting graphs in large structures are
explained in detail in :ref:`composition-java`. It is also possible to wrap complex computation graphs
as Flows, Sinks or Sources, which will be explained in detail in :ref:`partial-flow-graph-java`.