Remove localhost links from docs. Duh.

doc/_posts/2013-09-04-capnproto-0.3-python-tools-features.md

@@ -55,19 +55,19 @@ to you.  Use `capnp eval` to "compile" the whole thing to binary for deployment.
 been a common use case for Protobuf text format, which doesn't even support variable substitution
 or imports.)
 
-Anyway, check out the [full documentation](http://localhost:4000/capnproto/capnp-tool.html) for
+Anyway, check out the [full documentation]({{ site.baseurl }}capnp-tool.html) for
 more.
 
 ## New Features
 
 The core product has been updated as well:
 
-* Support for unnamed [unions](http://localhost:4000/capnproto/language.html#unions) reduces the
+* Support for unnamed [unions]({{ site.baseurl }}language.html#unions) reduces the
   need for noise-words, improving code readability.  Additionally, the syntax for unions has been
   simplified by removing the unnecessary ordinal number.
-* [Groups](http://localhost:4000/capnproto/language.html#groups) pair nicely with unions.
-* [Constants](http://localhost:4000/capnproto/language.html#constants) are now
-  [implemented in C++](http://localhost:4000/capnproto/cxx.html#constants).  Additionally, they
+* [Groups]({{ site.baseurl }}language.html#groups) pair nicely with unions.
+* [Constants]({{ site.baseurl }}language.html#constants) are now
+  [implemented in C++]({{ site.baseurl }}cxx.html#constants).  Additionally, they
   can now be defined in terms of other constants (variable substitution), as described earlier.
 * The schema API and `schema.capnp` have been radically refactored, in particular to take advantage
   of the new union and group features, making the code more readable.

doc/capnp-tool.md

@@ -30,7 +30,7 @@ and import paths.
 The above example generates C++ code, but the tool is able to generate output in any language
 for which a plugin is available.  Compiler plugins are just regular programs named
 `capnpc-language`.  For example, the above command runs `capnpc-c++`.  [More on how to write
-compiler plugins](http://localhost:4000/capnproto/otherlang.html#how_to_write_compiler_plugins).
+compiler plugins](otherlang.html#how_to_write_compiler_plugins).
 
 Note that some Cap'n Proto implementations (especially for interpreted languages) do not require
 generating source code.
@@ -41,16 +41,16 @@ generating source code.
 
 `capnp decode` reads a binary Cap'n Proto message from standard input and decodes it to a
 human-readable text format (specifically, the format used for specifying constants and default
-values in [the schema language](http://localhost:4000/capnproto/language.html)).  By default it
+values in [the schema language](language.html)).  By default it
 expects an unpacked message, but you can decode a
-[packed](http://localhost:4000/capnproto/encoding.html#packing) message with the `--packed` flag.
+[packed](encoding.html#packing) message with the `--packed` flag.
 
 ## Encoding Messages
 
     capnp encode myschema.capnp MyType < message.txt > message.bin
 
 `capnp encode` is the opposite of `capnp decode`: it takes a text-format message on stdin and
-encodes it to binary (possibly [packed](http://localhost:4000/capnproto/encoding.html#packing),
+encodes it to binary (possibly [packed](encoding.html#packing),
 with the `--packed` flag).
 
 This is mainly useful for debugging purposes, to build test data or to apply tweaks to data
@@ -61,9 +61,9 @@ and maintained in text format long-term -- instead, use `capnp eval`, which is m
 
     capnp eval myschema.capnp myConstant
 
-This prints the value of `myConstant`, a
-[const](http://localhost:4000/capnproto/language.html#constants) declaration, after applying
-variable substitution.  It can also output the value in binary format (`--binary` or `--packed`).
+This prints the value of `myConstant`, a [const](language.html#constants) declaration, after
+applying variable substitution.  It can also output the value in binary format (`--binary` or
+`--packed`).
 
 At first glance, this may seem no more interesting that `capnp encode`:  the syntax used to define
 constants in schema files is the same as the format accepted by `capnp encode`, right?  There is,

doc/language.md

@@ -348,7 +348,7 @@ reference to an object inherently represents a "capability" to access it.
 
 You can define constants in Cap'n Proto.  These don't affect what is sent on the wire, but they
 will be included in the generated code, and can be [evaluated using the `capnp`
-tool](http://localhost:4000/capnproto/capnp-tool.html#evaluating_constants).
+tool](capnp-tool.html#evaluating_constants).
 
 {% highlight capnp %}
 const pi :Float32 = 3.14159;

doc/otherlang.md

@@ -100,5 +100,5 @@ compiled source files as `.pyc` bytecode, but that's up to you.
 ### Testing Your Implementation
 
 The easiest way to test that you've implemented the spec correctly is to use the `capnp` tool
-to [encode](http://localhost:4000/capnproto/capnp-tool.html#encoding_messages) test inputs and
-[decode](http://localhost:4000/capnproto/capnp-tool.html#decoding_messages) outputs.
+to [encode](capnp-tool.html#encoding_messages) test inputs and
+[decode](capnp-tool.html#decoding_messages) outputs.