From 18a5288b99a812b9237f426c1194876afa2362d4 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Fri, 12 Jun 2015 14:19:03 -0700 Subject: Use https links instead of http links for sites that support it. --- BinaryEncoding.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 3aad2a6..0635a20 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -27,7 +27,7 @@ Reducing download size, is achieved through three layers: features like constant pools. * Another example is reordering of functions and some internal nodes, which we know does not change semantics, but - [can improve general compression](http://www.rfk.id.au/blog/entry/cromulate-improve-compressibility/). + [can improve general compression](https://www.rfk.id.au/blog/entry/cromulate-improve-compressibility/). * **Generic** compression, such as gzip, already supported in browsers, or LZMA and other compression algorithms, which might be standardized as well. @@ -61,7 +61,7 @@ Yes: ### Variable-length integers * 31% size reduction before compression, 7% size reduction after compression. - * [LEB128](http://en.wikipedia.org/wiki/LEB128) except limited to uint32_t payloads. + * [LEB128](https://en.wikipedia.org/wiki/LEB128) except limited to uint32_t payloads. ## Global structure @@ -113,7 +113,7 @@ having unique names for unique features (and associated [conventions](https://hs The current proposal is to maintain both the efficiency of indices in the [serialized AST](BinaryEncoding.md#serialized-ast) and the established conflict-avoidance practices surrounding string names: * The WebAssembly spec doesn't define any global index spaces - * So, as a general rule, no magic numbers in the spec (other than the literal [magic number](http://en.wikipedia.org/wiki/Magic_number_%28programming%29)). + * So, as a general rule, no magic numbers in the spec (other than the literal [magic number](https://en.wikipedia.org/wiki/Magic_number_%28programming%29)). * Instead, a module defines its *own* local index spaces of opcodes by providing tables *of names*. * So what the spec *would* define is a set of names and their associated semantics. * If the implementation encounters a name it doesn't implement, by default an error is thrown while loading. -- cgit v1.2.3 From ef6799f98620b327e7668075dd709f532e60ace2 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Mon, 15 Jun 2015 10:13:35 -0800 Subject: Add trailing slashes to URLs that want it. --- AstSemantics.md | 2 +- BinaryEncoding.md | 2 +- FAQ.md | 4 ++-- README.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) (limited to 'BinaryEncoding.md') diff --git a/AstSemantics.md b/AstSemantics.md index 82450b7..1e87c49 100644 --- a/AstSemantics.md +++ b/AstSemantics.md @@ -6,7 +6,7 @@ expressions. Expressions are typed; validation consists of simple, bottom-up, Why not a stack-, register- or SSA-based bytecode? * Smaller binary encoding: - [JSZap](https://research.microsoft.com/en-us/projects/jszap), + [JSZap](https://research.microsoft.com/en-us/projects/jszap/), [Slim Binaries](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.1711) * [Polyfill prototype](https://github.com/WebAssembly/polyfill-prototype-1) shows simple and efficient translation to asm.js. diff --git a/BinaryEncoding.md b/BinaryEncoding.md index 0635a20..9788abf 100644 --- a/BinaryEncoding.md +++ b/BinaryEncoding.md @@ -108,7 +108,7 @@ F1 and F2 and vendor V1 implements F1, assigning the next logical opcode indices opcodes, and V2 implements F2, assigning the same next logical opcode indices to F2's new opcodes and now a single binary has ambiguous semantics if it tries to use either F1 or F2. This type of non-linear feature addition is commonplace in JS and Web APIs and is guarded against by -having unique names for unique features (and associated [conventions](https://hsivonen.fi/vendor-prefixes)). +having unique names for unique features (and associated [conventions](https://hsivonen.fi/vendor-prefixes/)). The current proposal is to maintain both the efficiency of indices in the [serialized AST](BinaryEncoding.md#serialized-ast) and the established conflict-avoidance practices surrounding string names: diff --git a/FAQ.md b/FAQ.md index 8207fd1..28e4b69 100644 --- a/FAQ.md +++ b/FAQ.md @@ -36,7 +36,7 @@ memory usage is basically the size of the input plus the size of the decoded tex Additionally, there are two further improvements that can be made in the real polyfill: 1. Decode while downloading using either chunked files, HTTP `Range` requests or (eventually) - the [Stream API](https://www.w3.org/TR/streams-api). + the [Stream API](https://www.w3.org/TR/streams-api/). 2. Include optional better-than-`gzip` compression in the polyfill. For example, the [lzham](https://github.com/richgel999/lzham_codec) library shows an *additional* 24% improvement over the above "`gzip` binary" figures while maintaining high decode rates. @@ -83,7 +83,7 @@ The [WebAssembly Community Group][] would be delighted to collaborate with more compiler vendors, take their input into consideration in WebAssembly itself, and work with them on ABI matters. - [WebAssembly Community Group]: https://www.w3.org/community/webassembly + [WebAssembly Community Group]: https://www.w3.org/community/webassembly/ ## Will WebAssembly support View Source on the Web? diff --git a/README.md b/README.md index 932d4df..4533183 100644 --- a/README.md +++ b/README.md @@ -17,4 +17,4 @@ Join us: * On IRC: `irc://irc.w3.org:6667/#webassembly` * [Contribute](Contributing.md)! - [WebAssembly]: https://www.w3.org/community/webassembly + [WebAssembly]: https://www.w3.org/community/webassembly/ -- cgit v1.2.3