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.

crates/lightbeam/README.md

@@ -162,7 +162,7 @@ Lightbeam passes 100% of the specification test suite, but that doesn't necessar
 
 ## Getting involved
 
-You can file issues in the [Wasmtime issue tracker][Wasmtime issue tracker]. If you want to get involved jump into the [CraneStation Gitter room][cranestation-gitter] and someone can direct you to the right place. I wish I could say "the most useful thing you can do is play with it and open issues where you find problems" but until it passes the spec suite that won't be very helpful.
+You can file issues in the [Wasmtime issue tracker][Wasmtime issue tracker]. If you want to get involved jump into the [Bytecode Alliance Zulip][bytecodealliance-zulip] and someone can direct you to the right place. I wish I could say "the most useful thing you can do is play with it and open issues where you find problems" but until it passes the spec suite that won't be very helpful.
 
-[cranestation-gitter]: https://gitter.im/CraneStation/Lobby
+[bytecodealliance-zulip]: https://bytecodealliance.zulipchat.com/
 [Wasmtime issue tracker]: https://github.com/bytecodealliance/wasmtime/issues

crates/wasi-common/README.md

@@ -42,7 +42,7 @@ We expect these to be implemented when network access is standardised.
 We also currently do not support the `proc_raise` hostcall, as it is expected to
 be dropped entirely from WASI.
 
-[WASI API]: https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-api.md
+[WASI API]: https://github.com/WebAssembly/WASI/blob/master/phases/snapshot/docs.md
 
 ### Windows
 In our Windows implementation, we currently support the minimal subset of [WASI API]

crates/wasi-common/src/old/snapshot_0/sys/unix/hostcalls_impl/mod.rs

@@ -1,5 +1,5 @@
 //! Unix-specific hostcalls that implement
-//! [WASI](https://github.com/bytecodealliance/wasmtime-wasi/blob/wasi/docs/WASI-overview.md).
+//! [WASI](https://github.com/WebAssembly/WASI).
 mod fs;
 pub(crate) mod fs_helpers;
 mod misc;

crates/wasi-common/src/old/snapshot_0/sys/windows/hostcalls_impl/mod.rs

@@ -1,5 +1,5 @@
 //! Windows-specific hostcalls that implement
-//! [WASI](https://github.com/bytecodealliance/wasmtime-wasi/blob/wasi/docs/WASI-overview.md).
+//! [WASI](https://github.com/WebAssembly/WASI).
 mod fs;
 pub(crate) mod fs_helpers;
 mod misc;

crates/wasi-common/src/sys/unix/hostcalls_impl/mod.rs

@@ -1,5 +1,5 @@
 //! Unix-specific hostcalls that implement
-//! [WASI](https://github.com/bytecodealliance/wasmtime-wasi/blob/wasi/docs/WASI-overview.md).
+//! [WASI](https://github.com/WebAssembly/WASI).
 mod fs;
 pub(crate) mod fs_helpers;
 mod misc;

crates/wasi-common/src/sys/windows/hostcalls_impl/mod.rs

@@ -1,5 +1,5 @@
 //! Windows-specific hostcalls that implement
-//! [WASI](https://github.com/bytecodealliance/wasmtime-wasi/blob/wasi/docs/WASI-overview.md).
+//! [WASI](https://github.com/WebAssembly/WASI).
 mod fs;
 pub(crate) mod fs_helpers;
 mod misc;

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.