Miscelaneous docs updates and fixes. (#1249)

Update references to things in CraneStation which have moved, WASI documentation
which has moved to the WASI repo, and fix a few typos.

docs/WASI-background.md

@@ -53,7 +53,7 @@ of browsers and outside of JS VMs.
 
 It's been obvious since WebAssembly was just getting started that it'd eventually
 want some kind of "system call"-like API, which could be standardized, and
-implemented in any general-purpose WebAssembly VM. 
+implemented in any general-purpose WebAssembly VM.
 
 And while there are many existing systems we could model this after, [POSIX]
 stands out, as being a vendor-neutral standard with considerable momentum. Many

docs/WASI-documents.md

@@ -5,11 +5,13 @@ To get started using WASI, see [the intro document](WASI-intro.md) and
 
 For more detail on what WASI is, see [the overview](WASI-overview.md).
 
-For specifics on the API, see the [API documentation](https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-api.md).
+For specifics on the API, see the [API documentation](https://github.com/WebAssembly/WASI/blob/master/phases/snapshot/docs.md).
 Additionally, a C header file describing the WASI API is
-[here](https://github.com/CraneStation/wasi-libc/blob/master/libc-bottom-half/headers/public/wasi/api.h).
+[here](https://github.com/WebAssembly/wasi-libc/blob/master/libc-bottom-half/headers/public/wasi/api.h).
 
-The WASI libc repository is [wasi-libc](https://github.com/CraneStation/wasi-libc/).
+The WASI C/C++ SDK repository is [wasi-sdk](https://github.com/WebAssembly/wasi-sdk/).
+
+The WASI libc repository, used by wasi-sdk, is [wasi-libc](https://github.com/WebAssembly/wasi-libc/).
 
 For some discussion of capability-based design, see the [Capabilities document](WASI-capabilities.md).
 

docs/WASI-proposed-CG-subgroup-charter.md

@@ -1,55 +0,0 @@
-# WebAssembly System Interface Subgroup Charter
-
-The System Interface Subgroup is a sub-organization of the
-[WebAssembly Community Group](https://www.w3.org/community/webassembly/) of the W3C.
-As such, it is intended that its charter align with that of the CG. In particular, 
-the sections of the [CG charter](https://webassembly.github.io/cg-charter/) relating to
-[Community and Business Group Process](https://webassembly.github.io/cg-charter/#process),
-[Contribution Mechanics](https://webassembly.github.io/cg-charter/#contrib),
-[Transparency](https://webassembly.github.io/cg-charter/#transparency), and
-[Decision Process](https://webassembly.github.io/cg-charter/#decision) also apply to the Subgroup.
-
-## Goals
-
-The mission of this sugbroup is to provide a forum for pre-standardization
-collaboration on a system interface API for WebAssembly programs.
-
-## Scope
-
-The Subgroup will consider topics related to system interface APIs, including:
-
-- APIs for host filesystems, network stacks, and other resources.
-- APIs for graphics, audio, input devices
-- APIs for encryption, format conversion, and other transformations
-  (particularly where hardware accelleration may be available on some plaforms)
-
-
-## Deliverables
-
-### Specifications
-The Subgroup may produce several kinds of specification-related work output:
-- Creation of new specifications in standards bodies or working
-groups (e.g. Wasm WG or TC39)
-- Creation of new specifications outside of standards bodies
-(e.g. similar to the LLVM object file format documentation in Wasm tool conventions)
-
-### Non-normative reports
-The Subgroup may produce non-normative material such as requirements
-documents, recommendations, and use cases.
-
-### Software
-The Subgroup may produce software related to Wasm system interface APIs (either
-as standalone libraries, tooling, or integration of interface-related
-functionality in existing CG software such as Binaryen or WABT). Capabilities may
-include:
-- Libraries implementing external standard APIs in terms of WebAssembly
-  System Interface APIs
-- Tools for producing code that uses WebAssembly System Interface APIs
-- Tools for implementing WebAssembly APIs
-- Tools for debugging programs using WebAssembly System Interface APIs
-
-## Amendments to this Charter and Chair Selection
-
-This charter may be amended, and Subgroup Chairs may be selected by vote of the full
-WebAssembly Community Group.
-

docs/WASI-tutorial.md

@@ -74,7 +74,7 @@ int main(int argc, char **argv) {
 
 We'll put this source in a file called `demo.c`.
 
-The [wasi-sdk](https://github.com/CraneStation/wasi-sdk/releases) provides a clang
+The [wasi-sdk](https://github.com/WebAssembly/wasi-sdk/releases) provides a clang
 which is configured to target WASI and use the WASI sysroot by default if you put the extracted tree into `/`, so we can
 compile our program like so:
 

docs/cli-options.md

@@ -60,7 +60,7 @@ $ wasmtime wast foo.wast
 
 ## `config`
 
-This subcomand is used to control and edit local Wasmtime configuration
+This subcommand is used to control and edit local Wasmtime configuration
 settings. The primary purpose of this currently is to configure [how Wasmtime's
 code caching works](./cli-cache.md). You can create a new configuration file for
 you to edit with:

docs/cli.md

@@ -1,7 +1,7 @@
 # Using the `wasmtime` CLI
 
 In addition to the embedding API which allows you to use Wasmtime as a
-library, the Wasmtime project also provies a `wasmtime` CLI tool to conveniently
+library, the Wasmtime project also provides a `wasmtime` CLI tool to conveniently
 execute WebAssembly modules from the command line.
 
 This section will provide a guide to the `wasmtime` CLI and major functionality

docs/contributing-release-process.md

@@ -1,7 +1,7 @@
 # Release Process
 
-This is intended to serve as documentation for wasmtime's release process. It's
-largely an internal checklist for those of us performing a wasmtime release, but
+This is intended to serve as documentation for Wasmtime's release process. It's
+largely an internal checklist for those of us performing a Wasmtime release, but
 others might be curious in this as well!
 
 To kick off the release process someone decides to do a release. Currently
@@ -17,11 +17,11 @@ be executed to make the release:
   * Commit the changes
 1. Make sure `RELEASES.md` is up-to-date, and fill it out if it doesn't have an
    entry yet for the current release.
-1. Send this version update as a PR to the wasmtime repository, wait for a merge
+1. Send this version update as a PR to the `wasmtime` repository, wait for a merge
 1. After merging, tag the merge as `vA.B.C`
 1. Push the tag to the repository
   * This will trigger the release CI which will create all release artifacts and
     publish them to GitHub releases.
 1. Run `scripts/publish-all.sh` to publish all crates to crates.io
 
-And that's it, then you've done a wasmtime release.
+And that's it, then you've done a Wasmtime release.

docs/contributing-testing.md

@@ -134,7 +134,7 @@ new tests.
 
 ### Adding WASI Integration Tests
 
-When you have a WASI-specific test program that you'd like to include as a 
+When you have a WASI-specific test program that you'd like to include as a
 test case to run against our WASI implementation, you can add it to our
 `test-programs` crate. In particular, you should drop a main-style Rust source
 file into `crates/test-programs/wasi-tests/src/bin/some_new_test.rs` with a

docs/wasm-c.md

@@ -6,7 +6,7 @@ to build WebAssembly-targeted versions of the library parts, and it can
 be tricky to get all the CMake invocations lined up properly.
 
 To make things easier, we provide
-[prebuilt packages](https://github.com/CraneStation/wasi-sdk/releases)
+[prebuilt packages](https://github.com/WebAssembly/wasi-sdk/releases)
 that provide builds of Clang and sysroot libraries.
 
 WASI doesn't yet support `setjmp`/`longjmp` or C++ exceptions, as it is

docs/wasm-rust.md

@@ -191,14 +191,14 @@ and we have our new wasm binary!
 We can then test out support for this with the CLI:
 
 ```sh
-$ wasmtime --invoke greet ./target/wasm32-wasi/release/hello_world.wasm "wasmtime CLI"
+$ wasmtime --invoke greet ./target/wasm32-wasi/release/hello_world.wasm "Wasmtime CLI"
 warning: using `--invoke` with a function that takes arguments is experimental and may break in the future
 warning: using `--invoke` with a function that returns values is experimental and may break in the future
-Hello, wasmtime CLI!
+Hello, Wasmtime CLI!
 ```
 
 Here we can see some experimental warnings, but we got our error message printed
-out! The first CLI parameter, `"wasmtime CLI"`, was passed as the first argument
+out! The first CLI parameter, `"Wasmtime CLI"`, was passed as the first argument
 of the `greet` function. The resulting string was then printed out to the
 console.