Imported Upstream version 2011.01.12upstream/2011.01.12

59 files changed, 3832 insertions, 2152 deletions

diff --git a/doc/ExpressivenessOfGo.pdf b/doc/ExpressivenessOfGo.pdf
new file mode 100644
index 000000000..f1931d081
--- /dev/null
+++ b/doc/ExpressivenessOfGo.pdf
diff --git a/doc/Makefile b/doc/Makefile
index 0abb881b1..d992a39f3 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -2,10 +2,10 @@
 # Use of this source code is governed by a BSD-style
 # license that can be found in the LICENSE file.
 
-include $(GOROOT)/src/Make.$(GOARCH)
+include ../src/Make.inc
 
 TARG=htmlgen
 GOFILES=\
 	htmlgen.go\
 
-include $(GOROOT)/src/Make.cmd
+include ../src/Make.cmd
diff --git a/doc/all.css b/doc/all.css
new file mode 100644
index 000000000..f70ef1599
--- /dev/null
+++ b/doc/all.css
@@ -0,0 +1,197 @@
+/* General Styles */
+body {
+  font-family: "Bitstream Vera Sans", Verdana, sans-serif;
+  font-size: 81.25%;
+  line-height: 1.23em;
+  padding: 0;
+  margin: 1.23em;
+  background: white;
+  color: black;
+}
+a {
+  color: #04a;
+  text-decoration: none;
+}
+a:visited {
+  color: #04a;
+}
+a:hover {
+  color: #a40;
+  text-decoration: underline;
+}
+a:active {
+  color: #c00;
+}
+code, pre {
+  font-size: 1.2em; 
+}
+pre {
+  background: #F0F0F0;
+  padding: 0.5em 1em;
+}
+
+/* Top bar */
+#container {
+  width: 100%;
+  margin: auto;
+}
+#topnav {
+  height: 55px;
+  background: url(/doc/logo.png) no-repeat top left;
+}
+a#logo-box {
+  display: block;
+  height: 55px;
+}
+h1#title {
+  display: none;
+}
+#nav-main {
+  float: right;
+  width: 500px;
+  margin-top: -5px;
+  text-align: center;
+}
+#nav-main ul {
+  padding-left: 0;
+  margin-left: 0;
+  margin-bottom: 0.5em;
+}
+#nav-main li a {
+  display: inline;
+  display: inline-block;
+  padding: .46em .62em .38em .62em;
+}
+#nav-main li a:link,
+#nav-main li a:visited {
+  color: #000;
+}
+#nav-main li {
+  display: inline;
+  display: inline-block;
+  background: #e6e6e6 url(/doc/button_background.png) repeat-x;
+  border: solid 1px #999;
+  margin-left: -1px;
+  text-shadow: #fff 0 1px 0;
+  box-shadow: 0 1px 1px #ccc;
+  -moz-box-shadow: 0 1px 1px #ccc;
+  -webkit-box-shadow: 0 1px 1px #ccc;
+}
+#nav-main li:first-child {
+  -moz-border-top-left-radius: 4px;
+  border-top-left-radius: 4px;
+  -moz-border-bottom-left-radius: 4px;
+  border-bottom-left-radius: 4px;
+}
+#nav-main li:last-child {
+  -moz-border-top-right-radius: 4px;
+  border-top-right-radius: 4px;
+  -moz-border-bottom-right-radius: 4px;
+  border-bottom-right-radius: 4px;
+}
+#nav-main .quickref {
+  color: #444;
+}
+#nav-main .quickref .sep {
+  color: #999;
+}
+#search {
+  width: 100px;
+  margin-left: 0.5em;
+}
+#search.inactive {
+  text-align: center;
+  color: #444;
+}
+
+/* Footer */
+#site-info {
+  position: relative;
+  text-align: center;
+}
+#site-info, #site-info a:link, #site-info a:visited {
+  color: #aaa;
+}
+
+/* Content */
+#content {
+  clear: both;
+  padding: 0;
+  position: relative;
+  margin-top: 1.5em;
+  margin-bottom: 1.5em;
+  border-top: solid 1px #aaa;
+  border-bottom: solid 1px #aaa;
+}
+.left-column {
+  width: 49%;
+  float: left;
+}
+.right-column {
+  width: 49%;
+  float: right;
+}
+.end-columns {
+  clear: both;
+}
+#content h1 {
+  margin-bottom: -0em;
+  padding: 0;
+}
+#content h2 {
+  border-top: 1px solid #ddd;
+  background: #E2E7F0;
+  padding: 5px;
+  margin: 1.5em 0 0;
+}
+#content .subtitle {
+  margin-top: 1em;
+  display: block;
+}
+.navtop a {
+  font-weight: normal; font-size: 7pt; 
+  float: right; color: #999;
+}
+
+/* Content and Code Highlighting */
+pre.ebnf, pre.grammar {
+  background: #FFFFE0;
+}
+span.comment {
+  color: #002090;
+}
+span.highlight {
+  background: #FF9900;
+  font-weight: bold;
+}
+span.highlight-comment {
+  background: #FF9900;
+  font-weight: bold;
+  color: #002090;
+}
+span.selection {
+  background: #FFFF00
+}
+span.selection-comment {
+  color: #002090;
+  background: #FFFF00
+}
+span.selection-highlight {
+  background: #FF9900;
+  font-weight: bold;
+}
+span.selection-highlight-comment {
+  background: #FF9900;
+  font-weight: bold;
+  color: #002090;
+}
+span.alert {
+  color: #D00000;
+}
+#nav table {
+  width: 100%;
+}
+.detail {
+  padding: 0.25em 1em;
+  background: #F4F4F4;
+}
diff --git a/doc/button_background.png b/doc/button_background.png
new file mode 100644
index 000000000..86a3b3086
--- /dev/null
+++ b/doc/button_background.png
diff --git a/doc/code.html b/doc/code.html
index 14bb6f9fe..55afe09af 100644
--- a/doc/code.html
+++ b/doc/code.html
@@ -64,7 +64,7 @@ is illustrated by <a href="../src/pkg/container/vector/Makefile"><code>src/pkg/c
 </p>
 
 <pre>
-include ../../../Make.$(GOARCH)
+include ../../../Make.inc
 
 TARG=container/vector
 GOFILES=\
@@ -80,7 +80,7 @@ Outside the Go source tree (for personal packages), the standard form is
 </p>
 
 <pre>
-include $(GOROOT)/src/Make.$(GOARCH)
+include $(GOROOT)/src/Make.inc
 
 TARG=mypackage
 GOFILES=\
@@ -99,6 +99,14 @@ This makes it easy for programmers to try Go.
 </p>
 
 <p>
+If you have not set <code>$GOROOT</code> in your environment,
+you must run <code>gomake</code> to use this form of makefile.
+<code>Gomake</code> also takes care to invoke GNU Make
+even on systems where it is installed as <code>gmake</code>
+rather than <code>make</code>.
+</p>
+
+<p>
 <code>TARG</code> is the target install path for the package,
 the string that clients will use to import it.
 Inside the Go tree, this string should be the same as the directory
@@ -131,8 +139,8 @@ cd $GOROOT/src/pkg
 </pre>
 <p>
 to update the dependency file <code>Make.deps</code>.
-(This happens automatically each time you run <code>make all</code>
-or <code>make build</code>.)
+(This happens automatically each time you run <code>all.bash</code>
+or <code>make.bash</code>.)
 </p>
 
 <p>
@@ -169,6 +177,32 @@ Writing clean, idiomatic Go code is beyond the scope of this document.
 that topic.
 </p>
 
+<h2 id="Building_programs">Building programs</h2>
+<p>To build a Go program with gomake, create a Makefile alongside your program's
+source files. It should be similar to the example above, but include
+<code>Make.cmd</code> instead of <code>Make.pkg</code>:
+
+<pre>
+include $(GOROOT)/src/Make.inc
+
+TARG=helloworld
+GOFILES=\
+	helloworld.go\
+
+include $(GOROOT)/src/Make.cmd
+</pre>
+
+<p>Running <code>gomake</code> will compile <code>helloworld.go</code>
+and produce an executable named <code>helloworld</code> in the current
+directory.
+</p>
+
+<p>
+Running <code>gomake install</code> will build <code>helloworld</code> if
+necessary and copy it to the <code>$GOBIN</code> directory
+(<code>$GOROOT/bin/</code> is the default).
+</p>
+
 <h2 id="Testing">Testing</h2>
 
 <p>
@@ -259,7 +293,7 @@ Finally, the <code>Makefile</code>:
 </p>
 
 <pre>
-include $(GOROOT)/src/Make.$(GOARCH)
+include $(GOROOT)/src/Make.inc
 
 TARG=numbers
 GOFILES=\
@@ -269,13 +303,13 @@ include $(GOROOT)/src/Make.pkg
 </pre>
 
 <p>
-Running <code>make install</code> will build and install the package to
+Running <code>gomake install</code> will build and install the package to
 the <code>$GOROOT/pkg/</code> directory (it can then be used by any
 program on the system).
 </p>
 
 <p>
-Running <code>make test</code> (or just running the command
+Running <code>gomake test</code> (or just running the command
 <code>gotest</code>) will rebuild the package, including the
 <code>numbers_test.go</code> file, and then run the <code>TestDouble</code>
 function. The output "<code>PASS</code>" indicates that all tests passed
diff --git a/doc/codelab/wiki/Makefile b/doc/codelab/wiki/Makefile
index 76ab5c5bc..e0549fc8e 100644
--- a/doc/codelab/wiki/Makefile
+++ b/doc/codelab/wiki/Makefile
@@ -2,16 +2,11 @@
 # Use of this source code is governed by a BSD-style
 # license that can be found in the LICENSE file.
 
-include ../../../src/Make.$(GOARCH)
+include ../../../src/Make.inc
 
 all: index.html
 
-# ugly hack to deal with whitespaces in $GOROOT
-nullstring :=
-space := $(nullstring) # a space at the end
-QUOTED_GOROOT:=$(subst $(space),\ ,$(GOROOT))
-
-include $(QUOTED_GOROOT)/src/Make.common
+include ../../../src/Make.common
 
 CLEANFILES+=index.html srcextract.bin htmlify.bin
 
@@ -23,7 +18,7 @@ test: final.bin
 	rm -f final.6 final.bin
 
 %.bin: %.$O
-	$(QUOTED_GOBIN)/$(LD) -o $@ $<
-%.$O: 
-	$(QUOTED_GOBIN)/$(GC) $*.go
+	$(LD) -o $@ $<
+%.$O:
+	$(GC) $*.go
 
diff --git a/doc/codelab/wiki/final-noclosure.go b/doc/codelab/wiki/final-noclosure.go
index d4ce71560..2f48565ca 100644
--- a/doc/codelab/wiki/final-noclosure.go
+++ b/doc/codelab/wiki/final-noclosure.go
@@ -27,21 +27,21 @@ func loadPage(title string) (*page, os.Error) {
 	return &page{title: title, body: body}, nil
 }
 
-func viewHandler(c *http.Conn, r *http.Request) {
-	title, err := getTitle(c, r)
+func viewHandler(w http.ResponseWriter, r *http.Request) {
+	title, err := getTitle(w, r)
 	if err != nil {
 		return
 	}
 	p, err := loadPage(title)
 	if err != nil {
-		http.Redirect(c, "/edit/"+title, http.StatusFound)
+		http.Redirect(w, r, "/edit/"+title, http.StatusFound)
 		return
 	}
-	renderTemplate(c, "view", p)
+	renderTemplate(w, "view", p)
 }
 
-func editHandler(c *http.Conn, r *http.Request) {
-	title, err := getTitle(c, r)
+func editHandler(w http.ResponseWriter, r *http.Request) {
+	title, err := getTitle(w, r)
 	if err != nil {
 		return
 	}
@@ -49,11 +49,11 @@ func editHandler(c *http.Conn, r *http.Request) {
 	if err != nil {
 		p = &page{title: title}
 	}
-	renderTemplate(c, "edit", p)
+	renderTemplate(w, "edit", p)
 }
 
-func saveHandler(c *http.Conn, r *http.Request) {
-	title, err := getTitle(c, r)
+func saveHandler(w http.ResponseWriter, r *http.Request) {
+	title, err := getTitle(w, r)
 	if err != nil {
 		return
 	}
@@ -61,21 +61,21 @@ func saveHandler(c *http.Conn, r *http.Request) {
 	p := &page{title: title, body: []byte(body)}
 	err = p.save()
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	http.Redirect(c, "/view/"+title, http.StatusFound)
+	http.Redirect(w, r, "/view/"+title, http.StatusFound)
 }
 
-func renderTemplate(c *http.Conn, tmpl string, p *page) {
+func renderTemplate(w http.ResponseWriter, tmpl string, p *page) {
 	t, err := template.ParseFile(tmpl+".html", nil)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	err = t.Execute(p, c)
+	err = t.Execute(p, w)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 	}
 }
 
@@ -83,10 +83,10 @@ const lenPath = len("/view/")
 
 var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")
 
-func getTitle(c *http.Conn, r *http.Request) (title string, err os.Error) {
+func getTitle(w http.ResponseWriter, r *http.Request) (title string, err os.Error) {
 	title = r.URL.Path[lenPath:]
 	if !titleValidator.MatchString(title) {
-		http.NotFound(c, r)
+		http.NotFound(w, r)
 		err = os.NewError("Invalid Page Title")
 	}
 	return
diff --git a/doc/codelab/wiki/final-noerror.go b/doc/codelab/wiki/final-noerror.go
index 3b699452a..cf4852265 100644
--- a/doc/codelab/wiki/final-noerror.go
+++ b/doc/codelab/wiki/final-noerror.go
@@ -28,21 +28,21 @@ func loadPage(title string) (*page, os.Error) {
 
 const lenPath = len("/view/")
 
-func editHandler(c *http.Conn, r *http.Request) {
+func editHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &page{title: title}
 	}
 	t, _ := template.ParseFile("edit.html", nil)
-	t.Execute(p, c)
+	t.Execute(p, w)
 }
 
-func viewHandler(c *http.Conn, r *http.Request) {
+func viewHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
 	t, _ := template.ParseFile("view.html", nil)
-	t.Execute(p, c)
+	t.Execute(p, w)
 }
 
 func main() {
diff --git a/doc/codelab/wiki/final-parsetemplate.go b/doc/codelab/wiki/final-parsetemplate.go
index 93b956b9d..f02d116b2 100644
--- a/doc/codelab/wiki/final-parsetemplate.go
+++ b/doc/codelab/wiki/final-parsetemplate.go
@@ -27,43 +27,43 @@ func loadPage(title string) (*page, os.Error) {
 	return &page{title: title, body: body}, nil
 }
 
-func viewHandler(c *http.Conn, r *http.Request, title string) {
+func viewHandler(w http.ResponseWriter, r *http.Request, title string) {
 	p, err := loadPage(title)
 	if err != nil {
-		http.Redirect(c, "/edit/"+title, http.StatusFound)
+		http.Redirect(w, r, "/edit/"+title, http.StatusFound)
 		return
 	}
-	renderTemplate(c, "view", p)
+	renderTemplate(w, "view", p)
 }
 
-func editHandler(c *http.Conn, r *http.Request, title string) {
+func editHandler(w http.ResponseWriter, r *http.Request, title string) {
 	p, err := loadPage(title)
 	if err != nil {
 		p = &page{title: title}
 	}
-	renderTemplate(c, "edit", p)
+	renderTemplate(w, "edit", p)
 }
 
-func saveHandler(c *http.Conn, r *http.Request, title string) {
+func saveHandler(w http.ResponseWriter, r *http.Request, title string) {
 	body := r.FormValue("body")
 	p := &page{title: title, body: []byte(body)}
 	err := p.save()
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	http.Redirect(c, "/view/"+title, http.StatusFound)
+	http.Redirect(w, r, "/view/"+title, http.StatusFound)
 }
 
-func renderTemplate(c *http.Conn, tmpl string, p *page) {
+func renderTemplate(w http.ResponseWriter, tmpl string, p *page) {
 	t, err := template.ParseFile(tmpl+".html", nil)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	err = t.Execute(p, c)
+	err = t.Execute(p, w)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 	}
 }
 
@@ -71,14 +71,14 @@ const lenPath = len("/view/")
 
 var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")
 
-func makeHandler(fn func(*http.Conn, *http.Request, string)) http.HandlerFunc {
-	return func(c *http.Conn, r *http.Request) {
+func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
+	return func(w http.ResponseWriter, r *http.Request) {
 		title := r.URL.Path[lenPath:]
 		if !titleValidator.MatchString(title) {
-			http.NotFound(c, r)
+			http.NotFound(w, r)
 			return
 		}
-		fn(c, r, title)
+		fn(w, r, title)
 	}
 }
 
diff --git a/doc/codelab/wiki/final-template.go b/doc/codelab/wiki/final-template.go
index 06c9366ad..0bb133d3a 100644
--- a/doc/codelab/wiki/final-template.go
+++ b/doc/codelab/wiki/final-template.go
@@ -28,32 +28,32 @@ func loadPage(title string) (*page, os.Error) {
 
 const lenPath = len("/view/")
 
-func editHandler(c *http.Conn, r *http.Request) {
+func editHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &page{title: title}
 	}
-	renderTemplate(c, "edit", p)
+	renderTemplate(w, "edit", p)
 }
 
-func viewHandler(c *http.Conn, r *http.Request) {
+func viewHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
-	renderTemplate(c, "view", p)
+	renderTemplate(w, "view", p)
 }
 
-func saveHandler(c *http.Conn, r *http.Request) {
+func saveHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	body := r.FormValue("body")
 	p := &page{title: title, body: []byte(body)}
 	p.save()
-	http.Redirect(c, "/view/"+title, http.StatusFound)
+	http.Redirect(w, r, "/view/"+title, http.StatusFound)
 }
 
-func renderTemplate(c *http.Conn, tmpl string, p *page) {
+func renderTemplate(w http.ResponseWriter, tmpl string, p *page) {
 	t, _ := template.ParseFile(tmpl+".html", nil)
-	t.Execute(p, c)
+	t.Execute(p, w)
 }
 
 func main() {
diff --git a/doc/codelab/wiki/final.go b/doc/codelab/wiki/final.go
index 0186729c2..0c0206bc0 100644
--- a/doc/codelab/wiki/final.go
+++ b/doc/codelab/wiki/final.go
@@ -27,32 +27,32 @@ func loadPage(title string) (*page, os.Error) {
 	return &page{title: title, body: body}, nil
 }
 
-func viewHandler(c *http.Conn, r *http.Request, title string) {
+func viewHandler(w http.ResponseWriter, r *http.Request, title string) {
 	p, err := loadPage(title)
 	if err != nil {
-		http.Redirect(c, "/edit/"+title, http.StatusFound)
+		http.Redirect(w, r, "/edit/"+title, http.StatusFound)
 		return
 	}
-	renderTemplate(c, "view", p)
+	renderTemplate(w, "view", p)
 }
 
-func editHandler(c *http.Conn, r *http.Request, title string) {
+func editHandler(w http.ResponseWriter, r *http.Request, title string) {
 	p, err := loadPage(title)
 	if err != nil {
 		p = &page{title: title}
 	}
-	renderTemplate(c, "edit", p)
+	renderTemplate(w, "edit", p)
 }
 
-func saveHandler(c *http.Conn, r *http.Request, title string) {
+func saveHandler(w http.ResponseWriter, r *http.Request, title string) {
 	body := r.FormValue("body")
 	p := &page{title: title, body: []byte(body)}
 	err := p.save()
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	http.Redirect(c, "/view/"+title, http.StatusFound)
+	http.Redirect(w, r, "/view/"+title, http.StatusFound)
 }
 
 var templates = make(map[string]*template.Template)
@@ -63,10 +63,10 @@ func init() {
 	}
 }
 
-func renderTemplate(c *http.Conn, tmpl string, p *page) {
-	err := templates[tmpl].Execute(p, c)
+func renderTemplate(w http.ResponseWriter, tmpl string, p *page) {
+	err := templates[tmpl].Execute(p, w)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 	}
 }
 
@@ -74,14 +74,14 @@ const lenPath = len("/view/")
 
 var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")
 
-func makeHandler(fn func(*http.Conn, *http.Request, string)) http.HandlerFunc {
-	return func(c *http.Conn, r *http.Request) {
+func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
+	return func(w http.ResponseWriter, r *http.Request) {
 		title := r.URL.Path[lenPath:]
 		if !titleValidator.MatchString(title) {
-			http.NotFound(c, r)
+			http.NotFound(w, r)
 			return
 		}
-		fn(c, r, title)
+		fn(w, r, title)
 	}
 }
 
diff --git a/doc/codelab/wiki/http-sample.go b/doc/codelab/wiki/http-sample.go
index 11d5d7861..33379a1b6 100644
--- a/doc/codelab/wiki/http-sample.go
+++ b/doc/codelab/wiki/http-sample.go
@@ -5,8 +5,8 @@ import (
 	"http"
 )
 
-func handler(c *http.Conn, r *http.Request) {
-	fmt.Fprintf(c, "Hi there, I love %s!", r.URL.Path[1:])
+func handler(w http.ResponseWriter, r *http.Request) {
+	fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])
 }
 
 func main() {
diff --git a/doc/codelab/wiki/index.html b/doc/codelab/wiki/index.html
index 107e49f26..c494a3ced 100644
--- a/doc/codelab/wiki/index.html
+++ b/doc/codelab/wiki/index.html
@@ -1,7 +1,4 @@
-<div class="content">
-
-<h1>Writing Web Applications</h1>
-
+<!-- Codelab: Writing Web Applications -->
 <h2>Introduction</h2>
 
 <p>
@@ -243,8 +240,8 @@ import (
 	&#34;http&#34;
 )
 
-func handler(c *http.Conn, r *http.Request) {
-	fmt.Fprintf(c, &#34;Hi there, I love %s!&#34;, r.URL.Path[1:])
+func handler(w http.ResponseWriter, r *http.Request) {
+	fmt.Fprintf(w, &#34;Hi there, I love %s!&#34;, r.URL.Path[1:])
 }
 
 func main() {
@@ -269,12 +266,12 @@ This function will block until the program is terminated.
 
 <p>
 The function <code>handler</code> is of the type <code>http.HandlerFunc</code>.
-It takes an <code>http.Conn</code> and <code>http.Request</code> as its 
-arguments.
+It takes an <code>http.ResponseWriter</code> and an <code>http.Request</code> as
+its arguments.
 </p>
 
 <p>
-An <code>http.Conn</code> is the server end of an HTTP connection; by writing 
+An <code>http.ResponseWriter</code> value assembles the HTTP server's response; by writing 
 to it, we send data to the HTTP client.
 </p>
 
@@ -317,10 +314,10 @@ Let's create a handler to view a wiki page:
 <pre>
 const lenPath = len(&#34;/view/&#34;)
 
-func viewHandler(c *http.Conn, r *http.Request) {
+func viewHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
-	fmt.Fprintf(c, &#34;&lt;h1&gt;%s&lt;/h1&gt;&lt;div&gt;%s&lt;/div&gt;&#34;, p.title, p.body)
+	fmt.Fprintf(w, &#34;&lt;h1&gt;%s&lt;/h1&gt;&lt;div&gt;%s&lt;/div&gt;&#34;, p.title, p.body)
 }
 </pre>
 
@@ -336,7 +333,7 @@ begin with <code>"/view/"</code>, which is not part of the page title.
 
 <p>
 The function then loads the page data, formats the page with a string of simple 
-HTML, and writes it to <code>c</code>, the <code>http.Conn</code>. 
+HTML, and writes it to <code>w</code>, the <code>http.ResponseWriter</code>. 
 </p>
 
 <p>
@@ -409,13 +406,13 @@ and displays an HTML form.
 </p>
 
 <pre>
-func editHandler(c *http.Conn, r *http.Request) {
+func editHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &amp;page{title: title}
 	}
-	fmt.Fprintf(c, &#34;&lt;h1&gt;Editing %s&lt;/h1&gt;&#34;+
+	fmt.Fprintf(w, &#34;&lt;h1&gt;Editing %s&lt;/h1&gt;&#34;+
 		&#34;&lt;form action=\&#34;/save/%s\&#34; method=\&#34;POST\&#34;&gt;&#34;+
 		&#34;&lt;textarea name=\&#34;body\&#34;&gt;%s&lt;/textarea&gt;&lt;br&gt;&#34;+
 		&#34;&lt;input type=\&#34;submit\&#34; value=\&#34;Save\&#34;&gt;&#34;+
@@ -471,14 +468,14 @@ HTML:
 </p>
 
 <pre>
-func editHandler(c *http.Conn, r *http.Request) {
+func editHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &amp;page{title: title}
 	}
 	t, _ := template.ParseFile(&#34;edit.html&#34;, nil)
-	t.Execute(p, c)
+	t.Execute(p, w)
 }
 </pre>
 
@@ -491,7 +488,7 @@ The function <code>template.ParseFile</code> will read the contents of
 The method <code>t.Execute</code> replaces all occurrences of 
 <code>{title}</code> and <code>{body}</code> with the values of 
 <code>p.title</code> and <code>p.body</code>, and writes the resultant
-HTML to the <code>http.Conn</code>.
+HTML to the <code>http.ResponseWriter</code>.
 </p>
 
 <p>
@@ -526,11 +523,11 @@ Modify <code>viewHandler</code> accordingly:
 </p>
 
 <pre>
-func viewHandler(c *http.Conn, r *http.Request) {
+func viewHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
 	t, _ := template.ParseFile(&#34;view.html&#34;, nil)
-	t.Execute(p, c)
+	t.Execute(p, w)
 }
 </pre>
 
@@ -541,24 +538,24 @@ to its own function:
 </p>
 
 <pre>
-func viewHandler(c *http.Conn, r *http.Request) {
+func viewHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
-	renderTemplate(c, &#34;view&#34;, p)
+	renderTemplate(w, &#34;view&#34;, p)
 }
 
-func editHandler(c *http.Conn, r *http.Request) {
+func editHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &amp;page{title: title}
 	}
-	renderTemplate(c, &#34;edit&#34;, p)
+	renderTemplate(w, &#34;edit&#34;, p)
 }
 
-func renderTemplate(c *http.Conn, tmpl string, p *page) {
+func renderTemplate(w http.ResponseWriter, tmpl string, p *page) {
 	t, _ := template.ParseFile(tmpl+&#34;.html&#34;, nil)
-	t.Execute(p, c)
+	t.Execute(p, w)
 }
 </pre>
 
@@ -576,13 +573,13 @@ redirect the client to the edit page so the content may be created:
 </p>
 
 <pre>
-func viewHandler(c *http.Conn, r *http.Request, title string) {
+func viewHandler(w http.ResponseWriter, r *http.Request, title string) {
 	p, err := loadPage(title)
 	if err != nil {
-		http.Redirect(c, &#34;/edit/&#34;+title, http.StatusFound)
+		http.Redirect(w, r, &#34;/edit/&#34;+title, http.StatusFound)
 		return
 	}
-	renderTemplate(c, &#34;view&#34;, p)
+	renderTemplate(w, &#34;view&#34;, p)
 }
 </pre>
 
@@ -599,12 +596,12 @@ The function <code>saveHandler</code> will handle the form submission.
 </p>
 
 <pre>
-func saveHandler(c *http.Conn, r *http.Request) {
+func saveHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	body := r.FormValue(&#34;body&#34;)
 	p := &amp;page{title: title, body: []byte(body)}
 	p.save()
-	http.Redirect(c, &#34;/view/&#34;+title, http.StatusFound)
+	http.Redirect(w, r, &#34;/view/&#34;+title, http.StatusFound)
 }
 </pre>
 
@@ -637,15 +634,15 @@ First, let's handle the errors in <code>renderTemplate</code>:
 </p>
 
 <pre>
-func renderTemplate(c *http.Conn, tmpl string, p *page) {
+func renderTemplate(w http.ResponseWriter, tmpl string, p *page) {
 	t, err := template.ParseFile(tmpl+&#34;.html&#34;, nil)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	err = t.Execute(p, c)
+	err = t.Execute(p, w)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 	}
 }
 </pre>
@@ -661,15 +658,15 @@ Now let's fix up <code>saveHandler</code>:
 </p>
 
 <pre>
-func saveHandler(c *http.Conn, r *http.Request, title string) {
+func saveHandler(w http.ResponseWriter, r *http.Request, title string) {
 	body := r.FormValue(&#34;body&#34;)
 	p := &amp;page{title: title, body: []byte(body)}
 	err := p.save()
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	http.Redirect(c, &#34;/view/&#34;+title, http.StatusFound)
+	http.Redirect(w, r, &#34;/view/&#34;+title, http.StatusFound)
 }
 </pre>
 
@@ -728,10 +725,10 @@ the <code>Execute</code> method on the appropriate <code>Template</code> from
 <code>templates</code>:
 
 <pre>
-func renderTemplate(c *http.Conn, tmpl string, p *page) {
-	err := templates[tmpl].Execute(p, c)
+func renderTemplate(w http.ResponseWriter, tmpl string, p *page) {
+	err := templates[tmpl].Execute(p, w)
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 	}
 }
 </pre>
@@ -768,10 +765,10 @@ URL, and tests it against our <code>titleValidator</code> expression:
 </p>
 
 <pre>
-func getTitle(c *http.Conn, r *http.Request) (title string, err os.Error) {
+func getTitle(w http.ResponseWriter, r *http.Request) (title string, err os.Error) {
 	title = r.URL.Path[lenPath:]
 	if !titleValidator.MatchString(title) {
-		http.NotFound(c, r)
+		http.NotFound(w, r)
 		err = os.NewError(&#34;Invalid Page Title&#34;)
 	}
 	return
@@ -790,21 +787,21 @@ Let's put a call to <code>getTitle</code> in each of the handlers:
 </p>
 
 <pre>
-func viewHandler(c *http.Conn, r *http.Request) {
-	title, err := getTitle(c, r)
+func viewHandler(w http.ResponseWriter, r *http.Request) {
+	title, err := getTitle(w, r)
 	if err != nil {
 		return
 	}
 	p, err := loadPage(title)
 	if err != nil {
-		http.Redirect(c, &#34;/edit/&#34;+title, http.StatusFound)
+		http.Redirect(w, r, &#34;/edit/&#34;+title, http.StatusFound)
 		return
 	}
-	renderTemplate(c, &#34;view&#34;, p)
+	renderTemplate(w, &#34;view&#34;, p)
 }
 
-func editHandler(c *http.Conn, r *http.Request) {
-	title, err := getTitle(c, r)
+func editHandler(w http.ResponseWriter, r *http.Request) {
+	title, err := getTitle(w, r)
 	if err != nil {
 		return
 	}
@@ -812,11 +809,11 @@ func editHandler(c *http.Conn, r *http.Request) {
 	if err != nil {
 		p = &amp;page{title: title}
 	}
-	renderTemplate(c, &#34;edit&#34;, p)
+	renderTemplate(w, &#34;edit&#34;, p)
 }
 
-func saveHandler(c *http.Conn, r *http.Request) {
-	title, err := getTitle(c, r)
+func saveHandler(w http.ResponseWriter, r *http.Request) {
+	title, err := getTitle(w, r)
 	if err != nil {
 		return
 	}
@@ -824,10 +821,10 @@ func saveHandler(c *http.Conn, r *http.Request) {
 	p := &amp;page{title: title, body: []byte(body)}
 	err = p.save()
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	http.Redirect(c, &#34;/view/&#34;+title, http.StatusFound)
+	http.Redirect(w, r, &#34;/view/&#34;+title, http.StatusFound)
 }
 </pre>
 
@@ -848,9 +845,9 @@ a title string:
 </p>
 
 <pre>
-func viewHandler(c *http.Conn, r *http.Request, title string)
-func editHandler(c *http.Conn, r *http.Request, title string)
-func saveHandler(c *http.Conn, r *http.Request, title string)
+func viewHandler(w http.ResponseWriter, r *http.Request, title string)
+func editHandler(w http.ResponseWriter, r *http.Request, title string)
+func saveHandler(w http.ResponseWriter, r *http.Request, title string)
 </pre>
 
 <p>
@@ -860,8 +857,8 @@ type</i>, and returns a function of type <code>http.HandlerFunc</code>
 </p>
 
 <pre>
-func makeHandler(fn func (*http.Conn, *http.Request, string)) http.HandlerFunc {
-	return func(c *http.Conn, r *http.Request) {
+func makeHandler(fn func (http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
+	return func(w http.ResponseWriter, r *http.Request) {
 		// Here we will extract the page title from the Request,
 		// and call the provided handler 'fn'
 	}
@@ -881,28 +878,28 @@ Now we can take the code from <code>getTitle</code> and use it here
 </p>
 
 <pre>
-func makeHandler(fn func(*http.Conn, *http.Request, string)) http.HandlerFunc {
-	return func(c *http.Conn, r *http.Request) {
+func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
+	return func(w http.ResponseWriter, r *http.Request) {
 		title := r.URL.Path[lenPath:]
 		if !titleValidator.MatchString(title) {
-			http.NotFound(c, r)
+			http.NotFound(w, r)
 			return
 		}
-		fn(c, r, title)
+		fn(w, r, title)
 	}
 }
 </pre>
 
 <p>
 The closure returned by <code>makeHandler</code> is a function that takes
-an <code>http.Conn</code> and <code>http.Request</code> (in other words,
-an <code>http.HandlerFunc</code>). 
+an <code>http.ResponseWriter</code> and <code>http.Request</code> (in other
+words, an <code>http.HandlerFunc</code>). 
 The closure extracts the <code>title</code> from the request path, and
 validates it with the <code>titleValidator</code> regexp. If the
 <code>title</code> is invalid, an error will be written to the
-<code>Conn</code> using the <code>http.NotFound</code> function. 
+<code>ResponseWriter</code> using the <code>http.NotFound</code> function. 
 If the <code>title</code> is valid, the enclosed handler function
-<code>fn</code> will be called with the <code>Conn</code>,
+<code>fn</code> will be called with the <code>ResponseWriter</code>,
 <code>Request</code>, and <code>title</code> as arguments.
 </p>
 
@@ -927,32 +924,32 @@ making them much simpler:
 </p>
 
 <pre>
-func viewHandler(c *http.Conn, r *http.Request, title string) {
+func viewHandler(w http.ResponseWriter, r *http.Request, title string) {
 	p, err := loadPage(title)
 	if err != nil {
-		http.Redirect(c, &#34;/edit/&#34;+title, http.StatusFound)
+		http.Redirect(w, r, &#34;/edit/&#34;+title, http.StatusFound)
 		return
 	}
-	renderTemplate(c, &#34;view&#34;, p)
+	renderTemplate(w, &#34;view&#34;, p)
 }
 
-func editHandler(c *http.Conn, r *http.Request, title string) {
+func editHandler(w http.ResponseWriter, r *http.Request, title string) {
 	p, err := loadPage(title)
 	if err != nil {
 		p = &amp;page{title: title}
 	}
-	renderTemplate(c, &#34;edit&#34;, p)
+	renderTemplate(w, &#34;edit&#34;, p)
 }
 
-func saveHandler(c *http.Conn, r *http.Request, title string) {
+func saveHandler(w http.ResponseWriter, r *http.Request, title string) {
 	body := r.FormValue(&#34;body&#34;)
 	p := &amp;page{title: title, body: []byte(body)}
 	err := p.save()
 	if err != nil {
-		http.Error(c, err.String(), http.StatusInternalServerError)
+		http.Error(w, err.String(), http.StatusInternalServerError)
 		return
 	}
-	http.Redirect(c, &#34;/view/&#34;+title, http.StatusFound)
+	http.Redirect(w, r, &#34;/view/&#34;+title, http.StatusFound)
 }
 </pre>
 
@@ -996,5 +993,3 @@ Here are some simple tasks you might want to tackle on your own:
 	(hint: you could use <code>regexp.ReplaceAllFunc</code> to do this)
 	</li>
 </ul>
-
-</div>
diff --git a/doc/codelab/wiki/notemplate.go b/doc/codelab/wiki/notemplate.go
index a61d905e3..c1f952c83 100644
--- a/doc/codelab/wiki/notemplate.go
+++ b/doc/codelab/wiki/notemplate.go
@@ -28,19 +28,19 @@ func loadPage(title string) (*page, os.Error) {
 
 const lenPath = len("/view/")
 
-func viewHandler(c *http.Conn, r *http.Request) {
+func viewHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
-	fmt.Fprintf(c, "<h1>%s</h1><div>%s</div>", p.title, p.body)
+	fmt.Fprintf(w, "<h1>%s</h1><div>%s</div>", p.title, p.body)
 }
 
-func editHandler(c *http.Conn, r *http.Request) {
+func editHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &page{title: title}
 	}
-	fmt.Fprintf(c, "<h1>Editing %s</h1>"+
+	fmt.Fprintf(w, "<h1>Editing %s</h1>"+
 		"<form action=\"/save/%s\" method=\"POST\">"+
 		"<textarea name=\"body\">%s</textarea><br>"+
 		"<input type=\"submit\" value=\"Save\">"+
diff --git a/doc/codelab/wiki/part2.go b/doc/codelab/wiki/part2.go
index c2c29dc3b..8d4454a74 100644
--- a/doc/codelab/wiki/part2.go
+++ b/doc/codelab/wiki/part2.go
@@ -28,10 +28,10 @@ func loadPage(title string) (*page, os.Error) {
 
 const lenPath = len("/view/")
 
-func viewHandler(c *http.Conn, r *http.Request) {
+func viewHandler(w http.ResponseWriter, r *http.Request) {
 	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
-	fmt.Fprintf(c, "<h1>%s</h1><div>%s</div>", p.title, p.body)
+	fmt.Fprintf(w, "<h1>%s</h1><div>%s</div>", p.title, p.body)
 }
 
 func main() {
diff --git a/doc/codelab/wiki/srcextract.go b/doc/codelab/wiki/srcextract.go
index 607375183..0addc61c4 100644
--- a/doc/codelab/wiki/srcextract.go
+++ b/doc/codelab/wiki/srcextract.go
@@ -25,7 +25,7 @@ func main() {
 		os.Exit(2)
 	}
 	// load file
-	file, err := parser.ParseFile(*srcFn, nil, nil, 0)
+	file, err := parser.ParseFile(*srcFn, nil, 0)
 	if err != nil {
 		log.Exit(err)
 	}
diff --git a/doc/codelab/wiki/wiki.html b/doc/codelab/wiki/wiki.html
index c7f44ded4..919385edf 100644
--- a/doc/codelab/wiki/wiki.html
+++ b/doc/codelab/wiki/wiki.html
@@ -1,7 +1,4 @@
-<div class="content">
-
-<h1>Writing Web Applications</h1>
-
+<!-- Codelab: Writing Web Applications -->
 <h2>Introduction</h2>
 
 <p>
@@ -233,12 +230,12 @@ This function will block until the program is terminated.
 
 <p>
 The function <code>handler</code> is of the type <code>http.HandlerFunc</code>.
-It takes an <code>http.Conn</code> and <code>http.Request</code> as its 
-arguments.
+It takes an <code>http.ResponseWriter</code> and an <code>http.Request</code> as
+its arguments.
 </p>
 
 <p>
-An <code>http.Conn</code> is the server end of an HTTP connection; by writing 
+An <code>http.ResponseWriter</code> value assembles the HTTP server's response; by writing 
 to it, we send data to the HTTP client.
 </p>
 
@@ -296,7 +293,7 @@ begin with <code>"/view/"</code>, which is not part of the page title.
 
 <p>
 The function then loads the page data, formats the page with a string of simple 
-HTML, and writes it to <code>c</code>, the <code>http.Conn</code>. 
+HTML, and writes it to <code>w</code>, the <code>http.ResponseWriter</code>. 
 </p>
 
 <p>
@@ -418,7 +415,7 @@ The function <code>template.ParseFile</code> will read the contents of
 The method <code>t.Execute</code> replaces all occurrences of 
 <code>{title}</code> and <code>{body}</code> with the values of 
 <code>p.title</code> and <code>p.body</code>, and writes the resultant
-HTML to the <code>http.Conn</code>.
+HTML to the <code>http.ResponseWriter</code>.
 </p>
 
 <p>
@@ -670,9 +667,9 @@ a title string:
 </p>
 
 <pre>
-func viewHandler(c *http.Conn, r *http.Request, title string)
-func editHandler(c *http.Conn, r *http.Request, title string)
-func saveHandler(c *http.Conn, r *http.Request, title string)
+func viewHandler(w http.ResponseWriter, r *http.Request, title string)
+func editHandler(w http.ResponseWriter, r *http.Request, title string)
+func saveHandler(w http.ResponseWriter, r *http.Request, title string)
 </pre>
 
 <p>
@@ -682,8 +679,8 @@ type</i>, and returns a function of type <code>http.HandlerFunc</code>
 </p>
 
 <pre>
-func makeHandler(fn func (*http.Conn, *http.Request, string)) http.HandlerFunc {
-	return func(c *http.Conn, r *http.Request) {
+func makeHandler(fn func (http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
+	return func(w http.ResponseWriter, r *http.Request) {
 		// Here we will extract the page title from the Request,
 		// and call the provided handler 'fn'
 	}
@@ -708,14 +705,14 @@ Now we can take the code from <code>getTitle</code> and use it here
 
 <p>
 The closure returned by <code>makeHandler</code> is a function that takes
-an <code>http.Conn</code> and <code>http.Request</code> (in other words,
-an <code>http.HandlerFunc</code>). 
+an <code>http.ResponseWriter</code> and <code>http.Request</code> (in other
+words, an <code>http.HandlerFunc</code>). 
 The closure extracts the <code>title</code> from the request path, and
 validates it with the <code>titleValidator</code> regexp. If the
 <code>title</code> is invalid, an error will be written to the
-<code>Conn</code> using the <code>http.NotFound</code> function. 
+<code>ResponseWriter</code> using the <code>http.NotFound</code> function. 
 If the <code>title</code> is valid, the enclosed handler function
-<code>fn</code> will be called with the <code>Conn</code>,
+<code>fn</code> will be called with the <code>ResponseWriter</code>,
 <code>Request</code>, and <code>title</code> as arguments.
 </p>
 
@@ -782,5 +779,3 @@ Here are some simple tasks you might want to tackle on your own:
 	(hint: you could use <code>regexp.ReplaceAllFunc</code> to do this)
 	</li>
 </ul>
-
-</div>
diff --git a/doc/codereview_with_mq.html b/doc/codereview_with_mq.html
index 7b2e0f3bf..33f415f13 100644
--- a/doc/codereview_with_mq.html
+++ b/doc/codereview_with_mq.html
@@ -36,11 +36,11 @@ prevent that case:
 <pre>
 [hooks]
 # Prevent "hg pull" if MQ patches are applied.
-prechangegroup.mq-no-pull = ! hg qtop > /dev/null 2>&1
+prechangegroup.mq-no-pull = ! hg qtop > /dev/null 2>&amp;1
 # Prevent "hg push" if MQ patches are applied.
-preoutgoing.mq-no-push = ! hg qtop > /dev/null 2>&1
+preoutgoing.mq-no-push = ! hg qtop > /dev/null 2>&amp;1
 # Prevent "hg update" if MQ patches are applied.
-preupdate.mq-no-update = ! hg qtop > /dev/null 2>&1
+preupdate.mq-no-update = ! hg qtop > /dev/null 2>&amp;1
 </pre>
 
 <h2>Making a change</h2>
diff --git a/doc/codewalk/urlpoll.go b/doc/codewalk/urlpoll.go
index 2629f2b68..b51be9502 100644
--- a/doc/codewalk/urlpoll.go
+++ b/doc/codewalk/urlpoll.go
@@ -52,9 +52,9 @@ func StateMonitor(updateInterval int64) chan<- State {
 
 // logState prints a state map.
 func logState(s map[string]string) {
-	log.Stdout("Current state:")
+	log.Println("Current state:")
 	for k, v := range s {
-		log.Stdoutf(" %s %s", k, v)
+		log.Printf(" %s %s", k, v)
 	}
 }
 
@@ -69,7 +69,7 @@ type Resource struct {
 func (r *Resource) Poll() string {
 	resp, err := http.Head(r.url)
 	if err != nil {
-		log.Stderr("Error", r.url, err)
+		log.Println("Error", r.url, err)
 		r.errCount++
 		return err.String()
 	}
diff --git a/doc/community.html b/doc/community.html
new file mode 100644
index 000000000..c3b16cacb
--- /dev/null
+++ b/doc/community.html
@@ -0,0 +1,53 @@
+<!-- title Community -->
+
+<div class="left-column">
+
+<h2 id="developer_info">The Go Community</h2>
+
+<h3 id="mailinglist"><a href="http://groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
+<p>The <a href="http://groups.google.com/group/golang-nuts">golang-nuts</a> 
+mailing list is for general Go discussion.</p>
+
+<h3 id=""><a href="http://godashboard.appspot.com/package">Go Packages Dashboard</a></h3>
+<p>A list of the most popular <a href="/cmd/goinstall/">goinstall</a>'d
+Go libraries.</p>
+
+<h3 id=""><a href="http://godashboard.appspot.com/project">Go Project Dashboard</a></h3>
+<p>A list of external Go projects including programs and libraries.</p>
+
+<h3 id="irc"><a href="irc:irc.freenode.net/go-nuts">Go IRC Channel</a></h3>
+<p><b>#go-nuts</b> on <b>irc.freenode.net</b> is the official Go IRC channel.</p>
+
+<h3 id="twitter"><a href="http://twitter.com/go_nuts">@go_nuts at Twitter</a></h3>
+<p>The Go project's official Twitter account.</p>
+
+</div>
+
+<div class="right-column">
+
+<h2 id="blogs">Blogs</h2>
+
+<h3 id="blog_go"><a href="http://blog.golang.org/">The Go Blog</a></h3>
+<p>
+The Go project's official blog, maintained by the core Go developers.
+</p>
+
+<h3 id="blog_rsc"><a href="http://research.swtch.com/search/label/Go">research!rsc</a></h3>
+<p>
+Posts labelled 'Go' by Russ Cox, one of the core Go developers.
+</p>
+
+<h3 id="blog_iant"><a href="http://www.airs.com/blog/archives/category/programming">Airs</a></h3>
+<p>
+Posts labelled 'Programming' by Ian Lance Taylor, one of the core Go developers.
+</p>
+
+<h3 id="blog_adg"><a href="http://nf.id.au/tag/go">nf.id.au</a></h3>
+<p>
+Posts labelled 'Go' by Andrew Gerrand, one of the core Go developers.
+</p>
+
+</div>
+
+<div class="end-columns"></div>
+
diff --git a/doc/contrib.html b/doc/contrib.html
new file mode 100644
index 000000000..121cc45dc
--- /dev/null
+++ b/doc/contrib.html
@@ -0,0 +1,45 @@
+<!-- title Contributing -->
+
+<div class="left-column">
+
+<h2 id="developer_info">Resources for Developers</h2>
+
+<h3 id="issuetracker"><a href="http://code.google.com/p/go/issues">Issue Tracker</a></h3>
+<p>Having an issue with Go? Check the tracker to see if it's a known issue.</p>
+<p>If your issue is not listed, please file a <a
+href="http://code.google.com/p/go/issues/entry">bug report</a>.</p>
+
+<h3 id="build_status"><a href="http://godashboard.appspot.com/">Build Status</a></h3>
+<p>View the status of Go builds across the supported operating
+systems and architectures.</p>
+
+<h3 id="contibute"><a href="contribute.html">Contribution Guidelines</a></h3>
+<p>So, you want to contribute code to the Go project? That's great!</p>
+<p>The first step is to read these contributions guidelines for information on 
+design, testing, and our code review process.</p>
+
+</div>
+
+<div class="right-column">
+
+<h2 id="">The Go Project</h2>
+
+<h3 id="roadmap"><a href="devel/roadmap.html">Roadmap</a></h3>
+<p>Features and ideas being developed or discussed by the Go team.</p>
+
+<h3 id="release"><a href="devel/release.html">Release History</a></h3>
+<p>A summarization of the changes between tagged releases of Go.</p>
+
+<h3 id="golang-dev"><a href="http://groups.google.com/group/golang-dev">Developer Mailing List</a></h3>
+<p>The <a href="http://groups.google.com/group/golang-dev">golang-dev</a>
+mailing list is for discussing and reviewing code for the Go project.</p>
+<p>For general discussion of Go programming, see <a
+href="http://groups.google.com/group/golang-nuts">golang-nuts</a>.</p>
+
+<h3 id="golang-checkins"><a href="http://groups.google.com/group/golang-checkins">Checkins Mailing List</a></h3>
+<p>A mailing list that receives a message summarizing each checkin to the Go repository.</p>
+
+</div>
+
+<div class="end-columns"></div>
+
diff --git a/doc/contribute.html b/doc/contribute.html
index 6814274ba..ba70c9600 100644
--- a/doc/contribute.html
+++ b/doc/contribute.html
@@ -1,4 +1,4 @@
-<!-- Contributing to the Go project -->
+<!-- Contribution Guidelines -->
 
 <h2 id="Introduction">Introduction</h2>
 
@@ -218,9 +218,9 @@ mailing list.
 <p>
 Replace &ldquo;<code>&lt;enter description here&gt;</code>&rdquo;
 with a description of your change.
-The first line of the change description is conventionally
-a one-line summary of the change and is used as the
-subject for code review mail; the rest of the
+The first line of the change description is conventionally a one-line
+summary of the change, prefixed by the primary affected package,
+and is used as the subject for code review mail; the rest of the
 description elaborates.
 </p>
 
@@ -245,7 +245,7 @@ Reviewer: golang-dev@googlegroups.com
 CC: math-nuts@swtch.com
 
 Description:
-	Sin, Cos, Tan: improved precision for very large arguments
+	math: improved Sin, Cos and Tan precision for very large arguments.
 
 	See Bimmler and Shaney, ``Extreme sinusoids,'' J. Math 3(14).
 	Fixes issue 159.
@@ -522,7 +522,7 @@ This rigmarole needs to be done only for your first submission.
 <p>Code that you contribute should use the standard copyright header:</p>
 
 <pre>
-// Copyright 2010 The Go Authors. All rights reserved.
+// Copyright 2011 The Go Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 </pre>
diff --git a/doc/devel/release.html b/doc/devel/release.html
index 39c521c1e..ecf125953 100644
--- a/doc/devel/release.html
+++ b/doc/devel/release.html
@@ -5,6 +5,1149 @@
 <p>This page summarizes the changes between tagged releases of Go.
 For full details, see the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>.</p>
 
+<h3 id="2011-01-12">2011-01-12</h3>
+
+<pre>
+The json, gob, and template packages have changed, and code that uses them
+may need to be updated after this release. They will no longer read or write
+unexported struct fields. When marshalling a struct with json or gob the
+unexported fields will be silently ignored. Attempting to unmarshal json or
+gob data into an unexported field will generate an error. Accessing an
+unexported field from a template will cause the Execute function to return
+an error.
+
+Godoc now supports regular expression full text search, and this
+functionality is now available on golang.org.
+
+Other changes:
+* arm: initial cut at arm optimizer.
+* bytes.Buffer: Fix bug in UnreadByte.
+* cgo: export unsafe.Pointer as void*, fix enum const conflict,
+        output alignment fix (thanks Gustavo Niemeyer).
+* crypto/block: mark as deprecated.
+* crypto/openpgp: add error and armor.
+* crypto: add twofish package (thanks Berengar Lehr).
+* doc/spec: remove Maxalign from spec.
+* encoding/line: new package for reading lines from an io.Reader.
+* go/ast: correct end position for Index and TypeAssert expressions.
+* gob: make (en|dec)code(Ui|I)nt methods rather than functions.
+* godefs: better handling of enums.
+* gofmt: don't attempt certain illegal rewrites,
+        rewriter matches apply to expressions only.
+* goinstall: preliminary support for cgo packages (thanks Gustavo Niemeyer).
+* hg: add cgo/_cgo_* to .hgignore.
+* http: fix text displayed in Redirect.
+* ld: fix exported dynamic symbols on Mach-O,
+        permit a Mach-O symbol to be exported in the dynamic symbol table.
+* log: add methods for exit and panic.
+* net: use closesocket api instead of CloseHandle on Windows (thanks Alex Brainman).
+* netchan: make fields exported for gob change.
+* os: add Sync to *File, wraps syscall.Fsync.
+* runtime/cgo: Add callbacks to support SWIG.
+* runtime: Restore scheduler stack position if cgo callback panics.
+* suffixarray: faster creation algorithm (thanks Eric Eisner).
+* syscall: fix mksysnum_linux.sh (thanks Anthony Martin).
+* time.NewTicker: panic for intervals <= 0.
+* time: add AfterFunc to call a function after a duration (thanks Roger Peppe),
+        fix tick accuracy when using multiple Tickers (thanks Eoghan Sherry).</pre>
+
+<h3 id="2011-01-06">2011-01-06</h3>
+
+<pre>
+This release includes several fixes and changes:
+
+* build: Make.pkg: use installed runtime.h for cgo.
+* cgo: disallow use of C.errno.
+* crypto/cipher: fix OCFB,
+        make NewCBCEncrypter return BlockMode.
+* doc: 6l: fix documentation of -L flag,
+        add golanguage.ru to foreign-language doc list,
+        effective go: explain the effect of repanicking better,
+        update Effective Go for template API change,
+        update contribution guidelines to prefix the change description.
+* encoding/binary: reject types with implementation-dependent sizes (thanks Patrick Gavlin).
+* exp/evalsimple fix handling of slices like s[:2] (thanks Sebastien Binet).
+* fmt: made format string handling more efficient,
+        normalize processing of format string.
+* gc: return constant floats for parts of complex constants (thanks Anthony Martin),
+        rewrite complex /= to l = l / r (thanks Patrick Gavlin),
+        fix &^=.
+* go/ast: provide complete node text range info.
+* gob: generate a better error message in one confusing place.
+* godoc: fix godoc -src (thanks Icarus Sparry).
+* goinstall: add -clean flag (thanks Kyle Lemons),
+        add checkout concept (thanks Caine Tighe),
+        fix -u for bzr (thanks Gustavo Niemeyer).
+* http: permit empty Reason-Phrase in response Status-Line.
+* io: fix Copyn EOF handling.
+* net: fix close of Listener (thanks Michael Hoisie).
+* regexp: fix performance bug, make anchored searches fail fast,
+        fix prefix bug.
+* runtime/cgo: fix stackguard on FreeBSD/amd64 (thanks Anthony Martin).
+* strconv: atof: added 'E' as valid token for exponent (thanks Stefan Nilsson),
+        update ftoa comment for 'E' and 'G'.
+* strings: fix description of FieldsFunc (thanks Roger Peppe).
+* syscall: correct Linux Splice definition,
+        make Access second argument consistently uint32.
+</pre>
+
+<h3 id="2010-12-22">2010-12-22</h3>
+
+<pre>
+A small release this week. The most significant change is that some 
+outstanding cgo issues were resolved.
+
+* cgo: handle references to symbols in shared libraries.
+* crypto/elliptic: add serialisation and key pair generation.
+* crypto/hmac: add HMAC-SHA256 (thanks Anthony Martin).
+* crypto/tls: add ECDHE support ("Elliptic Curve Diffie Hellman Ephemeral"),
+        add support code for generating handshake scripts for testing.
+* darwin, freebsd: ignore write failure (during print, panic).
+* exp/draw: remove Border function.
+* expvar: quote StringFunc output, same as String output.
+* hash/crc64: fix typo in Sum.
+* ld: allow relocations pointing at ELF .bss symbols, ignore stab symbols.
+* misc/cgo/life: fix, add to build.
+* regexp: add HasMeta, HasOperator, and String methods to Regexp.
+* suffixarray: implemented FindAllIndex regexp search.
+* test/bench: update numbers for regex-dna after speedup to regexp.
+* time: explain the formats a little better.
+</pre>
+
+<h3 id="2010-12-15">2010-12-15</h3>
+
+<pre>
+Package crypto/cipher has been started, to replace crypto/block.
+As part of the changes, rc4.Cipher’s XORKeyStream method signature has changed from
+        XORKeyStream(buf []byte)
+to
+        XORKeyStream(dst, src []byte)
+to implement the cipher.Stream interface.  If you use crypto/block, you’ll need
+to switch to crypto/cipher once it is complete.
+
+Package smtp’s StartTLS now takes a *tls.Config argument.
+
+Package reflect’s ArrayCopy has been renamed to Copy.  There are new functions
+Append and AppendSlice.
+
+The print/println bootstrapping functions now write to standard error.
+To write to standard output, use fmt.Print[ln].
+
+A new tool, govet, has been added to the Go distribution. Govet is a static
+checker for Go programs. At the moment, and for the forseeable future,
+it only checks arguments to print calls.
+
+The cgo tool for writing Go bindings for C code has changed so that it no
+longer uses stub .so files (like cgo_stdio.so).  Cgo-based packages using the
+standard Makefiles should build without any changes.  Any alternate build
+mechanisms will need to be updated.
+
+The C and Go compilers (6g, 6c, 8g, 8c, 5g, 5c) now align structs according to
+the maximum alignment of the fields they contain; previously they aligned
+structs to word boundaries.  This may break non-cgo-based code that attempts to
+mix C and Go.
+
+NaCl support has been removed. The recent linker changes broke NaCl support
+a month ago, and there are no known users of it.
+If necessary, the NaCl code can be recovered from the repository history.
+
+* 5g/8g, 8l, ld, prof: fix output of 32-bit values (thanks Eoghan Sherry).
+* [68]l and runtime: GDB support for interfaces and goroutines.
+* 6l, 8l: support for linking ELF and Mach-O .o files.
+* all: simplify two-variable ranges with unused second variable (thanks Ryan Hitchman).
+* arm: updated soft float support.
+* codereview: keep quiet when not in use (thanks Eoghan Sherry).
+* compress/flate: implement Flush, equivalent to zlib's Z_SYNC_FLUSH.
+* crypto/tls: use rand.Reader in cert generation example (thanks Anthony Martin).
+* dashboard: fix project tag filter.
+* debug/elf, debug/macho: add ImportedLibraries, ImportedSymbols.
+* doc/go_mem: goroutine exit is not special.
+* event.go: another print glitch from gocheck.
+* gc: bug fixes,
+        syntax error for incomplete chan type (thanks Ryan Hitchman).
+* go/ast: fix ast.Walk.
+* gob: document the byte count used in the encoding of values,
+        fix bug sending zero-length top-level slices and maps,
+        Register should use the original type, not the indirected one.
+* godashboard: support submitting projects with non-ascii names (thanks Ryan Hitchman)
+* godefs: guard against structs with pad fields
+* godoc: added textual search, to enable use -fulltext flag.
+* gofmt: simplify "x, _ = range y" to "x = range y".
+* gopack: allow ELF/Mach-O objects in .a files without clearing allobj.
+* go/token,scanner: fix comments so godoc aligns properly.
+* govet: on error continue to the next file (thanks Christopher Wedgwood).
+* html: improved parsing.
+* http: ServeFile handles Range header for partial requests.
+* json: check for invalid UTF-8.
+* ld: allow .o files with no symbols,
+        reading of ELF object files,
+        reading of Mach-O object files.
+* math: change float64 bias constant from 1022 to 1023 (thanks Eoghan Sherry),
+        rename the MinFloat constant to SmallestNonzeroFloat.
+* nm: silently ignore .o files in .a files.
+* os: fix test of RemoveAll.
+* os/inotify: new package (thanks Balazs Lecz).
+* os: make MkdirAll work with symlinks (thanks Ryan Hitchman).
+* regexp: speed up by about 30%; also simplify code for brackets.
+* runtime/linux/386: set FPU to 64-bit precision.
+* runtime: remove paranoid mapping at 0.
+* suffixarray: add Bytes function.
+* syscall: add network interface constants for linux/386, linux/amd64 (thanks Mikio Hara).
+* syscall/windows: restrict access rights param of OpenProcess(),
+        remove \r and \n from error messages (thanks Alex Brainman).
+* test/bench: fixes to timing.sh (thanks Anthony Martin).
+* time: fix bug in Ticker: shutdown using channel rather than memory.
+* token/position: provide FileSet.File, provide files iterator.
+* xml: disallow invalid Unicode code points (thanks Nigel Kerr).
+</pre>
+
+<h3 id="2010-12-08">2010-12-08</h3>
+
+<pre>
+This release includes some package changes. If you use the crypto/tls or
+go/parser packages your code may require changes.
+
+The crypto/tls package's Dial function now takes an additional *Config
+argument.  Most uses will pass nil to get the same default behavior as before.
+See the documentation for details:
+        http://golang.org/pkg/crypto/tls/#Config
+        http://golang.org/pkg/crypto/tls/#Dial
+
+The go/parser package's ParseFile function now takes a *token.FileSet as its
+first argument. This is a pointer to a data structure used to store
+position information. If you don't care about position information you
+can pass "token.NewFileSet()". See the documentation for details:
+        http://golang.org/pkg/go/parser/#ParseFile
+
+This release also splits the patent grant text out of the LICENSE file into a
+separate PATENTS file and changes it to be more like the WebM grant.
+These clarifications were made at the request of the Fedora project.
+
+Other changes:
+* [68]l: generate debug info for builtin structured types, prettyprinting in gdb.
+* 8l: add dynimport to import table in Windows PE (thanks Wei Guangjing).
+* 8l, runtime: fix Plan 9 386 build (thanks Yuval Pavel Zholkover).
+* all: fix broken calls to Printf etc.
+* bufio: make Reader.Read implement io.Reader semantics (thanks Roger Peppe).
+* build: allow archiver to be specified by HOST_AR (thanks Albert Strasheim).
+* bytes: add Buffer.UnreadRune, Buffer.UnreadByte (thanks Roger Peppe).
+* crypto/tls: fix build of certificate generation example (thanks Christian Himpel).
+* doc/install: describe GOHOSTOS and GOHOSTARCH.
+* errchk: accept multiple source files (thanks Eoghan Sherry).
+* exec.LookPath: return os.PathError instad of os.ENOENT (thanks Michael Hoisie)..
+* flag: fix format error in boolean error report,
+        handle multiple calls to flag.Parse.
+* fmt: add %U format for standard Unicode representation of code point values.
+* gc: fix method offsets of anonymous interfaces (thanks Eoghan Sherry),
+        skip undefined symbols in import . (thanks Eoghan Sherry).
+* go/scanner: remove Tokenize - was only used in tests
+* gobuilder: add buildroot command-line flag (thanks Devon H. O'Dell).
+* html: unescape numeric entities (thanks Ryan Hitchman).
+* http: Add EncodeQuery, helper for constructing query strings.
+* ld: fix dwarf decoding of 64-bit reflect values (thanks Eoghan Sherry).
+* math: improve accuracy of Exp2 (thanks Eoghan Sherry).
+* runtime: add Goroutines (thanks Keith Rarick).
+* sync: small naming fix for armv5 (thanks Dean Prichard).
+* syscall, net: Add Recvmsg and Sendmsg on Linux (thanks Albert Strasheim).
+* time: make After use fewer goroutines and host processes (thanks Roger Peppe).
+</pre>
+
+<h3 id="2010-12-02">2010-12-02</h3>
+
+<pre>
+Several package changes in this release may require you to update your code if
+you use the bytes, template, or utf8 packages. In all cases, any outdated code
+will fail to compile rather than behave erroneously.
+
+The bytes package has changed. Its Add and AddByte functions have been removed,
+as their functionality is provided by the recently-introduced built-in function
+“append”. Any code that uses them will need to be changed:
+s = bytes.Add(s, b)    ->    s = append(s, b...)
+s = bytes.AddByte(b, c)    ->    s = append(s, b)
+s = bytes.Add(nil, c)    ->    append([]byte(nil), c)
+
+The template package has changed. Your code will need to be updated if it calls
+the HTMLFormatter or StringFormatter functions, or implements its own formatter
+functions. The function signature for formatter types has changed to:
+        func(wr io.Writer, formatter string, data ...interface{})
+to allow multiple arguments to the formatter.  No templates will need updating.
+See the change for examples:
+        http://code.google.com/p/go/source/detail?r=2c2be793120e
+
+The template change permits the implementation of multi-word variable
+instantiation for formatters. Before one could say
+        {field}
+or
+        {field|formatter}
+Now one can also say
+        {field1 field2 field3}
+or
+        {field1 field2 field3|formatter}
+and the fields are passed as successive arguments to the formatter,
+by analogy to fmt.Print.
+
+The utf8 package has changed. The order of EncodeRune’s arguments has been
+reversed to satisfy the convention of “destination first”.
+Any code that uses EncodeRune will need to be updated.
+
+Other changes:
+* [68]l: correct dwarf location for globals and ranges for arrays.
+* big: fix (*Rat) SetFrac64(a, b) when b < 0 (thanks Eoghan Sherry).
+* compress/flate: fix typo in comment (thanks Mathieu Lonjaret).
+* crypto/elliptic: use a Jacobian transform for better performance.
+* doc/code.html: fix reference to "gomake build" (thanks Anschel Schaffer-Cohen).
+* doc/roadmap: update gdb status.
+* doc/spec: fixed some omissions and type errors.
+* doc: some typo fixes (thanks Peter Mundy).
+* exp/eval: build fix for parser.ParseFile API change (thanks Anschel Schaffer-Cohen).
+* fmt: Scan accepts Inf and NaN,
+        allow "% X" as well as "% x".
+* go/printer: preserve newlines in func parameter lists (thanks Jamie Gennis).
+* http: consume request body before next request.
+* log: ensure writes are atomic (thanks Roger Peppe).
+* path: Windows support for Split (thanks Benny Siegert).
+* runtime: fix SysFree to really free memory on Windows (thanks Alex Brainman),
+        parallel definitions in Go for all C structs.
+* sort: avoid overflow in pivot calculation,
+        reduced stack depth to lg(n) in quickSort (thanks Stefan Nilsson).
+* strconv: Atof on Infs and NaNs.
+</pre>
+
+<h3 id="2010-11-23">2010-11-23</h3>
+
+<pre>
+This release includes a backwards-incompatible package change to the
+sort.Search function (introduced in the last release).
+See the change for details and examples of how you might change your code:
+        http://code.google.com/p/go/source/detail?r=102866c369
+
+* build: automatically #define _64BIT in 6c.
+* cgo: print required space after parameter name in wrapper function.
+* crypto/cipher: new package to replace crypto/block (thanks Adam Langley).
+* crypto/elliptic: new package, implements elliptic curves over prime fields (thanks Adam Langley).
+* crypto/x509: policy OID support and fixes (thanks Adam Langley).
+* doc: add link to codewalks,
+        fix recover() documentation (thanks Anschel Schaffer-Cohen),
+        explain how to write Makefiles for commands.
+* exec: enable more tests on windows (thanks Alex Brainman).
+* gc: adjustable hash code in typecheck of composite literals
+        (thanks to vskrap, Andrey Mirtchovski, and Eoghan Sherry).
+* gc: better error message for bad type in channel send (thanks Anthony Martin).
+* godoc: bug fix in relativePath,
+        compute search index for all file systems under godoc's observation,
+        use correct time stamp to indicate accuracy of search result.
+* index/suffixarray: use sort.Search.
+* net: add ReadFrom and WriteTo windows version (thanks Wei Guangjing).
+* reflect: remove unnecessary casts in Get methods.
+* rpc: add RegisterName to allow override of default type name.
+* runtime: free memory allocated by windows CommandLineToArgv (thanks Alex Brainman).
+* sort: simplify Search (thanks Roger Peppe).
+* strings: add LastIndexAny (thanks Benny Siegert).
+</pre>
+
+<h3 id="2010-11-10">2010-11-10</h3>
+
+<pre>
+The birthday release includes a new Search capability inside the sort package.
+It takes an unusual but very general and easy-to-use approach to searching
+arbitrary indexable sorted data.  See the documentation for details:
+    http://golang.org/pkg/sort/#Search
+
+The ARM port now uses the hardware floating point unit (VFP).  It still has a
+few bugs, mostly around conversions between unsigned integer and floating-point
+values, but it's stabilizing.
+
+In addition, there have been many smaller fixes and updates: 
+
+* 6l: generate dwarf variable names with disambiguating suffix.
+* container/list: make Remove return Value of removed element.
+    makes it easier to remove first or last item.
+* crypto: add cast5 (default PGP cipher),
+    switch block cipher methods to be destination first.
+* crypto/tls: use pool building for certificate checking
+* go/ast: change embedded token.Position fields to named fields
+    (preparation for a different position representation)
+* net: provide public access to file descriptors (thanks Keith Rarick)
+* os: add Expand function to evaluate environment variables.
+* path: add Glob (thanks Benny Siegert)
+* runtime: memequal optimization (thanks Graham Miller)
+    prefix all external symbols with "runtime·" to avoid
+    conflicts linking with external C libraries.
+</pre>
+
+<h3 id="2010-11-02">2010-11-02</h3>
+
+<pre>
+This release includes a language change: the new built-in function, append.
+Append makes growing slices much simpler. See the spec for details:
+        http://golang.org/doc/go_spec.html#Appending_and_copying_slices
+
+Other changes:
+* 8l: pe generation fixes (thanks Alex Brainman).
+* doc: Effective Go: append and a few words about "..." args.
+* build: fiddle with make variables.
+* codereview: fix sync and download in Python 2.7 (thanks Fazlul Shahriar).
+* debug/pe, cgo: add windows support (thanks Wei Guangjing <vcc.163@gmail.com>).
+* go/ast: add Inspect function for easy AST inspection w/o a visitor.
+* go/printer: do not remove parens around composite literals starting with
+        a type name in control clauses.
+* go/scanner: bug fixes, revisions, and more tests.
+* gob: several fixes and documentation updates.
+* godoc: bug fix (bug introduced with revision 3ee58453e961).
+* gotest: print empty benchmark list in a way that gofmt will leave alone.
+* http server: correctly respond with 304 NotModified (thanks Michael Hoisie).
+* kate: update list of builtins (thanks Evan Shaw).
+* libutf: update to Unicode 5.2.0 to match pkg/unicode (thanks Anthony Martin).
+* misc/bbedit: update list of builtins (thanks Anthony Starks).
+* misc/vim: update list of builtins.
+* mkrunetype: install a Makefile and tweak it slightly so it can be built.
+* netchan: fix locking bug.
+* pidigits: minor improvements (thanks Evan Shaw).
+* rpc: fix client deadlock bug.
+* src: use append where appropriate (often instead of vector).
+* strings: add Contains helper function (thanks Brad Fitzpatrick).
+* syscall: SIO constants for Linux (thanks Albert Strasheim),
+        Stat(path) on windows (thanks Alex Brainman).
+* test/ken/convert.go: add conversion torture test.
+* testing: add Benchmark (thanks Roger Peppe).
+</pre>
+
+<h3 id="2010-10-27">2010-10-27</h3>
+
+<pre>
+*** This release changes the encoding used by package gob. 
+    If you store gobs on disk, see below. ***
+
+The ARM port (5g) now passes all tests. The optimizer is not yet enabled, and
+floating point arithmetic is performed entirely in software. Work is underway
+to address both of these deficiencies.
+
+The syntax for arrays, slices, and maps of composite literals has been
+simplified. Within a composite literal of array, slice, or map type, elements
+that are themselves composite literals may elide the type if it is identical to
+the outer literal’s element type. For example, these expressions:
+	[][]int{[]int{1, 2, 3}, []int{4, 5}}
+	map[string]Point{“x”: Point{1.5, -3.5}, “y”: Point{0, 0}}
+can be simplified to:
+	[][]int{{1, 2, 3}, {4, 5}}
+	map[string]Point{“x”: {1.5, -3.5}, “y”: {0, 0}}
+Gofmt can make these simplifications mechanically when invoked with the 
+new -s flag.
+
+The built-in copy function can now copy bytes from a string value to a []byte.
+Code like this (for []byte b and string s): 
+	for i := 0; i < len(s); i++ {
+		b[i] = s[i]
+	}
+can be rewritten as:
+	copy(b, s)
+
+The gob package can now encode and decode interface values containing types
+registered ahead of time with the new Register function. These changes required
+a backwards-incompatible change to the wire format.  Data written with the old
+version of the package will not be readable with the new one, and vice versa.
+(Steps were made in this change to make sure this doesn’t happen again.) 
+We don’t know of anyone using gobs to create permanent data, but if you do this
+and need help converting, please let us know, and do not update to this release
+yet.  We will help you convert your data.
+
+Other changes:
+* 5g, 6g, 8g: generate code for string index instead of calling function.
+* 5l, 6l, 8l: introduce sub-symbols.
+* 6l/8l: global and local variables and type info.
+* Make.inc: delete unnecessary -fno-inline flag to quietgcc.
+* arm: precise float64 software floating point, bug fixes.
+* big: arm assembly, faster software mulWW, divWW.
+* build: only print "You need to add foo to PATH" when needed.
+* container/list: fix Remove bug and use pointer to self as identifier.
+* doc: show page title in browser title bar,
+        update roadmap.
+* encoding/binary: give LittleEndian, BigEndian specific types.
+* go/parser: consume auto-inserted semi when calling ParseExpr().
+* gobuilder: pass GOHOSTOS and GOHOSTARCH to build,
+        write build and benchmarking logs to disk.
+* goinstall: display helpful message when encountering a cgo package,
+        fix test for multiple package names (thanks Fazlul Shahriar).
+* gotest: generate correct gofmt-formatted _testmain.go.
+* image/png: speed up paletted encoding ~25% (thanks Brad Fitzpatrick).
+* misc: update python scripts to specify python2 as python3 is now "python".
+* net: fix comment on Dial to mention unix/unixgram.
+* rpc: expose Server type to allow multiple RPC Server instances.
+* runtime: print unknown types in panic.
+* spec: append built-in (not yet implemented).
+* src: gofmt -s -w src misc.
+        update code to use copy-from-string.
+* test/bench: update numbers.
+* websocket: fix short Read.
+</pre>
+
+<h3 id="2010-10-20">2010-10-20</h3>
+
+<pre>
+This release removes the log package's deprecated functions.
+Code that has not been updated to use the new interface will break.
+See the previous release notes for details:
+	http://golang.org/doc/devel/release.html#2010-10-13
+
+Also included are major improvements to the linker. It is now faster, 
+uses less memory, and more parallelizable (but not yet parallel).
+
+The nntp package has been removed from the standard library.
+Its new home is the nntp-go project at Google Code:
+	http://code.google.com/p/nntp-go
+You can install it with goinstall:
+	goinstall nntp-go.googlecode.com/hg/nntp
+And import it in your code like so:
+	import "nntp-go.googlecode.com/hg/nntp"
+
+Other changes:
+* 6g: avoid too-large immediate constants.
+* 8l, runtime: initial support for Plan 9 (thanks Yuval Pavel Zholkover).
+* 6l, 8l: more improvements on exporting debug information (DWARF).
+* arm: code gen fixes. Most tests now pass, except for floating point code.
+* big: add random number generation (thanks Florian Uekermann).
+* gc: keep track of real actual type of identifiers,
+	report that shift must be unsigned integer,
+	select receive with implicit conversion.
+* goplay: fix to run under windows (thanks Yasuhiro Matsumoto).
+* http: do not close connection after sending HTTP/1.0 request.
+* netchan: add new method Hangup to terminate transmission on a channel.
+* os: change TestForkExec so it can run on windows (thanks Yasuhiro Matsumoto).
+* runtime: don't let select split stack.
+* syscall/arm: correct 64-bit system call arguments.
+</pre>
+
+<h3 id="2010-10-13">2010-10-13</h3>
+
+<pre>
+This release includes changes to the log package, the removal of exp/iterable,
+two new tools (gotry and goplay), one small language change, and many other
+changes and fixes.  If you use the log or iterable packages, you need to make
+changes to your code.
+
+The log package has changed.  Loggers now have only one output, and output to
+standard error by default.  The names have also changed, although the old names
+are still supported.  They will be deleted in the next release, though, so it
+would be good to update now if you can.  For most purposes all you need to do
+is make these substitutions:
+        log.Stderr -> log.Println or log.Print
+        log.Stderrf -> log.Printf
+        log.Crash -> log.Panicln or log.Panic
+        log.Crashf -> log.Panicf
+        log.Exit -> log.Exitln or log.Exit
+        log.Exitf -> log.Exitf (no change)
+Calls to log.New() must drop the second argument.
+Also, custom loggers with exit or panic properties will need to be reworked.
+For full details, see the change description:
+        http://code.google.com/p/go/source/detail?r=d8a3c7563d
+
+The language change is that uses of pointers to interface values no longer
+automatically dereference the pointer.  A pointer to an interface value is more
+often a beginner’s bug than correct code.
+
+The package exp/iterable has been removed. It was an interesting experiment,
+but it encourages writing inefficient code and has outlived its utility.
+
+The new tools:
+* gotry: an exercise in reflection and an unusual tool. Run 'gotry' for details.
+* goplay: a stand-alone version of the Go Playground. See misc/goplay.
+
+Other changes:
+* 6l: Mach-O fixes, and fix to work with OS X nm/otool (thanks Jim McGrath).
+* [568]a: correct line numbers for statements.
+* arm: code generation and runtime fixes,
+	adjust recover for new reflect.call,
+	enable 6 more tests after net fix.
+* big: fix panic and round correctly in Rat.FloatString (thanks Anthony Martin).
+* build: Make.cmd: remove $(OFILES) (thanks Eric Clark),
+        Make.pkg: remove .so before installing new one,
+        add GOHOSTOS and GOHOSTARCH environment variables.
+* crypto/tls: better error messages for certificate issues,
+        make SetReadTimeout work.
+* doc: add Sydney University video,
+	add The Expressiveness of Go talk.
+* exp/draw/x11: support X11 vendors other than "The X.Org Foundation".
+* expvar: add (*Int).Set (thanks Sam Thorogood).
+* fmt: add Errorf helper function,
+        allow %d on []byte.
+* gc: O(1) string comparison when lengths differ,
+        various bug fixes.
+* http: return the correct error if a header line is too long.
+* image: add image.Tiled type, the Go equivalent of Plan 9's repl bit.
+* ld: be less picky about bad line number info.
+* misc/cgo/life: fix for new slice rules (thanks Graham Miller).
+* net: allow _ in DNS names.
+* netchan: export before import when testing, and
+        zero out request to ensure correct gob decoding. (thanks Roger Peppe).
+* os: make tests work on windows (thanks Alex Brainman).
+* runtime: bug fix: serialize mcache allocation,
+        correct iteration of large map values,
+        faster strequal, memequal (thanks Graham Miller),
+        fix argument dump in traceback,
+        fix tiny build.
+* smtp: new package (thanks Evan Shaw).
+* syscall: add sockaddr_ll support for linux/386, linux/amd64 (thanks Mikio Hara),
+        add ucred structure for SCM_CREDENTIALS over UNIX sockets. (thanks Albert Strasheim).
+* syscall: implement WaitStatus and Wait4() for windows (thanks Wei Guangjing).
+* time: add After.
+* websocket: enable tests on windows (thanks Alex Brainman).
+</pre>
+
+<h3 id="2010-09-29">2010-09-29</h3>
+
+<pre>
+This release includes some minor language changes and some significant package
+changes. You may need to change your code if you use ...T parameters or the
+http package.
+
+The semantics and syntax of forwarding ...T parameters have changed.
+        func message(f string, s ...interface{}) { fmt.Printf(f, s) }
+Here, s has type []interface{} and contains the parameters passed to message.
+Before this language change, the compiler recognized when a function call
+passed a ... parameter to another ... parameter of the same type, and just
+passed it as though it was a list of arguments.  But this meant that you
+couldn't control whether to pass the slice as a single argument and you
+couldn't pass a regular slice as a ... parameter, which can be handy.  This
+change gives you that control at the cost of a few characters in the call.
+If you want the promotion to ...,  append ... to the argument:
+        func message(f string, s ...interface{}) { fmt.Printf(f, s...) }
+Without the ..., s would be passed to Printf as a single argument of type
+[]interface{}.  The bad news is you might need to fix up some of your code, 
+but the compiler will detect the situation and warn you.
+
+Also, the http.Handler and http.HandlerFunc types have changed. Where http
+handler functions previously accepted an *http.Conn, they now take an interface
+type http.ResponseWriter. ResponseWriter implements the same methods as *Conn,
+so in most cases the only change required will be changing the type signature
+of your handler function's first parameter. See:
+  http://golang.org/pkg/http/#Handler
+
+The utf8 package has a new type, String, that provides efficient indexing 
+into utf8 strings by rune (previously an expensive conversion to []int 
+was required). See:
+  http://golang.org/pkg/utf8/#String
+
+The compiler will now automatically insert a semicolon at the end of a file if
+one is not found. This effect of this is that Go source files are no longer
+required to have a trailing newline.
+
+Other changes:
+* 6prof: more accurate usage message.
+* archive/zip: new package for reading Zip files.
+* arm: fix code generation, 10 more package tests pass.
+* asn1: make interface consistent with json.
+* bufio.UnreadRune: fix bug at EOF.
+* build: clear custom variables like GREP_OPTIONS,
+        silence warnings generated by ubuntu gcc,
+        use full path when compiling libraries.
+* bytes, strings: change lastIndexFunc to use DecodeLastRune (thanks Roger Peppe).
+* doc: add to and consolidate non-english doc references,
+        consolidate FAQs into a single file, go_faq.html,
+        updates for new http interface.
+* fmt/Printf: document and tweak error messages produced for bad formats.
+* gc: allow select case expr = <-c,
+        eliminate duplicates in method table,
+        fix reflect table method receiver,
+        improve error message for x \= 0.
+* go/scanner: treat EOF like a newline for purposes of semicolon insertion.
+* gofmt: stability improvements.
+* gotest: leave _testmain.go for "make clean" to clean up.
+* http: correct escaping of different parts of URL,
+        support HTTP/1.0 Keep-Alive.
+* json: do not write to unexported fields.
+* libcgo: don't build for NaCl,
+        set g, m in thread local storage for windows 386 (thanks Wei Guangjing).
+* math: Fix off-by-one error in Ilogb and Logb.  (thanks Charles L. Dorian).
+* misc/dashboard/builder: remove build files after benchmarking.
+* nacl: update instructions for new SDK.
+* net: enable v4-over-v6 on ip sockets,
+        fix crash in DialIP.
+* os: check for valid arguments in windows Readdir (thanks Peter Mundy).
+* runtime: add mmap of null page just in case,
+        correct stats in SysFree,
+        fix unwindstack crash.
+* syscall: add IPPROTO_IPV6 and IPV6_V6ONLY const to fix nacl and windows build,
+        add inotify on Linux (thanks Balazs Lecz),
+        fix socketpair in syscall_bsd,
+        fix windows value of IPV6_V6ONLY (thanks Alex Brainman),
+        implement windows version of Utimes (thanks Alex Brainman),
+        make mkall.sh work for nacl.
+* test: Add test that causes incorrect error from gccgo.
+* utf8: add DecodeLastRune and DecodeLastRuneInString (thanks Roger Peppe).
+* xml: Allow entities inside CDATA tags (thanks Dan Sinclair).
+</pre>
+
+<h3 id="2010-09-22">2010-09-22</h3>
+
+<pre>
+This release includes new package functionality, and many bug fixes and changes.
+It also improves support for the arm and nacl platforms.
+
+* 5l: avoid fixed buffers in list.
+* 6l, 8l: clean up ELF code, fix NaCl.
+* 6l/8l: emit DWARF frame info.
+* Make.inc: make GOOS detection work on windows (thanks Alex Brainman).
+* build: fixes for native arn build,
+        make all.bash run on Ubuntu ARM.
+* cgo: bug fixes,
+        show preamble gcc errors (thanks Eric Clark).
+* crypto/x509, crypto/tls: improve root matching and observe CA flag.
+* crypto: Fix certificate validation.
+* doc: variable-width layout.
+* env.bash: fix building in directory with spaces in the path (thanks Alex Brainman).
+* exp/4s, exp/nacl/av: sync to recent exp/draw changes.
+* exp/draw/x11: mouse location is a signed integer.
+* exp/nacl/av: update color to max out at 1<<16-1 instead of 1<<32-1.
+* fmt: support '*' for width or precision (thanks Anthony Martin).
+* gc: improvements to static initialization,
+        make sure path names are canonical.
+* gob: make robust when decoding a struct with non-struct data.
+* gobuilder: add -cmd for user-specified build command,
+        add -rev= flag to build specific revision and exit,
+        fix bug that caused old revisions to be rebuilt.
+* godoc: change default filter file name to "",
+        don't use quadratic algorithm to filter paths,
+        show "Last update" info for directory listings.
+* http: new redirect test,
+        URLEscape now escapes all reserved characters as per the RFC.
+* nacl: fix zero-length writes.
+* net/dict: parse response correctly (thanks Fazlul Shahriar).
+* netchan: add a cross-connect test,
+        handle closing of channels,
+        provide a method (Importer.Errors()) to recover protocol errors.
+* os: make Open() O_APPEND flag work on windows (thanks Alex Brainman),
+        make RemoveAll() work on windows (thanks Alex Brainman).
+* pkg/Makefile: disable netchan test to fix windows build (thanks Alex Brainman).
+* regexp: delete Iter methods.
+* runtime: better panic for send to nil channel.
+* strings: fix minor bug in LastIndexFunc (thanks Roger Peppe).
+* suffixarray: a package for creating suffixarray-based indexes.
+* syscall: Use vsyscall for syscall.Gettimeofday and .Time on linux amd64.
+* test: fix NaCl build.
+* windows: fix netchan test by using 127.0.0.1.
+</pre>
+
+<h3 id="2010-09-15">2010-09-15</h3>
+
+<pre>
+This release includes a language change: the lower bound of a subslice may
+now be omitted, in which case the value will default to 0.
+For example, s[0:10] may now be written as s[:10], and s[0:] as s[:].
+
+The release also includes important bug fixes for the ARM architecture,
+as well as the following fixes and changes:
+
+* 5g: register allocation bugs
+* 6c, 8c: show line numbers in -S output
+* 6g, 6l, 8g, 8l: move read-only data to text segment
+* 6l, 8l: make etext accurate; introduce rodata, erodata.
+* arm: fix build bugs.
+        make libcgo build during OS X cross-compile
+        remove reference to deleted file syntax/slice.go
+        use the correct stat syscalls
+        work around reg allocator bug in 5g
+* bufio: add UnreadRune.
+* build: avoid bad environment interactions
+        fix build for tiny
+        generate, clean .exe files on Windows (thanks Joe Poirier)
+        test for _WIN32, not _MINGW32 (thanks Joe Poirier)
+        work with GNU Make 3.82 (thanks Jukka-Pekka Kekkonen)
+* cgo: add typedef for uintptr in generated headers
+        silence warning for C call returning const pointer
+* codereview: convert email address to lower case before checking CONTRIBUTORS
+* crypto/tls: don't return an error from Close()
+* doc/tutorial: update for slice changes.
+* exec: separate LookPath implementations for unix/windows (thanks Joe Poirier)
+* exp/draw/x11: allow clean shutdown when the user closes the window.
+* exp/draw: clip destination rectangle to the image bounds.
+        fast path for drawing overlapping image.RGBAs.
+        fix double-counting of pt.Min for the src and mask points.
+        reintroduce the MouseEvent.Nsec timestamp.
+        rename Context to Window, and add a Close method.
+* exp/debug: preliminary support for 'copy' function (thanks Sebastien Binet)
+* fmt.Fscan: use UnreadRune to preserve data across calls.
+* gc: better printing of named constants, func literals in errors
+        many bug fixes
+        fix line number printing with //line directives
+        fix symbol table generation on windows (thanks Alex Brainman)
+        implement comparison rule from spec change 33abb649cb63
+        implement new slice spec (thanks Scott Lawrence)
+        make string x + y + z + ... + w efficient
+        more accurate line numbers for ATEXT
+        remove &[10]int -> []int conversion
+* go-mode.el: fix highlighting for 'chan' type (thanks Scott Lawrence)
+* godoc: better support for directory trees for user-supplied paths
+        use correct delay time (bug fix)
+* gofmt, go/printer: update internal estimated position correctly
+* goinstall: warn when package name starts with http:// (thanks Scott Lawrence)
+* http: check https certificate against host name
+        do not cache CanonicalHeaderKey (thanks Jukka-Pekka Kekkonen)
+* image: change a ColorImage's minimum point from (0, 0) to (-1e9, -1e9).
+        introduce Intersect and Union rectangle methods.
+* ld: handle quoted spaces in package path (thanks Dan Sinclair)
+* libcgo: fix NaCl build.
+* libmach: fix build on arm host
+        fix new thread race with Linux
+* math: make portable Tan(Pi/2) return NaN
+* misc/dashboard/builder: gobuilder, a continuous build client
+* net: disable tests for functions not available on windows (thanks Alex Brainman)
+* netchan: make -1 unlimited, as advertised.
+* os, exec: rename argv0 to name
+* path: add IsAbs (thanks Ivan Krasin)
+* runtime: fix bug in tracebacks
+        fix crash trace on amd64
+        fix windows build (thanks Alex Brainman)
+        use manual stack for garbage collection
+* spec: add examples for slices with omitted index expressions.
+        allow omission of low slice bound (thanks Scott Lawrence)
+* syscall: fix windows Gettimeofday (thanks Alex Brainman)
+* test(arm): disable zerodivide.go because compilation fails.
+* test(windows): disable tests that cause the build to fail (thanks Joe Poirier)
+* test/garbage/parser: sync with recent parser changes
+* test: Add test for //line
+        Make gccgo believe that the variables can change.
+        Recognize gccgo error messages.
+        Reduce race conditions in chan/nonblock.go.
+        Run garbage collector before testing malloc numbers.
+* websocket: Add support for secure WebSockets (thanks Jukka-Pekka Kekkonen)
+* windows: disable unimplemented tests (thanks Joe Poirier)
+</pre>
+
+<h3 id="2010-09-06">2010-09-06</h3>
+
+<pre>
+This release includes the syntactic modernization of more than 100 files in /test,
+and these additions, changes, and fixes: 
+* 6l/8l: emit DWARF in macho.
+* 8g: use FCHS, not FMUL, for minus float.
+* 8l: emit DWARF in ELF,
+        suppress emitting DWARF in Windows PE (thanks Alex Brainman).
+* big: added RatString, some simplifications.
+* build: create bin and pkg directories as needed; drop from hg,
+        delete Make.386 Make.amd64 Make.arm (obsoleted by Make.inc),
+        fix cgo with -j2,
+        let pkg/Makefile coordinate building of Go commands,
+        never use quietgcc in Make.pkg,
+        remove more references to GOBIN and GOROOT (thanks Christian Himpel).
+* codereview: Fix uploading for Mercurial 1.6.3 (thanks Evan Shaw),
+        consistent indent, cut dead code,
+        fix hang on standard hg commands,
+        print status when tasks take longer than 30 seconds,
+        really disable codereview when not available,
+        upload files in parallel (5x improvement on large CLs).
+* crypto/hmac: make Sum idempotent (thanks Jukka-Pekka Kekkonen).
+* doc: add links to more German docs,
+        add round-robin flag to io2010 balance example,
+        fix a bug in the example in Constants subsection (thanks James Fysh),
+        various changes for validating HTML (thanks Scott Lawrence).
+* fmt: delete erroneous sentence about return value for Sprint*.
+* gc: appease bison version running on FreeBSD builder,
+        fix spurious syntax error.
+* go/doc: use correct escaper for URL.
+* go/printer: align ImportPaths in ImportDecls (thanks Scott Lawrence).
+* go/typechecker: 2nd step towards augmenting AST with full type information.
+* gofmt: permit omission of first index in slice expression.
+* goinstall: added -a flag to mean "all remote packages" (thanks Scott Lawrence),
+        assume go binaries are in path (following new convention),
+        use https for Google Code checkouts.
+* gotest: allow make test of cgo packages (without make install).
+* http: add Date to server, Last-Modified and If-Modified-Since to file server,
+        add PostForm function to post url-encoded key/value data,
+        obscure passwords in return value of URL.String (thanks Scott Lawrence).
+* image: introduce Config type and DecodeConfig function.
+* libcgo: update Makefile to use Make.inc.
+* list: update comment to state that the zero value is ready to use.
+* math: amd64 version of Sincos (thanks Charles L. Dorian).
+* misc/bash: add *.go completion for gofmt (thanks Scott Lawrence).
+* misc/emacs: make _ a word symbol (thanks Scott Lawrence).
+* misc: add zsh completion (using compctl),
+        syntax highlighting for Fraise.app (OS X) (thanks Vincent Ambo).
+* net/textproto: Handle multi-line responses (thanks Evan Shaw).
+* net: add LookupMX (thanks Corey Thomasson).
+* netchan: Fix race condition in test,
+        rather than 0, make -1 mean infinite (a la strings.Split et al),
+        use acknowledgements on export send.
+        new methods Sync and Drain for clean teardown.
+* regexp: interpret all Go characer escapes \a \b \f \n \r \t \v.
+* rpc: fix bug that caused private methods to attempt to be registered.
+* runtime: Correct commonType.kind values to match compiler,
+        add GOOS, GOARCH; fix FuncLine,
+        special case copy, equal for one-word interface values (thanks Kyle Consalus).
+* scanner: fix incorrect reporting of error in Next (thanks Kyle Consalus).
+* spec: clarify that arrays must be addressable to be sliceable.
+* template: fix space handling around actions.
+* test/solitaire: an exercise in backtracking and string conversions.
+* test: Recognize gccgo error messages and other fixes.
+* time: do not crash in String on nil Time.
+* tutorial: regenerate HTML to pick up change to progs/file.go.
+* websocket: fix missing Sec-WebSocket-Protocol on server response (thanks Jukka-Pekka Kekkonen).
+</pre>
+
+<h3 id="2010-08-25">2010-08-25</h3>
+
+<pre>
+This release includes changes to the build system that will likely require you
+to make changes to your environment variables and Makefiles.
+
+All environment variables are now optional:
+ - $GOOS and $GOARCH are now optional; their values should now be inferred 
+   automatically by the build system,
+ - $GOROOT is now optional, but if you choose not to set it you must run
+   'gomake' instead of 'make' or 'gmake' when developing Go programs
+   using the conventional Makefiles,
+ - $GOBIN remains optional and now defaults to $GOROOT/bin;
+   if you wish to use this new default, make sure it is in your $PATH
+   and that you have removed the existing binaries from $HOME/bin.
+
+As a result of these changes, the Go Makefiles have changed. If your Makefiles
+inherit from the Go Makefiles, you must change this line:
+    include ../../Make.$(GOARCH)
+to this:
+    include ../../Make.inc
+
+This release also removes the deprecated functions in regexp and the 
+once package. Any code that still uses them will break.
+See the notes from the last release for details:
+    http://golang.org/doc/devel/release.html#2010-08-11
+
+Other changes:
+* 6g: better registerization for slices, strings, interface values
+* 6l: line number information in DWARF format
+* build: $GOBIN defaults to $GOROOT/bin,
+        no required environment variables
+* cgo: add C.GoStringN (thanks Eric Clark).
+* codereview: fix issues with leading tabs in CL descriptions,
+        do not send "Abandoned" mail if the CL has not been mailed.
+* crypto/ocsp: add missing Makefile.
+* crypto/tls: client certificate support (thanks Mikkel Krautz).
+* doc: update gccgo information for recent changes.
+        fix errors in Effective Go.
+* fmt/print: give %p priority, analogous to %T,
+        honor Formatter in Print, Println.
+* gc: fix parenthesization check.
+* go/ast: facility for printing AST nodes,
+        first step towards augmenting AST with full type information.
+* go/printer: do not modify tabwriter.Escape'd text.
+* gofmt: do not modify multi-line string literals,
+        print AST nodes by setting -ast flag.
+* http: fix typo in http.Request documentation (thanks Scott Lawrence)
+        parse query string always, not just in GET
+* image/png: support 16-bit color.
+* io: ReadAtLeast now errors if min > len(buf).
+* jsonrpc: use `error: null` for success, not `error: ""`.
+* libmach: implement register fetch for 32-bit x86 kernel.
+* net: make IPv6 String method standards-compliant (thanks Mikio Hara).
+* os: FileInfo.Permission() now returns uint32 (thanks Scott Lawrence),
+        implement env using native Windows API (thanks Alex Brainman).
+* reflect: allow PtrValue.PointTo(nil).
+* runtime: correct line numbers for .goc files,
+        fix another stack split bug,
+        fix freebsd/386 mmap.
+* syscall: regenerate syscall/z* files for linux/386, linux/amd64, linux/arm.
+* tabwriter: Introduce a new flag StripEscape.
+* template: fix handling of space around actions,
+        vars preceded by white space parse correctly (thanks Roger Peppe).
+* test: add test case that crashes gccgo.
+* time: parse no longer requires minutes for time zone (thanks Jan H. Hosang)
+* yacc: fix bounds check in error recovery.
+</pre>
+
+<h3 id="2010-08-11">2010-08-11</h3>
+
+<pre>
+This release introduces some package changes. You may need to change your
+code if you use the once, regexp, image, or exp/draw packages.
+
+The type Once has been added to the sync package. The new sync.Once will
+supersede the functionality provided by the once package. We intend to remove
+the once package after this release. See:
+    http://golang.org/pkg/sync/#Once
+All instances of once in the standard library have been replaced with
+sync.Once. Reviewing these changes may help you modify your existing code. 
+The relevant changeset:
+    http://code.google.com/p/go/source/detail?r=fa2c43595119
+
+A new set of methods has been added to the regular expression package, regexp.
+These provide a uniformly named approach to discovering the matches of an
+expression within a piece of text; see the package documentation for details: 
+    http://golang.org/pkg/regexp/
+These new methods will, in a later release, replace the old methods for
+matching substrings.  The following methods are deprecated:
+    Execute (use FindSubmatchIndex)
+    ExecuteString (use FindStringSubmatchIndex)
+    MatchStrings(use FindStringSubmatch)
+    MatchSlices (use FindSubmatch)
+    AllMatches (use FindAll; note that n<0 means 'all matches'; was n<=0)
+    AllMatchesString (use FindAllString; note that n<0 means 'all matches'; was n<=0)
+(Plus there are ten new methods you didn't know you wanted.) 
+Please update your code to use the new routines before the next release.
+
+An image.Image now has a Bounds rectangle, where previously it ranged 
+from (0, 0) to (Width, Height). Loops that previously looked like:
+    for y := 0; y < img.Height(); y++ {
+        for x := 0; x < img.Width(); x++ {
+            // Do something with img.At(x, y)
+        }
+    }
+should instead be:
+    b := img.Bounds()
+    for y := b.Min.Y; y < b.Max.Y; y++ {
+        for x := b.Min.X; x < b.Max.X; x++ {
+            // Do something with img.At(x, y)
+        }
+    }
+The Point and Rectangle types have also moved from exp/draw to image.
+
+Other changes:
+* arm: bugfixes and syscall (thanks Kai Backman).
+* asn1: fix incorrect encoding of signed integers (thanks Nicholas Waples).
+* big: fixes to bitwise functions (thanks Evan Shaw).
+* bytes: add IndexRune, FieldsFunc and To*Special (thanks Christian Himpel).
+* encoding/binary: add complex (thanks Roger Peppe).
+* exp/iterable: add UintArray (thanks Anschel Schaffer-Cohen).
+* godoc: report Status 404 if a pkg or file is not found.
+* gofmt: better reporting for unexpected semicolon errors.
+* html: new package, an HTML tokenizer.
+* image: change image representation from slice-of-slices to linear buffer,
+        introduce Decode and RegisterFormat,
+        introduce Transparent and Opaque,
+        replace Width and Height by Bounds, add the Point and Rect types.
+* libbio: fix Bprint to address 6g issues with large data structures.
+* math: fix amd64 Hypot (thanks Charles L. Dorian).
+* net/textproto: new package, with example net/dict.
+* os: fix ForkExec() handling of envv == nil (thanks Alex Brainman).
+* png: grayscale support (thanks Mathieu Lonjaret).
+* regexp: document that backslashes are the escape character.
+* rpc: catch errors from ReadResponseBody.
+* runtime: memory free fix (thanks Alex Brainman).
+* template: add ParseFile method to template.Template.
+* test/peano: use directly recursive type def.
+</pre>
+
+<h3 id="2010-08-04">2010-08-04</h3>
+
+<pre>
+This release includes a change to os.Open (and co.). The file permission
+argument has been changed to a uint32. Your code may require changes - a simple
+conversion operation at most.
+
+Other changes:
+* amd64: use segment memory for thread-local storage.
+* arm: add gdb support to android launcher script,
+        bugfixes (stack clobbering, indices),
+        disable another flaky test,
+        remove old qemu dependency from gotest.
+* bufio: introduce Peek.
+* bytes: added test case for explode with blank string (thanks Scott Lawrence).
+* cgo: correct multiple return value function invocations (thanks Christian Himpel).
+* crypto/x509: unwrap Subject Key Identifier (thanks Adam Langley).
+* gc: index bounds tests and other fixes.
+* gofmt/go/parser: strengthen syntax checks.
+* goinstall: check for error from exec.*Cmd.Wait() (thanks Alex Brainman).
+* image/png: use image-specific methods for checking opacity.
+* image: introduce Gray and Gray16 types,
+        remove the named colors except for Black and White.
+* json: object members must have a value (thanks Anthony Martin).
+* misc/vim: highlight misspelled words only in comments (thanks Christian Himpel).
+* os: Null device (thanks Peter Mundy).
+* runtime: do not fall through in SIGBUS/SIGSEGV.
+* strings: fix Split("", "", -1) (thanks Scott Lawrence).
+* syscall: make go errors not clash with windows errors (thanks Alex Brainman).
+* test/run: diff old new,
+* websocket: correct challenge response (thanks Tarmigan Casebolt),
+        fix bug involving spaces in header keys (thanks Bill Neubauer). 
+</pre>
+
+<h3 id="2010-07-29">2010-07-29</h3>
+
+<pre>
+* 5g: more soft float support and several bugfixes.
+* asn1: Enumerated, Flag and GeneralizedTime support.
+* build: clean.bash to check that GOOS and GOARCH are set.
+* bytes: add IndexFunc and LastIndexFunc (thanks Fazlul Shahriar),
+	add Title.
+* cgo: If CC is set in environment, use it rather than "gcc",
+	use new command line syntax: -- separates cgo flags from gcc flags.
+* codereview: avoid crash if no config,
+	don't run gofmt with an empty file list,
+	make 'hg submit' work with Mercurial 1.6.
+* crypto/ocsp: add package to parse OCSP responses.
+* crypto/tls: add client-side SNI support and PeerCertificates.
+* exp/bignum: delete package - functionality subsumed by package big.
+* fmt.Print: fix bug in placement of spaces introduced when ...T went in.
+* fmt.Scanf: handle trailing spaces.
+* gc: fix smaller-than-pointer-sized receivers in interfaces,
+	floating point precision/normalization fixes,
+	graceful exit on seg fault,
+	import dot shadowing bug,
+	many fixes including better handling of invalid input,
+	print error detail about failure to open import.
+* gccgo_install.html: add description of the port to RTEMS (thanks Vinu Rajashekhar).
+* gobs: fix bug in singleton arrays.
+* godoc: display synopses for all packages that have some kind of documentation..
+* gofmt: fix some linebreak issues.
+* http: add https client support (thanks Fazlul Shahriar),
+	write body when content length unknown (thanks James Whitehead).
+* io: MultiReader and MultiWriter (thanks Brad Fitzpatrick),
+	fix another race condition in Pipes.
+* ld: many fixes including better handling of invalid input.
+* libmach: correct handling of .5 files with D_REGREG addresses.
+* linux/386: use Xen-friendly ELF TLS instruction sequence.
+* mime: add AddExtensionType (thanks Yuusei Kuwana).
+* misc/vim: syntax file recognizes constants like 1e9 (thanks Petar Maymounkov).
+* net: TCPConn.SetNoDelay, back by popular demand.
+* net(windows): fix crashing Read/Write when passed empty slice on (thanks Alex Brainman),
+	implement LookupHost/Port/SRV (thanks Wei Guangjing),
+	properly handle EOF in (*netFD).Read() (thanks Alex Brainman).
+* runtime: fix bug introduced in revision 4a01b8d28570 (thanks Alex Brainman),
+	rename cgo2c, *.cgo to goc2c, *.goc (thanks Peter Mundy).
+* scanner: better comment.
+* strings: add Title.
+* syscall: add ForkExec, Syscall12 on Windows (thanks Daniel Theophanes),
+	improve windows errno handling (thanks Alex Brainman).
+* syscall(windows): fix FormatMessage (thanks Peter Mundy),
+	implement Pipe() (thanks Wei Guangjing).
+* time: fix parsing of minutes in time zones.
+* utf16(windows): fix cyclic dependency when testing (thanks Peter Mundy).
+</pre>
+
+<h3 id="2010-07-14">2010-07-14</h3>
+
+<pre>
+This release includes a package change. In container/vector, the Iter method
+has been removed from the Vector, IntVector, and StringVector types. Also, the
+Data method has been renamed to Copy to better express its actual behavior.
+Now that Vector is just a slice, any for loops ranging over v.Iter() or
+v.Data() can be changed to range over v instead.
+
+Other changes:
+* big: Improvements to Rat.SetString (thanks Evan Shaw),
+        add sign, abs, Rat.IsInt.
+* cgo: various bug fixes.
+* codereview: Fix for Mercurial >= 1.6 (thanks Evan Shaw).
+* crypto/rand: add Windows implementation (thanks Peter Mundy).
+* crypto/tls: make HTTPS servers easier,
+        add client OCSP stapling support.
+* exp/eval: converted from bignum to big (thanks Evan Shaw).
+* gc: implement new len spec, range bug fix, optimization.
+* go/parser: require that '...' parameters are followed by a type.
+* http: fix ParseURL to handle //relative_path properly.
+* io: fix SectionReader Seek to seek backwards (thanks Peter Mundy).
+* json: Add HTMLEscape (thanks Micah Stetson).
+* ld: bug fixes.
+* math: amd64 version of log (thanks Charles L. Dorian).
+* mime/multipart: new package to parse multipart MIME messages
+        and HTTP multipart/form-data support.
+* os: use TempFile with default TempDir for test files (thanks Peter Mundy).
+* runtime/tiny: add docs for additional VMs, fix build (thanks Markus Duft).
+* runtime: better error for send/recv on nil channel.
+* spec: clarification of channel close(),
+        lock down some details about channels and select,
+        restrict when len(x) is constant,
+        specify len/cap for nil slices, maps, and channels.
+* windows: append .exe to binary names (thanks Joe Poirier).
+</pre>
+
 <h3 id="2010-07-01">2010-07-01</h3>
 
 <pre>
diff --git a/doc/devel/roadmap.html b/doc/devel/roadmap.html
index eace183f7..021ed6478 100644
--- a/doc/devel/roadmap.html
+++ b/doc/devel/roadmap.html
@@ -2,6 +2,7 @@
 
 <h2 id="Roadmap">Go Roadmap</h2>
 
+<p>
 This page lists features and ideas being developed or discussed by the
 Go team.  This list will be updated as work continues.
 
@@ -26,6 +27,9 @@ Variant types.  A way to define a type as being the union of some set
 of types.
 <li>
 Generics.  An active topic of discussion.
+<li>
+Methods for operators, to allow a type to use arithmetic notation for
+expressions.
 </ul>
 
 <h3 id="Implementation_roadmap">
@@ -38,14 +42,10 @@ with a cycle detector running in a separate core.
 <li>
 Debugger.
 <li>
-Native Client (NaCl) support.
-<li>
 App Engine support.
 <li>
 Improved CGO including some mechanism for calling back from C to Go.
 <li>
-SWIG support.
-<li>
 Improved implementation documentation.
 </ul>
 
@@ -56,28 +56,55 @@ Gc compiler roadmap</h4>
 <li>
 Implement goto restrictions.
 <li>
-Safe compilation mode: generate code that is guaranteed not to obtain
-an invalid memory address other than via <code>import "unsafe"</code>.
-<li>
-Generate ELF debug info.
-<li>
 Improved optimization.
 <li>
 5g: Better floating point support.
+<li>
+Use escape analysis to keep more data on stack.
 </ul>
 
-<h4 id = "Gccgo_roadmap">
+<h4 id="Gccgo_roadmap">
 Gccgo compiler roadmap</h4>
 
 <ul>
 <li>
 Implement goto restrictions.
 <li>
-Implement garbage collection.
-<li>
 Use goroutines rather than threads.
 <li>
 Separate gcc interface from frontend proper.
 <li>
 Use escape analysis to keep more data on stack.
 </ul>
+
+<h3 id="done">Done</h3>
+
+<ul>
+<li>
+gc: Generate DWARF debug info.
+<li>
+gc: Provide gdb support for runtime facilities.
+<li>
+Safe compilation mode: generate code that is guaranteed not to obtain an invalid memory address other than via <code>import "unsafe"</code>.
+<li>
+Gccgo: garbage collection.
+<li>
+SWIG support.
+<li>		
+Simpler semicolon rules.
+<li>		
+A more general definition of <code>...</code> in parameter lists.
+<li>		
+Explicit conversions from <code>string</code>		
+to <code>[]byte</code> and <code>[]int</code>.		
+<li>
+A function that will be run by the garbage collector when an item is freed
+(runtime.SetFinalizer).
+<li>
+Public continuous build and benchmark infrastructure (gobuilder).
+<li>
+Package manager (goinstall).
+<li>
+A means of recovering from a panic (recover).
+</ul>
+
diff --git a/doc/docs.html b/doc/docs.html
new file mode 100644
index 000000000..e8152bb35
--- /dev/null
+++ b/doc/docs.html
@@ -0,0 +1,195 @@
+<!-- title Documentation -->
+
+<div class="left-column">
+
+<h2 id="learning">Learning Go</h2>
+
+<p>
+If you're new to Go, we recommend you work through the 
+<a href="go_tutorial.html">tutorial</a>. The 
+<a href="go_spec.html">language specification</a> has all the details should
+you want to explore.
+</p>
+<p>
+Once you've learned a little about the language, 
+<a href="effective_go.html">Effective Go</a> will help you learn the style and
+idioms of programming in Go.
+</p>
+
+<h3 id="orig_tutorial"><a href="go_tutorial.html">A Tutorial for the Go Programming Language</a></h3>
+<p>
+The first tutorial. An introductory text that touches upon several core
+concepts: syntax, types, allocation, constants, I/O, sorting, printing,
+goroutines, and channels.
+</p>
+
+<h3 id="effective_go"><a href="effective_go.html">Effective Go</a></h3>
+<p>
+A document that gives tips for writing clear, idiomatic Go code.
+A must read for any new Go programmer. It augments the tutorial and
+the language specification, both of which should be read first.
+</p>
+
+<h3 id="go_faq"><a href="go_faq.html">Frequently Asked Questions (FAQ)</a></h3>
+<p>
+Answers to common questions about Go.
+</p>
+
+<h3 id="code"><a href="code.html">How to write Go code</a></h3>
+<p>
+How to write a new package and how to test code.
+</p>
+
+<h3 id="codelab_wiki"><a href="codelab/wiki/">Codelab: Writing Web Applications</a></h3>
+<p>
+This codelab takes the reader through the creation of a simple wiki web 
+application. It touches on structs, methods, file I/O, http, regular expressions,
+and closures.
+</p>
+
+<h3 id="codewalks"><a href="codewalk/">Codewalks</a></h3>
+<p>
+Guided tours of Go programs. 
+</p>
+
+<h3 id="go_for_cpp_programmers"><a href="go_for_cpp_programmers.html">Go for C++ Programmers</a></h3>
+<p>
+An introduction to Go for C++ programmers.
+</p>
+
+<h2 id="tutorials_nonenglish">Non-English Documentation</h2>
+
+<h3 id="docs_cn">Chinese &mdash; 中文</h3>
+
+<ul>
+<li><a href="http://code.google.com/p/golang-china/">golang-china</a> - a broad range of Go documentation.</li>
+<li><a href="http://code.google.com/p/ac-me/downloads/detail?name=fango.pdf">Effective Go and Tutorial</a></li>
+</ul>
+
+<h3 id="docs_de">German &mdash; Deutsch</h3>
+
+<ul>
+<li><a href="http://bitloeffel.de/DOC/golang/go_tutorial_de.html">Eine Anleitung zum Programmieren in Go</a> - the Go Tutorial.</li>
+<li><a href="http://bitloeffel.de/DOC/golang/effective_go_de.html">Wirkungsvoll Go programmieren</a> - Effective Go.</li>
+<li><a href="http://bitloeffel.de/DOC/golang/code_de.html">Wie man Go-Kode schreibt</a> - How to Write Go Code.</li>
+</ul>
+
+<h3 id="docs_jp">Japanese &mdash; 日本語</h3>
+<ul>
+<li><a href="http://golang.jp/">golang.jp</a> - Go documentation and news.
+</ul>
+
+<h3 id="docs_ru">Russian &mdash; Русский</h3>
+<ul>
+<li><a href="http://golanguage.ru/">golanguage.ru</a> - Go documentation.
+</ul>
+
+</div>
+
+
+<div class="right-column">
+
+<h2 id="References">References</h2>
+
+<p>Keep these under your pillow.</p>
+
+<h3 id="pkg"><a href="/pkg/">Package Documentation</a></h3>
+<p>
+The built-in documentation for the Go standard library.
+</p>
+
+<h3 id="cmd"><a href="/cmd/">Command Documentation</a></h3>
+<p>
+The built-in documentation for the Go tools.
+</p>
+
+<h3 id="spec"><a href="go_spec.html">Language Specification</a></h3>
+<p>
+The official Go Language specification. 
+</p>
+
+<h3 id="go_mem"><a href="go_mem.html">The Go Memory Model</a></h3>
+<p>
+A document that specifies the conditions under which reads of a variable in
+one goroutine can be guaranteed to observe values produced by writes to the
+same variable in a different goroutine.
+</p>
+
+<h2 id="videos_talks">Videos and Talks</h2>
+
+<h3 id="go_programming"><a href="http://www.youtube.com/watch?v=jgVhBThJdXc">Go Programming</a></h3>
+<p>
+A presentation delivered by Rob Pike and Russ Cox at Google I/O 2010.  It
+illustrates how programming in Go differs from other languages through a set of
+examples demonstrating features particular to Go.  These include concurrency,
+embedded types, methods on any type, and program construction using interfaces. 
+</p>
+
+<h3 id="practical_go_programming"><a href="http://osdc.blip.tv/file/4432146/">Practical Go Programming</a></h3>
+<p>
+This talk presents the development of a complete web application in Go.
+It looks at design, storage, concurrency, and scaling issues in detail, using
+the simple example of an URL shortening service.
+See the <a href="http://wh3rd.net/practical-go/">presentation slides</a>.
+</p>
+
+<h3 id="techtalk"><a href="http://www.youtube.com/watch?v=rKnDgT73v8s">The Go Tech Talk</a></h3>
+<p>
+An hour-long talk delivered by Rob Pike at Google in October 2009. 
+The language's first public introduction. (See the <a href="talks/go_talk-20091030.pdf">slides in PDF format</a>.) The language has changed since it was made,
+but it's still a good introduction.
+</p>
+
+<h3 id="gocoding_channel"><a href="http://www.youtube.com/gocoding">gocoding YouTube Channel</a></h3>
+<p>
+A YouTube channel that includes screencasts and other Go-related videos:
+</p>
+<ul>
+<li><a href="http://www.youtube.com/gocoding#p/u/0/jDWBJOXs_iI">Screencast: Writing Go Packages</a> - writing, building, and distributing Go packages.</li>
+<li><a href="http://www.youtube.com/watch?v=3brH0zOqm0w">Screencast: Testing Go Packages</a> - writing unit tests and benchmarking Go packages.</li>
+</ul>
+
+<h3 id="jaoo_go"><a href="/doc/ExpressivenessOfGo.pdf">The Expressiveness Of Go</a></h3>
+<p>
+A discussion of the qualities that make Go an expressive and comprehensible
+language.  The talk was presented by Rob Pike at JAOO 2010.
+The recording of the event was lost due to a hardware error.
+</p>
+
+<h3 id="oscon_go"><a href="http://www.oscon.com/oscon2010/public/schedule/detail/14760">Another Go at Language Design</a></h3>
+<p>
+A tour, with some background, of the major features of Go, intended for
+an audience new to the language.  The talk was presented at OSCON 2010.
+See the <a href="http://assets.en.oreilly.com/1/event/45/Another%20Go%20at%20Language%20Design%20Presentation.pdf">presentation slides</a>.
+</p>
+<p>
+This talk was also delivered at Sydney University in September 2010. A video
+of the lecture is available 
+<a href="http://sydney.edu.au/engineering/it/videos/seminar_pike">here</a>.
+</p>
+
+<h3 id="emerging_go"><a href="http://www.oscon.com/oscon2010/public/schedule/detail/15464">Go Emerging Languages Conference Talk</a></h3>
+<p>
+Rob Pike's Emerging Languages Conference presentation delivered in July 2010. See the <a href="http://assets.en.oreilly.com/1/event/45/Go%20Presentation.pdf">presentation slides</a>. Abstract:
+</p>
+<p><i>
+Go’s approach to concurrency differs from that of many languages, even those
+(such as Erlang) that make concurrency central, yet it has deep roots. The path
+from Hoare’s 1978 paper to Go provides insight into how and why Go works as it
+does.
+</i></p>
+
+<h3 id="emerging_go"><a href="talks/gofrontend-gcc-summit-2010.pdf">The Go frontend for GCC</a></h3>
+<p>
+A description of the Go language frontend for gcc.
+Ian Lance Taylor's paper delivered at the GCC Summit 2010.
+</p>
+
+<h3 id="promo_video"><a href="http://www.youtube.com/watch?v=wwoWei-GAPo">The Go Promo Video</a></h3>
+<p>
+A short promotional video featuring Russ Cox demonstrating Go's fast compiler.
+</p>
+
+</div>
+
+<div class="end-columns"></div>
diff --git a/doc/effective_go.html b/doc/effective_go.html
index 41a7b8af9..26e317b5d 100644
--- a/doc/effective_go.html
+++ b/doc/effective_go.html
@@ -207,7 +207,7 @@ have a doc comment.
 </p>
 
 <p>
-Doc comments work best as complete English sentences, which allow
+Doc comments work best as complete sentences, which allow
 a wide variety of automated presentations.
 The first sentence should be a one-sentence summary that
 starts with the name being declared.
@@ -463,7 +463,7 @@ statement, it's common to see one used to set up a local variable.
 
 <pre>
 if err := file.Chmod(0664); err != nil {
-    log.Stderr(err)
+    log.Print(err)
     return err
 }
 </pre>
@@ -794,7 +794,7 @@ func Contents(filename string) (string, os.Error) {
     buf := make([]byte, 100)
     for {
         n, err := f.Read(buf[0:])
-        result = bytes.Add(result, buf[0:n])
+        result = append(result, buf[0:n]...) // append is discussed later.
         if err != nil {
             if err == os.EOF {
                 break
@@ -815,7 +815,7 @@ which is much clearer than placing it at the end of the function.
 </p>
 
 <p>
-The arguments to the deferred function (which includes the receiver if
+The arguments to the deferred function (which include the receiver if
 the function is a method) are evaluated when the <i>defer</i>
 executes, not when the <i>call</i> executes.  Besides avoiding worries
 about variables changing values as the function executes, this means
@@ -1218,6 +1218,11 @@ func Append(slice, data[]byte) []byte {
 We must return the slice afterwards because, although <code>Append</code>
 can modify the elements of <code>slice</code>, the slice itself (the run-time data
 structure holding the pointer, length, and capacity) is passed by value.
+<p>
+The idea of appending to a slice is so useful it's captured by the
+<code>append</code> built-in function.  To understand that function's
+design, though, we need a little more information, so we'll return
+to it later.
 </p>
 
 
@@ -1288,7 +1293,7 @@ func offset(tz string) int {
     if seconds, ok := timeZone[tz]; ok {
         return seconds
     }
-    log.Stderr("unknown time zone", tz)
+    log.Println("unknown time zone", tz)
     return 0
 }
 </pre>
@@ -1326,13 +1331,15 @@ You don't need to provide a format string.  For each of <code>Printf</code>,
 <code>Fprintf</code> and <code>Sprintf</code> there is another pair
 of functions, for instance <code>Print</code> and <code>Println</code>.
 These functions do not take a format string but instead generate a default
-format for each argument. The <code>ln</code> version also inserts a blank
-between arguments if neither is a string and appends a newline to the output.
+format for each argument. The <code>Println</code> versions also insert a blank
+between arguments and append a newline to the output while
+the <code>Print</code> versions add blanks only if the operand on neither side is a string.
 In this example each line produces the same output.
 </p>
 <pre>
 fmt.Printf("Hello %d\n", 23)
 fmt.Fprint(os.Stdout, "Hello ", 23, "\n")
+fmt.Println("Hello", 23)
 fmt.Println(fmt.Sprint("Hello ", 23))
 </pre>
 <p>
@@ -1453,16 +1460,20 @@ Within the function <code>Printf</code>, <code>v</code> acts like a variable of
 <code>[]interface{}</code> but if it is passed to another variadic function, it acts like
 a regular list of arguments.
 Here is the implementation of the
-function <code>log.Stderr</code> we used above. It passes its arguments directly to
+function <code>log.Println</code> we used above. It passes its arguments directly to
 <code>fmt.Sprintln</code> for the actual formatting.
 </p>
 <pre>
-// Stderr is a helper function for easy logging to stderr. It is analogous to Fprintln(os.Stderr).
-func Stderr(v ...interface{}) {
-    stderr.Output(2, fmt.Sprintln(v))  // Output takes parameters (int, string)
+// Println prints to the standard logger in the manner of fmt.Println.
+func Println(v ...interface{}) {
+    std.Output(2, fmt.Sprintln(v...))  // Output takes parameters (int, string)
 }
 </pre>
 <p>
+We write <code>...</code> after <code>v</code> in the nested call to <code>Sprintln</code> to tell the
+compiler to treat <code>v</code> as a list of arguments; otherwise it would just pass
+<code>v</code> as a single slice argument.
+<p>
 There's even more to printing than we've covered here.  See the <code>godoc</code> documentation
 for package <code>fmt</code> for the details.
 </p>
@@ -1482,6 +1493,47 @@ func Min(a ...int) int {
 }
 </pre>
 
+<h3 id="append">Append</h3>
+<p>
+Now we have the missing piece we needed to explain the design of
+the <code>append</code> built-in function.  The signature of <code>append</code>
+is different from our custom <code>Append</code> function above.
+Schematically, it's like this:
+<pre>
+func append(slice []<i>T</i>, elements...T) []<i>T</i>
+</pre>
+where <i>T</i> is a placeholder for any given type.  You can't
+actually write a function in Go where the type <code>T</code>
+is determined by the caller.
+That's why <code>append</code> is built in: it needs support from the
+compiler.
+<p>
+What <code>append</code> does is append the elements to the end of
+the slice and return the result.  The result needs to be returned
+because, as with our hand-written <code>Append</code>, the underlying
+array may change.  This simple example
+<pre>
+x := []int{1,2,3}
+x = append(x, 4, 5, 6)
+fmt.Println(x)
+</pre>
+prints <code>[1 2 3 4 5 6]</code>.  So <code>append</code> works a
+little like <code>Printf</code>, collecting an arbitrary number of
+arguments.
+<p>
+But what if we wanted to do what our <code>Append</code> does and
+append a slice to a slice?  Easy: use <code>...</code> at the call
+site, just as we did in the call to <code>Output</code> above.  This
+snippet produces identical output to the one above.
+<pre>
+x := []int{1,2,3}
+y := []int{4,5,6}
+x = append(x, y...)
+fmt.Println(x)
+</pre>
+Without that <code>...</code>, it wouldn't compile because the types
+would be wrong; <code>y</code> is not of type <code>int</code>.
+
 <h2 id="initialization">Initialization</h2>
 
 <p>
@@ -1537,26 +1589,29 @@ automatically for printing, even as part of a general type.
 func (b ByteSize) String() string {
     switch {
     case b &gt;= YB:
-        return fmt.Sprintf("%.2fYB", b/YB)
+        return fmt.Sprintf("%.2fYB", float64(b/YB))
     case b &gt;= ZB:
-        return fmt.Sprintf("%.2fZB", b/ZB)
+        return fmt.Sprintf("%.2fZB", float64(b/ZB))
     case b &gt;= EB:
-        return fmt.Sprintf("%.2fEB", b/EB)
+        return fmt.Sprintf("%.2fEB", float64(b/EB))
     case b &gt;= PB:
-        return fmt.Sprintf("%.2fPB", b/PB)
+        return fmt.Sprintf("%.2fPB", float64(b/PB))
     case b &gt;= TB:
-        return fmt.Sprintf("%.2fTB", b/TB)
+        return fmt.Sprintf("%.2fTB", float64(b/TB))
     case b &gt;= GB:
-        return fmt.Sprintf("%.2fGB", b/GB)
+        return fmt.Sprintf("%.2fGB", float64(b/GB))
     case b &gt;= MB:
-        return fmt.Sprintf("%.2fMB", b/MB)
+        return fmt.Sprintf("%.2fMB", float64(b/MB))
     case b &gt;= KB:
-        return fmt.Sprintf("%.2fKB", b/KB)
+        return fmt.Sprintf("%.2fKB", float64(b/KB))
     }
-    return fmt.Sprintf("%.2fB", b)
+    return fmt.Sprintf("%.2fB", float64(b))
 }
 </pre>
 <p>
+(The <code>float64</code> conversions prevent <code>Sprintf</code> 
+from recurring back through the <code>String</code> method for 
+<code>ByteSize</code>.)
 The expression <code>YB</code> prints as <code>1.00YB</code>,
 while <code>ByteSize(1e13)</code> prints as <code>9.09TB</code>.
 </p>
@@ -1849,10 +1904,18 @@ that implements <code>Handler</code> can serve HTTP requests.
 </p>
 <pre>
 type Handler interface {
-    ServeHTTP(*Conn, *Request)
+    ServeHTTP(ResponseWriter, *Request)
 }
 </pre>
 <p>
+<code>ResponseWriter</code> is itself an interface that provides access
+to the methods needed to return the response to the client.
+Those methods include the standard <code>Write</code> method, so an
+<code>http.ResponseWriter</code> can be used wherever an <code>io.Writer</code>
+can be used.
+<code>Request</code> is a struct containing a parsed representation
+of the request from the client.
+<p>
 For brevity, let's ignore POSTs and assume HTTP requests are always
 GETs; that simplification does not affect the way the handlers are
 set up.  Here's a trivial but complete implementation of a handler to
@@ -1865,13 +1928,14 @@ type Counter struct {
     n int
 }
 
-func (ctr *Counter) ServeHTTP(c *http.Conn, req *http.Request) {
+func (ctr *Counter) ServeHTTP(w http.ResponseWriter, req *http.Request) {
     ctr.n++
-    fmt.Fprintf(c, "counter = %d\n", ctr.n)
+    fmt.Fprintf(w, "counter = %d\n", ctr.n)
 }
 </pre>
 <p>
-(Keeping with our theme, note how <code>Fprintf</code> can print to an HTTP connection.)
+(Keeping with our theme, note how <code>Fprintf</code> can print to an
+<code>http.ResponseWriter</code>.)
 For reference, here's how to attach such a server to a node on the URL tree.
 <pre>
 import "http"
@@ -1887,9 +1951,9 @@ But why make <code>Counter</code> a struct?  An integer is all that's needed.
 // Simpler counter server.
 type Counter int
 
-func (ctr *Counter) ServeHTTP(c *http.Conn, req *http.Request) {
+func (ctr *Counter) ServeHTTP(w http.ResponseWriter, req *http.Request) {
     *ctr++
-    fmt.Fprintf(c, "counter = %d\n", *ctr)
+    fmt.Fprintf(w, "counter = %d\n", *ctr)
 }
 </pre>
 <p>
@@ -1901,9 +1965,9 @@ has been visited?  Tie a channel to the web page.
 // (Probably want the channel to be buffered.)
 type Chan chan *http.Request
 
-func (ch Chan) ServeHTTP(c *http.Conn, req *http.Request) {
+func (ch Chan) ServeHTTP(w http.ResponseWriter, req *http.Request) {
     ch &lt;- req
-    fmt.Fprint(c, "notification sent")
+    fmt.Fprint(w, "notification sent")
 }
 </pre>
 <p>
@@ -1930,11 +1994,11 @@ The <code>http</code> package contains this code:
 // ordinary functions as HTTP handlers.  If f is a function
 // with the appropriate signature, HandlerFunc(f) is a
 // Handler object that calls f.
-type HandlerFunc func(*Conn, *Request)
+type HandlerFunc func(ResponseWriter, *Request)
 
 // ServeHTTP calls f(c, req).
-func (f HandlerFunc) ServeHTTP(c *Conn, req *Request) {
-    f(c, req)
+func (f HandlerFunc) ServeHTTP(w ResponseWriter, req *Request) {
+    f(w, req)
 }
 </pre>
 <p>
@@ -1950,9 +2014,9 @@ to have the right signature.
 </p>
 <pre>
 // Argument server.
-func ArgServer(c *http.Conn, req *http.Request) {
+func ArgServer(w http.ResponseWriter, req *http.Request) {
     for i, s := range os.Args {
-        fmt.Fprintln(c, s)
+        fmt.Fprintln(w, s)
     }
 }
 </pre>
@@ -2014,7 +2078,7 @@ two methods explicitly, but it's easier and more evocative
 to embed the two interfaces to form the new one, like this:
 </p>
 <pre>
-// ReadWrite is the interface that groups the basic Read and Write methods.
+// ReadWriter is the interface that combines the Reader and Writer interfaces.
 type ReadWriter interface {
     Reader
     Writer
@@ -2119,7 +2183,7 @@ func NewJob(command string, logger *log.Logger) *Job {
 or with a composite literal,
 </p>
 <pre>
-job := &amp;Job{command, log.New(os.Stderr, nil, "Job: ", log.Ldate)}
+job := &amp;Job{command, log.New(os.Stderr, "Job: ", log.Ldate)}
 </pre>
 <p>
 If we need to refer to an embedded field directly, the type name of the field,
@@ -2603,7 +2667,7 @@ func CubeRoot(x float64) float64 {
         }
     }
     // A million iterations has not converged; something is wrong.
-    panic(fmt.Sprintf("CubeRoot(%g) did not converge", x)
+    panic(fmt.Sprintf("CubeRoot(%g) did not converge", x))
 }
 </pre>
 
@@ -2654,14 +2718,14 @@ inside a server without killing the other executing goroutines.
 <pre>
 func server(workChan <-chan *Work) {
     for work := range workChan {
-        safelyDo(work)
+        go safelyDo(work)
     }
 }
 
 func safelyDo(work *Work) {
     defer func() {
         if err := recover(); err != nil {
-            log.Stderr("work failed:", err)
+            log.Println("work failed:", err)
         }
     }()
     do(work)
@@ -2728,7 +2792,7 @@ user-triggered errors.
 </p>
 
 <p>
-With this error handling in place, the <code>error</code> method
+With error handling in place, the <code>error</code> method
 makes it easy to report parse errors without worrying about unwinding
 the parse stack by hand.
 </p>
@@ -2740,6 +2804,17 @@ Useful though this pattern is, it should be used only within a package.
 to its client.  That is a good rule to follow.
 </p>
 
+<p>
+By the way, this re-panic idiom changes the panic value if an actual
+error occurs.  However, both the original and new failures will be
+presented in the crash report, so the root cause of the problem will
+still be visible.  Thus this simple re-panic approach is usually
+sufficient&mdash;it's a crash after all&mdash;but if you want to
+display only the original value, you can write a little more code to
+filter unexpected problems and re-panic with the original error.
+That's left as an exercise for the reader.
+</p>
+
 
 <h2 id="web_server">A web server</h2>
 
@@ -2789,12 +2864,12 @@ func main() {
     }
 }
 
-func QR(c *http.Conn, req *http.Request) {
-    templ.Execute(req.FormValue("s"), c)
+func QR(w http.ResponseWriter, req *http.Request) {
+    templ.Execute(req.FormValue("s"), w)
 }
 
-func UrlHtmlFormatter(w io.Writer, v interface{}, fmt string) {
-    template.HTMLEscape(w, []byte(http.URLEscape(v.(string))))
+func UrlHtmlFormatter(w io.Writer, fmt string, v ...interface{}) {
+    template.HTMLEscape(w, []byte(http.URLEscape(v[0].(string))))
 }
 
 
diff --git a/doc/frontpage.css b/doc/frontpage.css
new file mode 100644
index 000000000..bcdca6401
--- /dev/null
+++ b/doc/frontpage.css
@@ -0,0 +1,140 @@
+/* Overloads to all.css */
+#container { width: 76em }
+.left-column { width: 48%; }
+.right-column { width: 48%; }
+
+/* Frontpage styles */
+#content-introductory code {
+  font-family: "Bitstream Vera Sans Mono", "Andale Mono", monospace;
+}
+#content-introductory input, select, textarea {
+  font-family: "Bitstream Vera Sans", Verdana, sans-serif;
+  font-size: 1em;
+}
+span.keyword {
+  font-family: Cambria, Georgia, Times, "Times New Roman", serif;
+  font-size: 1.15em;
+  font-style: italic;
+}
+#content h3, #content h2 {
+  margin: 0;
+  font-size: 1em;
+  background: none;
+  border: none;
+  padding: 0;
+}
+#content .more {
+ color: #999;
+ font-weight: normal;
+}
+#frontpage h2#branding-tagline {
+	font-weight: normal;
+	font-style: italic;
+}
+#resources {
+  position: relative;
+  margin-top: 1em;
+}
+#resources h3 {
+  margin-top: 0; 
+  margin-bottom: -.5em;
+  font-size: 1em;
+  font-weight: normal;
+}
+#resources-users {
+  float: left;
+  width: 48%;
+}
+#resources-contributors {
+  float: right;
+  width: 50%;
+}
+#resources ul {
+  padding-left: 2em;
+}
+#resources li {
+  margin-bottom: 0.5em;
+}
+#content-rotating {
+  height: 200px;
+}
+#content-videos {
+  float: left;
+  width: 170px;
+}
+#content-videos .thumbnail {
+  width: 150px;
+  height: 103px;
+  background-repeat: no-repeat;
+  border: none;
+}
+#content-videos .thumbnail._001 {
+  background: url(/doc/video-001.png);
+}
+#content-videos .thumbnail._002 {
+  background: url(/doc/video-002.png);
+}
+#content-videos .thumbnail._003 {
+  background: url(/doc/video-003.png);
+}
+#content-videos .thumbnail._004 {
+  background: url(/doc/video-004.png);
+}
+#content-videos a.video {
+  display: inline-block;
+  width: 150px;
+  margin-right: .30em;
+  margin-top: 1.2em;
+}                        
+#content-videos a.video .caption {
+  display: block;
+  text-align: center;
+}
+#content-videos a.video .caption.title {
+  margin-top: .31em;
+  font-weight: bold;
+}
+#content-blog ul {
+  margin-top: 1em;
+  margin-left: 0;
+  padding-left: 0;
+}
+#content-blog li {
+  list-style: none;
+  margin-bottom: 1em;
+}
+#content-blog li a {
+  color: #999;
+  text-decoration: none;
+}
+#content-blog .date {
+  color: #999;
+  font-size: 0.8em;
+  display: inline-block;
+  margin-left: 0.5em;
+}
+#content-blog li a:link .title {
+  color: #04a;
+}
+#content-blog li a:visited .title {
+  color: #04a;
+}
+#content-blog li a:hover .title {
+  color: #a40;
+  text-decoration: underline;
+}
+#content-blog li a:active .title {
+  color: #c00;
+}
+.navtop {
+  display: none !important;
+}
+.how {
+  float: right;
+  font-size: 75%;
+}
+.unsupported {
+  font-weight: bold;
+  color: red;
+}
+
diff --git a/doc/gccgo_install.html b/doc/gccgo_install.html
index 3ffd6a645..393e57963 100644
--- a/doc/gccgo_install.html
+++ b/doc/gccgo_install.html
@@ -224,12 +224,9 @@ gccgo -o main main.o mypackage.o   # Explicitly links with mypackage.o
 
 <p>
 Some Go features are not yet implemented in <code>gccgo</code>.  As of
-2009-11-06, the following are not implemented:
+2010-08-23, the following are not implemented:
 
 <ul>
-<li>Garbage collection is not implemented. There is no way to free memory.
-    Thus long running programs are not supported.
-
 <li>goroutines are implemented as NPTL threads.  If you can not use
     the gold linker as described above, they are created with a fixed
     stack size, and the number of goroutines that may be created at
@@ -263,14 +260,13 @@ Pointers in Go are pointers in C. A Go <code>struct</code> is the same as C
 <code>struct</code> with the same fields and types.
 
 <p>
-The Go <code>string</code> type is a pointer to a structure.
-The current definition is
-(this is <b style="color: red;">expected to change</b>):
+The Go <code>string</code> type is currently defined as a two-element
+structure (this is <b style="color: red;">subject to change</b>):
 
 <pre>
 struct __go_string {
-  size_t __length;
-  unsigned char __data[];
+  const unsigned char *__data;
+  int __length;
 };
 </pre>
 
@@ -310,9 +306,10 @@ when the functions have equivalent types.
 
 <p>
 Go <code>interface</code>, <code>channel</code>, and <code>map</code>
-types have no corresponding C type (they roughly correspond to pointers
-to structs in C, but the structs are deliberately undocumented). C
-<code>enum</code> types correspond to some Go type, but precisely
+types have no corresponding C type (<code>interface</code> is a
+two-element struct and <code>channel</code> and <code>map</code> are
+pointers to structs in C, but the structs are deliberately undocumented). C
+<code>enum</code> types correspond to some integer type, but precisely
 which one is difficult to predict in general; use a cast. C <code>union</code>
 types have no corresponding Go type. C <code>struct</code> types containing
 bitfields have no corresponding Go type. C++ <code>class</code> types have
@@ -359,12 +356,15 @@ i := c_open(&amp;name[0], os.O_RDONLY, 0);
 <p>
 The name of Go functions accessed from C is subject to change. At present
 the name of a Go function that does not have a receiver is
-<code>package.Functionname</code>. To call it from C you must set the
-name using a <code>gcc</code> extension similar to the <code>gccgo</code>
+<code>prefix.package.Functionname</code>. The prefix is set by
+the <code>-fgo-prefix</code> option used when the package is compiled;
+if the option is not used, the default is simply <code>go</code>.
+To call the function from C you must set the name using
+a <code>gcc</code> extension similar to the <code>gccgo</code>
 extension.
 
 <pre>
-extern int go_function(int) __asm__ ("mypackage.Function");
+extern int go_function(int) __asm__ ("myprefix.mypackage.Function");
 </pre>
 
 <h3 id="Automatic_generation_of_Go_declarations_from_C_source_code">
@@ -395,3 +395,15 @@ grep '#GO' foo.s | grep -v INVALID | grep -v unknowndefine | grep -v undef > foo
 This procedure is full of unstated caveats and restrictions and we make no
 guarantee that it will not change in the future. It is more useful as a
 starting point for real Go code than as a regular procedure.
+
+<h2 id="RTEMS_Port">RTEMS Port</h2>
+<p>
+The <code>gccgo</code> compiler has been ported to <a href="http://www.rtems.com/">
+<code>RTEMS</code></a>. <code>RTEMS</code> is a real-time executive
+that provides a high performance environment for embedded applications
+on a range of processors and embedded hardware. The current <code>gccgo</code>
+port is for x86. The goal is to extend the port to most of the
+<a href="http://www.rtems.org/wiki/index.php/SupportedCPUs">
+architectures supported by <code>RTEMS</code></a>. For more information on the port,
+as well as instructions on how to install it, please see this
+<a href="http://www.rtems.com/wiki/index.php/GCCGoRTEMS"><code>RTEMS</code> Wiki page</a>.
diff --git a/doc/go_faq.html b/doc/go_faq.html
index 4f11baa80..1c7b85ef8 100644
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -56,6 +56,21 @@ What is the origin of the name?</h3>
 <p>
 &ldquo;Ogle&rdquo; would be a good name for a Go debugger.
 
+<h3 id="Whats_the_origin_of_the_mascot">
+What's the origin of the mascot?</h3>
+
+<p>
+The mascot and logo were designed by
+<a href="http://reneefrench.blogspot.com">Renée French</a>, who also designed
+<a href="http://plan9.bell-labs.com/plan9/glenda.html">Glenda</a>,
+the Plan 9 bunny.
+The gopher is derived from one she used for an <a href="http://wfmu.org/">WFMU</a>
+T-shirt design some years ago.
+The logo and mascot are covered by the
+<a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a>
+license.
+</p>
+
 <h3 id="What_kind_of_a_name_is_6g">
 What kind of a name is 6g?</h3>
 
@@ -69,42 +84,102 @@ http://plan9.bell-labs.com/sys/doc/compiler.html</a>
 <code>6</code> is the architecture letter for amd64 (or x86-64, if you prefer), while
 <code>g</code> stands for Go.
 
-<h3 id="Why_not_just_write_some_libraries_for_Cpp_to_do_communication">
-Why not just write some libraries for C++ to do communication?</h3>
+<h3 id="history">
+What is the history of the project?</h3>
+<p>
+Robert Griesemer, Rob Pike and Ken Thompson started sketching the
+goals for a new language on the white board on September 21, 2007.
+Within a few days the goals had settled into a plan to do something
+and a fair idea of what it would be.  Design continued part-time in
+parallel with unrelated work.  By January 2008, Ken had started work
+on a compiler with which to explore ideas; it generated C code as its
+output.  By mid-year the language had become a full-time project and
+had settled enough to attempt a production compiler.  In May 2008,
+Ian Taylor independently started on a GCC front end for Go using the
+draft specification.  Russ Cox joined in late 2008 and helped move the language
+and libraries from prototype to reality.
+</p>
 
-<p>We considered doing that, but too many of the problems&mdash;lack of
-garbage collection, long dependency chains, nested include files,
-lack of concurrency awareness&mdash;are rooted in the design of
-the C and C++ languages themselves.
-We felt a viable solution required a more complete approach.
+<p>
+Many others have contributed ideas, discussions, and code.
+</p>
 
-<h3 id="Why_doesnt_Go_run_on_Windows">
-Why doesn't Go run on Windows yet?</h3>
 
+<h3 id="creating_a_new_language">
+Why are you creating a new language?</h3>
 <p>
-We understand that a significant fraction of computers in the world
-run Windows and it would be great if those computers could run Go
-programs.  A group of volunteers has made significant progress toward 
-porting Go to <a href="http://www.mingw.org/">MinGW</a>.
-You can follow their progress at the Go Wiki's
-<a href="http://code.google.com/p/go/wiki/WindowsPort">WindowsPort</a> page.
+Go was born out of frustration with existing languages and
+environments for systems programming.  Programming had become too
+difficult and the choice of languages was partly to blame.  One had to
+choose either efficient compilation, efficient execution, or ease of
+programming; all three were not available in the same mainstream
+language.  Programmers who could were choosing ease over
+safety and efficiency by moving to dynamically typed languages such as
+Python and JavaScript rather than C++ or, to a lesser extent, Java.
+</p>
+<p>
+Go is an attempt to combine the ease of programming of an interpreted,
+dynamically typed
+language with the efficiency and safety of a statically typed, compiled language.
+It also aims to be modern, with support for networked and multicore
+computing.  Finally, it is intended to be <i>fast</i>: it should take
+at most a few seconds to build a large executable on a single computer.
+To meet these goals required addressing a number of
+linguistic issues: an expressive but lightweight type system;
+concurrency and garbage collection; rigid dependency specification;
+and so on.  These cannot be addressed well by libraries or tools; a new
+language was called for.
 </p>
 
-<h3 id="Whats_the_origin_of_the_mascot">
-What's the origin of the mascot?</h3>
 
+<h3 id="ancestors">
+What are Go's ancestors?</h3>
 <p>
-The mascot and logo were designed by
-<a href="http://reneefrench.blogspot.com">Renée French</a>, who also designed
-<a href="http://plan9.bell-labs.com/plan9/glenda.html">Glenda</a>,
-the Plan 9 bunny.
-The gopher is derived from one she used for an <a href="http://wfmu.org/">WFMU</a>
-T-shirt design some years ago.
-The logo and mascot are covered by the
-<a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a>
-license.
+Go is mostly in the C family (basic syntax),
+with significant input from the Pascal/Modula/Oberon
+family (declarations, packages),
+plus some ideas from languages
+inspired by Tony Hoare's CSP,
+such as Newsqueak and Limbo (concurrency).
+However, it is a new language across the board.
+In every respect the language was designed by thinking
+about what programmers do and how to make programming, at least the
+kind of programming we do, more effective, which means more fun.
+</p>
+
+
+<h3 id="principles">
+What are the guiding principles in the design?</h3>
+<p>
+Programming today involves too much bookkeeping, repetition, and
+clerical work.  As Dick Gabriel says, &ldquo;Old programs read
+like quiet conversations between a well-spoken research worker and a
+well-studied mechanical colleague, not as a debate with a compiler.
+Who'd have guessed sophistication bought such noise?&rdquo;
+The sophistication is worthwhile&mdash;no one wants to go back to
+the old languages&mdash;but can it be more quietly achieved?
+</p>
+<p>
+Go attempts to reduce the amount of typing in both senses of the word.
+Throughout its design, we have tried to reduce clutter and
+complexity.  There are no forward declarations and no header files;
+everything is declared exactly once.  Initialization is expressive,
+automatic, and easy to use.  Syntax is clean and light on keywords.
+Stuttering (<code>foo.Foo* myFoo = new(foo.Foo)</code>) is reduced by
+simple type derivation using the <code>:=</code>
+declare-and-initialize construct.  And perhaps most radically, there
+is no type hierarchy: types just <i>are</i>, they don't have to
+announce their relationships.  These simplifications allow Go to be
+expressive yet comprehensible without sacrificing, well, sophistication.
+</p>
+<p>
+Another important principle is to keep the concepts orthogonal.
+Methods can be implemented for any type; structures represent data while
+interfaces represent abstraction; and so on.  Orthogonality makes it
+easier to understand what happens when things combine.
 </p>
 
+
 <h2 id="Usage">Usage</h2>
 
 <h3 id="Who_should_use_the_language">
@@ -116,37 +191,31 @@ if they enjoy it. Not every programmer
 will, but we hope enough will find satisfaction in the approach it
 offers to justify further development.
 
-<h3 id="Is_Google_using_go_internally"> Is Google using Go
-internally?</h3>
+<h3 id="Is_Google_using_go_internally"> Is Google using Go internally?</h3>
 
-<p> The Go project was conceived to make it easier to write the kind
-of servers and other software Google uses internally, but the
-implementation isn't quite mature enough yet for large-scale
-production use.  While we continue development we are also doing
-experiments with the language as a candidate server environment.  It's
-getting there.  For instance, the server behind <a
-href="http://golang.org">http://golang.org</a> is a Go program; in
-fact it's just the <a href="/cmd/godoc"><code>godoc</code></a> document server running in a
-production configuration.
+<p>Yes. There are now several Go programs deployed in 
+production inside Google.  For instance, the server behind
+<a href="http://golang.org">http://golang.org</a> is a Go program; 
+in fact it's just the <a href="/cmd/godoc"><code>godoc</code></a>
+document server running in a production configuration.
 
 
 <h3 id="Do_Go_programs_link_with_Cpp_programs">
 Do Go programs link with C/C++ programs?</h3>
 
 <p>
-There are two Go compiler implementations, <code>6g</code> and friends, generically called
-<code>gc</code>, and <code>gccgo</code>.
+There are two Go compiler implementations, <code>6g</code> and friends, 
+generically called <code>gc</code>, and <code>gccgo</code>.
 <code>Gc</code> uses a different calling convention and linker and can
 therefore only be linked with C programs using the same convention.
-There is such a C compiler but no C++ compiler. <code>Gccgo</code> is a
-GCC front-end that can, with care, be linked with GCC-compiled
-C or C++ programs. However, because Go is garbage-collected it will be
-unwise to do so, at least naively.
+There is such a C compiler but no C++ compiler. 
+<code>Gccgo</code> is a GCC front-end that can, with care, be linked with 
+GCC-compiled C or C++ programs. 
 
 <p>
-There is a &ldquo;foreign function interface&rdquo; to allow safe calling of C-written
-libraries from Go code.  We expect to use SWIG to extend this capability
-to C++ libraries.  There is no safe way to call Go code from C or C++ yet.
+The <a href="/cmd/cgo/">cgo</a> program provides the mechanism for a 
+&ldquo;foreign function interface&rdquo; to allow safe calling of 
+C libraries from Go code. SWIG extends this capability to C++ libraries.
 
 <h3 id="Does_Go_support_Google_protocol_buffers">
 Does Go support Google's protocol buffers?</h3>
@@ -170,7 +239,35 @@ you will need to abide by the guidelines at
 
 <h2 id="Design">Design</h2>
 
-<h3 id="Why_doesnt_Go_have_feature_X">Why doesn't Go have feature X?</h3>
+<h3 id="unicode_identifiers">
+What's up with Unicode identifiers?</h3>
+
+<p>
+It was important to us to extend the space of identifiers from the
+confines of ASCII.  Go's rule&mdash;identifier characters must be
+letters or digits as defined by Unicode&mdash;is simple to understand
+and to implement but has restrictions.  Combining characters are
+excluded by design, for instance.
+Until there
+is an agreed external definition of what an identifier might be,
+plus a definition of canonicalization of identifiers that guarantees
+no ambiguity, it seemed better to keep combining characters out of
+the mix.  Thus we have a simple rule that can be expanded later
+without breaking programs, one that avoids bugs that would surely arise
+from a rule that admits ambiguous identifiers.
+</p>
+
+<p>
+On a related note, since an exported identifier must begin with an
+upper-case letter, identifiers created from &ldquo;letters&rdquo;
+in some languages can, by definition, not be exported.  For now the
+only solution is to use something like <code>X日本語</code>, which
+is clearly unsatisfactory; we are considering other options.  The
+case-for-visibility rule is unlikely to change however; it's one
+of our favorite features of Go.
+</p>
+
+<h3 id="Why_doesnt_Go_have_feature_X">Why does Go not have feature X?</h3>
 
 <p>
 Every language contains novel features and omits someone's favorite
@@ -186,15 +283,145 @@ If it bothers you that Go is missing feature <var>X</var>,
 please forgive us and investigate the features that Go does have. You might find that
 they compensate in interesting ways for the lack of <var>X</var>.
 
-<h3 id="Why_is_the_syntax_so_different_from_Cpp">
-Why is the syntax so different from C++?</h3>
+<h3 id="generics">
+Why does Go not have generic types?</h3>
+<p>
+Generics may well be added at some point.  We don't feel an urgency for
+them, although we understand some programmers do.
+</p>
+<p>
+Generics are convenient but they come at a cost in
+complexity in the type system and run-time.  We haven't yet found a
+design that gives value proportionate to the complexity, although we
+continue to think about it.  Meanwhile, Go's built-in maps and slices,
+plus the ability to use the empty interface to construct containers
+(with explicit unboxing) mean in many cases it is possible to write
+code that does what generics would enable, if less smoothly.
+</p>
+<p>
+This remains an open issue.
+</p>
 
+<h3 id="exceptions">
+Why does Go not have exceptions?</h3>
 <p>
-This and other language design questions are answered in
-the separate <a href="go_lang_faq.html">language design FAQ</a>.
+We believe that coupling exceptions to a control
+structure, as in the <code>try-catch-finally</code> idiom, results in
+convoluted code.  It also tends to encourage programmers to label
+too many ordinary errors, such as failing to open a file, as
+exceptional.
+</p>
+<p>
+Go takes a different approach.  Instead of exceptions, it has a couple
+of built-in functions to signal and recover from truly exceptional
+conditions.  The recovery mechanism is executed only as part of a
+function's state being torn down after an error, which is sufficient
+to handle catastrophe but requires no extra control structures and,
+when used well, can result in clean error-handling code.
+</p>
+<p>
+See the <a href="http://blog.golang.org/2010/08/defer-panic-and-recover.html">Defer, Panic, and Recover</a> article for details.
+</p>
 
-<h2 id="Object_Oriented_Programming">
-Object-Oriented Programming</h2>
+
+<h3 id="assertions">
+Why does Go not have assertions?</h3>
+
+<p>
+Go doesn't provide assertions. They are undeniably convenient, but our
+experience has been that programmers use them as a crutch to avoid thinking
+about proper error handling and reporting. Proper error handling means that
+servers continue operation after non-fatal errors instead of crashing.
+Proper error reporting means that errors are direct and to the point,
+saving the programmer from interpreting a large crash trace. Precise
+errors are particularly important when the programmer seeing the errors is
+not familiar with the code.
+
+<p>
+The same arguments apply to the use of <code>assert()</code> in test programs. Proper
+error handling means letting other tests run after one has failed, so
+that the person debugging the failure gets a complete picture of what is
+wrong. It is more useful for a test to report that
+<code>isPrime</code> gives the wrong answer for 2, 3, 5, and 7 (or for
+2, 4, 8, and 16) than to report that <code>isPrime</code> gives the wrong
+answer for 2 and therefore no more tests were run. The programmer who
+triggers the test failure may not be familiar with the code that fails.
+Time invested writing a good error message now pays off later when the
+test breaks.
+
+<p>
+In testing, if the amount of extra code required to write
+good errors seems repetitive and overwhelming, it might work better as a
+table-driven test instead.
+Go has excellent support for data structure literals.
+
+<p>
+We understand that this is a point of contention. There are many things in
+the Go language and libraries that differ from modern practices, simply
+because we feel it's sometimes worth trying a different approach.
+
+<h3 id="csp">
+Why build concurrency on the ideas of CSP?</h3>
+<p>
+Concurrency and multi-threaded programming have a reputation
+for difficulty.  We believe the problem is due partly to complex
+designs such as pthreads and partly to overemphasis on low-level details
+such as mutexes, condition variables, and even memory barriers.
+Higher-level interfaces enable much simpler code, even if there are still
+mutexes and such under the covers.
+</p>
+<p>
+One of the most successful models for providing high-level linguistic support
+for concurrency comes from Hoare's Communicating Sequential Processes, or CSP.
+Occam and Erlang are two well known languages that stem from CSP.
+Go's concurrency primitives derive from a different part of the family tree
+whose main contribution is the powerful notion of channels as first class objects.
+</p>
+
+<h3 id="goroutines">
+Why goroutines instead of threads?</h3>
+<p>
+Goroutines are part of making concurrency easy to use.  The idea, which has
+been around for a while, is to multiplex independently executing
+functions&mdash;coroutines, really&mdash;onto a set of threads.
+When a coroutine blocks, such as by calling a blocking system call,
+the run-time automatically moves other coroutines on the same operating
+system thread to a different, runnable thread so they won't be blocked.
+The programmer sees none of this, which is the point.
+The result, which we call goroutines, can be very cheap: unless they spend a lot of time
+in long-running system calls, they cost little more than the memory
+for the stack.
+</p>
+<p>
+To make the stacks small, Go's run-time uses segmented stacks.  A newly
+minted goroutine is given a few kilobytes, which is almost always enough.
+When it isn't, the run-time allocates (and frees) extension segments automatically.
+The overhead averages about three cheap instructions per function call.
+It is practical to create hundreds of thousands of goroutines in the same
+address space.  If goroutines were just threads, system resources would
+run out at a much smaller number.
+</p>
+
+<h3 id="atomic_maps">
+Why are map operations not defined to be atomic?</h3>
+
+<p>
+After long discussion it was decided that the typical use of maps did not require
+safe access from multiple threads, and in those cases where it did, the map was
+probably part of some larger data structure or computation that was already
+synchronized.  Therefore requiring that all map operations grab a mutex would slow
+down most programs and add safety to few.  This was not an easy decision,
+however, since it means uncontrolled map access can crash the program.
+</p>
+
+<p>
+The language does not preclude atomic map updates.  When required, such
+as when hosting an untrusted program, the implementation could interlock
+map access.
+</p>
+
+
+<h2 id="types">Types</h2>
 
 <h3 id="Is_Go_an_object-oriented_language">
 Is Go an object-oriented language?</h3>
@@ -220,6 +447,130 @@ How do I get dynamic dispatch of methods?</h3>
 The only way to have dynamically dispatched methods is through an
 interface. Methods on structs or other types are always resolved statically.
 
+<h3 id="inheritance">
+Why is there no type inheritance?</h3>
+<p>
+Object-oriented programming, at least in the best-known languages,
+involves too much discussion of the relationships between types,
+relationships that often could be derived automatically.  Go takes a
+different approach.
+</p>
+<p>
+Rather than requiring the programmer to declare ahead of time that two
+types are related, in Go a type automatically satisfies any interface
+that specifies a subset of its methods.  Besides reducing the
+bookkeeping, this approach has real advantages.  Types can satisfy
+many interfaces at once, without the complexities of traditional
+multiple inheritance.
+Interfaces can be very lightweight&mdash;having one or even zero methods
+in an interface can express useful concepts.
+Interfaces can be added after the fact if a new idea comes along
+or for testing&mdash;without annotating the original types.
+Because there are no explicit relationships between types
+and interfaces, there is no type hierarchy to manage or discuss.
+</p>
+<p>
+It's possible to use these ideas to construct something analogous to
+type-safe Unix pipes.  For instance, see how <code>fmt.Fprintf</code>
+enables formatted printing to any output, not just a file, or how the
+<code>bufio</code> package can be completely separate from file I/O,
+or how the <code>crypto</code> packages stitch together block and
+stream ciphers.  All these ideas stem from a single interface
+(<code>io.Writer</code>) representing a single method
+(<code>Write</code>).  And that's only scratching the surface.
+</p>
+<p>
+It takes some getting used to but this implicit style of type
+dependency is one of the most exciting things about Go.
+</p>
+
+<h3 id="methods_on_basics">
+Why is <code>len</code> a function and not a method?</h3>
+<p>
+We debated this issue but decided
+implementing <code>len</code> and friends as functions was fine in practice and
+didn't complicate questions about the interface (in the Go type sense)
+of basic types.
+</p>
+
+<h3 id="overloading">
+Why does Go not support overloading of methods and operators?</h3>
+<p>
+Method dispatch is simplified if it doesn't need to do type matching as well.
+Experience with other languages told us that having a variety of
+methods with the same name but different signatures was occasionally useful
+but that it could also be confusing and fragile in practice.  Matching only by name
+and requiring consistency in the types was a major simplifying decision
+in Go's type system.
+</p>
+<p>
+Regarding operator overloading, it seems more a convenience than an absolute
+requirement.  Again, things are simpler without it.
+</p>
+
+
+<h2 id="values">Values</h2>
+
+<h3 id="conversions">
+Why does Go not provide implicit numeric conversions?</h3>
+<p>
+The convenience of automatic conversion between numeric types in C is
+outweighed by the confusion it causes.  When is an expression unsigned?
+How big is the value?  Does it overflow?  Is the result portable, independent
+of the machine on which it executes?
+It also complicates the compiler; &ldquo;the usual arithmetic conversions&rdquo;
+are not easy to implement and inconsistent across architectures.
+For reasons of portability, we decided to make things clear and straightforward
+at the cost of some explicit conversions in the code.
+The definition of constants in Go&mdash;arbitrary precision values free
+of signedness and size annotations&mdash;ameliorates matters considerably,
+though.
+</p>
+<p>
+A related detail is that, unlike in C, <code>int</code> and <code>int64</code>
+are distinct types even if <code>int</code> is a 64-bit type.  The <code>int</code>
+type is generic; if you care about how many bits an integer holds, Go
+encourages you to be explicit.
+</p>
+
+<h3 id="builtin_maps">
+Why are maps built in?</h3>
+<p>
+The same reason strings are: they are such a powerful and important data
+structure that providing one excellent implementation with syntactic support
+makes programming more pleasant.  We believe that Go's implementation of maps
+is strong enough that it will serve for the vast majority of uses.
+If a specific application can benefit from a custom implementation, it's possible
+to write one but it will not be as convenient syntactically; this seems a reasonable tradeoff.
+</p>
+
+
+<h3 id="map_keys">
+Why don't maps allow structs and arrays as keys?</h3>
+<p>
+Map lookup requires an equality operator, which structs and arrays do not implement.
+They don't implement equality because equality is not well defined on such types;
+there are multiple considerations involving shallow vs. deep comparison, pointer vs.
+value comparison, how to deal with recursive structures, and so on.
+We may revisit this issue&mdash;and implementing equality for structs and arrays
+will not invalidate any existing programs&mdash;but without a clear idea of what
+equality of structs and arrays should mean, it was simpler to leave it out for now.
+</p>
+
+<h3 id="references">
+Why are maps, slices, and channels references while arrays are values?</h3>
+<p>
+There's a lot of history on that topic.  Early on, maps and channels
+were syntactically pointers and it was impossible to declare or use a
+non-pointer instance.  Also, we struggled with how arrays should work.
+Eventually we decided that the strict separation of pointers and
+values made the language harder to use.  Introducing reference types,
+including slices to handle the reference form of arrays, resolved
+these issues.  Reference types add some regrettable complexity to the
+language but they have a large effect on usability: Go became a more
+productive, comfortable language when they were introduced.
+</p>
+
 
 <h2 id="Writing_Code">Writing Code</h2>
 
@@ -259,41 +610,284 @@ See the document
 <a href="contribute.html">Contributing to the Go project</a>
 for more information about how to proceed.
 
-<h3 id="Where_is_assert">
-Where is assert?</h3>
+
+<h2 id="Pointers">Pointers and Allocation</h2>
+
+<h3 id="pass_by_value">
+When are function parameters passed by value?</h3>
 
 <p>
-Go doesn't provide assertions. They are undeniably convenient, but our
-experience has been that programmers use them as a crutch to avoid thinking
-about proper error handling and reporting. Proper error handling means that
-servers continue operation after non-fatal errors instead of crashing.
-Proper error reporting means that errors are direct and to the point,
-saving the programmer from interpreting a large crash trace. Precise
-errors are particularly important when the programmer seeing the errors is
-not familiar with the code.
+Everything in Go is passed by value.  A function always gets a copy of the
+thing being passed, as if there were an assignment statement assigning the
+value to the parameter.  For instance, copying a pointer value makes a copy of
+the pointer, not the data it points to. 
+</p>
 
 <p>
-The same arguments apply to the use of <code>assert()</code> in test programs. Proper
-error handling means letting other tests run after one has failed, so
-that the person debugging the failure gets a complete picture of what is
-wrong. It is more useful for a test to report that
-<code>isPrime</code> gives the wrong answer for 2, 3, 5, and 7 (or for
-2, 4, 8, and 16) than to report that <code>isPrime</code> gives the wrong
-answer for 2 and therefore no more tests were run. The programmer who
-triggers the test failure may not be familiar with the code that fails.
-Time invested writing a good error message now pays off later when the
-test breaks.
+Map and slice values behave like pointers; they are descriptors that
+contain pointers to the underlying map or slice data.  Copying a map or
+slice value doesn't copy the data it points to.  Copying an interface value
+makes a copy of the thing stored in the interface value.  If the interface
+value holds a struct, copying the interface value makes a copy of the
+struct.  If the interface value holds a pointer, copying the interface value
+makes a copy of the pointer, but again not the data it points to. 
+</p>
+
+<h3 id="methods_on_values_or_pointers">
+Should I define methods on values or pointers?</h3>
+
+<pre>
+func (s *MyStruct) someMethod() { } // method on pointer
+func (s MyStruct) someMethod() { }  // method on value
+</pre>
 
 <p>
-In testing, if the amount of extra code required to write
-good errors seems repetitive and overwhelming, it might work better as a
-table-driven test instead.
-Go has excellent support for data structure literals.
+When defining a method on a type, the receiver (<code>s</code> in the above
+example) behaves exactly is if it were an argument to the method. Define the
+method on a pointer type if you need the method to modify the data the receiver
+points to. Otherwise, it is often cleaner to define the method on a value type.
+</p>
+
+<h3 id="new_and_make">
+What's the difference between new and make?</h3>
 
 <p>
-We understand that this is a point of contention. There are many things in
-the Go language and libraries that differ from modern practices, simply
-because we feel it's sometimes worth trying a different approach.
+In short: <code>new</code> allocates memory, <code>make</code> initializes
+the slice, map, and channel types.
+</p>
+
+<p>
+See the <a href="/doc/effective_go.html#allocation_new">relevant section
+of Effective Go</a> for more details.
+</p>
+
+<h3 id="q_int_sizes">
+Why is <code>int</code> 32 bits on 64 bit machines?</h3>
+
+<p>
+The size of <code>int</code> and <code>float</code> is implementation-specific.
+The 64 bit Go compilers (both 6g and gccgo) use a 32 bit representation for
+both <code>int</code> and <code>float</code>.  Code that relies on a particular
+size of value should use an explicitly sized type, like <code>int64</code> or
+<code>float64</code>.
+</p>
+
+<h2 id="Concurrency">Concurrency</h2>
+
+<h3 id="What_operations_are_atomic_What_about_mutexes">
+What operations are atomic? What about mutexes?</h3>
+
+<p>
+We haven't fully defined it all yet, but some details about atomicity are
+available in the <a href="go_mem.html">Go Memory Model specification</a>.
+</p>
+
+<p>
+Regarding mutexes, the <a href="/pkg/sync">sync</a>
+package implements them, but we hope Go programming style will
+encourage people to try higher-level techniques. In particular, consider
+structuring your program so that only one goroutine at a time is ever
+responsible for a particular piece of data.
+</p>
+
+<p>
+Do not communicate by sharing memory. Instead, share memory by communicating.
+</p>
+
+<p>
+See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <a href="http://blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
+</p>
+
+<h3 id="Why_no_multi_CPU">
+Why doesn't my multi-goroutine program use multiple CPUs?</h3>
+
+<p>
+Under the gc compilers you must set <code>GOMAXPROCS</code> to allow the
+runtime to utilise more than one OS thread. Under <code>gccgo</code> an OS
+thread will be created for each goroutine, and <code>GOMAXPROCS</code> is
+effectively equal to the number of running goroutines.  
+</p>
+
+<p>
+Programs that perform concurrent computation should benefit from an increase in
+<code>GOMAXPROCS</code>. (See the <a
+href="http://golang.org/pkg/runtime/#GOMAXPROCS">runtime package
+documentation</a>.)
+</p>
+
+<h3 id="Why_GOMAXPROCS">
+Why does using <code>GOMAXPROCS</code> &gt; 1 sometimes make my program
+slower?</h3>
+
+<p>
+(This is specific to the gc compilers. See above.)
+</p>
+
+<p>
+It depends on the nature of your program. 
+Programs that contain several goroutines that spend a lot of time
+communicating on channels will experience performance degradation when using
+multiple OS threads. This is because of the significant context-switching
+penalty involved in sending data between threads.
+</p>
+
+<p>
+The Go runtime's scheduler is not as good as it needs to be. In future, it
+should recognise such cases and optimize its use of OS threads. For now,
+<code>GOMAXPROCS</code> should be set on a per-application basis.
+</p>
+
+
+<h2 id="Functions_methods">Functions and Methods</h2>
+
+<h3 id="different_method_sets">
+Why do T and *T have different method sets?</h3>
+
+<p>
+From the <a href="http://golang.org/doc/go_spec.html#Types">Go Spec</a>:
+</p>
+
+<blockquote>
+The method set of any other named type <code>T</code> consists of all methods
+with receiver type <code>T</code>. The method set of the corresponding pointer
+type <code>*T</code> is the set of all methods with receiver <code>*T</code> or
+<code>T</code> (that is, it also contains the method set of <code>T</code>).
+</blockquote>
+
+<p>
+If an interface value contains a pointer <code>*T</code>,
+a method call can obtain a value by dereferencing the pointer,
+but if an interface value contains a value <code>T</code>,
+there is no useful way for a method call to obtain a pointer.
+</p>
+
+<p>
+If not for this restriction, this code:
+</p>
+
+<pre>
+var buf bytes.Buffer
+io.Copy(buf, os.Stdin)
+</pre>
+
+<p>
+would copy standard input into a <i>copy</i> of <code>buf</code>,
+not into <code>buf</code> itself.
+This is almost never the desired behavior.
+</p>
+
+<h3 id="closures_and_goroutines">
+Why am I confused by the way my closures behave as goroutines?</h3>
+
+<p>
+Some confusion may arise when using closures with concurrency.
+Consider the following program:
+</p>
+
+<pre>
+func main() {
+	done := make(chan bool)
+
+	values = []string{ "a", "b", "c" }
+	for _, v := range values {
+		go func() {
+			fmt.Println(v)
+			done &lt;- true
+		}()
+	}
+
+	// wait for all goroutines to complete before exiting
+	for i := range values {
+		&lt;-done 
+	}
+}
+</pre>
+
+<p>
+One might mistakenly expect to see <code>a, b, c</code> as the output. 
+What you'll probably see instead is <code>c, c, c</code>.  This is because 
+each closure shares the same variable <code>v</code>. Each closure prints the 
+value of <code>v</code> at the time <code>fmt.Println</code> is executed, 
+rather than the value of <code>v</code> when the goroutine was launched. 
+</p>
+
+<p>
+To bind the value of <code>v</code> to each closure as they are launched, one
+could modify the inner loop to read:
+</p>
+
+<pre>
+	for _, v := range values {
+		go func(<b>u</b>) {
+			fmt.Println(<b>u</b>)
+			done &lt;- true
+		}(<b>v</b>)
+	}
+</pre>
+
+<p>
+In this example, the value of <code>v</code> is passed as an argument to the 
+anonymous function. That value is then accessible inside the function as
+the variable <code>u</code>.
+</p>
+
+<h2 id="Control_flow">Control flow</h2>
+
+<h3 id="Does_Go_have_a_ternary_form">
+Does Go have the <code>?:</code> operator?</h3>
+
+<p>
+There is no ternary form in Go. You may use the following to achieve the same
+result:
+</p>
+
+<pre>
+if expr {
+	n = trueVal
+} else {
+	n = falseVal
+}
+</pre>
+
+<h2 id="Packages_Testing">Packages and Testing</h2>
+
+<h3 id="How_do_I_create_a_multifile_package">
+How do I create a multifile package?</h3>
+
+<p>
+Put all the source files for the package in a directory by themselves.
+Source files can refer to items from different files at will; there is
+no need for forward declarations or a header file.
+</p>
+
+<p>
+Other than being split into multiple files, the package will compile and test
+just like a single-file package.
+</p>
+
+<h3 id="How_do_I_write_a_unit_test">
+How do I write a unit test?</h3>
+
+<p>
+Create a new file ending in <code>_test.go</code> in the same directory
+as your package sources. Inside that file, <code>import "testing"</code>
+and write functions of the form
+</p>
+
+<pre>
+func TestFoo(t *testing.T) {
+    ...
+}
+</pre>
+
+<p>
+Run <code>gotest</code> in that directory.
+That script finds the <code>Test</code> functions,
+builds a test binary, and runs it.
+</p>
+
+<p>See the <a href="/doc/code.html">How to Write Go Code</a> document for more details.</p>
+
 
 <h2 id="Implementation">Implementation</h2>
 
@@ -368,3 +962,143 @@ isn't fast enough yet (even if it were, taking care not to generate unnecessary
 garbage can have a huge effect).
 </p>
 
+
+<h2 id="change_from_c">Changes from C</h2>
+
+<h3 id="different_syntax">
+Why is the syntax so different from C?</h3>
+<p>
+Other than declaration syntax, the differences are not major and stem
+from two desires.  First, the syntax should feel light, without too
+many mandatory keywords, repetition, or arcana.  Second, the language
+has been designed to be easy to analyze
+and can be parsed without a symbol table.  This makes it much easier
+to build tools such as debuggers, dependency analyzers, automated
+documentation extractors, IDE plug-ins, and so on.  C and its
+descendants are notoriously difficult in this regard.
+</p>
+
+<h3 id="declarations_backwards">
+Why are declarations backwards?</h3>
+<p>
+They're only backwards if you're used to C. In C, the notion is that a
+variable is declared like an expression denoting its type, which is a
+nice idea, but the type and expression grammars don't mix very well and
+the results can be confusing; consider function pointers.  Go mostly
+separates expression and type syntax and that simplifies things (using
+prefix <code>*</code> for pointers is an exception that proves the rule).  In C,
+the declaration
+</p>
+<pre>
+	int* a, b;
+</pre>
+<p>
+declares <code>a</code> to be a pointer but not <code>b</code>; in Go
+</p>
+<pre>
+	var a, b *int;
+</pre>
+<p>
+declares both to be pointers.  This is clearer and more regular.
+Also, the <code>:=</code> short declaration form argues that a full variable
+declaration should present the same order as <code>:=</code> so
+</p>
+<pre>
+	var a uint64 = 1;
+</pre>
+has the same effect as
+<pre>
+	a := uint64(1);
+</pre>
+<p>
+Parsing is also simplified by having a distinct grammar for types that
+is not just the expression grammar; keywords such as <code>func</code>
+and <code>chan</code> keep things clear.
+</p>
+
+<p>
+See the <a href="http://blog.golang.org/2010/07/gos-declaration-syntax.html">Go's Declaration Syntax</a> article for more details.
+</p>
+
+<h3 id="no_pointer_arithmetic">
+Why is there no pointer arithmetic?</h3>
+<p>
+Safety.  Without pointer arithmetic it's possible to create a
+language that can never derive an illegal address that succeeds
+incorrectly.  Compiler and hardware technology have advanced to the
+point where a loop using array indices can be as efficient as a loop
+using pointer arithmetic.  Also, the lack of pointer arithmetic can
+simplify the implementation of the garbage collector.
+</p>
+
+<h3 id="inc_dec">
+Why are <code>++</code> and <code>--</code> statements and not expressions?  And why postfix, not prefix?</h3>
+<p>
+Without pointer arithmetic, the convenience value of pre- and postfix
+increment operators drops.  By removing them from the expression
+hierarchy altogether, expression syntax is simplified and the messy
+issues around order of evaluation of <code>++</code> and <code>--</code>
+(consider <code>f(i++)</code> and <code>p[i] = q[++i]</code>)
+are eliminated as well.  The simplification is
+significant.  As for postfix vs. prefix, either would work fine but
+the postfix version is more traditional; insistence on prefix arose
+with the STL, a library for a language whose name contains, ironically, a
+postfix increment.
+</p>
+
+<h3 id="semicolons">
+Why are there braces but no semicolons? And why can't I put the opening
+brace on the next line?</h3>
+<p>
+Go uses brace brackets for statement grouping, a syntax familiar to
+programmers who have worked with any language in the C family.
+Semicolons, however, are for parsers, not for people, and we wanted to
+eliminate them as much as possible.  To achieve this goal, Go borrows
+a trick from BCPL: the semicolons that separate statements are in the
+formal grammar but are injected automatically, without lookahead, by
+the lexer at the end of any line that could be the end of a statement.
+This works very well in practice but has the effect that it forces a
+brace style.  For instance, the opening brace of a function cannot
+appear on a line by itself.
+</p>
+<p>
+Some have argued that the lexer should do lookahead to permit the
+brace to live on the next line.  We disagree.  Since Go code is meant
+to be formatted automatically by
+<a href="http://golang.org/cmd/gofmt/"><code>gofmt</code></a>,
+<i>some</i> style must be chosen.  That style may differ from what
+you've used in C or Java, but Go is a new language and
+<code>gofmt</code>'s style is as good as any other.  More
+important&mdash;much more important&mdash;the advantages of a single,
+programmatically mandated format for all Go programs greatly outweigh
+any perceived disadvantages of the particular style.
+Note too that Go's style means that an interactive implementation of
+Go can use the standard syntax one line at a time without special rules.
+</p>
+
+<h3 id="garbage_collection">
+Why do garbage collection?  Won't it be too expensive?</h3>
+<p>
+One of the biggest sources of bookkeeping in systems programs is
+memory management.  We feel it's critical to eliminate that
+programmer overhead, and advances in garbage collection
+technology in the last few years give us confidence that we can
+implement it with low enough overhead and no significant
+latency.  (The current implementation is a plain mark-and-sweep
+collector but a replacement is in the works.)
+</p>
+<p>
+Another point is that a large part of the difficulty of concurrent
+and multi-threaded programming is memory management;
+as objects get passed among threads it becomes cumbersome
+to guarantee they become freed safely.
+Automatic garbage collection makes concurrent code far easier to write.
+Of course, implementing garbage collection in a concurrent environment is
+itself a challenge, but meeting it once rather than in every
+program helps everyone.
+</p>
+<p>
+Finally, concurrency aside, garbage collection makes interfaces
+simpler because they don't need to specify how memory is managed across them.
+</p>
+
diff --git a/doc/go_for_cpp_programmers.html b/doc/go_for_cpp_programmers.html
index a2291715c..fae2ec44e 100644
--- a/doc/go_for_cpp_programmers.html
+++ b/doc/go_for_cpp_programmers.html
@@ -198,7 +198,7 @@ the <code>else</code>, causing a syntax error.
 Since semicolons do end statements, you may continue using them as in
 C++.  However, that is not the recommended style.  Idiomatic Go code
 omits unnecessary semicolons, which in practice is all of them other
-than the initial <for> loop clause and cases where you want several
+than the initial <code>for</code> loop clause and cases where you want several
 short statements on a single line.
 
 <p>
@@ -668,7 +668,7 @@ func manager(ch chan cmd) {
 	var val int = 0
 	for {
 		c := &lt;- ch
-		if c.get { c.val = val ch &lt;- c }
+		if c.get { c.val = val; ch &lt;- c }
 		else { val = c.val }
 	}
 }
diff --git a/doc/go_lang_faq.html b/doc/go_lang_faq.html
deleted file mode 100644
index b8deb1534..000000000
--- a/doc/go_lang_faq.html
+++ /dev/null
@@ -1,491 +0,0 @@
-<!-- Language Design FAQ -->
-
-<h2 id="origins">Origins</h2>
-
-<h3 id="history">
-What is the history of the project?</h3>
-<p>
-Robert Griesemer, Rob Pike and Ken Thompson started sketching the
-goals for a new language on the white board on September 21, 2007.
-Within a few days the goals had settled into a plan to do something
-and a fair idea of what it would be.  Design continued part-time in
-parallel with unrelated work.  By January 2008, Ken had started work
-on a compiler with which to explore ideas; it generated C code as its
-output.  By mid-year the language had become a full-time project and
-had settled enough to attempt a production compiler.  In May 2008,
-Ian Taylor independently started on a GCC front end for Go using the
-draft specification.  Russ Cox joined in late 2008 and helped move the language
-and libraries from prototype to reality.
-</p>
-
-<p>
-Many others have contributed ideas, discussions, and code.
-</p>
-
-<h3 id="creating_a_new_language">
-Why are you creating a new language?</h3>
-<p>
-Go was born out of frustration with existing languages and
-environments for systems programming.  Programming had become too
-difficult and the choice of languages was partly to blame.  One had to
-choose either efficient compilation, efficient execution, or ease of
-programming; all three were not available in the same mainstream
-language.  Programmers who could were choosing ease over
-safety and efficiency by moving to dynamically typed languages such as
-Python and JavaScript rather than C++ or, to a lesser extent, Java.
-</p>
-<p>
-Go is an attempt to combine the ease of programming of an interpreted,
-dynamically typed
-language with the efficiency and safety of a statically typed, compiled language.
-It also aims to be modern, with support for networked and multicore
-computing.  Finally, it is intended to be <i>fast</i>: it should take
-at most a few seconds to build a large executable on a single computer.
-To meet these goals required addressing a number of
-linguistic issues: an expressive but lightweight type system;
-concurrency and garbage collection; rigid dependency specification;
-and so on.  These cannot be addressed well by libraries or tools; a new
-language was called for.
-</p>
-
-
-<h3 id="ancestors">
-What are Go's ancestors?</h3>
-<p>
-Go is mostly in the C family (basic syntax),
-with significant input from the Pascal/Modula/Oberon
-family (declarations, packages),
-plus some ideas from languages
-inspired by Tony Hoare's CSP,
-such as Newsqueak and Limbo (concurrency).
-However, it is a new language across the board.
-In every respect the language was designed by thinking
-about what programmers do and how to make programming, at least the
-kind of programming we do, more effective, which means more fun.
-</p>
-
-<h3 id="principles">
-What are the guiding principles in the design?</h3>
-<p>
-Programming today involves too much bookkeeping, repetition, and
-clerical work.  As Dick Gabriel says, &ldquo;Old programs read
-like quiet conversations between a well-spoken research worker and a
-well-studied mechanical colleague, not as a debate with a compiler.
-Who'd have guessed sophistication bought such noise?&rdquo;
-The sophistication is worthwhile&mdash;no one wants to go back to
-the old languages&mdash;but can it be more quietly achieved?
-</p>
-<p>
-Go attempts to reduce the amount of typing in both senses of the word.
-Throughout its design, we have tried to reduce clutter and
-complexity.  There are no forward declarations and no header files;
-everything is declared exactly once.  Initialization is expressive,
-automatic, and easy to use.  Syntax is clean and light on keywords.
-Stuttering (<code>foo.Foo* myFoo = new(foo.Foo)</code>) is reduced by
-simple type derivation using the <code>:=</code>
-declare-and-initialize construct.  And perhaps most radically, there
-is no type hierarchy: types just <i>are</i>, they don't have to
-announce their relationships.  These simplifications allow Go to be
-expressive yet comprehensible without sacrificing, well, sophistication.
-</p>
-<p>
-Another important principle is to keep the concepts orthogonal.
-Methods can be implemented for any type; structures represent data while
-interfaces represent abstraction; and so on.  Orthogonality makes it
-easier to understand what happens when things combine.
-</p>
-
-
-<h2 id="change_from_c">Changes from C</h2>
-
-<h3 id="different_syntax">
-Why is the syntax so different from C?</h3>
-<p>
-Other than declaration syntax, the differences are not major and stem
-from two desires.  First, the syntax should feel light, without too
-many mandatory keywords, repetition, or arcana.  Second, the language
-has been designed to be easy to analyze
-and can be parsed without a symbol table.  This makes it much easier
-to build tools such as debuggers, dependency analyzers, automated
-documentation extractors, IDE plug-ins, and so on.  C and its
-descendants are notoriously difficult in this regard.
-</p>
-
-<h3 id="declarations_backwards">
-Why are declarations backwards?</h3>
-<p>
-They're only backwards if you're used to C. In C, the notion is that a
-variable is declared like an expression denoting its type, which is a
-nice idea, but the type and expression grammars don't mix very well and
-the results can be confusing; consider function pointers.  Go mostly
-separates expression and type syntax and that simplifies things (using
-prefix <code>*</code> for pointers is an exception that proves the rule).  In C,
-the declaration
-</p>
-<pre>
-	int* a, b;
-</pre>
-<p>
-declares <code>a</code> to be a pointer but not <code>b</code>; in Go
-</p>
-<pre>
-	var a, b *int;
-</pre>
-<p>
-declares both to be pointers.  This is clearer and more regular.
-Also, the <code>:=</code> short declaration form argues that a full variable
-declaration should present the same order as <code>:=</code> so
-</p>
-<pre>
-	var a uint64 = 1;
-</pre>
-has the same effect as
-<pre>
-	a := uint64(1);
-</pre>
-<p>
-Parsing is also simplified by having a distinct grammar for types that
-is not just the expression grammar; keywords such as <code>func</code>
-and <code>chan</code> keep things clear.
-</p>
-
-<h3 id="no_pointer_arithmetic">
-Why is there no pointer arithmetic?</h3>
-<p>
-Safety.  Without pointer arithmetic it's possible to create a
-language that can never derive an illegal address that succeeds
-incorrectly.  Compiler and hardware technology have advanced to the
-point where a loop using array indices can be as efficient as a loop
-using pointer arithmetic.  Also, the lack of pointer arithmetic can
-simplify the implementation of the garbage collector.
-</p>
-
-<h3 id="inc_dec">
-Why are <code>++</code> and <code>--</code> statements and not expressions?  And why postfix, not prefix?</h3>
-<p>
-Without pointer arithmetic, the convenience value of pre- and postfix
-increment operators drops.  By removing them from the expression
-hierarchy altogether, expression syntax is simplified and the messy
-issues around order of evaluation of <code>++</code> and <code>--</code>
-(consider <code>f(i++)</code> and <code>p[i] = q[++i]</code>)
-are eliminated as well.  The simplification is
-significant.  As for postfix vs. prefix, either would work fine but
-the postfix version is more traditional; insistence on prefix arose
-with the STL, a library for a language whose name contains, ironically, a
-postfix increment.
-</p>
-
-<h3 id="semicolons">
-Why are there braces but no semicolons? And why can't I put the opening
-brace on the next line?</h3>
-<p>
-Go uses brace brackets for statement grouping, a syntax familiar to
-programmers who have worked with any language in the C family.
-Semicolons, however, are for parsers, not for people, and we wanted to
-eliminate them as much as possible.  To achieve this goal, Go borrows
-a trick from BCPL: the semicolons that separate statements are in the
-formal grammar but are injected automatically, without lookahead, by
-the lexer at the end of any line that could be the end of a statement.
-This works very well in practice but has the effect that it forces a
-brace style.  For instance, the opening brace of a function cannot
-appear on a line by itself.
-</p>
-<p>
-Some have argued that the lexer should do lookahead to permit the
-brace to live on the next line.  We disagree.  Since Go code is meant
-to be formatted automatically by
-<a href="http://golang.org/cmd/gofmt/"><code>gofmt</code></a>,
-<i>some</i> style must be chosen.  That style may differ from what
-you've used in C or Java, but Go is a new language and
-<code>gofmt</code>'s style is as good as any other.  More
-important&mdash;much more important&mdash;the advantages of a single,
-programmatically mandated format for all Go programs greatly outweigh
-any perceived disadvantages of the particular style.
-Note too that Go's style means that an interactive implementation of
-Go can use the standard syntax one line at a time without special rules.
-</p>
-
-<h3 id="garbage_collection">
-Why do garbage collection?  Won't it be too expensive?</h3>
-<p>
-One of the biggest sources of bookkeeping in systems programs is
-memory management.  We feel it's critical to eliminate that
-programmer overhead, and advances in garbage collection
-technology in the last few years give us confidence that we can
-implement it with low enough overhead and no significant
-latency.  (The current implementation is a plain mark-and-sweep
-collector but a replacement is in the works.)
-</p>
-<p>
-Another point is that a large part of the difficulty of concurrent
-and multi-threaded programming is memory management;
-as objects get passed among threads it becomes cumbersome
-to guarantee they become freed safely.
-Automatic garbage collection makes concurrent code far easier to write.
-Of course, implementing garbage collection in a concurrent environment is
-itself a challenge, but meeting it once rather than in every
-program helps everyone.
-</p>
-<p>
-Finally, concurrency aside, garbage collection makes interfaces
-simpler because they don't need to specify how memory is managed across them.
-</p>
-
-<h2 id="unicode_identifiers">What's up with Unicode identifiers?</h2>
-
-<p>
-It was important to us to extend the space of identifiers from the
-confines of ASCII.  Go's rule&mdash;identifier characters must be
-letters or digits as defined by Unicode&mdash;is simple to understand
-and to implement but has restrictions.  Combining characters are
-excluded by design, for instance.
-Until there
-is an agreed external definition of what an identifier might be,
-plus a definition of canonicalization of identifiers that guarantees
-no ambiguity, it seemed better to keep combining characters out of
-the mix.  Thus we have a simple rule that can be expanded later
-without breaking programs, one that avoids bugs that would surely arise
-from a rule that admits ambiguous identifiers.
-</p>
-
-<p>
-On a related note, since an exported identifier must begin with an
-upper-case letter, identifiers created from &ldquo;letters&rdquo;
-in some languages can, by definition, not be exported.  For now the
-only solution is to use something like <code>X日本語</code>, which
-is clearly unsatisfactory; we are considering other options.  The
-case-for-visibility rule is unlikely to change however; it's one
-of our favorite features of Go.
-</p>
-
-<h2 id="absent_features">Absent features</h2>
-
-<h3 id="generics">
-Why does Go not have generic types?</h3>
-<p>
-Generics may well be added at some point.  We don't feel an urgency for
-them, although we understand some programmers do.
-</p>
-<p>
-Generics are convenient but they come at a cost in
-complexity in the type system and run-time.  We haven't yet found a
-design that gives value proportionate to the complexity, although we
-continue to think about it.  Meanwhile, Go's built-in maps and slices,
-plus the ability to use the empty interface to construct containers
-(with explicit unboxing) mean in many cases it is possible to write
-code that does what generics would enable, if less smoothly.
-</p>
-<p>
-This remains an open issue.
-</p>
-
-<h3 id="exceptions">
-Why does Go not have exceptions?</h3>
-<p>
-We believe that coupling exceptions to a control
-structure, as in the <code>try-catch-finally</code> idiom, results in
-convoluted code.  It also tends to encourage programmers to label
-too many ordinary errors, such as failing to open a file, as
-exceptional.
-</p>
-<p>
-Go takes a different approach.  Instead of exceptions, it has a couple
-of built-in functions to signal and recover from truly exceptional
-conditions.  The recovery mechanism is executed only as part of a
-function's state being torn down after an error, which is sufficient
-to handle catastrophe but requires no extra control structures and,
-when used well, can result in clean error-handling code.
-</p>
-
-<h3 id="assertions">
-Why does Go not have assertions?</h3>
-<p>
-This is answered in the general <a href="go_faq.html#Where_is_assert">FAQ</a>.
-</p>
-
-<h2 id="types">Types</h2>
-
-<h3 id="inheritance">
-Why is there no type inheritance?</h3>
-<p>
-Object-oriented programming, at least in the best-known languages,
-involves too much discussion of the relationships between types,
-relationships that often could be derived automatically.  Go takes a
-different approach.
-</p>
-<p>
-Rather than requiring the programmer to declare ahead of time that two
-types are related, in Go a type automatically satisfies any interface
-that specifies a subset of its methods.  Besides reducing the
-bookkeeping, this approach has real advantages.  Types can satisfy
-many interfaces at once, without the complexities of traditional
-multiple inheritance.
-Interfaces can be very lightweight&mdash;having one or even zero methods
-in an interface can express useful concepts.
-Interfaces can be added after the fact if a new idea comes along
-or for testing&mdash;without annotating the original types.
-Because there are no explicit relationships between types
-and interfaces, there is no type hierarchy to manage or discuss.
-</p>
-<p>
-It's possible to use these ideas to construct something analogous to
-type-safe Unix pipes.  For instance, see how <code>fmt.Fprintf</code>
-enables formatted printing to any output, not just a file, or how the
-<code>bufio</code> package can be completely separate from file I/O,
-or how the <code>crypto</code> packages stitch together block and
-stream ciphers.  All these ideas stem from a single interface
-(<code>io.Writer</code>) representing a single method
-(<code>Write</code>).  And that's only scratching the surface.
-</p>
-<p>
-It takes some getting used to but this implicit style of type
-dependency is one of the most exciting things about Go.
-</p>
-
-<h3 id="methods_on_basics">
-Why is <code>len</code> a function and not a method?</h3>
-<p>
-We debated this issue but decided
-implementing <code>len</code> and friends as functions was fine in practice and
-didn't complicate questions about the interface (in the Go type sense)
-of basic types.
-</p>
-
-<h3 id="overloading">
-Why does Go not support overloading of methods and operators?</h3>
-<p>
-Method dispatch is simplified if it doesn't need to do type matching as well.
-Experience with other languages told us that having a variety of
-methods with the same name but different signatures was occasionally useful
-but that it could also be confusing and fragile in practice.  Matching only by name
-and requiring consistency in the types was a major simplifying decision
-in Go's type system.
-</p>
-<p>
-Regarding operator overloading, it seems more a convenience than an absolute
-requirement.  Again, things are simpler without it.
-</p>
-
-<h2 id="values">Values</h2>
-
-<h3 id="conversions">
-Why does Go not provide implicit numeric conversions?</h3>
-<p>
-The convenience of automatic conversion between numeric types in C is
-outweighed by the confusion it causes.  When is an expression unsigned?
-How big is the value?  Does it overflow?  Is the result portable, independent
-of the machine on which it executes?
-It also complicates the compiler; &ldquo;the usual arithmetic conversions&rdquo;
-are not easy to implement and inconsistent across architectures.
-For reasons of portability, we decided to make things clear and straightforward
-at the cost of some explicit conversions in the code.
-The definition of constants in Go&mdash;arbitrary precision values free
-of signedness and size annotations&mdash;ameliorates matters considerably,
-though.
-</p>
-<p>
-A related detail is that, unlike in C, <code>int</code> and <code>int64</code>
-are distinct types even if <code>int</code> is a 64-bit type.  The <code>int</code>
-type is generic; if you care about how many bits an integer holds, Go
-encourages you to be explicit.
-</p>
-
-<h3 id="builtin_maps">
-Why are maps built in?</h3>
-<p>
-The same reason strings are: they are such a powerful and important data
-structure that providing one excellent implementation with syntactic support
-makes programming more pleasant.  We believe that Go's implementation of maps
-is strong enough that it will serve for the vast majority of uses.
-If a specific application can benefit from a custom implementation, it's possible
-to write one but it will not be as convenient syntactically; this seems a reasonable tradeoff.
-</p>
-
-
-<h3 id="map_keys">
-Why don't maps allow structs and arrays as keys?</h3>
-<p>
-Map lookup requires an equality operator, which structs and arrays do not implement.
-They don't implement equality because equality is not well defined on such types;
-there are multiple considerations involving shallow vs. deep comparison, pointer vs.
-value comparison, how to deal with recursive structures, and so on.
-We may revisit this issue&mdash;and implementing equality for structs and arrays
-will not invalidate any existing programs&mdash;but without a clear idea of what
-equality of structs and arrays should mean, it was simpler to leave it out for now.
-</p>
-
-<h3 id="references">
-Why are maps, slices, and channels references while arrays are values?</h3>
-<p>
-There's a lot of history on that topic.  Early on, maps and channels
-were syntactically pointers and it was impossible to declare or use a
-non-pointer instance.  Also, we struggled with how arrays should work.
-Eventually we decided that the strict separation of pointers and
-values made the language harder to use.  Introducing reference types,
-including slices to handle the reference form of arrays, resolved
-these issues.  Reference types add some regrettable complexity to the
-language but they have a large effect on usability: Go became a more
-productive, comfortable language when they were introduced.
-</p>
-
-<h2 id="concurrency">Concurrency</h2>
-
-<h3 id="csp">
-Why build concurrency on the ideas of CSP?</h3>
-<p>
-Concurrency and multi-threaded programming have a reputation
-for difficulty.  We believe the problem is due partly to complex
-designs such as pthreads and partly to overemphasis on low-level details
-such as mutexes, condition variables, and even memory barriers.
-Higher-level interfaces enable much simpler code, even if there are still
-mutexes and such under the covers.
-</p>
-<p>
-One of the most successful models for providing high-level linguistic support
-for concurrency comes from Hoare's Communicating Sequential Processes, or CSP.
-Occam and Erlang are two well known languages that stem from CSP.
-Go's concurrency primitives derive from a different part of the family tree
-whose main contribution is the powerful notion of channels as first class objects.
-</p>
-
-<h3 id="goroutines">
-Why goroutines instead of threads?</h3>
-<p>
-Goroutines are part of making concurrency easy to use.  The idea, which has
-been around for a while, is to multiplex independently executing
-functions&mdash;coroutines, really&mdash;onto a set of threads.
-When a coroutine blocks, such as by calling a blocking system call,
-the run-time automatically moves other coroutines on the same operating
-system thread to a different, runnable thread so they won't be blocked.
-The programmer sees none of this, which is the point.
-The result, which we call goroutines, can be very cheap: unless they spend a lot of time
-in long-running system calls, they cost little more than the memory
-for the stack.
-</p>
-<p>
-To make the stacks small, Go's run-time uses segmented stacks.  A newly
-minted goroutine is given a few kilobytes, which is almost always enough.
-When it isn't, the run-time allocates (and frees) extension segments automatically.
-The overhead averages about three cheap instructions per function call.
-It is practical to create hundreds of thousands of goroutines in the same
-address space.  If goroutines were just threads, system resources would
-run out at a much smaller number.
-</p>
-
-<h3 id="atomic_maps">
-Why are map operations not defined to be atomic?</h3>
-
-<p>
-After long discussion it was decided that the typical use of maps did not require
-safe access from multiple threads, and in those cases where it did, the map was
-probably part of some larger data structure or computation that was already
-synchronized.  Therefore requiring that all map operations grab a mutex would slow
-down most programs and add safety to few.  This was not an easy decision,
-however, since it means uncontrolled map access can crash the program.
-</p>
-
-<p>
-The language does not preclude atomic map updates.  When required, such
-as when hosting an untrusted program, the implementation could interlock
-map access.
-</p>
diff --git a/doc/go_learning.html b/doc/go_learning.html
deleted file mode 100644
index 072d047f0..000000000
--- a/doc/go_learning.html
+++ /dev/null
@@ -1,141 +0,0 @@
-<!-- title Go Resources -->
-<!-- subtitle Go documents and learning materials -->
-
-<h2 id="about">Recommendations</h2>
-<p>
-If you're new to Go, we recommend following the 
-<a href="go_tutorial.html">tutorial</a> while consulting the 
-<a href="go_spec.html">language spec</a>.
-Then read <a href="effective_go.html">Effective Go</a>, as it addresses many
-common beginner questions.
-</p>
-
-<h2 id="reference">Reference Materials</h2>
-<p>Keep these under your pillow.</p>
-
-<h3 id="pkg"><a href="/pkg/">Package Documentation</a></h3>
-<p>
-The built-in documentation for the Go standard library.
-</p>
-
-<h3 id="pkg"><a href="/cmd/">Command Documentation</a></h3>
-<p>
-The built-in documentation for the Go tools.
-</p>
-
-<h3 id="spec"><a href="go_spec.html">Language Specification</a></h3>
-<p>
-The official Go Language specification. 
-</p>
-
-<h3 id="go_mem"><a href="go_mem.html">The Go Memory Model</a></h3>
-<p>
-A document that specifies the conditions under which reads of a variable in
-one goroutine can be guaranteed to observe values produced by writes to the
-same variable in a different goroutine.
-</p>
-
-<h2 id="tutorials">Tutorials</h2>
-
-<h3 id="orig_tutorial"><a href="go_tutorial.html">A Tutorial for the Go Programming Language</a></h3>
-<p>
-The first tutorial. An introductory text that touches upon several core
-concepts: syntax, types, allocation, constants, I/O, sorting, printing,
-goroutines, and channels.
-</p>
-
-<h3 id="effective_go"><a href="effective_go.html">Effective Go</a></h3>
-<p>
-A document that gives tips for writing clear, idiomatic Go code.
-A must read for any new Go programmer. It augments the tutorial and
-the language spec, both of which should be read first.
-</p>
-
-<h3 id="codelab_wiki"><a href="codelab/wiki/">Codelab: Writing Web Applications</a></h3>
-<p>
-This codelab takes the reader through the creation of a simple wiki web 
-application. It touches on structs, methods, file I/O, http, regular expressions,
-and closures.
-</p>
-
-<h3 id="go_for_cpp_programmers"><a href="go_for_cpp_programmers.html">Go for C++ Programmers</a></h3>
-<p>
-An introduction to Go for C++ programmers.
-</p>
-
-<h3 id="code"><a href="code.html">How to write Go code</a></h3>
-<p>
-How to write a new package and how to test code.
-</p>
-
-<h2 id="faqs">Frequently Asked Questions</h2>
-
-<h3 id="go_faq"><a href="go_faq.html">Go FAQ</a></h3>
-<p>
-Answers to common questions about Go.
-</p>
-
-<h3 id="go_lang_faq"><a href="go_lang_faq.html">Language Design FAQ</a></h3>
-<p>
-Answers to common questions about the design decisions behind Go.
-</p>
-
-<h3 id="go_programming_faq"><a href="go_programming_faq.html">Programming FAQ</a></h3>
-<p>
-Answers to common questions about programming with Go.
-</p>
-
-<h2 id="faqs">Development</h2>
-
-<h3 id="contibute"><a href="contribute.html">Contributing to the Go project</a></h3>
-<p>
-How to contribute changes to the Go project.
-</p>
-
-<h3 id="roadmap"><a href="devel/roadmap.html">Roadmap</a></h3>
-<p>
-Features and ideas being developed or discussed by the Go team.
-</p>
-
-<h3 id="release"><a href="devel/release.html">Release History</a></h3>
-<p>
-A summarization of the changes between tagged releases of Go.
-</p>
-
-<h2 id="videos">Videos</h2>
-
-<h3 id="techtalk"><a href="http://www.youtube.com/watch?v=rKnDgT73v8s">The Go Tech Talk</a></h3>
-<p>
-An hour-long talk delivered by Rob Pike at Google in October 2009. 
-The language's first public introduction. (See the <a href="talks/go_talk-20091030.pdf">slides in PDF format</a>.) The language has changed since it was made,
-but it's still a good introduction.
-</p>
-
-
-<h3 id="gocoding_channel"><a href="http://www.youtube.com/gocoding">gocoding YouTube Channel</a></h3>
-<p>
-A YouTube channel that includes screencasts and other Go-related videos:
-</p>
-<ul>
-<li><a href="http://www.youtube.com/gocoding#p/u/0/jDWBJOXs_iI">Screencast: Writing Go Packages</a> - writing, building, and distributing Go packages.</li>
-</ul>
-
-<h3 id="promo_video"><a href="http://www.youtube.com/watch?v=wwoWei-GAPo">The Go Promo Video</a></h3>
-<p>
-A short promotional video featuring Russ Cox demonstrating Go's fast compiler.
-</p>
-
-<h2 id="blogs">Blog Posts</h2>
-<p>
-Articles about Go from external blogs.
-</p>
-
-<h3 id="blog_rsc"><a href="http://research.swtch.com/search/label/Go">Go articles at research!rsc</a></h3>
-<p>
-Posts labelled 'Go' by Russ Cox, one of the core Go developers.
-</p>
-
-<h3 id="blog_iant"><a href="http://www.airs.com/blog/archives/category/programming">Programming articles at Airs</a></h3>
-<p>
-Posts labelled 'Programming' by Ian Lance Taylor, one of the core Go developers.
-</p>
diff --git a/doc/go_mem.html b/doc/go_mem.html
index 33bce5f7a..da45a07d7 100644
--- a/doc/go_mem.html
+++ b/doc/go_mem.html
@@ -143,6 +143,35 @@ calling <code>hello</code> will print <code>"hello, world"</code>
 at some point in the future (perhaps after <code>hello</code> has returned).
 </p>
 
+<h3>Goroutine destruction</h3>
+
+<p>
+The exit of a goroutine is not guaranteed to happen before
+any event in the program.  For example, in this program:
+</p>
+
+<pre>
+var a string
+
+func hello() {
+	go func() { a = "hello" }()
+	print(a)
+}
+</pre>
+
+<p>
+the assignment to <code>a</code> is not followed by
+any synchronization event, so it is not guaranteed to be
+observed by any other goroutine.
+In fact, an aggressive compiler might delete the entire <code>go</code> statement.
+</p>
+
+<p>
+If the effects of a goroutine must be observed by another goroutine,
+use a synchronization mechanism such as a lock or channel
+communication to establish a relative ordering.
+</p>
+
 <h3>Channel communication</h3>
 
 <p>
@@ -276,8 +305,9 @@ before the <i>n</i>+1'th call to <code>l.Lock</code>.
 <h3>Once</h3>
 
 <p>
-The <code>once</code> package provides a safe mechanism for
-initialization in the presence of multiple goroutines.
+The <code>sync</code> package provides a safe mechanism for
+initialization in the presence of multiple goroutines
+through the use of the <code>Once</code> type.
 Multiple threads can execute <code>once.Do(f)</code> for a particular <code>f</code>,
 but only one will run <code>f()</code>, and the other calls block
 until <code>f()</code> has returned.
@@ -293,6 +323,7 @@ In this program:
 
 <pre>
 var a string
+var once sync.Once
 
 func setup() {
 	a = "hello, world"
diff --git a/doc/go_programming_faq.html b/doc/go_programming_faq.html
deleted file mode 100644
index 3c4f0e1ba..000000000
--- a/doc/go_programming_faq.html
+++ /dev/null
@@ -1,307 +0,0 @@
-<!-- Programming FAQ -->
-
-<h2 id="Pointers">Pointers and Allocation</h2>
-
-<h3 id="pass_by_value">
-When are function paramters passed by value?</h3>
-
-<p>
-Everything in Go is passed by value.  A function always gets a copy of the
-thing being passed, as if there were an assignment statement assigning the
-value to the parameter.  For instance, copying a pointer value makes a copy of
-the pointer, not the data it points to. 
-</p>
-
-<p>
-Map and slice values behave like pointers; they are descriptors that
-contain pointers to the underlying map or slice data.  Copying a map or
-slice value doesn't copy the data it points to.  Copying an interface value
-makes a copy of the thing stored in the interface value.  If the interface
-value holds a struct, copying the interface value makes a copy of the
-struct.  If the interface value holds a pointer, copying the interface value
-makes a copy of the pointer, but again not the data it points to. 
-</p>
-
-<h3 id="methods_on_values_or_pointers">
-Should I define methods on values or pointers?</h3>
-
-<pre>
-func (s *MyStruct) someMethod() { } // method on pointer
-func (s MyStruct) someMethod() { }  // method on value
-</pre>
-
-<p>
-When defining a method on a type, the receiver (<code>s</code> in the above
-example) behaves exactly is if it were an argument to the method. Define the
-method on a pointer type if you need the method to modify the data the receiver
-points to. Otherwise, it is often cleaner to define the method on a value type.
-</p>
-
-<h3 id="new_and_make">
-What's the difference between new and make?</h3>
-
-<p>
-In short: <code>new</code> allocates memory, <code>make</code> initializes
-the slice, map, and channel types.
-</p>
-
-<p>
-See the <a href="/doc/effective_go.html#allocation_new">relevant section
-of Effective Go</a> for more details.
-</p>
-
-<h3 id="64bit_machine_32bit_int">
-Why is <code>int</code> 32 bits on 64 bit machines?</h3>
-
-<p>
-The size of <code>int</code> and <code>float</code> is implementation-specific.
-The 64 bit Go compilers (both 6g and gccgo) use a 32 bit representation for
-both <code>int</code> and <code>float</code>.  Code that relies on a particular
-size of value should use an explicitly sized type, like <code>int64</code> or
-<code>float64</code>.
-</p>
-
-<h2 id="Concurrent_programming">Concurrent programming</h2>
-
-<h3 id="What_operations_are_atomic_What_about_mutexes">
-What operations are atomic? What about mutexes?</h3>
-
-<p>
-We haven't fully defined it all yet, but some details about atomicity are
-available in the <a href="go_mem.html">Go Memory Model specification</a>.
-Also, some concurrency questions are answered in more detail in the <a
-href="go_lang_faq.html">language design FAQ</a>.
-</p>
-
-<p>
-Regarding mutexes, the <a href="/pkg/sync">sync</a>
-package implements them, but we hope Go programming style will
-encourage people to try higher-level techniques. In particular, consider
-structuring your program so that only one goroutine at a time is ever
-responsible for a particular piece of data.
-</p>
-
-<p>
-Do not communicate by sharing memory. Instead, share memory by communicating.
-</p>
-
-<h3 id="Why_no_multi_CPU">
-Why doesn't my multi-goroutine program use multiple CPUs?</h3>
-
-<p>
-Under the gc compilers you must set <code>GOMAXPROCS</code> to allow the
-runtime to utilise more than one OS thread. Under <code>gccgo</code> an OS
-thread will be created for each goroutine, and <code>GOMAXPROCS</code> is
-effectively equal to the number of running goroutines.  
-</p>
-
-<p>
-Programs that perform concurrent computation should benefit from an increase in
-<code>GOMAXPROCS</code>. (See the <a
-href="http://golang.org/pkg/runtime/#GOMAXPROCS">runtime package
-documentation</a>.)
-</p>
-
-<h3 id="Why_GOMAXPROCS">
-Why does using <code>GOMAXPROCS</code> &gt; 1 sometimes make my program
-slower?</h3>
-
-<p>
-(This is specific to the gc compilers. See above.)
-</p>
-
-<p>
-It depends on the nature of your program. 
-Programs that contain several goroutines that spend a lot of time
-communicating on channels will experience performance degradation when using
-multiple OS threads. This is because of the significant context-switching
-penalty involved in sending data between threads.
-</p>
-
-<p>
-The Go runtime's scheduler is not as good as it needs to be. In future, it
-should recognise such cases and optimize its use of OS threads. For now,
-<code>GOMAXPROCS</code> should be set on a per-application basis.
-</p>
-
-
-<h2 id="Functions_methods">Functions and Methods</h2>
-
-<h3 id="different_method_sets">
-Why do T and *T have different method sets?</h3>
-
-<p>
-From the <a href="http://golang.org/doc/go_spec.html#Types">Go Spec</a>:
-</p>
-
-<blockquote>
-The method set of any other named type <code>T</code> consists of all methods
-with receiver type <code>T</code>. The method set of the corresponding pointer
-type <code>*T</code> is the set of all methods with receiver <code>*T</code> or
-<code>T</code> (that is, it also contains the method set of <code>T</code>).
-</blockquote>
-
-<p>
-If an interface value contains a pointer <code>*T</code>,
-a method call can obtain a value by dereferencing the pointer,
-but if an interface value contains a value <code>T</code>,
-there is no useful way for a method call to obtain a pointer.
-</p>
-
-<p>
-If not for this restriction, this code:
-</p>
-
-<pre>
-var buf bytes.Buffer
-io.Copy(buf, os.Stdin)
-</pre>
-
-<p>
-would copy standard input into a <i>copy</i> of <code>buf</code>,
-not into <code>buf</code> itself.
-This is almost never the desired behavior.
-</p>
-
-<h3 id="closures_and_goroutines">
-Why am I confused by the way my closures behave as goroutines?</h3>
-
-<p>
-Some confusion may arise when using closures with concurrency.
-Consider the following program:
-</p>
-
-<pre>
-func main() {
-	done := make(chan bool)
-
-	values = []string{ "a", "b", "c" }
-	for _, v := range values {
-		go func() {
-			fmt.Println(v)
-			done &lt;- true
-		}()
-	}
-
-	// wait for all goroutines to complete before exiting
-	for i := range values {
-		&lt;-done 
-	}
-}
-</pre>
-
-<p>
-One might mistakenly expect to see <code>a, b, c</code> as the output. 
-What you'll probably see instead is <code>c, c, c</code>.  This is because 
-each closure shares the same variable <code>v</code>. Each closure prints the 
-value of <code>v</code> at the time <code>fmt.Println</code> is executed, 
-rather than the value of <code>v</code> when the goroutine was launched. 
-</p>
-
-<p>
-To bind the value of <code>v</code> to each closure as they are launched, one
-could modify the inner loop to read:
-</p>
-
-<pre>
-	for _, v := range values {
-		go func(<b>u</b>) {
-			fmt.Println(<b>u</b>)
-			done &lt;- true
-		}(<b>v</b>)
-	}
-</pre>
-
-<p>
-In this example, the value of <code>v</code> is passed as an argument to the 
-anonymous function. That value is then accessible inside the function as
-the variable <code>u</code>.
-</p>
-
-<h2 id="Control_flow">Control flow</h2>
-
-<h3 id="Does_Go_have_a_ternary_form">
-Does Go have the <code>?:</code> operator?</h3>
-
-<p>
-There is no ternary form in Go. You may use the following to achieve the same
-result:
-</p>
-
-<pre>
-if expr {
-	n = trueVal
-} else {
-	n = falseVal
-}
-</pre>
-
-<h2 id="Packages_Testing">Packages and Testing</h2>
-
-<h3 id="How_do_I_create_a_multifile_package">
-How do I create a multifile package?</h3>
-
-<p>
-Put all the source files for the package in a directory by themselves.
-Source files can refer to items from different files at will; there is
-no need for forward declarations or a header file.
-</p>
-
-<p>
-Other than being split into multiple files, the package will compile and test
-just like a single-file package.
-</p>
-
-<h3 id="How_do_I_write_a_unit_test">
-How do I write a unit test?</h3>
-
-<p>
-Create a new file ending in <code>_test.go</code> in the same directory
-as your package sources. Inside that file, <code>import "testing"</code>
-and write functions of the form
-</p>
-
-<pre>
-func TestFoo(t *testing.T) {
-    ...
-}
-</pre>
-
-<p>
-Run <code>gotest</code> in that directory.
-That script finds the <code>Test</code> functions,
-builds a test binary, and runs it.
-</p>
-
-
-<h2 id="Data_structures">Data Structures</h2>
-
-<h3 id="nested_array_verbose"
->Why does the syntax for nested array literals seem overly verbose?</h3>
-
-<p>
-In Go, you must specify a 2-dimensional array literal like this:
-</p>
-
-<pre>
-var intArray = [4][4]int{
-	[4]int{1, 2, 3, 4},
-	[4]int{2, 4, 8, 16},
-	[4]int{3, 9, 27, 81},
-	[4]int{4, 16, 64, 256},
-}
-</pre>
-
-<p>
-It seems that the <code>[4]int</code> could be inferred, but in general it's
-hard to get this sort of thing right.
-</p>
-
-<p>
-Some of Go's designers had worked on other languages that derived types
-automatically in such expressions, but the special cases that arise can
-be messy, especially when interfaces, nil, constant conversions, and
-such are involved. It seemed better to require the full type
-information. That way there will be no surprises.
-</p>
-
diff --git a/doc/go_spec.html b/doc/go_spec.html
index f296c2a38..e1c7e90e2 100644
--- a/doc/go_spec.html
+++ b/doc/go_spec.html
@@ -1,5 +1,5 @@
 <!-- title The Go Programming Language Specification -->
-<!-- subtitle Version of June 7, 2010 -->
+<!-- subtitle Version of January 7, 2011 -->
 
 <!--
 TODO
@@ -14,7 +14,6 @@ TODO
 [ ] should string(1<<s) and float(1<<s) be valid?
 [ ] should probably write something about evaluation order of statements even
 	though obvious
-[ ] specify iteration direction for range clause
 [ ] review language on implicit dereferencing
 [ ] clarify what it means for two functions to be "the same" when comparing them
 -->
@@ -139,7 +138,7 @@ There are two forms of comments:
 <ol>
 <li>
 <i>Line comments</i> start with the character sequence <code>//</code>
-and continue through the next newline. A line comment acts like a newline.
+and stop at the end of the line. A line comment acts like a newline.
 </li>
 <li>
 <i>General comments</i> start with the character sequence <code>/*</code>
@@ -163,7 +162,7 @@ and delimiters</i>, and <i>literals</i>.  <i>White space</i>, formed from
 spaces (U+0020), horizontal tabs (U+0009),
 carriage returns (U+000D), and newlines (U+000A),
 is ignored except as it separates tokens
-that would otherwise combine into a single token. Also, a newline
+that would otherwise combine into a single token. Also, a newline or end of file
 may trigger the insertion of a <a href="#Semicolons">semicolon</a>.
 While breaking the input into tokens,
 the next token is the longest sequence of characters that form a
@@ -527,9 +526,10 @@ A constant value is represented by an
 <a href="#String_literals">string</a> literal,
 an identifier denoting a constant,
 a <a href="#Constant_expressions">constant expression</a>, or
-the result value of some built-in functions such as <code>unsafe.Sizeof</code>
-and <code>cap</code> or <code>len</code> applied to an array,
-<code>len</code> applied to a string constant,
+the result value of some built-in functions such as
+<code>unsafe.Sizeof</code> applied to any value,
+<code>cap</code> or <code>len</code> applied to
+<a href="#Length_and_capacity">some expressions</a>,
 <code>real</code> and <code>imag</code> applied to a complex constant
 and <code>cmplx</code> applied to numeric constants.
 The boolean truth values are represented by the predeclared constants
@@ -590,13 +590,13 @@ for floating-point values, both the mantissa and exponent must be twice as large
 <p>
 A type determines the set of values and operations specific to values of that
 type.  A type may be specified by a (possibly qualified) <i>type name</i>
-(§<a href="#Qualified_identifier">Qualified identifier</a>, §<a href="#Type_declarations">Type declarations</a>) or a <i>type literal</i>,
+(§<a href="#Qualified_identifiers">Qualified identifier</a>, §<a href="#Type_declarations">Type declarations</a>) or a <i>type literal</i>,
 which composes a new type from previously declared types.
 </p>
 
 <pre class="ebnf">
 Type      = TypeName | TypeLit | "(" Type ")" .
-TypeName  = QualifiedIdent.
+TypeName  = QualifiedIdent .
 TypeLit   = ArrayType | StructType | PointerType | FunctionType | InterfaceType |
 	    SliceType | MapType | ChannelType .
 </pre>
@@ -754,8 +754,8 @@ ElementType = Type .
 The length is part of the array's type and must be a
 <a href="#Constant_expressions">constant expression</a> that evaluates to a non-negative
 integer value.  The length of array <code>a</code> can be discovered
-using the built-in function <code>len(a)</code>, which is a
-compile-time constant.  The elements can be indexed by integer
+using the built-in function <a href="#Length_and_capacity"><code>len(a)</code></a>.
+The elements can be indexed by integer
 indices 0 through the <code>len(a)-1</code> (§<a href="#Indexes">Indexes</a>).
 Array types are always one-dimensional but may be composed to form
 multi-dimensional types.
@@ -785,7 +785,7 @@ SliceType = "[" "]" ElementType .
 <p>
 Like arrays, slices are indexable and have a length.  The length of a
 slice <code>s</code> can be discovered by the built-in function
-<code>len(s)</code>; unlike with arrays it may change during
+<a href="#Length_and_capacity"><code>len(s)</code></a>; unlike with arrays it may change during
 execution.  The elements can be addressed by integer indices 0
 through <code>len(s)-1</code> (§<a href="#Indexes">Indexes</a>).  The slice index of a
 given element may be less than the index of the same element in the
@@ -804,18 +804,14 @@ the length of the slice and the length of the array beyond the slice;
 a slice of length up to that capacity can be created by `slicing' a new
 one from the original slice (§<a href="#Slices">Slices</a>).
 The capacity of a slice <code>a</code> can be discovered using the
-built-in function <code>cap(a)</code> and the relationship between
-<code>len()</code> and <code>cap()</code> is:
+built-in function <a href="#Length_and_capacity"><code>cap(a)</code></a>.
 </p>
 
-<pre>
-0 <= len(a) <= cap(a)
-</pre>
-
 <p>
-The length and capacity of a <code>nil</code> slice
-are 0. A new, initialized slice value for a given element type <code>T</code> is
-made using the built-in function <code>make</code>, which takes a slice type
+A new, initialized slice value for a given element type <code>T</code> is
+made using the built-in function
+<a href="#Making_slices_maps_and_channels"><code>make</code></a>,
+which takes a slice type
 and parameters specifying the length and optionally the capacity:
 </p>
 
@@ -883,9 +879,10 @@ struct {
 </pre>
 
 <p>
-A field declared with a type but no explicit field name is an <i>anonymous field</i>.
+A field declared with a type but no explicit field name is an <i>anonymous field</i>
+(colloquially called an embedded field).
 Such a field type must be specified as
-a type name <code>T</code> or as a pointer to a type name <code>*T</code>,
+a type name <code>T</code> or as a pointer to a non-interface type name <code>*T</code>,
 and <code>T</code> itself may not be
 a pointer type. The unqualified type name acts as the field name.
 </p>
@@ -959,7 +956,7 @@ struct {
 <p>
 A pointer type denotes the set of all pointers to variables of a given
 type, called the <i>base type</i> of the pointer.
-The value of an unitialized pointer is <code>nil</code>.
+The value of an uninitialized pointer is <code>nil</code>.
 </p>
 
 <pre class="ebnf">
@@ -976,7 +973,7 @@ BaseType = Type .
 
 <p>
 A function type denotes the set of all functions with the same parameter
-and result types. The value of an unitialized variable of function type
+and result types. The value of an uninitialized variable of function type
 is <code>nil</code>.
 </p>
 
@@ -995,15 +992,14 @@ must either all be present or all be absent. If present, each name
 stands for one item (parameter or result) of the specified type; if absent, each
 type stands for one item of that type.  Parameter and result
 lists are always parenthesized except that if there is exactly
-one unnamed result it may written as an unparenthesized type.
+one unnamed result it may be written as an unparenthesized type.
 </p>
-<p>
-If the function's last parameter has a type prefixed with <code>...</code>,
-the function may be invoked with zero or more arguments for that parameter,
-each of which must be <a href="#Assignability">assignable</a>
-to the type that follows the <code>...</code>.
-Such a function is called <i>variadic</i>.
 
+<p>
+The final parameter in a function signature may have
+a type prefixed with <code>...</code>.
+A function with such a parameter is called <i>variadic</i> and
+may be invoked with zero or more arguments for that parameter.
 </p>
 
 <pre>
@@ -1026,7 +1022,7 @@ An interface type specifies a <a href="#Types">method set</a> called its <i>inte
 A variable of interface type can store a value of any type with a method set
 that is any superset of the interface. Such a type is said to
 <i>implement the interface</i>.
-The value of an unitialized variable of interface type is <code>nil</code>.
+The value of an uninitialized variable of interface type is <code>nil</code>.
 </p>
 
 <pre class="ebnf">
@@ -1155,16 +1151,16 @@ map [string] interface {}
 </pre>
 
 <p>
-The number of elements is called the length and is never negative.
-The length of a map <code>m</code> can be discovered using the
-built-in function <code>len(m)</code> and may change during execution.
-Values may be added and removed
+The number of map elements is called its length.
+For a map <code>m</code>, it can be discovered using the
+built-in function <a href="#Length_and_capacity"><code>len(m)</code></a>
+and may change during execution. Values may be added and removed
 during execution using special forms of <a href="#Assignments">assignment</a>.
 </p>
 <p>
 A new, empty map value is made using the built-in
-function <code>make</code>, which takes the map type and an optional
-capacity hint as arguments:
+function <a href="#Making_slices_maps_and_channels"><code>make</code></a>,
+which takes the map type and an optional capacity hint as arguments:
 </p>
 
 <pre>
@@ -1331,9 +1327,9 @@ A value <code>x</code> is <i>assignable</i> to a variable of type <code>T</code>
 <code>x</code>'s type is identical to <code>T</code>.
 </li>
 <li>
-<code>x</code>'s type <code>V</code> or <code>T</code> have identical
-<a href="#Types">underlying types</a> and <code>V</code> or <code>T</code>
-is not a named type.
+<code>x</code>'s type <code>V</code> and <code>T</code> have identical
+<a href="#Types">underlying types</a> and at least one of <code>V</code>
+or <code>T</code> is not a named type.
 </li>
 <li>
 <code>T</code> is an interface type and
@@ -1342,7 +1338,7 @@ is not a named type.
 <li>
 <code>x</code> is a bidirectional channel value, <code>T</code> is a channel type,
 <code>x</code>'s type <code>V</code> and <code>T</code> have identical element types,
-and <code>V</code> or <code>T</code> is not a named type.
+and at least one of <code>V</code> or <code>T</code> is not a named type.
 </li>
 <li>
 <code>x</code> is the predeclared identifier <code>nil</code> and <code>T</code>
@@ -1496,8 +1492,8 @@ Zero value:
 	nil
 
 Functions:
-	cap close closed cmplx copy imag len make
-	new panic print println real
+	append cap close closed cmplx copy imag len
+	make new panic print println real recover
 </pre>
 
 
@@ -1665,7 +1661,7 @@ TypeSpec     = identifier Type .
 type IntArray [16]int
 
 type (
-	Point struct { x, y float }
+	Point struct { x, y float64 }
 	Polar Point
 )
 
@@ -1835,7 +1831,7 @@ A function declaration binds an identifier to a function (§<a href="#Function_t
 
 <pre class="ebnf">
 FunctionDecl = "func" identifier Signature [ Body ] .
-Body         = Block.
+Body         = Block .
 </pre>
 
 <p>
@@ -1882,13 +1878,13 @@ Given type <code>Point</code>, the declarations
 </p>
 
 <pre>
-func (p *Point) Length() float {
-	return Math.sqrt(p.x * p.x + p.y * p.y)
+func (p *Point) Length() float64 {
+	return math.Sqrt(p.x * p.x + p.y * p.y)
 }
 
-func (p *Point) Scale(factor float) {
-	p.x = p.x * factor
-	p.y = p.y * factor
+func (p *Point) Scale(factor float64) {
+	p.x *= factor
+	p.y *= factor
 }
 </pre>
 
@@ -1910,7 +1906,7 @@ argument.  For instance, the method <code>Scale</code> has type
 </p>
 
 <pre>
-(p *Point, factor float)
+func(p *Point, factor float64)
 </pre>
 
 <p>
@@ -1975,15 +1971,16 @@ a single expression or a key-value pair.
 </p>
 
 <pre class="ebnf">
-CompositeLit  = LiteralType "{" [ ElementList [ "," ] ] "}" .
+CompositeLit  = LiteralType LiteralValue .
 LiteralType   = StructType | ArrayType | "[" "..." "]" ElementType |
-                SliceType | MapType | TypeName | "(" LiteralType ")" .
+                SliceType | MapType | TypeName .
+LiteralValue  = "{" [ ElementList [ "," ] ] "}" .
 ElementList   = Element { "," Element } .
 Element       = [ Key ":" ] Value .
 Key           = FieldName | ElementIndex .
 FieldName     = identifier .
 ElementIndex  = Expression .
-Value         = Expression .
+Value         = Expression | LiteralValue .
 </pre>
 
 <p>
@@ -2028,8 +2025,8 @@ For struct literals the following rules apply:
 Given the declarations
 </p>
 <pre>
-type Point struct { x, y, z float }
-type Line struct { p, q Point }
+type Point3D struct { x, y, z float64 }
+type Line struct { p, q Point3D }
 </pre>
 
 <p>
@@ -2037,8 +2034,8 @@ one may write
 </p>
 
 <pre>
-origin := Point{}                            // zero value for Point
-line := Line{origin, Point{y: -4, z: 12.3}}  // zero value for line.q.x
+origin := Point3D{}                            // zero value for Point3D
+line := Line{origin, Point3D{y: -4, z: 12.3}}  // zero value for line.q.x
 </pre>
 
 <p>
@@ -2061,7 +2058,7 @@ Taking the address of a composite literal (§<a href="#Address_operators">Addres
 generates a unique pointer to an instance of the literal's value.
 </p>
 <pre>
-var pointer *Point = &amp;Point{y: 1000}
+var pointer *Point3D = &amp;Point3D{y: 1000}
 </pre>
 
 <p>
@@ -2098,11 +2095,23 @@ and is a shortcut for a slice operation applied to an array literal:
 </pre>
 
 <p>
+Within a composite literal of array, slice, or map type <code>T</code>,
+elements that are themselves composite literals may elide the respective
+literal type if it is identical to the element type of <code>T</code>.
+</p>
+
+<pre>
+[...]Point{{1.5, -3.5}, {0, 0}}  // same as [...]Point{Point{1.5, -3.5}, Point{0, 0}}
+[][]int{{1, 2, 3}, {4, 5}}       // same as [][]int{[]int{1, 2, 3}, []int{4, 5}}
+</pre>
+
+<p>
 A parsing ambiguity arises when a composite literal using the
-TypeName form of the LiteralType appears in the condition of an
+TypeName form of the LiteralType appears between the
+<a href="#Keywords">keyword</a> and the opening brace of the block of an
 "if", "for", or "switch" statement, because the braces surrounding
 the expressions in the literal are confused with those introducing
-a block of statements. To resolve the ambiguity in this rare case,
+the block of statements. To resolve the ambiguity in this rare case,
 the composite literal must appear within
 parentheses.
 </p>
@@ -2185,9 +2194,10 @@ PrimaryExpr =
 
 Selector       = "." identifier .
 Index          = "[" Expression "]" .
-Slice          = "[" Expression ":" [ Expression ] "]" .
+Slice          = "[" [ Expression ] ":" [ Expression ] "]" .
 TypeAssertion  = "." "(" Type ")" .
-Call           = "(" [ ExpressionList [ "," ] ] ")" .
+Call           = "(" [ ArgumentList [ "," ] ] ")" .
+ArgumentList   = ExpressionList [ "..." ] .
 </pre>
 
 
@@ -2200,7 +2210,7 @@ Point{1, 2}
 m["foo"]
 s[i : j + 1]
 obj.color
-Math.sin
+math.Sin
 f.p[i].x()
 </pre>
 
@@ -2217,8 +2227,7 @@ x.f
 
 <p>
 denotes the field or method <code>f</code> of the value denoted by <code>x</code>
-(or of <code>*x</code> if
-<code>x</code> is of pointer type). The identifier <code>f</code>
+(or sometimes <code>*x</code>; see below). The identifier <code>f</code>
 is called the (field or method)
 <i>selector</i>; it must not be the <a href="#Blank_identifier">blank identifier</a>.
 The type of the expression is the type of <code>f</code>.
@@ -2261,16 +2270,13 @@ In all other cases, <code>x.f</code> is illegal.
 </li>
 </ol>
 <p>
-Selectors automatically dereference pointers.
-If <code>x</code> is of pointer type, <code>x.y</code>
-is shorthand for <code>(*x).y</code>; if <code>y</code>
-is also of pointer type, <code>x.y.z</code> is shorthand
+Selectors automatically dereference pointers to structs.
+If <code>x</code> is a pointer to a struct, <code>x.y</code>
+is shorthand for <code>(*x).y</code>; if the field <code>y</code>
+is also a pointer to a struct, <code>x.y.z</code> is shorthand
 for <code>(*(*x).y).z</code>, and so on.
-If <code>*x</code> is of pointer type, dereferencing
-must be explicit;
-only one level of automatic dereferencing is provided.
-For an <code>x</code> of type <code>T</code> containing an
-anonymous field declared as <code>*A</code>,
+If <code>x</code> contains an anonymous field of type <code>*A</code>,
+where <code>A</code> is also a struct type,
 <code>x.f</code> is a shortcut for <code>(*x.A).f</code>.
 </p>
 <p>
@@ -2428,14 +2434,14 @@ For a string, array, or slice <code>a</code>, the primary expression
 </p>
 
 <pre>
-a[lo : hi]
+a[low : high]
 </pre>
 
 <p>
-constructs a substring or slice. The index expressions <code>lo</code> and
-<code>hi</code> select which elements appear in the result. The result has
+constructs a substring or slice. The index expressions <code>low</code> and
+<code>high</code> select which elements appear in the result. The result has
 indexes starting at 0 and length equal to
-<code>hi</code>&nbsp;-&nbsp;<code>lo</code>.
+<code>high</code>&nbsp;-&nbsp;<code>low</code>.
 After slicing the array <code>a</code>
 </p>
 
@@ -2455,19 +2461,28 @@ s[2] == 4
 </pre>
 
 <p>
-For convenience, the <code>hi</code> expression may be omitted; the notation
-<code>a[lo :]</code> is shorthand for <code>a[lo : len(a)]</code>.
-For arrays or strings, the indexes
-<code>lo</code> and <code>hi</code> must satisfy
-0 &lt;= <code>lo</code> &lt;= <code>hi</code> &lt;= length;
-for slices, the upper bound is the capacity rather than the length.
+For convenience, any of the index expressions may be omitted. A missing <code>low</code>
+index defaults to zero; a missing <code>high</code> index defaults to the length of the
+sliced operand:
+</p>
+
+<pre>
+a[2:]	// same a[2 : len(a)]
+a[:3]   // same as a[0 : 3]
+a[:]    // same as a[0 : len(a)]
+</pre>
+
+<p>
+For arrays or strings, the indexes <code>low</code> and <code>high</code> must
+satisfy 0 &lt;= <code>low</code> &lt;= <code>high</code> &lt;= length; for
+slices, the upper bound is the capacity rather than the length.
 </p>
 
 <p>
 If the sliced operand is a string or slice, the result of the slice operation
 is a string or slice of the same type.
-If the sliced operand is an array, the result of the slice operation is a slice
-with the same element type as the array.
+If the sliced operand is an array, it must be <a href="#Address_operators">addressable</a>
+and the result of the slice operation is a slice with the same element type as the array.
 </p>
 
 
@@ -2605,9 +2620,9 @@ then within the function the argument is equivalent to a parameter of type
 <code>[]T</code>.  At each call of <code>f</code>, the argument
 passed to the final parameter is
 a new slice of type <code>[]T</code> whose successive elements are
-the actual arguments.  The length of the slice is therefore the
-number of arguments bound to the final parameter and
-may differ for each call site.
+the actual arguments, which all must be <a href="#Assignability">assignable</a>
+to the type <code>T</code>. The length of the slice is therefore the number of
+arguments bound to the final parameter and may differ for each call site.
 </p>
 
 <p>
@@ -2619,20 +2634,31 @@ Greeting("hello:", "Joe", "Anna", "Eileen")
 </pre>
 
 <p>
-Within <code>Greeting</code>, <code>who</code> will have value
-<code>[]string{"Joe", "Anna", "Eileen")</code>
+within <code>Greeting</code>, <code>who</code> will have the value
+<code>[]string{"Joe", "Anna", "Eileen"}</code>
 </p>
 
+<p>
+If the final argument is assignable to a slice type <code>[]T</code>, it may be
+passed unchanged as the value for a <code>...T</code> parameter if the argument
+is followed by <code>...</code>. In this case no new slice is created.
+</p>
 
 <p>
-As a special case, if a function passes its own <code>...</code> parameter
-as the <code>...</code> argument in a call to another function with
-a <code>...</code> parameter of <a href="#Type_identity">identical type</a>,
-the parameter is passed directly.  In short, a formal <code>...</code>
-parameter is passed unchanged as an actual <code>...</code> parameter provided the
-types match.
+Given the slice <code>s</code> and call
 </p>
 
+<pre>
+s := []string{"James", "Jasmine"}
+Greeting("goodbye:", s...)
+</pre>
+
+<p>
+within <code>Greeting</code>, <code>who</code> will have the same value as <code>s</code>
+with the same underlying array.
+</p>
+
+
 <h3 id="Operators">Operators</h3>
 
 <p>
@@ -2903,7 +2929,7 @@ and string values. The result of a comparison is defined as follows:
 	String values are compared byte-wise (lexically).
 	</li>
 	<li>
-	Boolean values are are equal if they are either both
+	Boolean values are equal if they are either both
 	<code>true</code> or both <code>false</code>.
 	</li>
 	<li>
@@ -3065,6 +3091,12 @@ to <code>false</code> and <code>x</code> is set to the
 zero value for its type (§<a href="#The_zero_value">The zero value</a>).
 </p>
 
+<p>
+Except in a communications clause of a <a href="#Select_statements">select statement</a>,
+sending or receiving from a <code>nil</code> channel causes a
+<a href="#Run_time_panics">run-time panic</a>.
+</p>
+
 <!---
 <p>
 <span class="alert">TODO: Probably in a separate section, communication semantics
@@ -3548,8 +3580,8 @@ f(x+y)
 <p>
 The "++" and "--" statements increment or decrement their operands
 by the untyped <a href="#Constants">constant</a> <code>1</code>.
-As with an assignment, the operand must be a variable, pointer indirection,
-field selector or index expression.
+As with an assignment, the operand must be <a href="#Address_operators">addressable</a>
+or a map index expression.
 </p>
 
 <pre class="ebnf">
@@ -3567,6 +3599,7 @@ x++                 x += 1
 x--                 x -= 1
 </pre>
 
+
 <h3 id="Assignments">Assignments</h3>
 
 <pre class="ebnf">
@@ -3925,59 +3958,81 @@ for      { S() }    is the same as    for true     { S() }
 <p>
 A "for" statement with a "range" clause
 iterates through all entries of an array, slice, string or map,
-or values received on a channel.
-For each entry it first assigns the current index or key to an iteration
-variable - or the current (index, element) or (key, value) pair to a pair
-of iteration variables - and then executes the block.
+or values received on a channel. For each entry it assigns <i>iteration values</i>
+to corresponding <i>iteration variables</i> and then executes the block.
 </p>
 
 <pre class="ebnf">
-RangeClause = ExpressionList ( "=" | ":=" ) "range" Expression .
-</pre>
-
-<p>
-The type of the right-hand expression in the "range" clause must be an
-array, slice, string or map, or a pointer to an array;
-or it may be a channel.
-Except for channels,
-the identifier list must contain one or two expressions
-(as in assignments, these must be a
-variable, pointer indirection, field selector, or index expression)
-denoting the
-iteration variables. On each iteration,
-the first variable is set to the string, array or slice index or
-map key, and the second variable, if present, is set to the corresponding
-string or array element or map value.
-The types of the array or slice index (always <code>int</code>)
-and element, or of the map key and value respectively,
-must be <a href="#Assignability">assignable</a> to
-the type of the iteration variables.  The expression on the right hand
-side is evaluated once before beginning the loop.  At each iteration
-of the loop, the values produced by the range clause are assigned to
-the left hand side as in an <a href="#Assignments">assignment
-statement</a>.  Function calls on the left hand side will be evaluated
-exactly once per iteration.
-</p>
-<p>
-For a value of a string type, the "range" clause iterates over the Unicode code points
-in the string.  On successive iterations, the index variable will be the
-index of the first byte of successive UTF-8-encoded code points in the string, and
-the second variable, of type <code>int</code>, will be the value of
+RangeClause = Expression [ "," Expression ] ( "=" | ":=" ) "range" Expression .
+</pre>
+
+<p>
+The expression on the right in the "range" clause is called the <i>range expression</i>,
+which may be an array, pointer to an array, slice, string, map, or channel.
+As with an assignment, the operands on the left must be
+<a href="#Address_operators">addressable</a> or map index expressions; they
+denote the iteration variables. If the range expression is a channel, only
+one iteration variable is permitted, otherwise there may be one or two.
+</p>
+
+<p>
+The range expression is evaluated once before beginning the loop.
+Function calls on the left are evaluated once per iteration.
+For each iteration, iteration values are produced as follows:
+</p>
+
+<pre class="grammar">
+Range expression                          1st value          2nd value (if 2nd variable is present)
+
+array or slice  a  [n]E, *[n]E, or []E    index    i  int    a[i]       E
+string          s  string type            index    i  int    see below  int
+map             m  map[K]V                key      k  K      m[k]       V
+channel         c  chan E                 element  e  E
+</pre>
+
+<ol>
+<li>
+For an array or slice value, the index iteration values are produced in
+increasing order, starting at element index 0.
+</li>
+
+<li>
+For a string value, the "range" clause iterates over the Unicode code points
+in the string starting at byte index 0.  On successive iterations, the index value will be the
+index of the first byte of successive UTF-8-encoded code points in the string,
+and the second value, of type <code>int</code>, will be the value of
 the corresponding code point.  If the iteration encounters an invalid
-UTF-8 sequence, the second variable will be <code>0xFFFD</code>,
+UTF-8 sequence, the second value will be <code>0xFFFD</code>,
 the Unicode replacement character, and the next iteration will advance
 a single byte in the string.
-</p>
+</li>
+
+<li>
+The iteration order over maps is not specified.
+If map entries that have not yet been reached are deleted during iteration,
+the corresponding iteration values will not be produced. If map entries are
+inserted during iteration, the behavior is implementation-dependent, but the
+iteration values for each entry will be produced at most once.
+</li>
+
+<li>
+For channels, the iteration values produced are the successive values sent on
+the channel until the channel is closed; it does not produce the zero value sent
+before the channel is closed
+(§<a href="#Close_and_closed"><code>close</code> and <code>closed</code></a>).
+</li>
+</ol
+
 <p>
-For channels, the identifier list must contain one identifier.
-The iteration receives values sent on the channel until the channel is closed;
-it does not process the zero value sent before the channel is closed.
+The iteration values are assigned to the respective
+iteration variables as in an <a href="#Assignments">assignment statement</a>.
 </p>
+
 <p>
-The iteration variables may be declared by the "range" clause (":="), in which
-case their scope ends at the end of the "for" statement (§<a href="#Declarations_and">Declarations and</a>
-scope rules). In this case their types are set to
-<code>int</code> and the array element type, or the map key and value types, respectively.
+The iteration variables may be declared by the "range" clause (<code>:=</code>).
+In this case their types are set to the types of the respective iteration values
+and their <a href="#Declarations_and_scope">scope</a> ends at the end of the "for"
+statement; they are re-used in each iteration.
 If the iteration variables are declared outside the "for" statement,
 after execution their values will be those of the last iteration.
 </p>
@@ -4002,11 +4057,6 @@ for key, val = range m {
 // val == map[key]
 </pre>
 
-<p>
-If map entries that have not yet been processed are deleted during iteration,
-they will not be processed. If map entries are inserted during iteration, the
-behavior is implementation-dependent, but each entry will be processed at most once.
-</p>
 
 <h3 id="Go_statements">Go statements</h3>
 
@@ -4050,18 +4100,22 @@ RecvExpr =  [ Expression ( "=" | ":=" ) ] "&lt;-" Expression .
 
 <p>
 For all the send and receive expressions in the "select"
-statement, the channel expressions are evaluated, along with
-any expressions that appear on the right hand side of send expressions,
-in top-to-bottom order.
-If any of the resulting operations can proceed, one is
-chosen and the corresponding communication and statements are
-evaluated.  Otherwise, if there is a default case, that executes;
-if not, the statement blocks until one of the communications can
-complete.  The channels and send expressions are not re-evaluated.
-A channel pointer may be <code>nil</code>,
+statement, the channel expressions are evaluated in top-to-bottom order, along with
+any expressions that appear on the right hand side of send expressions.
+A channel may be <code>nil</code>,
 which is equivalent to that case not
 being present in the select statement
 except, if a send, its expression is still evaluated.
+If any of the resulting operations can proceed, one of those is
+chosen and the corresponding communication and statements are
+evaluated.  Otherwise, if there is a default case, that executes;
+if there is no default case, the statement blocks until one of the communications can
+complete.
+If there are no cases with non-<code>nil</code> channels,
+the statement blocks forever.
+Even if the statement blocks,
+the channel and send expressions are evaluated only once,
+upon entering the select statement.
 </p>
 <p>
 Since all the channels and send expressions are evaluated, any side
@@ -4069,7 +4123,7 @@ effects in that evaluation will occur for all the communications
 in the "select" statement.
 </p>
 <p>
-If multiple cases can proceed, a uniform fair choice is made to decide
+If multiple cases can proceed, a pseudo-random fair choice is made to decide
 which single communication will execute.
 <p>
 The receive case may declare a new variable using a
@@ -4094,6 +4148,8 @@ for {  // send random sequence of bits to c
 	case c &lt;- 1:
 	}
 }
+
+select { }  // block forever
 </pre>
 
 
@@ -4150,7 +4206,7 @@ func complex_f2() (re float, im float) {
 }
 </pre>
 	</li>
-	<li>The expression list may be empty if the functions's result
+	<li>The expression list may be empty if the function's result
 		type specifies names for its result parameters (§<a href="#Function_Types">Function Types</a>).
 		The result parameters act as ordinary local variables
 		and the function may assign values to them as necessary.
@@ -4331,21 +4387,24 @@ they cannot be used as function values.
 </p>
 
 <pre class="ebnf">
-BuiltinCall = identifier "(" [ BuiltinArgs ] ")" .
+BuiltinCall = identifier "(" [ BuiltinArgs [ "," ] ] ")" .
 BuiltinArgs = Type [ "," ExpressionList ] | ExpressionList .
 </pre>
 
 <h3 id="Close_and_closed">Close and closed</h3>
 
 <p>
-For a channel <code>c</code>, the predefined function <code>close(c)</code>
-marks the channel as unable to accept more
-values through a send operation.  After any previously
+For a channel <code>c</code>, the built-in function <code>close(c)</code>
+marks the channel as unable to accept more values through a send operation;
+values sent to a closed channel are ignored.
+After calling <code>close</code>, and after any previously
 sent values have been received, receive operations will return
-the zero value for the channel's type.  After at least one such zero value has been
+the zero value for the channel's type without blocking.
+After at least one such zero value has been
 received, <code>closed(c)</code> returns true.
 </p>
 
+
 <h3 id="Length_and_capacity">Length and capacity</h3>
 
 <p>
@@ -4358,12 +4417,12 @@ The implementation guarantees that the result always fits into an <code>int</cod
 Call      Argument type        Result
 
 len(s)    string type          string length in bytes
-          [n]T, *[n]T          array length (== constant n)
+          [n]T, *[n]T          array length (== n)
           []T                  slice length
           map[K]T              map length (number of defined keys)
           chan T               number of elements queued in channel buffer
 
-cap(s)    [n]T, *[n]T          array length (== constant n)
+cap(s)    [n]T, *[n]T          array length (== n)
           []T                  slice capacity
           chan T               channel buffer capacity
 </pre>
@@ -4378,6 +4437,24 @@ At any time the following relationship holds:
 0 <= len(s) <= cap(s)
 </pre>
 
+<p>
+The length and capacity of a <code>nil</code> slice, map, or channel are 0.
+</p>
+
+<p>
+The expression
+<code>len(s)</code> is a
+<a href="#Constants">constant</a> if <code>s</code> is a string constant.
+The expressions
+<code>len(s)</code> and
+<code>cap(s)</code> are
+constants if <code>s</code> is an (optionally parenthesized)
+identifier or
+<a href="#Qualified_identifiers">qualified identifier</a> 
+denoting an array or pointer to array.
+Otherwise invocations of <code>len</code> and <code>cap</code> are not
+constant.
+</p>
 
 <h3 id="Allocation">Allocation</h3>
 
@@ -4450,20 +4527,53 @@ m := make(map[string] int, 100)  // map with initial space for 100 elements
 </pre>
 
 
-<h3 id="Copying_slices">Copying slices</h3>
+<h3 id="Appending_and_copying_slices">Appending to and copying slices</h3>
+
+<p>
+Two built-in functions assist in common slice operations.
+</p>
+
+<p>
+The function <code>append</code> appends zero or more values <code>x</code>
+to a slice <code>s</code> and returns the resulting slice, with the same type
+as s. Each value must be <a href="#Assignability">assignable</a> to the slice's
+element type.
+</p>
+
+<pre class="grammar">
+append(s S, x ...T) S  // S is assignable to []T
+</pre>
 
 <p>
-The built-in function <code>copy</code> copies slice elements from
+If the capacity of <code>s</code> is not large enough to fit the additional
+values, <code>append</code> allocates a new, sufficiently large slice that fits
+both the existing slice elements and the additional values. Thus, the returned
+slice may refer to a different underlying array. 
+</p>
+
+<pre>
+s0 := []int{0, 0}
+s1 := append(s0, 2)        // append a single element     s1 == []int{0, 0, 2}
+s2 := append(s1, 3, 5, 7)  // append multiple elements    s2 == []int{0, 0, 2, 3, 5, 7}
+s3 := append(s2, s0...)    // append a slice              s3 == []int{0, 0, 2, 3, 5, 7, 0, 0}
+</pre>
+
+<p>
+The function <code>copy</code> copies slice elements from
 a source <code>src</code> to a destination <code>dst</code> and returns the
 number of elements copied. Source and destination may overlap.
 Both arguments must have <a href="#Type_identity">identical</a> element type <code>T</code> and must be
-<a href="#Assignability">assignable</a> to a slice
-of type <code>[]T</code>. The number of arguments copied is the minimum of
+<a href="#Assignability">assignable</a> to a slice of type <code>[]T</code>.
+The number of arguments copied is the minimum of
 <code>len(src)</code> and <code>len(dst)</code>.
+As a special case, <code>copy</code> also accepts a destination argument assignable
+to type <code>[]byte</code> with a source argument of a string type.
+This form copies the bytes from the string into the byte slice.
 </p>
 
 <pre class="grammar">
 copy(dst, src []T) int
+copy(dst []byte, src string) int
 </pre>
 
 <p>
@@ -4473,8 +4583,10 @@ Examples:
 <pre>
 var a = [...]int{0, 1, 2, 3, 4, 5, 6, 7}
 var s = make([]int, 6)
-n1 := copy(s, a[0:])  // n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
-n2 := copy(s, s[2:])  // n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
+var b = make([]byte, 5)
+n1 := copy(s, a[0:])            // n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
+n2 := copy(s, s[2:])            // n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
+n3 := copy(b, "Hello, World!")  // n3 == 5, b == []byte("Hello")
 </pre>
 
 <h3 id="Complex_numbers">Assembling and disassembling complex numbers</h3>
@@ -4533,10 +4645,10 @@ func recover() interface{}
 </pre>
 
 <p>
-<font color=red>TODO: Most of this text could move to the respective
+<span class="alert">TODO: Most of this text could move to the respective
 comments in <code>runtime.go</code> once the functions are implemented.
 They are here, at least for now, for reference and discussion.
-</font>
+</span>
 </p>
 
 <p>
@@ -4630,8 +4742,9 @@ func IsPrintable(s string) (ok bool) {
 		}
 		// Panicking has stopped; execution will resume normally in caller.
 		// The return value will be true normally, false if a panic occurred.
-	}
+	}()
 	panicIfNotPrintable(s)	// will panic if validations fails.
+	return
 }
 </pre>
 
@@ -5086,27 +5199,24 @@ For the numeric types (§<a href="#Numeric_types">Numeric types</a>), the follow
 </p>
 
 <pre class="grammar">
-type                      size in bytes
+type                                 size in bytes
 
-byte, uint8, int8         1
-uint16, int16             2
-uint32, int32, float32    4
-uint64, int64, float64    8
+byte, uint8, int8                     1
+uint16, int16                         2
+uint32, int32, float32                4
+uint64, int64, float64, complex64     8
+complex128                           16
 </pre>
 
 <p>
 The following minimal alignment properties are guaranteed:
 </p>
 <ol>
-<li>For a variable <code>x</code> of any type: <code>1 <= unsafe.Alignof(x) <= unsafe.Maxalign</code>.
-</li>
-
-<li>For a variable <code>x</code> of numeric type: <code>unsafe.Alignof(x)</code> is the smaller
-   of <code>unsafe.Sizeof(x)</code> and <code>unsafe.Maxalign</code>, but at least 1.
+<li>For a variable <code>x</code> of any type: <code>unsafe.Alignof(x)</code> is at least 1.
 </li>
 
 <li>For a variable <code>x</code> of struct type: <code>unsafe.Alignof(x)</code> is the largest of
-   all the values <code>unsafe.Alignof(x.f)</code> for each field <code>f</code> of x, but at least 1.
+   all the values <code>unsafe.Alignof(x.f)</code> for each field <code>f</code> of <code>x</code>, but at least 1.
 </li>
 
 <li>For a variable <code>x</code> of array type: <code>unsafe.Alignof(x)</code> is the same as
@@ -5117,10 +5227,7 @@ The following minimal alignment properties are guaranteed:
 <h2 id="Implementation_differences"><span class="alert">Implementation differences - TODO</span></h2>
 <ul>
 	<li><span class="alert">Implementation does not honor the restriction on goto statements and targets (no intervening declarations).</span></li>
-	<li><span class="alert">Method expressions are partially implemented.</span></li>
+	<li><span class="alert">Gccgo: The <code>append</code> built-in function is not yet implemented.</span></li>
+	<li><span class="alert">Gccgo: Method expressions are partially implemented.</span></li>
 	<li><span class="alert">Gccgo: allows only one init() function per source file.</span></li>
-	<li><span class="alert">Gccgo: Deferred functions cannot access the surrounding function's result parameters.</span></li>
-	<li><span class="alert">Gccgo: Function results are not addressable.</span></li>
-	<li><span class="alert">Gccgo: Recover is not implemented.</span></li>
-	<li><span class="alert">Gccgo: The implemented version of panic differs from its specification.</span></li>
 </ul>
diff --git a/doc/go_tutorial.html b/doc/go_tutorial.html
index 7eb09b5b4..11e9b4ad7 100644
--- a/doc/go_tutorial.html
+++ b/doc/go_tutorial.html
@@ -286,14 +286,15 @@ In Go, since arrays are values, it's meaningful (and useful) to talk
 about pointers to arrays.
 <p>
 The size of the array is part of its type; however, one can declare
-a <i>slice</i> variable, to which one can assign a pointer to
-any array
-with the same element type or&mdash;much more commonly&mdash;a <i>slice
-expression</i> of the form <code>a[low : high]</code>, representing
-the subarray indexed by <code>low</code> through <code>high-1</code>.
-Slices look a lot like arrays but have
+a <i>slice</i> variable to hold a reference to any array, of any size,
+with the same element type.
+A <i>slice
+expression</i> has the form <code>a[low : high]</code>, representing
+the internal array indexed from <code>low</code> through <code>high-1</code>; the resulting
+slice is indexed from <code>0</code> through <code>high-low-1</code>.
+In short, slices look a lot like arrays but with
 no explicit size (<code>[]</code> vs. <code>[10]</code>) and they reference a segment of
-an underlying, often anonymous, regular array.  Multiple slices
+an underlying, usually anonymous, regular array.  Multiple slices
 can share data if they represent pieces of the same array;
 multiple arrays can never share data.
 <p>
@@ -302,17 +303,28 @@ regular arrays; they're more flexible, have reference semantics,
 and are efficient.  What they lack is the precise control of storage
 layout of a regular array; if you want to have a hundred elements
 of an array stored within your structure, you should use a regular
-array.
+array. To create one, use a compound value <i>constructor</i>&mdash;an
+expression formed
+from a type followed by a brace-bounded expression like this:
+<p>
+<pre>
+    [3]int{1,2,3}
+</pre>
+<p>
+In this case the constructor builds an array of 3 <code>ints</code>.
 <p>
 When passing an array to a function, you almost always want
 to declare the formal parameter to be a slice.  When you call
-the function, take the address of the array and  Go will
-create (efficiently) a slice reference and pass that.
+the function, slice the array to create
+(efficiently) a slice reference and pass that.
+By default, the lower and upper bounds of a slice match the
+ends of the existing object, so the concise notation <code>[:]</code>
+will slice the whole array.
 <p>
 Using slices one can write this function (from <code>sum.go</code>):
 <p>
 <pre> <!-- progs/sum.go /sum/ /^}/ -->
-09    func sum(a []int) int {   // returns an int
+09    func sum(a []int) int { // returns an int
 10        s := 0
 11        for i := 0; i &lt; len(a); i++ {
 12            s += a[i]
@@ -321,32 +333,27 @@ Using slices one can write this function (from <code>sum.go</code>):
 15    }
 </pre>
 <p>
-and invoke it like this:
-<p>
-<pre> <!-- progs/sum.go /1,2,3/ -->
-19        s := sum(&amp;[3]int{1,2,3})  // a slice of the array is passed to sum
-</pre>
-<p>
 Note how the return type (<code>int</code>) is defined for <code>sum()</code> by stating it
 after the parameter list.
-The expression <code>[3]int{1,2,3}</code>&mdash;a type followed by a
-brace-bounded
-expression&mdash;is a constructor for a value, in this case an array
-of 3 <code>ints</code>.
-Putting an <code>&amp;</code>
-in front gives us the address of a unique instance of the value.  We pass the
-pointer to <code>sum()</code> by (implicitly) promoting it to a slice.
+<p>
+To call the function, we slice the array.  This intricate call (we'll show
+a simpler way in a moment) constructs
+an array and slices it:
+<p>
+<pre>
+    s := sum([3]int{1,2,3}[:])
+</pre>
 <p>
 If you are creating a regular array but want the compiler to count the
 elements for you, use <code>...</code> as the array size:
 <p>
 <pre>
-    s := sum(&amp;[...]int{1,2,3})
+    s := sum([...]int{1,2,3}[:])
 </pre>
 <p>
-In practice, though, unless you're meticulous about storage layout within a
-data structure, a slice itself&mdash;using empty brackets and no
-<code>&amp;</code>&mdash;is all you need:
+That's fussier than necessary, though.
+In practice, unless you're meticulous about storage layout within a
+data structure, a slice itself&mdash;using empty brackets with no size&mdash;is all you need:
 <p>
 <pre>
     s := sum([]int{1,2,3})
@@ -470,8 +477,8 @@ sort of open/close/read/write interface.  Here's the start of <code>file.go</cod
 10    )
 <p>
 12    type File struct {
-13        fd      int    // file descriptor number
-14        name    string // file name at Open time
+13        fd   int    // file descriptor number
+14        name string // file name at Open time
 15    }
 </pre>
 <p>
@@ -524,7 +531,7 @@ object.  We could write
     return n
 </pre>
 <p>
-but for simple structures like <code>File</code> it's easier to return the address of a nonce
+but for simple structures like <code>File</code> it's easier to return the address of a 
 composite literal, as is done here on line 21.
 <p>
 We can use the factory to construct some familiar, exported variables of type <code>*File</code>:
@@ -541,7 +548,7 @@ The <code>newFile</code> function was not exported because it's internal. The pr
 exported factory to use is <code>Open</code>:
 <p>
 <pre> <!-- progs/file.go /func.Open/ /^}/ -->
-30    func Open(name string, mode int, perm int) (file *File, err os.Error) {
+30    func Open(name string, mode int, perm uint32) (file *File, err os.Error) {
 31        r, e := syscall.Open(name, mode, perm)
 32        if e != 0 {
 33            err = os.Errno(e)
@@ -581,7 +588,7 @@ each of which declares a receiver variable <code>file</code>.
 40            return os.EINVAL
 41        }
 42        e := syscall.Close(file.fd)
-43        file.fd = -1  // so it can't be closed again
+43        file.fd = -1 // so it can't be closed again
 44        if e != 0 {
 45            return os.Errno(e)
 46        }
@@ -642,24 +649,30 @@ We can now use our new package:
 13    func main() {
 14        hello := []byte(&quot;hello, world\n&quot;)
 15        file.Stdout.Write(hello)
-16        file, err := file.Open(&quot;/does/not/exist&quot;,  0,  0)
-17        if file == nil {
+16        f, err := file.Open(&quot;/does/not/exist&quot;,  0,  0)
+17        if f == nil {
 18            fmt.Printf(&quot;can't open file; err=%s\n&quot;,  err.String())
 19            os.Exit(1)
 20        }
 21    }
 </pre>
 <p>
-The ''<code>./</code>'' in the import of ''<code>./file</code>'' tells the compiler to use our own package rather than
+The ''<code>./</code>'' in the import of ''<code>./file</code>'' tells the compiler
+to use our own package rather than
 something from the directory of installed packages.
+(Also, ''<code>file.go</code>'' must be compiled before we can import the
+package.)
 <p>
-Finally we can run the program:
+Now we can compile and run the program:
 <p>
 <pre>
-    % helloworld3
+    $ 6g file.go                       # compile file package
+    $ 6g helloworld3.go                # compile main package
+    $ 6l -o helloworld3 helloworld3.6  # link - no need to mention "file"
+    $ helloworld3
     hello, world
     can't open file; err=No such file or directory
-    %
+    $
 </pre>
 <p>
 <h2>Rotting cats</h2>
@@ -681,11 +694,11 @@ Building on the <code>file</code> package, here's a simple version of the Unix u
 15        const NBUF = 512
 16        var buf [NBUF]byte
 17        for {
-18            switch nr, er := f.Read(&amp;buf); true {
+18            switch nr, er := f.Read(buf[:]); true {
 19            case nr &lt; 0:
 20                fmt.Fprintf(os.Stderr, &quot;cat: error reading from %s: %s\n&quot;, f.String(), er.String())
 21                os.Exit(1)
-22            case nr == 0:  // EOF
+22            case nr == 0: // EOF
 23                return
 24            case nr &gt; 0:
 25                if nw, ew := file.Stdout.Write(buf[0:nr]); nw != nr {
@@ -696,7 +709,7 @@ Building on the <code>file</code> package, here's a simple version of the Unix u
 30    }
 <p>
 32    func main() {
-33        flag.Parse()   // Scans the arg list and sets up flags
+33        flag.Parse() // Scans the arg list and sets up flags
 34        if flag.NArg() == 0 {
 35            cat(file.Stdin)
 36        }
@@ -757,7 +770,7 @@ we have a second implementation of the <code>reader</code> interface.
 <p>
 <pre> <!-- progs/cat_rot13.go /type.rotate13/ /end.of.rotate13/ -->
 31    type rotate13 struct {
-32        source    reader
+32        source reader
 33    }
 <p>
 35    func newRotate13(source reader) *rotate13 {
@@ -797,11 +810,11 @@ and use it from within a mostly unchanged <code>cat()</code> function:
 57            r = newRotate13(r)
 58        }
 59        for {
-60            switch nr, er := r.Read(&amp;buf); {
+60            switch nr, er := r.Read(buf[:]); {
 61            case nr &lt; 0:
 62                fmt.Fprintf(os.Stderr, &quot;cat: error reading from %s: %s\n&quot;, r.String(), er.String())
 63                os.Exit(1)
-64            case nr == 0:  // EOF
+64            case nr == 0: // EOF
 65                return
 66            case nr &gt; 0:
 67                nw, ew := file.Stdout.Write(buf[0:nr])
@@ -823,11 +836,11 @@ even though under the covers it holds a pointer to a <code>struct</code>.
 Here it is in action:
 <p>
 <pre>
-    % echo abcdefghijklmnopqrstuvwxyz | ./cat
+    $ echo abcdefghijklmnopqrstuvwxyz | ./cat
     abcdefghijklmnopqrstuvwxyz
-    % echo abcdefghijklmnopqrstuvwxyz | ./cat --rot13
+    $ echo abcdefghijklmnopqrstuvwxyz | ./cat --rot13
     nopqrstuvwxyzabcdefghijklm
-    %
+    $
 </pre>
 <p>
 Fans of dependency injection may take cheer from how easily interfaces
diff --git a/doc/go_tutorial.txt b/doc/go_tutorial.txt
index 6ab6094c0..9c08bd278 100644
--- a/doc/go_tutorial.txt
+++ b/doc/go_tutorial.txt
@@ -227,14 +227,15 @@ In Go, since arrays are values, it's meaningful (and useful) to talk
 about pointers to arrays.
 
 The size of the array is part of its type; however, one can declare
-a <i>slice</i> variable, to which one can assign a pointer to
-any array
-with the same element type or&mdash;much more commonly&mdash;a <i>slice
-expression</i> of the form "a[low : high]", representing
-the subarray indexed by "low" through "high-1".
-Slices look a lot like arrays but have
+a <i>slice</i> variable to hold a reference to any array, of any size,
+with the same element type.
+A <i>slice
+expression</i> has the form "a[low : high]", representing
+the internal array indexed from "low" through "high-1"; the resulting
+slice is indexed from "0" through "high-low-1".
+In short, slices look a lot like arrays but with
 no explicit size ("[]" vs. "[10]") and they reference a segment of
-an underlying, often anonymous, regular array.  Multiple slices
+an underlying, usually anonymous, regular array.  Multiple slices
 can share data if they represent pieces of the same array;
 multiple arrays can never share data.
 
@@ -243,39 +244,43 @@ regular arrays; they're more flexible, have reference semantics,
 and are efficient.  What they lack is the precise control of storage
 layout of a regular array; if you want to have a hundred elements
 of an array stored within your structure, you should use a regular
-array.
+array. To create one, use a compound value <i>constructor</i>&mdash;an
+expression formed
+from a type followed by a brace-bounded expression like this:
+
+	[3]int{1,2,3}
+
+In this case the constructor builds an array of 3 "ints".
 
 When passing an array to a function, you almost always want
 to declare the formal parameter to be a slice.  When you call
-the function, take the address of the array and  Go will
-create (efficiently) a slice reference and pass that.
+the function, slice the array to create
+(efficiently) a slice reference and pass that.
+By default, the lower and upper bounds of a slice match the
+ends of the existing object, so the concise notation "[:]"
+will slice the whole array.
 
 Using slices one can write this function (from "sum.go"):
 
 --PROG progs/sum.go /sum/ /^}/
 
-and invoke it like this:
-
---PROG progs/sum.go /1,2,3/
-
 Note how the return type ("int") is defined for "sum()" by stating it
 after the parameter list.
-The expression "[3]int{1,2,3}"&mdash;a type followed by a
-brace-bounded
-expression&mdash;is a constructor for a value, in this case an array
-of 3 "ints".
-Putting an "&amp;"
-in front gives us the address of a unique instance of the value.  We pass the
-pointer to "sum()" by (implicitly) promoting it to a slice.
+
+To call the function, we slice the array.  This intricate call (we'll show
+a simpler way in a moment) constructs
+an array and slices it:
+
+	s := sum([3]int{1,2,3}[:])
 
 If you are creating a regular array but want the compiler to count the
 elements for you, use "..." as the array size:
 
-	s := sum(&amp;[...]int{1,2,3})
+	s := sum([...]int{1,2,3}[:])
 
-In practice, though, unless you're meticulous about storage layout within a
-data structure, a slice itself&mdash;using empty brackets and no
-"&amp;"&mdash;is all you need:
+That's fussier than necessary, though.
+In practice, unless you're meticulous about storage layout within a
+data structure, a slice itself&mdash;using empty brackets with no size&mdash;is all you need:
 
 	s := sum([]int{1,2,3})
 
@@ -415,7 +420,7 @@ object.  We could write
 	n.name = name
 	return n
 
-but for simple structures like "File" it's easier to return the address of a nonce
+but for simple structures like "File" it's easier to return the address of a 
 composite literal, as is done here on line 21.
 
 We can use the factory to construct some familiar, exported variables of type "*File":
@@ -471,15 +476,21 @@ We can now use our new package:
 
 --PROG progs/helloworld3.go /package/ END
 
-The ''"./"'' in the import of ''"./file"'' tells the compiler to use our own package rather than
+The ''"./"'' in the import of ''"./file"'' tells the compiler
+to use our own package rather than
 something from the directory of installed packages.
+(Also, ''"file.go"'' must be compiled before we can import the
+package.)
 
-Finally we can run the program:
+Now we can compile and run the program:
 
-	% helloworld3
+	$ 6g file.go                       # compile file package
+	$ 6g helloworld3.go                # compile main package
+	$ 6l -o helloworld3 helloworld3.6  # link - no need to mention "file"
+	$ helloworld3
 	hello, world
 	can't open file; err=No such file or directory
-	%
+	$
 
 Rotting cats
 ----
@@ -549,11 +560,11 @@ even though under the covers it holds a pointer to a "struct".
 Here it is in action:
 
 <pre>
-	% echo abcdefghijklmnopqrstuvwxyz | ./cat
+	$ echo abcdefghijklmnopqrstuvwxyz | ./cat
 	abcdefghijklmnopqrstuvwxyz
-	% echo abcdefghijklmnopqrstuvwxyz | ./cat --rot13
+	$ echo abcdefghijklmnopqrstuvwxyz | ./cat --rot13
 	nopqrstuvwxyzabcdefghijklm
-	%
+	$
 </pre>
 
 Fans of dependency injection may take cheer from how easily interfaces
diff --git a/doc/godocs.js b/doc/godocs.js
index b2fc1b357..8b451547d 100644
--- a/doc/godocs.js
+++ b/doc/godocs.js
@@ -11,17 +11,32 @@
 /* We want to do some stuff on page load (after the HTML is rendered).
    So listen for that:
  */
-if (window.addEventListener){
-  window.addEventListener('load', godocs_onload, false);
-} else if (window.attachEvent){
-  window.attachEvent('onload', godocs_onload);
+function bindEvent(el, e, fn) {
+  if (el.addEventListener){
+    el.addEventListener(e, fn, false);
+  } else if (el.attachEvent){
+    el.attachEvent('on'+e, fn);
+  }
 }
+bindEvent(window, 'load', godocs_onload);
 
 function godocs_onload() {
+  godocs_bindSearchEvents();
   godocs_generateTOC();
   godocs_addTopLinks();
 }
 
+function godocs_bindSearchEvents() {
+  var search = document.getElementById('search');
+  function clearInactive() {
+    if (search.className == "inactive") {
+      search.value = "";
+      search.className = "";
+    }
+  }
+  bindEvent(search, 'focus', clearInactive);
+}
+
 /* Generates a table of contents: looks for h2 and h3 elements and generates
  * links.  "Decorates" the element with id=="nav" with this table of contents.
  */
diff --git a/doc/ie.css b/doc/ie.css
new file mode 100644
index 000000000..bb89d54be
--- /dev/null
+++ b/doc/ie.css
@@ -0,0 +1 @@
+#nav-main li { display: inline; }
diff --git a/doc/install.html b/doc/install.html
index 2c1ff2157..92b099fe8 100644
--- a/doc/install.html
+++ b/doc/install.html
@@ -1,6 +1,6 @@
-<!-- Installing Go -->
+<!-- Getting Started -->
 
-<h2>Introduction</h2>
+<h2 id="introduction">Introduction</h2>
 
 <p>Go is an open source project, distributed under a
 <a href="/LICENSE">BSD-style license</a>.
@@ -8,6 +8,8 @@ This document explains how to check out the sources,
 build them on your own machine, and run them.
 </p>
 
+<div class="detail">
+
 <p>
 There are two distinct ways to experiment with Go.
 This document focuses on the <code>gc</code> Go
@@ -17,117 +19,6 @@ compiler using the GCC back end, see
 <a href="gccgo_install.html">Setting up and using gccgo</a>.
 </p>
 
-<h2>Environment variables</h2>
-
-<p>
-The Go compilation environment depends on three environment variables plus one optional variable:
-</p>
-
-<dl>
-<dt>
-	<code>$GOROOT</code>
-</dt>
-<dd>The root of the Go tree.  Typically this is <code>$HOME/go</code>
-	but it can be any directory.
-</dd>
-
-<dt>
-<code>$GOOS</code> and <code>$GOARCH</code>
-</dt>
-<dd>
-	The name of the target operating system and compilation architecture.
-	Choices for <code>$GOOS</code> are <code>linux</code>,
-	<code>freebsd</code>,
-	<code>darwin</code> (Mac OS X 10.5 or 10.6),
-	and <code>nacl</code> (Native Client, an incomplete port).
-	Choices for <code>$GOARCH</code> are <code>amd64</code> (64-bit x86, the most mature port),
-	<code>386</code> (32-bit x86), and
-	<code>arm</code> (32-bit ARM, an incomplete port).
-	The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
-	<p>
-	<table cellpadding="0">
-	<tr>
-	<th width="50"><th align="left" width="100"><code>$GOOS</code></th> <th align="left" width="100"><code>$GOARCH</code></th>
-	</tr>
-	<tr>
-	<td></td><td><code>darwin</code></td> <td><code>386</code></td>
-	</tr>
-	<tr>
-	<td></td><td><code>darwin</code></td> <td><code>amd64</code></td>
-	</tr>
-	<tr>
-	<td></td><td><code>freebsd</code></td> <td><code>386</code></td>
-	</tr>
-	<tr>
-	<td></td><td><code>freebsd</code></td> <td><code>amd64</code></td>
-	</tr>
-	<tr>
-	<td></td><td><code>linux</code></td> <td><code>386</code></td>
-	</tr>
-	<tr>
-	<td></td><td><code>linux</code></td> <td><code>amd64</code></td>
-	</tr>
-	<tr>
-	<td></td><td><code>linux</code></td> <td><code>arm</code></td>
-	</tr>
-	<tr>
-	<td></td><td><code>nacl</code></td> <td><code>386</code></td>
-	</tr>
-	</table>
-	<p>
-</dd>
-
-<dt>
-<code>$GOBIN</code> (optional)
-</dt>
-<dd>
-	The location where binaries will be installed.
-	The default is <code>$HOME/bin</code>.
-	After installing, you will want to arrange to add this
-	directory to your <code>$PATH</code>, so you can use the tools.
-</dd>
-
-<dt>
-<code>$GOARM</code> (optional, arm, default=6)
-</dt>
-<dd>
-	The ARM architecture version the runtime libraries should target.
-	ARMv6 cores have more efficient synchronization primitives. Setting
-	<code>$GOARM</code> to 5 will compile the runtime libraries using
-	just SWP instructions that work on older architectures as well.
-	Running v6 code on an older core will cause an illegal instruction trap.
-</dd>
-</dl>
-
-<p>
-Note that <code>$GOARCH</code> and <code>$GOOS</code> identify the
-<em>target</em> environment, not the environment you are running on.
-In effect, you are always cross-compiling.
-</p>
-
-<p>
-Set these variables in your shell profile (<code>$HOME/.bashrc</code>,
-<code>$HOME/.profile</code>, or equivalent). The settings might look 
-something like this:
-</p>
-
-<pre>
-export GOROOT=$HOME/go
-export GOARCH=amd64
-export GOOS=linux
-</pre>
-
-<p>
-Double-check them by listing your environment. (You will need to launch
-a new shell or terminal window for the changes to take effect.)
-</p>
-
-<pre>
-$ env | grep '^GO'
-</pre>
-
-<h2>Ports</h2>
-
 <p>
 The Go compilers support three instruction sets.
 There are important differences in the quality of the compilers for the different
@@ -147,17 +38,19 @@ architectures.
 	<code>386</code> (a.k.a. <code>x86</code> or <code>x86-32</code>); <code>8g,8l,8c,8a</code>
 </dt>
 <dd>
-	Comparable to the <code>amd64</code> port. Not as well soaked but
-	should be nearly as solid.
-
+	Comparable to the <code>amd64</code> port.
 </dd>
 <dt>
 	<code>arm</code> (a.k.a. <code>ARM</code>); <code>5g,5l,5c,5a</code>
 </dt>
 <dd>
-	It's got a couple of outstanding bugs but is improving.
-	Tested against QEMU and an android phone.
-	Only supports Linux binaries.
+	Incomplete.
+	It only supports Linux binaries, the optimizer is not enabled,
+	and floating point is performed entirely in software.
+	However, all tests pass.
+	Work on the optimizer and use of the VFP hardware
+	floating point unit is underway.
+	Tested against a Nexus One.
 </dd>
 </dl>
 
@@ -169,74 +62,106 @@ support for segmented stacks, and a strong goroutine implementation.
 </p>
 
 <p>
-See the separate <a href="gccgo_install.html"><code>gccgo</code> document</a>
-for details about that compiler and environment.
+The compilers can target the FreeBSD, Linux,
+and OS X (a.k.a. Darwin) operating systems.
+(A port to Microsoft Windows is in progress but incomplete.  See the 
+<a href="http://code.google.com/p/go/wiki/WindowsPort">Windows Port</a>
+page for details.)
+The full set of supported combinations is listed in the discussion of
+<a href="#environment">environment variables</a> below.
 </p>
 
-<h2>Install C tools, if needed</h2>
+</div>
 
-<p>The Go tool chain is written in C.  To build it, you need
-to have GCC, the standard C libraries, the parser generator Bison,
-<tt>make</tt>, <tt>awk</tt>, and the text editor <tt>ed</tt> installed.  On OS X, they can be
-installed as part of
-<a href="http://developer.apple.com/TOOLS/Xcode/">Xcode</a>.  On Linux, use
+<h2 id="ctools">Install C tools, if needed</h2>
+
+<p>The Go tool chain is written in C.
+To build it, you need these programs installed: 
+<ul>
+<li>GCC, 
+<li>the standard C libraries, 
+<li>the parser generator Bison,
+<li><tt>make</tt>, 
+<li><tt>awk</tt>, and 
+<li>the text editor <tt>ed</tt>.
+</ul>
 </p>
 
-<pre>
-$ sudo apt-get install bison gcc libc6-dev ed gawk make
-</pre>
+<p>On OS X, they can be
+installed as part of
+<a href="http://developer.apple.com/TOOLS/Xcode/">Xcode</a>. 
+</p>
 
-<p>
-(or the equivalent on your Linux distribution).
+<p>On Ubuntu/Debian, use <code>sudo apt-get install bison ed gawk gcc libc6-dev make</code>.
 </p>
 
-<h2>Fetch the repository</h2>
+<h2 id="mercurial">Install Mercurial, if needed</h2>
 
 <p>
-If you do not have Mercurial installed (you do not have an <code>hg</code> command),
-this command:
+To perform the next step you must have Mercurial installed. (Check that you  have an <code>hg</code> command.) This suffices to install Mercurial on most systems:
 </p>
-
 <pre>
-$ sudo easy_install mercurial
+sudo easy_install mercurial
 </pre>
+(On Ubuntu/Debian, you might try <code>apt-get install python-setuptools
+python-dev build-essential</code> first. The Mercurial in your distribution's
+package repository will most likely be old and broken.)
+</p>
+<p>
+If that fails, try installing manually from the <a href="http://mercurial.selenic.com/wiki/Download">Mercurial Download</a> page.</p>
+</p>
 
-<p>works on most systems.
-(On Ubuntu/Debian, you might try <code>apt-get install python-setuptools python-dev build-essential gcc</code> first.)
-If that fails, visit the <a href="http://mercurial.selenic.com/wiki/Download">Mercurial Download</a> page.</p>
+<h2 id="fetch">Fetch the repository</h2>
 
-<p>Make sure the <code>$GOROOT</code> directory does not exist or is empty.
+<p>
+<p>Go will install to a directory named <code>go</code>.
+Change to the directory that will be its parent
+and make sure the <code>go</code> directory does not exist.
 Then check out the repository:</p>
 
 <pre>
-$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT
+$ hg clone -r release https://go.googlecode.com/hg/ go
 </pre>
 
-<h2>Install Go</h2>
+<h2 id="install">Install Go</h2>
 
 <p>
 To build the Go distribution, run
 </p>
 
 <pre>
-$ cd $GOROOT/src
+$ cd go/src
 $ ./all.bash
 </pre>
 
 <p>
-If all goes well, it will finish by printing
+If all goes well, it will finish by printing output like:
 </p>
 
 <pre>
 --- cd ../test
 N known bugs; 0 unexpected bugs
+
+---
+Installed Go for linux/amd64 in /home/you/go.
+Installed commands in /home/you/go/bin.
+*** You need to add /home/you/go/bin to your $PATH. ***
+The compiler is 6g.
 </pre>
 
 <p>
-where <var>N</var> is a number that varies from release to release.
+where <var>N</var> is a number that varies from release to release
+and the details on the last few lines will reflect the operating system,
+architecture, and root directory used during the install.
 </p>
 
-<h2>Writing programs</h2>
+<div class="detail">
+
+<p>For more information about ways to control the build,
+see the discussion of <a href="#environment">environment variables</a> below.</p>
+</div>
+
+<h2 id="writing">Writing programs</h2>
 
 <p>
 Given a file <code>file.go</code>, compile it using
@@ -299,34 +224,57 @@ command line.
 The linker learns about them by reading <code>hello.6</code>.
 </p>
 
+<div class="detail">
 <p>
 To build more complicated programs, you will probably
 want to use a
 <code>Makefile</code>.
 There are examples in places like
-<code>$GOROOT/src/cmd/godoc/Makefile</code>
-and <code>$GOROOT/src/pkg/*/Makefile</code>.
+<code>go/src/cmd/godoc/Makefile</code>
+and <code>go/src/pkg/*/Makefile</code>.
 The
 <a href="contribute.html">document</a>
 about contributing to the Go project
 gives more detail about
 the process of building and testing Go programs.
 </p>
+</div>
 
-<h2>Keeping up with releases</h2>
+<h2 id="next">What's next</h2>
+
+<p>
+Start by reading the <a href="go_tutorial.html">Go Tutorial</a>.
+</p>
+
+<p>
+Build a web application by following the <a href="codelab/wiki/">Wiki
+Codelab</a>.
+</p>
+
+<p>
+Read <a href="effective_go.html">Effective Go</a> to learn about writing
+idiomatic Go code.
+</p>
+
+<p>
+For the full story, consult Go's extensive 
+<a href="docs.html">documentation</a>.
+</p>
+
+<h2 id="releases">Keeping up with releases</h2>
 
 <p>New releases are announced on the <a href="http://groups.google.com/group/golang-nuts">Go Nuts</a> mailing list.
 To update an existing tree to the latest release, you can run:
 </p>
 
 <pre>
-$ cd $GOROOT/src
+$ cd go/src
 $ hg pull
 $ hg update release
 $ ./all.bash
 </pre>
 
-<h2>Community resources</h2>
+<h2 id="community">Community resources</h2>
 
 <p>
 For real-time help, there may be users or developers on
@@ -348,4 +296,144 @@ there is another mailing list, <a href="http://groups.google.com/group/golang-ch
 that receives a message summarizing each checkin to the Go repository.
 </p>
 
+<h2 id="environment">Environment variables</h2>
+
+<p>
+The Go compilation environment can be customized by environment variables.
+None are required by the build, but you may wish to set them
+to override the defaults.
+</p>
+
+<dl>
+<dt>
+	<code>$GOROOT</code>
+</dt>
+<dd>
+	The root of the Go tree, often <code>$HOME/go</code>.
+	This defaults to the parent of the directory where <code>all.bash</code> is run.
+	If you choose not to set <code>$GOROOT</code>, you must
+	run <code>gomake</code> instead of <code>make</code> or <code>gmake</code>
+	when developing Go programs using the conventional makefiles.
+</dd>
+
+<dt>
+	<code>$GOROOT_FINAL</code>
+</dt>
+<dd>
+	The value assumed by installed binaries and scripts when
+	<code>$GOROOT</code> is not set.
+	It defaults to the value used for <code>$GOROOT</code>.
+	If you want to build the Go tree in one location
+	but move it elsewhere after the build, set 
+	<code>$GOROOT_FINAL</code> to the eventual location.
+</dd>
+
+<dt>
+<code>$GOOS</code> and <code>$GOARCH</code>
+</dt>
+<dd>
+	The name of the target operating system and compilation architecture.
+	These default to the values of <code>$GOHOSTOS</code> and
+	<code>$GOHOSTARCH</code> respectively (described below).
 
+	<p>
+	Choices for <code>$GOOS</code> are <code>linux</code>,
+	<code>freebsd</code>,
+	<code>darwin</code> (Mac OS X 10.5 or 10.6),
+	and <code>windows</code> (Windows, an incomplete port).
+	Choices for <code>$GOARCH</code> are <code>amd64</code> (64-bit x86, the most mature port),
+	<code>386</code> (32-bit x86), and
+	<code>arm</code> (32-bit ARM, an incomplete port).
+	The valid combinations of <code>$GOOS</code> and <code>$GOARCH</code> are:
+	<table cellpadding="0">
+	<tr>
+	<th width="50"><th align="left" width="100"><code>$GOOS</code></th> <th align="left" width="100"><code>$GOARCH</code></th> <th align="left"></th>
+	</tr>
+	<tr>
+	<td></td><td><code>darwin</code></td> <td><code>386</code></td>
+	</tr>
+	<tr>
+	<td></td><td><code>darwin</code></td> <td><code>amd64</code></td>
+	</tr>
+	<tr>
+	<td></td><td><code>freebsd</code></td> <td><code>386</code></td>
+	</tr>
+	<tr>
+	<td></td><td><code>freebsd</code></td> <td><code>amd64</code></td>
+	</tr>
+	<tr>
+	<td></td><td><code>linux</code></td> <td><code>386</code></td>
+	</tr>
+	<tr>
+	<td></td><td><code>linux</code></td> <td><code>amd64</code></td>
+	</tr>
+	<tr>
+	<td></td><td><code>linux</code></td> <td><code>arm</code></td> <td><i>incomplete</i></td>
+	</tr>
+	<tr>
+	<td></td><td><code>windows</code></td> <td><code>386</code></td> <td><i>incomplete</i></td>
+	</tr>
+	</table>
+</dd>
+
+<dt>
+<code>$GOHOSTOS</code> and <code>$GOHOSTARCH</code>
+</dt>
+<dd>
+	The name of the host operating system and compilation architecture.
+	These default to the local system's operating system and
+	architecture.
+
+	<p>
+	Valid choices are the same as for <code>$GOOS</code> and
+	<code>$GOARCH</code>, listed above.
+	The specified values must be compatible with the local system.
+	For example, you should not set <code>$GOHOSTARCH</code> to 
+	<code>arm</code> on an x86 system.
+</dd>
+
+<dt>
+<code>$GOBIN</code>
+</dt>
+<dd>
+	The location where binaries will be installed.
+	The default is <code>$GOROOT/bin</code>.
+	After installing, you will want to arrange to add this
+	directory to your <code>$PATH</code>, so you can use the tools.
+</dd>
+
+<dt>
+<code>$GOARM</code> (arm, default=6)
+</dt>
+<dd>
+	The ARM architecture version the runtime libraries should target.
+	ARMv6 cores have more efficient synchronization primitives. Setting
+	<code>$GOARM</code> to 5 will compile the runtime libraries using
+	just SWP instructions that work on older architectures as well.
+	Running v6 code on an older core will cause an illegal instruction trap.
+</dd>
+</dl>
+
+<p>
+Note that <code>$GOARCH</code> and <code>$GOOS</code> identify the
+<em>target</em> environment, not the environment you are running on.
+In effect, you are always cross-compiling.
+By architecture, we mean the kind of binaries
+that the target environment can run:
+an x86-64 system running a 32-bit-only operating system
+must set <code>GOARCH</code> to <code>386</code>,
+not <code>amd64</code>.
+</p>
+
+<p>
+If you choose to override the defaults,
+set these variables in your shell profile (<code>$HOME/.bashrc</code>,
+<code>$HOME/.profile</code>, or equivalent). The settings might look 
+something like this:
+</p>
+
+<pre>
+export GOROOT=$HOME/go
+export GOARCH=386
+export GOOS=linux
+</pre>
diff --git a/doc/logo.png b/doc/logo.png
new file mode 100644
index 000000000..076ce398e
--- /dev/null
+++ b/doc/logo.png
diff --git a/doc/play_overlay.png b/doc/play_overlay.png
new file mode 100644
index 000000000..20ef7f399
--- /dev/null
+++ b/doc/play_overlay.png
diff --git a/doc/playground.html b/doc/playground.html
new file mode 100644
index 000000000..01d3adc9c
--- /dev/null
+++ b/doc/playground.html
@@ -0,0 +1,27 @@
+<!-- About the Go Playground -->
+
+<div class="left-column">
+<p>
+The Go Playground is a web service that runs on 
+<a href="http://golang.org/">golang.org</a>'s servers.
+The service receives a Go program, compiles, links, and runs the program inside 
+a sandbox, then returns the output.
+</p>
+
+<p>
+There are limitations to the programs that can be run in the Playground.
+They must be single-threaded (but they may use many goroutines).
+There are also limits on execution time, and CPU and memory usage.
+The Playground can access only a subset of the standard library
+(notably absent are network and file system access).
+Therefore, the only communication a Playground program has to the outside world
+is via standard output.
+</div>
+
+<div class="right-column">
+<script src="http://www.google.com/jsapi" type="text/javascript"></script>
+<div id="playground" class="small"></div>
+<script src="/doc/play/playground.js"></script>
+</div>
+
+<div class="end-columns"></div>
diff --git a/doc/progs/cat.go b/doc/progs/cat.go
index f8d1a54fb..697e5f786 100644
--- a/doc/progs/cat.go
+++ b/doc/progs/cat.go
@@ -15,11 +15,11 @@ func cat(f *file.File) {
 	const NBUF = 512
 	var buf [NBUF]byte
 	for {
-		switch nr, er := f.Read(&buf); true {
+		switch nr, er := f.Read(buf[:]); true {
 		case nr < 0:
 			fmt.Fprintf(os.Stderr, "cat: error reading from %s: %s\n", f.String(), er.String())
 			os.Exit(1)
-		case nr == 0:  // EOF
+		case nr == 0: // EOF
 			return
 		case nr > 0:
 			if nw, ew := file.Stdout.Write(buf[0:nr]); nw != nr {
@@ -30,7 +30,7 @@ func cat(f *file.File) {
 }
 
 func main() {
-	flag.Parse()   // Scans the arg list and sets up flags
+	flag.Parse() // Scans the arg list and sets up flags
 	if flag.NArg() == 0 {
 		cat(file.Stdin)
 	}
diff --git a/doc/progs/cat_rot13.go b/doc/progs/cat_rot13.go
index 42c6195fb..03fc02259 100644
--- a/doc/progs/cat_rot13.go
+++ b/doc/progs/cat_rot13.go
@@ -15,10 +15,10 @@ var rot13Flag = flag.Bool("rot13", false, "rot13 the input")
 
 func rot13(b byte) byte {
 	if 'a' <= b && b <= 'z' {
-	   b = 'a' + ((b - 'a') + 13) % 26
+		b = 'a' + ((b-'a')+13)%26
 	}
 	if 'A' <= b && b <= 'Z' {
-	   b = 'A' + ((b - 'A') + 13) % 26
+		b = 'A' + ((b-'A')+13)%26
 	}
 	return b
 }
@@ -29,7 +29,7 @@ type reader interface {
 }
 
 type rotate13 struct {
-	source	reader
+	source reader
 }
 
 func newRotate13(source reader) *rotate13 {
@@ -57,11 +57,11 @@ func cat(r reader) {
 		r = newRotate13(r)
 	}
 	for {
-		switch nr, er := r.Read(&buf); {
+		switch nr, er := r.Read(buf[:]); {
 		case nr < 0:
 			fmt.Fprintf(os.Stderr, "cat: error reading from %s: %s\n", r.String(), er.String())
 			os.Exit(1)
-		case nr == 0:  // EOF
+		case nr == 0: // EOF
 			return
 		case nr > 0:
 			nw, ew := file.Stdout.Write(buf[0:nr])
@@ -73,7 +73,7 @@ func cat(r reader) {
 }
 
 func main() {
-	flag.Parse()   // Scans the arg list and sets up flags
+	flag.Parse() // Scans the arg list and sets up flags
 	if flag.NArg() == 0 {
 		cat(file.Stdin)
 	}
diff --git a/doc/progs/file.go b/doc/progs/file.go
index b2f2c0476..d3fb5ae9e 100644
--- a/doc/progs/file.go
+++ b/doc/progs/file.go
@@ -10,8 +10,8 @@ import (
 )
 
 type File struct {
-	fd      int    // file descriptor number
-	name    string // file name at Open time
+	fd   int    // file descriptor number
+	name string // file name at Open time
 }
 
 func newFile(fd int, name string) *File {
@@ -27,7 +27,7 @@ var (
 	Stderr = newFile(2, "/dev/stderr")
 )
 
-func Open(name string, mode int, perm int) (file *File, err os.Error) {
+func Open(name string, mode int, perm uint32) (file *File, err os.Error) {
 	r, e := syscall.Open(name, mode, perm)
 	if e != 0 {
 		err = os.Errno(e)
@@ -40,7 +40,7 @@ func (file *File) Close() os.Error {
 		return os.EINVAL
 	}
 	e := syscall.Close(file.fd)
-	file.fd = -1  // so it can't be closed again
+	file.fd = -1 // so it can't be closed again
 	if e != 0 {
 		return os.Errno(e)
 	}
diff --git a/doc/progs/helloworld3.go b/doc/progs/helloworld3.go
index e065f02e6..adbcea324 100644
--- a/doc/progs/helloworld3.go
+++ b/doc/progs/helloworld3.go
@@ -13,8 +13,8 @@ import (
 func main() {
 	hello := []byte("hello, world\n")
 	file.Stdout.Write(hello)
-	file, err := file.Open("/does/not/exist",  0,  0)
-	if file == nil {
+	f, err := file.Open("/does/not/exist",  0,  0)
+	if f == nil {
 		fmt.Printf("can't open file; err=%s\n",  err.String())
 		os.Exit(1)
 	}
diff --git a/doc/progs/run b/doc/progs/run
index 07bc141df..29f1f8152 100755
--- a/doc/progs/run
+++ b/doc/progs/run
@@ -5,9 +5,7 @@
 
 set -e
 
-GOBIN="${GOBIN:-$HOME/bin}"
-
-. "$GOROOT"/src/Make.$GOARCH
+eval $(gomake --no-print-directory -f ../../src/Make.inc go-env)
 
 if [ -z "$O" ]; then
 	echo 'missing $O - maybe no Make.$GOARCH?' 1>&2
@@ -34,11 +32,11 @@ for i in \
 ; do
 	BASE=$(basename $i .go)
 
-	"$GOBIN"/$GC $i
+	$GC $i
 done
 
 function testit {
-	"$GOBIN"/$LD $1.$O
+	$LD $1.$O
 	x=$(echo $(./$O.out $2 2>&1))  # extra echo canonicalizes
 	if [ "$x" != "$3" ]
 	then
@@ -47,7 +45,7 @@ function testit {
 }
 
 function testitpipe {
-	"$GOBIN"/$LD $1.$O
+	$LD $1.$O
 	x=$(echo $(./$O.out | $2 2>&1))  # extra echo canonicalizes
 	if [ "$x" != "$3" ]
 	then
@@ -76,7 +74,7 @@ testitpipe sieve "sed 10q" "2 3 5 7 11 13 17 19 23 29"
 testitpipe sieve "sed 10q" "2 3 5 7 11 13 17 19 23 29"
 
 # server hangs; don't run it, just compile it
-"$GOBIN"/$GC server.go
+$GC server.go
 testit server1 "" ""
 
 rm -f $O.out *.$O
diff --git a/doc/progs/sortmain.go b/doc/progs/sortmain.go
index 6bd504a5b..a77ae7381 100644
--- a/doc/progs/sortmain.go
+++ b/doc/progs/sortmain.go
@@ -6,7 +6,7 @@ package main
 
 import (
 	"fmt"
-	"sort"
+	"./sort"
 )
 
 func ints() {
diff --git a/doc/progs/sum.go b/doc/progs/sum.go
index 74fd5bca3..9caa799fd 100644
--- a/doc/progs/sum.go
+++ b/doc/progs/sum.go
@@ -6,7 +6,7 @@ package main
 
 import "fmt"
 
-func sum(a []int) int {   // returns an int
+func sum(a []int) int { // returns an int
 	s := 0
 	for i := 0; i < len(a); i++ {
 		s += a[i]
@@ -16,6 +16,6 @@ func sum(a []int) int {   // returns an int
 
 
 func main() {
-	s := sum(&[3]int{1,2,3})  // a slice of the array is passed to sum
+	s := sum([3]int{1, 2, 3}[:]) // a slice of the array is passed to sum
 	fmt.Print(s, "\n")
 }
diff --git a/doc/root.html b/doc/root.html
index 3a5a49515..f98f9c243 100644
--- a/doc/root.html
+++ b/doc/root.html
@@ -1,131 +1,97 @@
-<!-- The Go Programming Language -->
+<link rel="stylesheet" type="text/css" href="/doc/frontpage.css">
 
-<script>
-  // On the frontpage we hide the header and navigation elements that other
-  // pages have.
-  document.getElementById('generatedHeader').style.display = 'none';
-  document.getElementById('nav').style.display = 'none';
-</script>
-
-<!-- begin blog post widget JS/styles -->
 <script src="http://www.google.com/jsapi" type="text/javascript"></script>
 <script type="text/javascript">
 function loadFeed() {
-	var url = "http://blog.golang.org/feeds/posts/default";
-	var divId = "blogFeed";
-	var feed = new google.feeds.Feed(url);
-	feed.setNumEntries(8)
-	feed.load(function (result) {
-		var container = document.getElementById(divId)
-		if (result.error) {
-			container.innerHTML = "Error loading feed.";
-			return;
-		}
-		container.innerHTML = "";
-		var entries = result.feed.entries;
-		for (var i=0; i<entries.length; i++) {
-			var a = document.createElement("a");
-			a.setAttribute("href", entries[i].link);
-			a.appendChild(document.createTextNode(entries[i].title));
-			container.appendChild(a);
-		}
-	});
+        var url = "http://blog.golang.org/feeds/posts/default";
+        var divId = "blogFeed";
+        var feed = new google.feeds.Feed(url);
+        feed.setNumEntries(4)
+        feed.load(function (result) {
+                var container = document.getElementById(divId)
+                if (result.error) {
+                        container.innerHTML = "Error loading feed.";
+                        return;
+                }
+                container.innerHTML = "";
+                var entries = result.feed.entries;
+                for (var i=0; i<entries.length; i++) {
+                        var li = document.createElement("li");
+                        var a = document.createElement("a");
+                        a.setAttribute("href", entries[i].link);
+                        var span_title = document.createElement("span"); 
+                        span_title.appendChild(document.createTextNode(entries[i].title));
+                        span_title.className = "title";
+                        a.appendChild(span_title);
+                        li.appendChild(a);
+                        var span_date = document.createElement("span"); 
+                        span_date.appendChild(document.createTextNode(entries[i].publishedDate.substr(0, 11)));
+                        span_date.className = "date";
+                        a.appendChild(span_date);
+                        container.appendChild(li);
+                }
+        });
 }
 google.load("feeds", "1");
 google.setOnLoadCallback(loadFeed);
 </script>
-<!-- end blog post widget JS/styles -->
-
-<div id="gettingStarted">
-  <h1>Getting started</h1>
-
-  <ol>
-    <li>
-      <span><a href="/doc/install.html">Install Go</a>.</span>
-    </li>
-
-    <li>
-      <span>Read the <a href="/doc/go_tutorial.html">tutorial</a>.</span>
-    </li>
-
-    <li>
-      <span>Learn the <a href="/pkg">libraries</a>.</span>
-    </li>
-  </ol>
-
-  <h1>Slow compiles?<br>Watch this</h1>
-  <table width="100%">
-    <tr>
-      <td align=center width="100%">
-        <a href="http://www.youtube.com/watch?v=wwoWei-GAPo"><img src="/doc/video-snap.jpg"></a>
-      </td>
-    </tr>
-  </table>
-</div>
-
-<div id="blog">
-	<h1>From the <a href="http://blog.golang.org">Go Blog</a>:</h1>
-	<div id="blogFeed">Loading...</div>
-</div>
-
-
-<div id="frontpage">
-
-<table style="padding-top: 1em; padding-bottom: 2em;">
-  <tr>
-    <td>
-      <img style="padding-right: 1em;" src="/doc/go-logo-black.png">
-    </td>
-    <td>
-      <div><span style="font-size: 2em; font-weight: bold;">a systems programming language</span><br><span style="font-size: 1.5em;">expressive, concurrent, garbage-collected</span></div>
-    </td>
-  </tr>
-</table>
-
-<p style="font-size: 1.5em; font-weight: bold;">Go is &hellip;</p>
-
-<h3>&hellip; simple</h3>
-<pre class="code">
-package main
-
-import "fmt"
-
-func main() {
-  fmt.Printf("Hello, 世界\n")
-}</pre>
-
-<h3>&hellip; fast</h3>
-
-<p>
-Go compilers produce fast code fast. Typical builds take a fraction of a second yet the resulting programs run nearly as quickly as comparable C or C++ code.
-</p>
-
-<h3>&hellip; safe</h3>
-
-<p>Go is type safe and memory safe. Go has pointers but no pointer arithmetic.
-For random access, use slices, which know their limits.</p>
-
-<h3>&hellip; concurrent</h3>
-
-<p>
-Go promotes writing systems and servers as sets of lightweight
-communicating processes, called goroutines, with strong support from the language.
-Run thousands of goroutines if you want&mdash;and say good-bye to stack overflows.
-</p>
-
-<h3>&hellip; fun</h3>
-
-<p>
-Go has fast builds, clean syntax, garbage collection,
-methods for any type, and run-time reflection.
-It feels like a dynamic language but has the speed and safety of a static language.
-It's a joy to use.
-</p>
-
-<h3>&hellip; open source</h3>
-
-<p>
-<a href="/doc/install.html">Go for it</a>.
-</p>
 
-</div>
+  <div id="frontpage">
+    <div class="left-column">
+      <p style="margin-top: 0;">
+        The Go programming language is an open source project to make
+        programmers more productive.  Go is expressive, concise, clean,
+        and efficient.  Its concurrency mechanisms make it easy to write
+        programs that get the most out of multicore and networked machines,
+        while its novel type system enables flexible and modular program
+        construction.  Go compiles quickly to machine code yet has the
+        convenience of garbage collection and the power of run-time reflection.
+        It's a fast, statically typed, compiled language that feels like a 
+        dynamically typed, interpreted language.
+      </p>
+      <h2>Check it out!</h2>
+      <p>
+      <div class="how">[<a href="/doc/playground.html">How does this work?</a>]</div>
+      <a href="/doc/install.html">Install Go now</a>, or try it right here in your browser:</p>
+      <div id="playground" class="small"></div>
+      <script src="/doc/play/playground.js"></script>
+    </div>
+    <div class="right-column">
+      <div id="content-rotating">
+      <div id="content-videos">
+        <h2>Go Videos <span class="more">| <a href="/doc/docs.html#videos_talks">More...</a></span></h2>
+        <a class="video" href="http://osdc.blip.tv/file/4432146/"><img src="/doc/play_overlay.png" class="thumbnail _004" /> <span class="caption title">&ldquo;Practical Go Programming&rdquo;</span> <span class="caption description">OSDC Tech Talk</span></a>
+      </div>
+      <h2>Go Blog <span class="more">| <a href="http://blog.golang.org/">More...</a></span></h2>
+      <div id="content-blog">
+        <ul id="blogFeed">
+        </ul>
+      </div>
+      </div>
+      <h2>Quick Links</h2>
+      <div id="resources">
+        <div id="resources-users">
+          <h3>For newcomers:</h3>
+          <ul>
+            <li><a href="/doc/install.html">Getting Started</a></li>
+            <li><a href="/doc/go_tutorial.html">Tutorial</a></li>
+            <li><a href="/doc/effective_go.html">Effective Go</a></li>
+            <li><a href="/doc/go_faq.html">Go FAQ</a></li>
+            <li><a href="/doc/docs.html">Other Documentation</a></li>
+          </ul>
+        </div>
+        <div id="resources-contributors" class="resources">
+          <h3>For developers:</h3>
+          <ul>
+            <li><a href="http://godashboard.appspot.com/package">Package Dashboard</a></li>
+            <li><a href="http://code.google.com/p/go/issues">Issue Tracker</a></li>
+            <li><a href="http://godashboard.appspot.com/">Build Status</a></li>
+            <li><a href="http://code.google.com/p/go/source/browse/">Go Source</a> [<a href="http://code.google.com/p/go/source/list">changes</a>]</li>
+            <li><a href="/pkg/">Package Reference</a></li>
+            <li><a href="/doc/go_spec.html">Language Specification</a></li>
+          </ul>
+        </div>
+      </div>  
+    </div>
+    <div class="end-columns"></div>
+  </div>
diff --git a/doc/style.css b/doc/style.css
deleted file mode 100644
index cd57232a7..000000000
--- a/doc/style.css
+++ /dev/null
@@ -1,282 +0,0 @@
-/*
-   Copyright 2009 The Go Authors. All rights reserved.
-   Use of this source code is governed by a BSD-style
-   license that can be found in the LICENSE file.
-*/
-
-/* ------------------------------------------------------------------------- */
-/* Styles meant to help page authors achieve beauty. */
-
-a {
-  text-decoration: none;
-}
-
-code, .code {
-  font-size: 100%;
-  font-family: monospace;
-  color: #0f398d;
-}
-
-kbd {
-  font-size: 100%;
-  font-family: monospace;
-  font-weight: bold;
-}
-
-pre.ebnf {
-  background-color: #ffffe9;
-}
-
-pre.grammar {
-  background-color: #ffffe9;
-}
-
-p.rule {
-  font-style: italic;
-}
-
-span.event {
-  font-style: italic;
-}
-
-span.alert {
-  color: #ff0000;
-}
-
-body {
-  font: 13px Helvetica, Arial, sans-serif;
-  margin-bottom: 0px;
-}
-
-h1 {
-  margin-top: 0;
-  padding-top: 0.75em;
-  margin-bottom: 0.75em;
-}
-
-h2, h3, h4, h5, h6 {
-  font-family: Helvetica, Arial, sans-serif;
-  margin-bottom: 0.25em;
-}
-
-h2 {
-  background-color: #e5ecf9;
-  margin-top: 2em;
-  border-top:1px solid #36C;
-  padding-left: 0.2em;
-}
-
-pre {
-  font-size: 9pt;
-  background-color: #f8f8ff;
-  margin: 1em 0 0 0;
-  padding: .99em;
-  line-height: 125%;
-  overflow: auto;
-  word-wrap: break-word;
-}
-
-li {
-  padding-bottom: 0.5em;
-}
-
-li pre {
-  margin: 0.5em 0px 1em 0px;
-}
-
-a:link {
-  color: #0f398d
-}
-
-a:visited {
-  color: #0b2455
-}
-
-a:hover {
-  color: #0000ff
-}
-
-/* ------------------------------------------------------------------------- */
-/* Styles used in the boilerplate-ish parts of pages. */
-
-div#content {
-  margin-left: 20%;
-  padding: 0 1em 2em 1em;
-  margin-top: 0px;
-  margin-bottom: 0px;
-/*
-  border-left: 2px solid #e5ecf9;
-  border-right: 2px solid #e5ecf9;
-  border-bottom: 2px solid #e5ecf9;
-*/
-}
-
-#topnav {
-  margin: 0px;
-  padding-top: 0.2em;
-  width: 100%;
-  white-space: nowrap;
-  background-color: #ffffff;
-  border-bottom: 2px solid #36C;
-  font: bold 150% Helvetica, Arial, sans-serif;
-}
-
-div#linkList {
-  margin-top: 1.5em;
-  padding-left: 0.5em;
-  font: 13px Helvetica, Arial, sans-serif;
-  float: left;
-  width: 18%;
-  background-color: #fffff0;
-  border: 2px solid #ba9836;
-}
-
-div#linkList ul {
-  padding: 1px;
-  list-style-type: none;
-}
-
-div#linkList li {
-  margin-left: 1em;
-  padding-bottom: 0.2em;
-}
-
-div#linkList li.navhead {
-  font-weight: bold;
-  margin-left: 0px;
-  padding-bottom: 0.25em;
-}
-
-#nav dl {
-  margin: 0 0.5em 0 0.5em;
-  padding: 0px;
-}
-
-.navtop {
-  font-size: xx-small;
-  float: right;
-}
-
-#footer {
-  margin: 2em 0 0 0;
-  text-align: center;
-  color: #555;
-  font-size: small;
-}
-
-#footer p {
-  margin: 0px;
-}
-
-#footer a {
-  color: #555;
-}
-
-@media print {
-  div#linkList {
-    display: none;
-  }
-  .navtop {
-    display: none;
-  }
-  div#content {
-    margin-left: 0px;
-    border: none;
-  }
-}
-
-
-/* ------------------------------------------------------------------------- */
-/* Styles used by godoc */
-
-table.layout {
-  border-width: 0px;
-  border-spacing: 0px;
-  padding: 0px;
-}
-
-span.comment {
-  color: #0000a0;
-}
-
-span.highlight {
-  font-weight: bold;
-  background-color: #ffffa0;
-}
-
-span.subtitle {
-  font-weight: bold;
-  font-size: medium;
-}
-
-/* same style as for gettingStarted */
-#menu {
-  margin-top: 1.5em;
-  margin-left: 1.75em;
-  margin-right: 0em;
-  float: right;
-  background-color: #fffff0;
-  padding-left: 1em;
-  padding-right: 1em;
-  padding-bottom: 0.75em;
-  border: 2px solid #ba9836;
-}
-
-/* same color scheme as for gettingStarted */
-#content .popup {
-  position: absolute;
-  border: 1px solid #ba9836;
-  background-color: #fffff0;
-  margin-top: 3em;
-  padding: 3px;
-}
-
-#content .identifier,
-#content .type {
-  color: #008;
-}
-
-/* ------------------------------------------------------------------------- */
-/* Styles for the frontpage */
-
-#gettingStarted, #blog {
-  margin-top: 1.5em;
-  margin-left: 1.75em;
-  margin-right: 0em;
-  float: right;
-  clear: right;
-  background-color: #fffff0;
-  padding-left: 1em;
-  padding-right: 1em;
-  padding-bottom: 0.75em;
-  border: 2px solid #ba9836;
-  width: 160px;
-}
-
-#blog { margin-bottom: 1.5em; }
-#blog h1 { font-size: 1.2em; }
-#blog #blogFeed a { font-size: 1.1em; display: block; margin-top: 1em; }
-
-#gettingStarted h1 {
-  padding-top: 0.3em;
-  margin-bottom: 0.2em;
-  font-size: 1.5em;
-}
-
-#gettingStarted ol {
-  padding-left: 2em;
-}
-
-#gettingStarted a img {
-  border: 1px solid blue;
-}
-
-#frontpage {
-  width: 100%;
-}
-
-#frontpage h3 {
-  margin-left: 3em;
-  font-size: 1.5em;
-  font-weight: normal;
-}
diff --git a/doc/talks/gofrontend-gcc-summit-2010.pdf b/doc/talks/gofrontend-gcc-summit-2010.pdf
new file mode 100644
index 000000000..157fd7676
--- /dev/null
+++ b/doc/talks/gofrontend-gcc-summit-2010.pdf
diff --git a/doc/talks/io2010/balance.go b/doc/talks/io2010/balance.go
index 6a0713831..b01f7468c 100644
--- a/doc/talks/io2010/balance.go
+++ b/doc/talks/io2010/balance.go
@@ -6,6 +6,7 @@ package main
 
 import (
 	"container/heap"
+	"flag"
 	"fmt"
 	"rand"
 	"time"
@@ -14,6 +15,8 @@ import (
 const nRequester = 100
 const nWorker = 10
 
+var roundRobin = flag.Bool("r", false, "use round-robin scheduling")
+
 // Simulation of some work: just sleep for a while and report how long.
 func op() int {
 	n := rand.Int63n(1e9)
@@ -125,7 +128,7 @@ func (b *Balancer) print() {
 }
 
 func (b *Balancer) dispatch(req Request) {
-	if false {
+	if *roundRobin {
 		w := b.pool[b.i]
 		w.requests <- req
 		w.pending++
@@ -144,7 +147,7 @@ func (b *Balancer) dispatch(req Request) {
 }
 
 func (b *Balancer) completed(w *Worker) {
-	if false {
+	if *roundRobin {
 		w.pending--
 		return
 	}
@@ -156,6 +159,7 @@ func (b *Balancer) completed(w *Worker) {
 }
 
 func main() {
+	flag.Parse()
 	work := make(chan Request)
 	for i := 0; i < nRequester; i++ {
 		go requester(work)
diff --git a/doc/video-001.png b/doc/video-001.png
new file mode 100644
index 000000000..d3468bbe8
--- /dev/null
+++ b/doc/video-001.png
diff --git a/doc/video-002.png b/doc/video-002.png
new file mode 100644
index 000000000..4f7c5d184
--- /dev/null
+++ b/doc/video-002.png
diff --git a/doc/video-003.png b/doc/video-003.png
new file mode 100644
index 000000000..3dff68602
--- /dev/null
+++ b/doc/video-003.png
diff --git a/doc/video-004.png b/doc/video-004.png
new file mode 100644
index 000000000..92144549a
--- /dev/null
+++ b/doc/video-004.png
diff --git a/doc/video-snap.jpg b/doc/video-snap.jpg
deleted file mode 100644
index ae66c558e..000000000
--- a/doc/video-snap.jpg
+++ /dev/null