---

yaml
---
r: 31003
b: refs/heads/incoming
c: 0eb9d41
h: refs/heads/master
i:
  31001: 6398bb7
  30999: f73b924
v: v3

Author: gmcabrita

[refs]

@@ -6,7 +6,7 @@ refs/heads/try: d324a424d8f84b1eb049b12cf34182bda91b0024
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: d0c6ce338884ee21843f4b40bf6bf18d222ce5df
-refs/heads/incoming: 56c9c815227a107e527ef1c978bc23d9f351efb2
+refs/heads/incoming: 0eb9d41454083d2e9cb11859669f35c25c0f3347
 refs/heads/dist-snap: 2f32a1581f522e524009138b33b1c7049ced668d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/incoming/doc/tutorial-macros.md

@@ -65,7 +65,7 @@ forbidden.
 To take as an argument a fragment of Rust code, write `$` followed by a name
  (for use on the right-hand side), followed by a `:`, followed by the sort of
 fragment to match (the most common ones are `ident`, `expr`, `ty`, `pat`, and
-`block`). Anything not preceeded by a `$` is taken literally. The standard
+`block`). Anything not preceded by a `$` is taken literally. The standard
 rules of tokenization apply,
 
 So `($x:ident => (($e:expr)))`, though excessively fancy, would create a macro
@@ -88,7 +88,7 @@ position).
 
 Going back to the motivating example, suppose that we wanted each invocation
 of `early_return` to potentially accept multiple "special" identifiers. The
-syntax `$(...)*` accepts zero or more occurences of its contents, much like
+syntax `$(...)*` accepts zero or more occurrences of its contents, much like
 the Kleene star operator in regular expressions. It also supports a separator
 token (a comma-separated list could be written `$(...),*`), and `+` instead of
 `*` to mean "at least one".

branches/incoming/doc/tutorial-tasks.md

@@ -47,7 +47,7 @@ In particular, there are currently two independent modules that provide
 a message passing interface to Rust code: `core::comm` and `core::pipes`.
 `core::comm` is an older, less efficient system that is being phased out
 in favor of `pipes`. At some point the existing `core::comm` API will
-be romoved and the user-facing portions of `core::pipes` will be moved
+be removed and the user-facing portions of `core::pipes` will be moved
 to `core::comm`. In this tutorial we will discuss `pipes` and ignore
 the `comm` API.
 
@@ -58,7 +58,7 @@ concurrency at the moment.
 * [`core::comm`] - The deprecated message passing API
 * [`core::pipes`] - The new message passing infrastructure and API
 * [`std::comm`] - Higher level messaging types based on `core::pipes`
-* [`std::sync`] - More exotic synchronization tools, including locks 
+* [`std::sync`] - More exotic synchronization tools, including locks
 * [`std::arc`] - The ARC type, for safely sharing immutable data
 * [`std::par`] - Some basic tools for implementing parallel algorithms
 
@@ -151,7 +151,7 @@ commonly used, which we will cover presently.
 
 The simplest way to create a pipe is to use the `pipes::stream`
 function to create a `(Chan, Port)` pair. In Rust parlance a 'channel'
-is a sending endpoint of a pipe, and a 'port' is the recieving
+is a sending endpoint of a pipe, and a 'port' is the receiving
 endpoint. Consider the following example of performing two calculations
 concurrently.
 
@@ -183,7 +183,7 @@ let (chan, port): (Chan<int>, Port<int>) = stream();
 ~~~~
 
 The channel will be used by the child task to send data to the parent task,
-which will wait to recieve the data on the port. The next statement
+which will wait to receive the data on the port. The next statement
 spawns the child task.
 
 ~~~~
@@ -307,7 +307,7 @@ unrecoverable within a single task - once a task fails there is no way
 to "catch" the exception.
 
 All tasks are, by default, _linked_ to each other, meaning their fate
-is interwined, and if one fails so do all of them.
+is intertwined, and if one fails so do all of them.
 
 ~~~
 # use task::spawn;