[release-branch.go1] syscall: use exported StringToUTF16 in windows test

R=golang-dev, rsc CC=golang-dev https://golang.org/cl/6551056
net/http: disable TestServeFileFromCWD test on windows
2026-01-30 23:52:05 +03:00 · 2012-09-21 17:10:44 -05:00 · 2012-08-07 13:19:49 +10:00 · 2012-09-22 05:55:21 +10:00 · 2012-09-22 05:55:20 +10:00 · 2012-09-22 05:55:20 +10:00
5185 changed files with 452320 additions and 784801 deletions
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,10 +0,0 @@
-# Treat all files in the Go repo as binary, with no git magic updating
-# line endings. Windows users contributing to Go will need to use a
-# modern version of git and editors capable of LF line endings.
-#
-# We'll prevent accidental CRLF line endings from entering the repo
-# via the git-review gofmt checks.
-#
-# See golang.org/issue/9281
-
-* -text
--- a/.gitignore
+++ b/.gitignore
@@ -1,52 +0,0 @@
-.DS_Store
-*.[5689ao]
-*.a[5689o]
-*.so
-*.pyc
-._*
-.nfs.*
-[5689a].out
-*~
-*.orig
-*.rej
-*.exe
-.*.swp
-core
-*.cgo*.go
-*.cgo*.c
-_cgo_*
-_obj
-_test
-_testmain.go
-build.out
-test.out
-doc/articles/wiki/*.bin
-include/plan9/libc_plan9.h
-misc/cgo/life/run.out
-misc/cgo/stdio/run.out
-misc/cgo/testso/main
-misc/dashboard/builder/builder
-src/liblink/anames?.c
-src/cmd/*/y.output
-src/cmd/cgo/zdefaultcc.go
-src/cmd/dist/dist.dSYM
-src/cmd/gc/mkbuiltin1
-src/cmd/gc/opnames.h
-src/cmd/go/zdefaultcc.go
-src/cmd/internal/obj/zbootstrap.go
-src/go/doc/headscan
-src/runtime/mkversion
-src/runtime/zaexperiment.h
-src/runtime/zversion.go
-src/unicode/maketables
-src/*.*/
-test/pass.out
-test/run.out
-test/times.out
-test/garbage/*.out
-goinstall.log
-last-change
-VERSION.cache
-
-bin/
-pkg/
--- a/.hgignore
+++ b/.hgignore
@@ -0,0 +1,65 @@
+syntax:glob
+.DS_Store
+.git
+.gitignore
+*.[568ao]
+*.a[568o]
+*.so
+*.pyc
+._*
+.nfs.*
+[568a].out
+*~
+*.orig
+*.rej
+*.exe
+.*.swp
+core
+*.cgo*.go
+*.cgo*.c
+_cgo_*
+_obj
+_test
+_testmain.go
+build.out
+test.out
+doc/tmpltohtml
+doc/articles/wiki/*.bin
+misc/cgo/life/run.out
+misc/cgo/stdio/run.out
+misc/cgo/testso/main
+misc/dashboard/builder/builder
+misc/goplay/goplay
+misc/osx/*.pkg
+misc/osx/*.dmg
+src/cmd/6a/6a
+src/cmd/?a/y.output
+src/cmd/?l/enam.c
+src/cmd/cc/y.output
+src/cmd/dist/dist.dSYM
+src/cmd/gc/mkbuiltin1
+src/cmd/gc/opnames.h
+src/cmd/gc/y.output
+src/pkg/exp/norm/maketables
+src/pkg/exp/norm/maketesttables
+src/pkg/exp/norm/normregtest
+src/pkg/exp/ebnflint/ebnflint
+src/pkg/go/doc/headscan
+src/pkg/runtime/goc2c
+src/pkg/runtime/mkversion
+src/pkg/runtime/z*
+src/pkg/unicode/maketables
+src/pkg/*.*/
+test/pass.out
+test/run.out
+test/times.out
+test/garbage/*.out
+goinstall.log
+last-change
+VERSION.cache
+
+syntax:regexp
+^bin/
+^pkg/
+^src/cmd/(.*)/6?\1$
+^.*/core.[0-9]*$
--- a/.hgtags
+++ b/.hgtags
@@ -0,0 +1,110 @@
+1f0a01c93d305f1ab636c68b67346659c5b957f7 weekly.2009-11-06
+64e703cb307da550861fe740ff70a482a2c14819 weekly.2009-11-10
+b51fd2d6c16034480f26c96ba32a11c598e4638e weekly.2009-11-10.1
+cb140bac9ab0fd9f734ee443cea9ebadc9c99737 weekly.2009-11-12
+d1b75410b793309532352a6fb6b44453f052f3f4 weekly.2009-11-17
+e205103b02e7393d4719df5faac2dac808234d3f weekly.2009-12-07
+3a47d2e3882bb12129de05382a2c131bb0c00964 weekly.2009-12-09
+a6fcf4303b0a92cce4011556b1c96044252d93af weekly.2009-12-22
+3887d4d81bca78b63d620985d93f1cc06c063871 weekly.2010-01-05
+40dd722155f6d0c83fa572c1a5abf7c6ff35049f weekly.2010-01-13
+0a2770db06efe92b08b5c6f30e14b7e8db012538 weekly.2010-01-27
+db4262ce882d8445764312d41547ee8f11a7f7a9 weekly.2010-02-04
+53fec18b83e2b93baafba4733b59bb86b8c1988e weekly.2010-02-17
+4a0661b86e50eae734dbe43ed1312c4a0304676b weekly.2010-02-23
+a215d03e7ee1013b2abe3f1e2c84457ec51c68e4 weekly.2010-03-04
+194d473264c1a015803d07bed200e0c312aca43e weekly.2010-03-15
+9482fde11a02ffd57ba0561dc8a4ac338061a3ae weekly.2010-03-22
+57380d620ee6b65eb88da1c52784b62c94d7e72e weekly.2010-03-30
+f98f784927abc56a61501eba0cf225966f2b0142 weekly.2010-04-13
+6cc6c0d85fc3234fc0a5ec0a8777aa9d59d05ae8 weekly.2010-04-27
+17ded5ad443b41ac05924864798f1bd8750da344 weekly.2010-05-04
+a85ad0a640154b5d33626ad8ea15ed17e3828178 weekly.2010-05-27
+f776656df34c009f2aad142bf7b34a778404acd1 weekly.2010-06-09
+113ec27f29f18825444f6f8a3cdc156c1df28e87 weekly.2010-06-21
+b761e0299e9bf66298778cf170b0f64216e3cf7d weekly.2010-07-01
+5992bf56aa72efcea87d8dff14985fc8fcc68575 weekly.2010-07-14
+db904d88dc0ebf6ee5b55e44088915695c1223ee weekly.2010-07-29
+8884f7b4c7750481ed246c249db47b61fe752c56 weekly.2010-08-04
+07d3a97302be88af68acff34c8a089589da21d18 weekly.2010-08-11
+18926649cda7498b8aa539b3a611abcff548f09f weekly.2010-08-25
+92fcf05736e8565a485adc52da1894270e06ed09 weekly.2010-09-06
+9329773e204fed50ec686ee78cc715b624bf1b1d weekly.2010-09-15
+1eec33c03bceef5d7607ea4636185f7bf773e0e4 weekly.2010-09-22
+c2b8c9f13fb8ad2b56920d9da2928c5314ebf725 weekly.2010-09-29
+7c2e97710bf49cdbe388260958a6674afefb6c0f weekly.2010-10-13
+ca4f9687cec0b9c4732afd57b8c2786c7fe242de weekly.2010-10-13.1
+79997f0e5823ee9d13a34ca9971a9d8811df1c4a weekly.2010-10-20
+4d5b0816392116d3a3452bb275b6dab6c6456278 weekly.2010-10-27
+c627e23260c7ddf4a1fcda6ef3197c98fa22551d weekly.2010-11-02
+a7800e20064a39585aa3ee339c2b7454ae1ce6d5 weekly.2010-11-10
+c5287468fcff0f8a7bb9ffaece2a4863e7e5d83e weekly.2010-11-23
+f7e692dc29b02fba8e5d59b967880a347b53607c weekly.2010-12-02
+56e39c466cc1c49b587eb56dc2166d61151637df weekly.2010-12-08
+26f4898dc1ca18bb77f9968aca23773637e34f0d weekly.2010-12-15
+61b2c52b0d2246430395f2869d7b34e565333cf5 weekly.2010-12-15.1
+51c777dbccb9f537ebffb99244f521c05bf65df6 weekly.2010-12-22
+8eeee945e358f19405e81792db0e16a1cad14bc0 weekly.2011-01-06
+514c7ba501a1dd74d69ea2d0a2b4116802ada2b5 weekly.2011-01-12
+72f9cb714f08b98c6a65ab2f2256fad6bb16967a weekly.2011-01-19
+d8ba80011a986470a54e5262ec125105aa4adc34 weekly.2011-01-20
+5b98b59dd37292e36afb24babb2d22758928e13d weekly.2011-02-01
+867d37fb41a4d96ab7a6202fd6ad54c345494051 weekly.2011-02-01.1
+b2be017f91348d5f8cbaf42f77a99fc905044b59 weekly.2011-02-15
+322350d6fdbf11d9c404d6fc766349d824031339 weekly.2011-02-24
+21848430d60167817ca965c813a2118068ca660f weekly.2011-03-07
+c5c62aeb6267e124cf05f9622e28dbd0dc6b971d weekly.2011-03-07.1
+c5c62aeb6267e124cf05f9622e28dbd0dc6b971d release.r56
+3b4e9c85b643a35860805718323b05186dd7f235 weekly.2011-03-15
+b84e614e25161f626a6102813c41a80a15e3a625 weekly.2011-03-28
+cd89452cfea3d125aaf75a1ec8004e2f6a868d38 weekly.2011-04-04
+d6903b7fbff40c13ee7ea3177c0ae54c7f89d2e6 weekly.2011-04-13
+2f0fa51fa2da6ab50fcebba526326153da8ed999 weekly.2011-04-27
+8493bb64e5592bd20c0e60e78e7f8052c1276fcf release.r57
+95d2ce135523c96c4cea049af94ce76dd8c7d981 release.r57.1
+c98449d685d2b6aa1df9bfd2e1cce9307efb6e00 weekly.2011-05-22
+3418f22c39eb8299053ae681199ee90f8cd29c6d weekly.2011-06-02
+c81944152e973a917797679055b8fcdc70fbc802 weekly.2011-06-09
+9d7967223815ef6415ff01aa0fe6ad38cdbc7810 release.r57.2
+dac76f0b1a18a5de5b54a1dc0b231aceaf1c8583 weekly.2011-06-16
+541c445d6c1353fbfa39df7dc4b0eb27558d1fc1 weekly.2011-06-23
+1b38d90eebcddefabb3901c5bb63c7e2b04a6ec5 release.r58
+16bfa562ba767aefd82e598da8b15ee4729e23b0 weekly.2011-07-07
+d292bc7886682d35bb391bf572be28656baee12d release.r58.1
+3c21f37b25a3f7a1726265c5339c8a7b0b329336 weekly.2011-07-19
+bb28251f6da4aca85658582c370c7df89d34efd4 weekly.2011-07-29
+d5785050f61d973fc36775f7bd2e26689529cb3e release.r59
+c17ce5ec06b4bd5cf6e7ff2ceb0a60c2e40e0b17 weekly.2011-08-10
+6eb2b9dbe489acb57a2bfc1de31ec2239ed94326 weekly.2011-08-17
+c934f6f5fe8b30b4b3210ee3f13669e6e4670c32 weekly.2011-09-01
+c77997547d546c36c7b969586a36de7ceda74e33 weekly.2011-09-07
+b0819469a6df6029a27192fe7b19a73d97404c63 release.r60
+8a09ce0cefc64deab4e6d1ed59a08a53e879bbee weekly.2011-09-16
+fd30c132d1bdeb79f8f111cb721fb1c78b767b27 release.r60.1
+d7322ae4d055a4cf3efaf842d0717a41acd85bac weekly.2011-09-21
+32a5db19629897641b2d488de4d1b998942ef80e release.r60.2
+3bdabf483805fbf0c7ef013fd09bfd6062b9d3f2 weekly.2011-10-06
+c1702f36df0397c19fc333571a771666029aa37e release.r60.3
+acaddf1cea75c059d19b20dbef35b20fb3f38954 release.r58.2
+6d7136d74b656ba6e1194853a9486375005227ef weekly.2011-10-18
+941b8015061a0f6480954821dd589c60dfe35ed1 weekly.2011-10-25
+7c1f789e6efd153951e85e3f28722fc69efc2af2 weekly.2011-10-26
+e69e528f2afc25a8334cfb9359fa4fcdf2a934b6 weekly.2011-11-01
+780c85032b174c9d4b42adf75d82bc85af7d78d1 weekly.2011-11-02
+f4397ad6e87c7ce5feac9b01686f1ebd6cbaac4e weekly.2011-11-08
+2f4482b89a6b5956828872137b6b96636cd904d3 weekly.2011-11-09
+b4a91b6933748db1a7150c06a1b55ad506e52906 weekly.2011-11-18
+80db2da6495a20ddff8305c236825811db8c8665 weekly.2011-12-01
+0beb796b4ef8747af601ed5ea6766d5b1340086b weekly.2011-12-02
+0c39eee85b0d1606b79c8ebcdeb3b67ed5849e39 weekly.2011-12-06
+82fdc445f2ff2c85043446eb84a19cc999dfcb95 weekly.2011-12-14
+4a82689277582a2a60f006e3f158985f2f8d1da3 weekly.2011-12-22
+354b17404643c0f1a710bdc48927dff02f203ae3 weekly.2012-01-15
+9f2be4fbbf690b9562c6e98b91daa0003f0913c7 weekly.2012-01-20
+1107a7d3cb075836387adfab5ce56d1b3e56637d weekly.2012-01-27
+52ba9506bd993663a0a033c2bd68699e25d061ab weekly.2012-02-07
+43cf9b39b6477d3144b0353ee91096e55db6107f weekly.2012-02-14
+96bd78e7d35e892113bdfa1bdc392d3a5f2e644b weekly.2012-02-22
+f4470a54e6dbcdd52d8d404e12e4754adcd2c948 weekly.2012-03-04
+3cdba7b0650c6c906ef3e782654f61701abd7dd2 weekly.2012-03-13
+bce220d0377405146527ab9478867cbc572a6886 weekly.2012-03-22
--- a/223
+++ b/223
@@ -8,195 +8,102 @@

 # Please keep the list sorted.

-Aaron France <aaron.l.france@gmail.com>
 Abhinav Gupta <abhinav.g90@gmail.com>
-Adrian Nos <nos.adrian@gmail.com>
 Adrian O'Grady <elpollouk@gmail.com>
-Adrien Bustany <adrien-xx-google@bustany.org>
-Ahmed Waheed Moanes <oneofone@gmail.com>
 Akshat Kumar <seed@mail.nanosouffle.net>
-Alan Shreve <alan@inconshreveable.com>
 Albert Strasheim <fullung@gmail.com>
-Alberto Donizetti <alb.donizetti@gmail.com>
-Alberto García Hierro <alberto@garciahierro.com> <alberto.garcia.hierro@gmail.com>
 Aleksandar Dezelin <dezelin@gmail.com>
-Alex A Skinner <alex@lx.lc>
 Alex Brainman <alex.brainman@gmail.com>
-Alex Jin <toalexjin@gmail.com>
-Alexander Larsson <alexander.larsson@gmail.com>
 Alexander Orlov <alexander.orlov@loxal.net>
 Alexander Reece <awreece@gmail.com>
-Alexander Surma <surma@surmair.de>
-Alexander Zhavnerchik <alex.vizor@gmail.com>
-Alexandre Normand <alexandre.normand@gmail.com>
-Alexei Sholik <alcosholik@gmail.com>
 Alexey Borzenkov <snaury@gmail.com>
-Alexey Palazhchenko <alexey.palazhchenko@gmail.com>
 Amir Mohammad Saied <amir@gluegadget.com>
 Amrut Joshi <amrut.joshi@gmail.com>
 Andrei Vieru <euvieru@gmail.com>
 Andrew Balholm <andybalholm@gmail.com>
-Andrew Bonventre <andybons@chromium.org>
-Andrew Bursavich <abursavich@gmail.com>
 Andrew Harding <andrew@spacemonkey.com>
 Andrew Lutomirski <andy@luto.us>
 Andrew Pritchard <awpritchard@gmail.com>
-Andrew Radev <andrey.radev@gmail.com>
 Andrew Skiba <skibaa@gmail.com>
-Andrew Szeto <andrew@jabagawee.com>
 Andrew Wilkins <axwalk@gmail.com>
 Andrey Mirtchovski <mirtchovski@gmail.com>
-Andriy Lytvynov <lytvynov.a.v@gmail.com>
 Andy Davis <andy@bigandian.com>
-Anfernee Yongkun Gui <anfernee.gui@gmail.com>
 Anh Hai Trinh <anh.hai.trinh@gmail.com>
 Anschel Schaffer-Cohen <anschelsc@gmail.com>
 Anthony Eufemio <anthony.eufemio@gmail.com>
 Anthony Martin <ality@pbrane.org>
 Anthony Starks <ajstarks@gmail.com>
-Apisak Darakananda <pongad@gmail.com>
-Aram Hăvărneanu <aram@mgk.ro>
-Arnaud Ysmal <arnaud.ysmal@gmail.com>
-Arne Hormann <arnehormann@gmail.com>
 Aron Nopanen <aron.nopanen@gmail.com>
 Arvindh Rajesh Tamilmani <art@a-30.net>
-Ato Araki <ato.araki@gmail.com>
-Aulus Egnatius Varialus <varialus@gmail.com>
 Ben Olive <sionide21@gmail.com>
 Benjamin Black <b@b3k.us>
 Benny Siegert <bsiegert@gmail.com>
-Benoit Sigoure <tsunanet@gmail.com>
 Berengar Lehr <berengar.lehr@gmx.de>
-Billie Harold Cleek <bhcleek@gmail.com>
+Brian Dellisanti <briandellisanti@gmail.com>
 Bjorn Tillenius <bjorn@tillenius.me>
 Bjorn Tipling <bjorn.tipling@gmail.com>
 Blake Mizerany <blake.mizerany@gmail.com>
 Bobby Powers <bobbypowers@gmail.com>
-Brendan Daniel Tracey <tracey.brendan@gmail.com>
-Brian Dellisanti <briandellisanti@gmail.com>
-Brian G. Merrell <bgmerrell@gmail.com>
-Brian Gitonga Marete <marete@toshnix.com>
-Brian Ketelsen <bketelsen@gmail.com>
 Caine Tighe <arctanofyourface@gmail.com>
-Caleb Spare <cespare@gmail.com>
-Carl Chatfield <carlchatfield@gmail.com>
 Carlos Castillo <cookieo9@gmail.com>
-Case Nelson <case.nelson@gmail.com>
-Casey Marshall <casey.marshall@gmail.com>
-Cezar Sá Espinola <cezarsa@gmail.com>
-ChaiShushan <chaishushan@gmail.com>
 Charles L. Dorian <cldorian@gmail.com>
-Charles Lee <zombie.fml@gmail.com>
 Chris Dollin <ehog.hedge@gmail.com>
 Chris Farmiloe <chrisfarms@gmail.com>
-Chris Howey <howeyc@gmail.com>
 Chris Jones <chris@cjones.org>
 Chris Lennert <calennert@gmail.com>
-Chris McGee <sirnewton_01@yahoo.ca> <newton688@gmail.com>
 Christian Himpel <chressie@googlemail.com>
 Christine Hansmann <chhansmann@gmail.com>
-Christoffer Buchholz <christoffer.buchholz@gmail.com>
 Christoph Hack <christoph@tux21b.org>
-Christopher Cahoon <chris.cahoon@gmail.com>
 Christopher Nielsen <m4dh4tt3r@gmail.com>
 Christopher Redden <christopher.redden@gmail.com>
 Christopher Wedgwood <cw@f00f.org>
 Clement Skau <clementskau@gmail.com>
 Conrad Meyer <cemeyer@cs.washington.edu>
 Corey Thomasson <cthom.lists@gmail.com>
-Cristian Staretu <unclejacksons@gmail.com>
 Damian Gryski <dgryski@gmail.com>
-Dan Callahan <dan.callahan@gmail.com>
-Dan Peterson <dpiddy@gmail.com>
 Dan Sinclair <dan.sinclair@gmail.com>
 Daniel Fleischman <danielfleischman@gmail.com>
 Daniel Krech <eikeon@eikeon.com>
-Daniel Lidén <daniel.liden.87@gmail.com>
 Daniel Morsing <daniel.morsing@gmail.com>
 Daniel Theophanes <kardianos@gmail.com>
 Darren Elwood <darren@textnode.com>
 Dave Cheney <dave@cheney.net>
-David Bürgin <676c7473@gmail.com>
-David Calavera <david.calavera@gmail.com>
 David du Colombier <0intro@gmail.com>
 David Forsythe <dforsythe@gmail.com>
 David G. Andersen <dave.andersen@gmail.com>
 David Jakob Fritz <david.jakob.fritz@gmail.com>
-David Leon Gil <coruus@gmail.com>
-David Thomas <davidthomas426@gmail.com>
 David Titarenco <david.titarenco@gmail.com>
 Dean Prichard <dean.prichard@gmail.com>
-Denis Brandolini <denis.brandolini@gmail.com>
-Derek Parker <parkerderek86@gmail.com>
 Devon H. O'Dell <devon.odell@gmail.com>
-Dhiru Kholia <dhiru.kholia@gmail.com>
-Dimitri Tcaciuc <dtcaciuc@gmail.com>
-Dmitri Shuralyov <shurcooL@gmail.com>
-Dmitriy Shelenin <deemok@googlemail.com> <deemok@gmail.com>
 Dmitry Chestnykh <dchest@gmail.com>
-Dominik Honnef <dominik.honnef@gmail.com>
-Donovan Hide <donovanhide@gmail.com>
-Dropbox, Inc.
-Duncan Holm <mail@frou.org>
-Dustin Sallings <dsallings@gmail.com>
-Dustin Shields-Cloues <dcloues@gmail.com>
 Eden Li <eden.li@gmail.com>
-Egon Elbre <egonelbre@gmail.com>
-Ehren Kret <ehren.kret@gmail.com>
 Eivind Uggedal <eivind@uggedal.com>
-Elias Naur <elias.naur@gmail.com>
-Emil Hessman <c.emil.hessman@gmail.com> <emil@hessman.se>
+Emil Hessman <c.emil.hessman@gmail.com>
 Eoghan Sherry <ejsherry@gmail.com>
 Eric Clark <zerohp@gmail.com>
-Eric Milliken <emilliken@gmail.com>
 Eric Roshan-Eisner <eric.d.eisner@gmail.com>
-Erik St. Martin <alakriti@gmail.com>
-Erik Westrup <erik.westrup@gmail.com>
 Esko Luontola <esko.luontola@gmail.com>
 Evan Shaw <chickencha@gmail.com>
-Ewan Chou <coocood@gmail.com>
-Fabrizio Milo <mistobaan@gmail.com>
 Fan Hongjian <fan.howard@gmail.com>
-Fastly, Inc.
-Fatih Arslan <fatih@arslan.io>
 Fazlul Shahriar <fshahriar@gmail.com>
-Felix Geisendörfer <haimuiba@gmail.com>
 Firmansyah Adiputra <frm.adiputra@gmail.com>
 Florian Uekermann <florian@uekermann-online.de>
 Florian Weimer <fw@deneb.enyo.de>
 Francisco Souza <franciscossouza@gmail.com>
-Frederick Kelly Mayle III <frederickmayle@gmail.com>
-Fredrik Enestad <fredrik.enestad@soundtrackyourbrand.com>
-Frithjof Schulze <schulze@math.uni-hannover.de> <sfrithjof@gmail.com>
-Gabriel Aszalos <gabriel.aszalos@gmail.com>
 Gary Burd <gary@beagledreams.com>
-Gautham Thambidorai <gautham.dorai@gmail.com>
-Georg Reinke <guelfey@gmail.com>
-Gerasimos Dimitriadis <gedimitr@gmail.com>
 Gideon Jan-Wessel Redelinghuys <gjredelinghuys@gmail.com>
 Giles Lean <giles.lean@pobox.com>
 Google Inc.
-Gordon Klaus <gordon.klaus@gmail.com>
-Graham King <graham4king@gmail.com>
 Graham Miller <graham.miller@gmail.com>
-Greg Ward <greg@gerg.ca>
-Guillaume J. Charmes <guillaume@charmes.net>
 Gustav Paul <gustav.paul@gmail.com>
 Gustavo Niemeyer <gustavo@niemeyer.net>
 Gwenael Treguier <gwenn.kahz@gmail.com>
 Harley Laue <losinggeneration@gmail.com>
 Hector Chu <hectorchu@gmail.com>
-Hector Martin Cantero <hector@marcansoft.com>
-Henning Schmiedehausen <henning@schmiedehausen.org>
-Henrik Edwards <henrik.edwards@gmail.com>
-Herbert Georg Fischer <herbert.fischer@gmail.com>
 Hong Ruiqi <hongruiqi@gmail.com>
 Icarus Sparry <golang@icarus.freeuk.com>
 Ingo Oeser <nightlyone@googlemail.com>
 Isaac Wagner <ibw@isaacwagner.me>
-Jakob Borg <jakob@nym.se>
-Jakub Ryszard Czarnowicz <j.czarnowicz@gmail.com>
-James David Chalfant <james.chalfant@gmail.com>
 James Fysh <james.fysh@gmail.com>
 James Gray <james@james4k.com>
 James Meneghello <rawrz0r@gmail.com>
@@ -204,255 +111,133 @@ James P. Cooper <jamespcooper@gmail.com>
 James Toy <nil@opensesame.st>
 James Whitehead <jnwhiteh@gmail.com>
 Jan H. Hosang <jan.hosang@gmail.com>
-Jan Mercl <0xjnml@gmail.com>
 Jan Mercl <befelemepeseveze@gmail.com>
 Jan Newmarch <jan.newmarch@gmail.com>
 Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
 Jani Monoses <jani.monoses@ubuntu.com>
 Jaroslavas Počepko <jp@webmaster.ms>
-Jason Del Ponte <delpontej@gmail.com>
-Jason Travis <infomaniac7@gmail.com>
-Jay Weisskopf <jay@jayschwa.net>
 Jeff Hodges <jeff@somethingsimilar.com>
 Jeff R. Allen <jra@nella.org>
-Jeff Sickel <jas@corpus-callosum.com>
-Jeff Wendling <jeff@spacemonkey.com>
-Jens Frederich <jfrederich@gmail.com>
 Jeremy Jackins <jeremyjackins@gmail.com>
 Jim McGrath <jimmc2@gmail.com>
-Jimmy Zelinskie <jimmyzelinskie@gmail.com>
-Jingcheng Zhang <diogin@gmail.com>
 Joakim Sernbrant <serbaut@gmail.com>
 Joe Poirier <jdpoirier@gmail.com>
-Joe Shaw <joe@joeshaw.org>
-Joel Stemmer <stemmertech@gmail.com>
 John Asmuth <jasmuth@gmail.com>
-John C Barstow <jbowtie@amathaine.com>
-John Graham-Cumming <jgc@jgc.org> <jgrahamc@gmail.com>
-John Howard Palevich <jack.palevich@gmail.com>
-John Shahid <jvshahid@gmail.com>
-John Tuley <john@tuley.org>
 Jonathan Gold <jgold.bg@gmail.com>
 Jonathan Mark <jhmark@xenops.com>
-Jonathan Rudenberg <jonathan@titanous.com>
 Jonathan Wills <runningwild@gmail.com>
 Jongmin Kim <atomaths@gmail.com>
 Jose Luis Vázquez González <josvazg@gmail.com>
-Joseph Holsten <joseph@josephholsten.com>
-Josh Bleecher Snyder <josharian@gmail.com>
 Josh Goebel <dreamer3@gmail.com>
-Josh Holland <jrh@joshh.co.uk>
-Joshua Chase <jcjoshuachase@gmail.com>
-JT Olds <jtolds@xnet5.com>
 Jukka-Pekka Kekkonen <karatepekka@gmail.com>
 Julian Phillips <julian@quantumfyre.co.uk>
 Julien Schmidt <google@julienschmidt.com>
 Kai Backman <kaib@golang.org>
-Kamil Kisiel <kamil@kamilkisiel.net> <kamil.kisiel@gmail.com>
-Katrina Owen <katrina.owen@gmail.com>
 Kei Son <hey.calmdown@gmail.com>
 Keith Rarick <kr@xph.us>
-Kelsey Hightower <kelsey.hightower@gmail.com>
-Kelvin Foo Chuan Lyi <vmirage@gmail.com>
 Ken Friedenbach <kenliz@cruzio.com>
 Ken Rockot <ken@oz.gs>
 Kevin Ballard <kevin@sb.org>
 Kyle Consalus <consalus@gmail.com>
-Kyle Isom <kyle@gokyle.net>
 Kyle Lemons <kyle@kylelemons.net>
 L Campbell <unpantsu@gmail.com>
 Lai Jiangshan <eag0628@gmail.com>
-Linaro Limited
 Lorenzo Stoakes <lstoakes@gmail.com>
 Luca Greco <luca.greco@alcacoop.it>
 Lucio De Re <lucio.dere@gmail.com>
 Luit van Drongelen <luitvd@gmail.com>
-Luka Zakrajšek <tr00.g33k@gmail.com>
-Luke Curley <qpingu@gmail.com>
-Manuel Mendez <mmendez534@gmail.com>
-Marc Weistroff <marc@weistroff.net>
-Marco Hennings <marco.hennings@freiheit.com>
-Mark Theunissen <mark.theunissen@gmail.com>
-Marko Juhani Silokunnas <marko.silokunnas@gmail.com>
-Marko Tiikkaja <marko@joh.to>
-Markover Inc. DBA Poptip
 Markus Duft <markus.duft@salomon.at>
 Markus Sonderegger <marraison@gmail.com>
-Markus Zimmermann <zimmski@gmail.com>
 Martin Neubauer <m.ne@gmx.net>
-Martin Olsson <martin@minimum.se>
 Mateusz Czapliński <czapkofan@gmail.com>
 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>
 Mats Lidell <mats.lidell@cag.se>
-Matt Aimonetti <mattaimonetti@gmail.com>
 Matt Jibson <matt.jibson@gmail.com>
-Matt Joiner <anacrolix@gmail.com>
-Matt Reiferson <mreiferson@gmail.com>
-Matthew Cottingham <mattcottingham@gmail.com>
 Matthew Horsnell <matthew.horsnell@gmail.com>
-Maxim Khitrov <max@mxcrypt.com>
 Micah Stetson <micah.stetson@gmail.com>
 Michael Chaten <mchaten@gmail.com>
 Michael Elkins <michael.elkins@gmail.com>
-Michael Fraenkel <michael.fraenkel@gmail.com>
-Michael Gehring <mg@ebfe.org> <gnirheg.leahcim@gmail.com>
+Michael Gehring <mg@ebfe.org>
 Michael Hoisie <hoisie@gmail.com>
 Michael Lewis <mikelikespie@gmail.com>
-Michael MacInnis <Michael.P.MacInnis@gmail.com>
-Michael Pearson <mipearson@gmail.com>
 Michael Stapelberg <michael@stapelberg.de>
-Michael Teichgräber <mteichgraeber@gmx.de>
 Michał Derkacz <ziutek@lnet.pl>
 Miek Gieben <miek@miek.nl>
-Mihai Borobocea <MihaiBorobocea@gmail.com>
 Mikael Tillenius <mikti42@gmail.com>
-Mike Andrews <mra@xoba.com>
 Mike Rosset <mike.rosset@gmail.com>
-Mikhail Panchenko <m@mihasya.com>
 Miki Tebeka <miki.tebeka@gmail.com>
 Mikio Hara <mikioh.mikioh@gmail.com>
 Mikkel Krautz <mikkel@krautz.dk>
-Miquel Sabaté Solà <mikisabate@gmail.com>
-Moov Corporation
 Moriyoshi Koizumi <mozo@mozo.jp>
 Môshe van der Sterre <moshevds@gmail.com>
-Nan Deng <monnand@gmail.com>
-Nathan John Youngman <nj@nathany.com>
-Nathan P Finch <nate.finch@gmail.com>
 ngmoco, LLC
-Nicholas Katsaros <nick@nickkatsaros.com>
-Nicholas Presta <nick@nickpresta.ca> <nick1presta@gmail.com>
-Nicholas Sullivan <nicholas.sullivan@gmail.com>
 Nicholas Waples <nwaples@gmail.com>
-Nick Craig-Wood <nick@craig-wood.com> <nickcw@gmail.com>
-Nicolas Kaiser <nikai@nikai.net>
-Nicolas Owens <mischief@offblast.org>
 Nigel Kerr <nigel.kerr@gmail.com>
-Noah Campbell <noahcampbell@gmail.com>
 Oling Cat <olingcat@gmail.com>
-Oliver Hookins <ohookins@gmail.com>
 Olivier Antoine <olivier.antoine@gmail.com>
 Olivier Duperray <duperray.olivier@gmail.com>
-Olivier Saingre <osaingre@gmail.com>
 Padraig Kitterick <padraigkitterick@gmail.com>
 Paolo Giarrusso <p.giarrusso@gmail.com>
 Pascal S. de Kloe <pascal@quies.net>
 Patrick Crosby <patrick@stathat.com>
 Patrick Gavlin <pgavlin@gmail.com>
 Patrick Higgins <patrick.allen.higgins@gmail.com>
-Patrick Mézard <patrick@mezard.eu>
 Patrick Mylund Nielsen <patrick@patrickmn.com>
-Patrick Smith <pat42smith@gmail.com>
-Paul A Querna <paul.querna@gmail.com>
-Paul Hammond <paul@paulhammond.org>
 Paul Lalonde <paul.a.lalonde@gmail.com>
 Paul Sbarra <Sbarra.Paul@gmail.com>
-Paul van Brouwershaven <paul@vanbrouwershaven.com>
-Pavel Zinovkin <pavel.zinovkin@gmail.com>
-Percy Wegmann <ox.to.a.cart@gmail.com>
 Petar Maymounkov <petarm@gmail.com>
 Peter Armitage <peter.armitage@gmail.com>
 Peter Froehlich <peter.hans.froehlich@gmail.com>
 Peter Kleiweg <pkleiweg@xs4all.nl>
 Peter Mundy <go.peter.90@gmail.com>
-Péter Surányi <speter.go1@gmail.com>
-Péter Szilágyi <peterke@gmail.com>
-Peter Waller <peter.waller@gmail.com>
 Peter Williams <pwil3058@gmail.com>
-Philip K. Warren <pkwarren@gmail.com>
 Pieter Droogendijk <pieter@binky.org.uk>
-Pietro Gagliardi <pietro10@mac.com>
-Preetam Jinka <pj@preet.am>
 Quan Yong Zhai <qyzhai@gmail.com>
 Raif S. Naffah <go@naffah-raif.name>
-Red Hat, Inc.
 Rémy Oudompheng <oudomphe@phare.normalesup.org>
-Richard Crowley <r@rcrowley.org>
-Richard Eric Gavaletz <gavaletz@gmail.com>
-Richard Musiol <mail@richard-musiol.de>
-Rick Arnold <rickarnoldjr@gmail.com>
 Risto Jaakko Saarelma <rsaarelm@gmail.com>
-Robert Daniel Kortschak <dan.kortschak@adelaide.edu.au>
-Robert Dinu <r@varp.se>
 Robert Figueiredo <robfig@gmail.com>
 Robert Hencke <robert.hencke@gmail.com>
-Robert Obryk <robryk@gmail.com>
-Robin Eklind <r.eklind.87@gmail.com>
-Rodrigo Moraes de Oliveira <rodrigo.moraes@gmail.com>
-Rodrigo Rafael Monti Kochenburger <divoxx@gmail.com>
 Roger Pau Monné <royger@gmail.com>
 Roger Peppe <rogpeppe@gmail.com>
-Ron Hashimoto <mail@h2so5.net>
 Ron Minnich <rminnich@gmail.com>
 Ross Light <rlight2@gmail.com>
-Rowan Worth <sqweek@gmail.com>
 Ryan Hitchman <hitchmanr@gmail.com>
-Ryan Slade <ryanslade@gmail.com>
-S.Çağlar Onur <caglar@10ur.org>
 Sanjay Menakuru <balasanjay@gmail.com>
-Scott Ferguson <scottwferg@gmail.com>
 Scott Lawrence <bytbox@gmail.com>
 Sebastien Binet	<seb.binet@gmail.com>
 Sébastien Paolacci <sebastien.paolacci@gmail.com>
 Sergei Skorobogatov <skorobo@rambler.ru>
 Sergey 'SnakE'  Gromov <snake.scaly@gmail.com>
-Sergio Luis O. B. Correia <sergio@correia.cc>
-Shane Hansen <shanemhansen@gmail.com>
+Sergio Luis O. B. Correia <sergio@larces.uece.br>
 Shawn Smith <shawn.p.smith@gmail.com>
 Shenghou Ma <minux.ma@gmail.com>
-Shivakumar GN <shivakumar.gn@gmail.com>
-Simon Whitehead <chemnova@gmail.com>
-Sokolov Yura <funny.falcon@gmail.com>
 Spring Mc <heresy.mc@gmail.com>
-StalkR <stalkr@stalkr.net>
 Stefan Nilsson <snilsson@nada.kth.se> <trolleriprofessorn@gmail.com>
 Stéphane Travostino <stephane.travostino@gmail.com>
-Stephen McQuay <stephen@mcquay.me>
 Stephen Weinberg <stephen@q5comm.com>
-Steve McCoy <mccoyst@gmail.com>
-Steven Elliot Harris <seharris@gmail.com>
-Steven Hartland <steven.hartland@multiplay.co.uk>
 Sven Almgren <sven@tras.se>
 Szabolcs Nagy <nsz@port70.net>
-Tad Glines <tad.glines@gmail.com>
-Taj Khattra <taj.khattra@gmail.com>
 Tarmigan Casebolt <tarmigan@gmail.com>
 Taru Karttunen <taruti@taruti.net>
-Tetsuo Kiso <tetsuokiso9@gmail.com>
-Thiago Fransosi Farina <thiago.farina@gmail.com>
 Thomas Alan Copeland <talan.copeland@gmail.com>
-Thomas Kappler <tkappler@gmail.com>
 Timo Savola <timo.savola@gmail.com>
-Timo Truyts <alkaloid.btx@gmail.com>
 Tobias Columbus <tobias.columbus@gmail.com>
-Tom Linford <tomlinford@gmail.com>
 Tor Andersson <tor.andersson@gmail.com>
-Travis Cline <travis.cline@gmail.com>
-Tudor Golubenco <tudor.g@gmail.com>
-Tw <tw19881113@gmail.com>
-Tyler Bunnell <tylerbunnell@gmail.com>
 Ugorji Nwoke <ugorji@gmail.com>
-Ulf Holm Nielsen <doktor@dyregod.dk>
 Uriel Mangado <uriel@berlinblue.org>
 Vadim Vygonets <unixdj@gmail.com>
 Vincent Ambo <tazjin@googlemail.com>
 Vincent Vanackere <vincent.vanackere@gmail.com>
 Vinu Rajashekhar <vinutheraj@gmail.com>
-Vladimir Nikishenko <vova616@gmail.com>
 Volker Dobler <dr.volker.dobler@gmail.com>
 Wei Guangjing <vcc.163@gmail.com>
-Willem van der Schyff <willemvds@gmail.com>
 William Josephson <wjosephson@gmail.com>
-William Orr <will@worrbase.com> <ay1244@gmail.com>
-Xia Bin <snyh@snyh.org>
 Xing Xing <mikespook@gmail.com>
 Yasuhiro Matsumoto <mattn.jp@gmail.com>
 Yissakhar Z. Beck <yissakhar.beck@gmail.com>
 Yongjian Xu <i3dmaster@gmail.com>
 Yoshiyuki Kanno <nekotaroh@gmail.com> <yoshiyuki.kanno@stoic.co.jp>
-Yusuke Kagiwada <block.rxckin.beats@gmail.com>
 Yuusei Kuwana <kuwana@kumama.org>
 Yuval Pavel Zholkover <paulzhol@gmail.com>
 Ziad Hatahet <hatahet@gmail.com>
-Zorion Arrizabalaga <zorionk@gmail.com>
-申习之 <bronze1man@gmail.com>
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,31 +0,0 @@
-# Contributing to Go
-
-Go is an open source project.
-
-It is the work of hundreds of contributors. We appreciate your help!
-
-
-## Filing issues
-
-When filing an issue, make sure to answer these five questions:
-
-1. What version of Go are you using (`go version`)?
-2. What operating system and processor architecture are you using?
-3. What did you do?
-4. What did you expect to see?
-5. What did you see instead?
-
-General questions should go to the [golang-nuts mailing list](https://groups.google.com/group/golang-nuts) instead of the issue tracker.
-The gophers there will answer or ask you to file an issue if you've tripped over a bug.
-
-## Contributing code
-
-Please read the [Contribution Guidelines](https://golang.org/doc/contribute.html)
-before sending patches.
-
-**We do not accept GitHub pull requests**
-(we use [Gerrit](https://code.google.com/p/gerrit/) instead for code review).
-
-Unless otherwise noted, the Go source files are distributed under
-the BSD-style license found in the LICENSE file.
-
--- a/298
+++ b/298
@@ -31,72 +31,41 @@

 # Please keep the list sorted.

-Aaron France <aaron.l.france@gmail.com>
 Aaron Kemp <kemp.aaron@gmail.com>
 Abhinav Gupta <abhinav.g90@gmail.com>
 Adam Langley <agl@golang.org>
-Adrian Nos <nos.adrian@gmail.com>
 Adrian O'Grady <elpollouk@gmail.com>
-Adrien Bustany <adrien-xx-google@bustany.org>
-Ahmed Waheed Moanes <oneofone@gmail.com>
 Akshat Kumar <seed@mail.nanosouffle.net>
 Alan Donovan <adonovan@google.com>
-Alan Shreve <alan@inconshreveable.com>
 Albert Strasheim <fullung@gmail.com>
-Alberto Donizetti <alb.donizetti@gmail.com>
-Alberto García Hierro <alberto@garciahierro.com> <alberto.garcia.hierro@gmail.com>
 Aleksandar Dezelin <dezelin@gmail.com>
-Alex A Skinner <alex@lx.lc>
 Alex Brainman <alex.brainman@gmail.com>
-Alex Bramley <abramley@google.com>
-Alex Jin <toalexjin@gmail.com>
-Alexander Larsson <alexander.larsson@gmail.com>
 Alexander Orlov <alexander.orlov@loxal.net>
 Alexander Reece <awreece@gmail.com>
-Alexander Surma <surma@surmair.de>
-Alexander Zhavnerchik <alex.vizor@gmail.com>
-Alexandre Normand <alexandre.normand@gmail.com>
 Alexandru Moșoi <brtzsnr@gmail.com>
-Alexei Sholik <alcosholik@gmail.com>
 Alexey Borzenkov <snaury@gmail.com>
-Alexey Palazhchenko <alexey.palazhchenko@gmail.com>
-Alexis Imperial-Legrand <ail@google.com>
 Amir Mohammad Saied <amir@gluegadget.com>
 Amrut Joshi <amrut.joshi@gmail.com>
 Andrea Spadaccini <spadaccio@google.com>
 Andreas Jellinghaus <andreas@ionisiert.de> <anj@google.com>
 Andrei Vieru <euvieru@gmail.com>
-Andres Erbsen <andreser@google.com>
 Andrew Balholm <andybalholm@gmail.com>
-Andrew Bonventre <andybons@chromium.org>
-Andrew Bursavich <abursavich@gmail.com>
 Andrew Gerrand <adg@golang.org>
 Andrew Harding <andrew@spacemonkey.com>
 Andrew Lutomirski <andy@luto.us>
 Andrew Pritchard <awpritchard@gmail.com>
-Andrew Radev <andrey.radev@gmail.com>
 Andrew Skiba <skibaa@gmail.com>
-Andrew Szeto <andrew@jabagawee.com>
 Andrew Wilkins <axwalk@gmail.com>
 Andrey Mirtchovski <mirtchovski@gmail.com>
-Andriy Lytvynov <lytvynov.a.v@gmail.com>
 Andy Davis <andy@bigandian.com>
-Anfernee Yongkun Gui <anfernee.gui@gmail.com>
 Anh Hai Trinh <anh.hai.trinh@gmail.com>
 Anschel Schaffer-Cohen <anschelsc@gmail.com>
 Anthony Eufemio <anthony.eufemio@gmail.com>
 Anthony Martin <ality@pbrane.org>
 Anthony Starks <ajstarks@gmail.com>
-Apisak Darakananda <pongad@gmail.com>
-Aram Hăvărneanu <aram@mgk.ro>
-Arnaud Ysmal <arnaud.ysmal@gmail.com>
-Arne Hormann <arnehormann@gmail.com>
 Aron Nopanen <aron.nopanen@gmail.com>
 Arvindh Rajesh Tamilmani <art@a-30.net>
-Asim Shankar <asimshankar@gmail.com>
-Ato Araki <ato.araki@gmail.com>
-Aulus Egnatius Varialus <varialus@gmail.com>
-Austin Clements <austin@google.com> <aclements@csail.mit.edu>
+Austin Clements <aclements@csail.mit.edu>
 Balazs Lecz <leczb@google.com>
 Ben Eitzen <eitzenb@golang.org>
 Ben Fried <ben.fried@gmail.com>
@@ -104,271 +73,140 @@ Ben Lynn <benlynn@gmail.com>
 Ben Olive <sionide21@gmail.com>
 Benjamin Black <b@b3k.us>
 Benny Siegert <bsiegert@gmail.com>
-Benoit Sigoure <tsunanet@gmail.com>
 Berengar Lehr <Berengar.Lehr@gmx.de>
-Bill Neubauer <wcn@golang.org> <wcn@google.com> <bill.neubauer@gmail.com>
+Bill Neubauer <wcn@golang.org> <wcn@google.com>
 Bill Thiede <couchmoney@gmail.com>
-Billie Harold Cleek <bhcleek@gmail.com>
 Bjorn Tillenius <bjorn@tillenius.me>
 Bjorn Tipling <bjorn.tipling@gmail.com>
 Blake Mizerany <blake.mizerany@gmail.com>
 Bobby Powers <bobbypowers@gmail.com>
 Brad Fitzpatrick <bradfitz@golang.org> <bradfitz@gmail.com>
-Brad Garcia <bgarcia@golang.org>
-Brendan Daniel Tracey <tracey.brendan@gmail.com>
-Brendan O'Dea <bod@golang.org>
 Brian Dellisanti <briandellisanti@gmail.com>
-Brian G. Merrell <bgmerrell@gmail.com>
-Brian Gitonga Marete <marete@toshnix.com>
-Brian Ketelsen <bketelsen@gmail.com>
 Brian Slesinsky <skybrian@google.com>
-Burcu Dogan <jbd@google.com>
+Brendan O'Dea <bod@golang.org>
 Caine Tighe <arctanofyourface@gmail.com>
-Caleb Spare <cespare@gmail.com>
-Carl Chatfield <carlchatfield@gmail.com>
-Carl Mastrangelo <notcarl@google.com>
-Carl Shapiro <cshapiro@google.com> <cshapiro@golang.org>
 Carlos Castillo <cookieo9@gmail.com>
 Cary Hull <chull@google.com>
-Case Nelson <case.nelson@gmail.com>
-Casey Marshall <casey.marshall@gmail.com>
-Catalin Patulea <catalinp@google.com>
-Cezar Sá Espinola <cezarsa@gmail.com>
-ChaiShushan <chaishushan@gmail.com>
 Charles L. Dorian <cldorian@gmail.com>
-Charles Lee <zombie.fml@gmail.com>
 Chris Dollin <ehog.hedge@gmail.com>
 Chris Farmiloe <chrisfarms@gmail.com>
-Chris Howey <howeyc@gmail.com>
 Chris Hundt <hundt@google.com>
 Chris Jones <chris@cjones.org> <chris.jones.yar@gmail.com>
 Chris Lennert <calennert@gmail.com>
-Chris Manghane <cmang@golang.org>
-Chris McGee <sirnewton_01@yahoo.ca> <newton688@gmail.com>
 Christian Himpel <chressie@googlemail.com> <chressie@gmail.com>
 Christine Hansmann <chhansmann@gmail.com>
-Christoffer Buchholz <christoffer.buchholz@gmail.com>
 Christoph Hack <christoph@tux21b.org>
-Christopher Cahoon <chris.cahoon@gmail.com>
 Christopher Nielsen <m4dh4tt3r@gmail.com>
 Christopher Redden <christopher.redden@gmail.com>
-Christopher Swenson <cswenson@google.com>
 Christopher Wedgwood <cw@f00f.org>
 Clement Skau <clementskau@gmail.com>
 Colby Ranger <cranger@google.com>
 Conrad Meyer <cemeyer@cs.washington.edu>
 Corey Thomasson <cthom.lists@gmail.com>
-Cosmos Nicolaou <cnicolaou@google.com>
-Cristian Staretu <unclejacksons@gmail.com>
 Damian Gryski <dgryski@gmail.com>
-Damien Neil <dneil@google.com>
-Dan Callahan <dan.callahan@gmail.com>
-Dan Peterson <dpiddy@gmail.com>
 Dan Sinclair <dan.sinclair@gmail.com>
 Daniel Fleischman <danielfleischman@gmail.com>
 Daniel Krech <eikeon@eikeon.com>
-Daniel Lidén <daniel.liden.87@gmail.com>
 Daniel Morsing <daniel.morsing@gmail.com>
 Daniel Nadasi <dnadasi@google.com>
 Daniel Theophanes <kardianos@gmail.com>
 Darren Elwood <darren@textnode.com>
 Dave Borowitz <dborowitz@google.com>
 Dave Cheney <dave@cheney.net>
-Dave Day <djd@golang.org>
 Dave Grijalva <dgrijalva@ngmoco.com>
 David Anderson <danderson@google.com>
-David Barnett <dbarnett@google.com>
-David Bürgin <676c7473@gmail.com>
-David Calavera <david.calavera@gmail.com>
-David Covert <davidhcovert@gmail.com>
-David Crawshaw <david.crawshaw@zentus.com> <crawshaw@google.com> <crawshaw@golang.org>
+David Crawshaw <david.crawshaw@zentus.com> <crawshaw@google.com>
 David du Colombier <0intro@gmail.com>
 David Forsythe <dforsythe@gmail.com>
 David G. Andersen <dave.andersen@gmail.com>
 David Jakob Fritz <david.jakob.fritz@gmail.com>
-David Leon Gil <coruus@gmail.com>
-David McLeish <davemc@google.com>
-David Presotto <presotto@gmail.com>
 David Symonds <dsymonds@golang.org>
-David Thomas <davidthomas426@gmail.com>
 David Titarenco <david.titarenco@gmail.com>
 Dean Prichard <dean.prichard@gmail.com>
-Denis Brandolini <denis.brandolini@gmail.com>
-Derek Parker <parkerderek86@gmail.com>
 Devon H. O'Dell <devon.odell@gmail.com>
-Dhiru Kholia <dhiru.kholia@gmail.com>
-Dimitri Tcaciuc <dtcaciuc@gmail.com>
-Dmitri Shuralyov <shurcooL@gmail.com>
-Dmitriy Shelenin <deemok@googlemail.com> <deemok@gmail.com>
 Dmitriy Vyukov <dvyukov@google.com>
 Dmitry Chestnykh <dchest@gmail.com>
-Dominik Honnef <dominik.honnef@gmail.com>
-Donovan Hide <donovanhide@gmail.com>
-Drew Hintz <adhintz@google.com>
-Duncan Holm <mail@frou.org>
-Dustin Long <dustmop@gmail.com>
-Dustin Sallings <dsallings@gmail.com>
-Dustin Shields-Cloues <dcloues@gmail.com>
 Eden Li <eden.li@gmail.com>
-Egon Elbre <egonelbre@gmail.com>
-Ehren Kret <ehren.kret@gmail.com>
 Eivind Uggedal <eivind@uggedal.com>
-Elias Naur <elias.naur@gmail.com>
-Emil Hessman <c.emil.hessman@gmail.com> <emil@hessman.se>
+Emil Hessman <c.emil.hessman@gmail.com>
 Eoghan Sherry <ejsherry@gmail.com>
 Eric Clark <zerohp@gmail.com>
-Eric Milliken <emilliken@gmail.com>
 Eric Roshan-Eisner <eric.d.eisner@gmail.com>
-Erik St. Martin <alakriti@gmail.com>
-Erik Westrup <erik.westrup@gmail.com>
 Esko Luontola <esko.luontola@gmail.com>
-Evan Kroske <evankroske@google.com>
 Evan Martin <evan.martin@gmail.com>
 Evan Shaw <chickencha@gmail.com>
-Ewan Chou <coocood@gmail.com>
-Fabrizio Milo <mistobaan@gmail.com>
 Fan Hongjian <fan.howard@gmail.com>
-Fatih Arslan <fatih@arslan.io>
 Fazlul Shahriar <fshahriar@gmail.com>
-Felix Geisendörfer <haimuiba@gmail.com>
 Firmansyah Adiputra <frm.adiputra@gmail.com>
 Florian Uekermann <florian@uekermann-online.de> <f1@uekermann-online.de>
 Florian Weimer <fw@deneb.enyo.de>
-Folke Behrens <folke@google.com>
 Francesc Campoy <campoy@golang.org>
 Francisco Souza <franciscossouza@gmail.com>
-Frederick Kelly Mayle III <frederickmayle@gmail.com>
-Fredrik Enestad <fredrik.enestad@soundtrackyourbrand.com>
-Frithjof Schulze <schulze@math.uni-hannover.de> <sfrithjof@gmail.com>
 Fumitoshi Ukai <ukai@google.com>
-Gaal Yahas <gaal@google.com>
-Gabriel Aszalos <gabriel.aszalos@gmail.com>
 Gary Burd <gary@beagledreams.com> <gary.burd@gmail.com>
-Gautham Thambidorai <gautham.dorai@gmail.com>
-Georg Reinke <guelfey@gmail.com>
-Gerasimos Dimitriadis <gedimitr@gmail.com>
 Gideon Jan-Wessel Redelinghuys <gjredelinghuys@gmail.com>
 Giles Lean <giles.lean@pobox.com>
-Glenn Lewis <gmlewis@google.com>
-Gordon Klaus <gordon.klaus@gmail.com>
-Graham King <graham4king@gmail.com>
 Graham Miller <graham.miller@gmail.com>
-Greg Ward <greg@gerg.ca>
-Guillaume J. Charmes <guillaume@charmes.net>
 Gustav Paul <gustav.paul@gmail.com>
-Gustavo Franco <gustavorfranco@gmail.com>
 Gustavo Niemeyer <gustavo@niemeyer.net> <n13m3y3r@gmail.com>
 Gwenael Treguier <gwenn.kahz@gmail.com>
-Hana Kim <hyangah@gmail.com>
 Han-Wen Nienhuys <hanwen@google.com>
 Harley Laue <losinggeneration@gmail.com>
 Hector Chu <hectorchu@gmail.com>
-Hector Martin Cantero <hector@marcansoft.com>
-Henning Schmiedehausen <henning@schmiedehausen.org>
-Henrik Edwards <henrik.edwards@gmail.com>
-Herbert Georg Fischer <herbert.fischer@gmail.com>
 Hong Ruiqi <hongruiqi@gmail.com>
-Hossein Sheikh Attar <hattar@google.com>
 Ian Lance Taylor <iant@golang.org>
 Icarus Sparry <golang@icarus.freeuk.com>
 Ingo Oeser <nightlyone@googlemail.com> <nightlyone@gmail.com>
 Isaac Wagner <ibw@isaacwagner.me>
 Ivan Krasin <krasin@golang.org>
 Jacob Baskin <jbaskin@google.com>
-Jakob Borg <jakob@nym.se>
-Jakub Ryszard Czarnowicz <j.czarnowicz@gmail.com>
 James Aguilar <jaguilar@google.com>
-James David Chalfant <james.chalfant@gmail.com>
 James Fysh <james.fysh@gmail.com>
 James Gray <james@james4k.com>
 James Meneghello <rawrz0r@gmail.com>
 James P. Cooper <jamespcooper@gmail.com>
-James Robinson <jamesr@google.com> <jamesr.gatech@gmail.com>
 James Toy <nil@opensesame.st>
-James Tucker <raggi@google.com>
 James Whitehead <jnwhiteh@gmail.com>
 Jamie Gennis <jgennis@google.com> <jgennis@gmail.com>
-Jamie Turner <jamwt@dropbox.com>
-Jamie Wilkinson <jaq@spacepants.org>
 Jan H. Hosang <jan.hosang@gmail.com>
-Jan Mercl <0xjnml@gmail.com>
 Jan Mercl <befelemepeseveze@gmail.com>
 Jan Newmarch <jan.newmarch@gmail.com>
 Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
 Jani Monoses <jani.monoses@ubuntu.com> <jani.monoses@gmail.com>
 Jaroslavas Počepko <jp@webmaster.ms>
-Jason Del Ponte <delpontej@gmail.com>
-Jason Travis <infomaniac7@gmail.com>
-Jay Weisskopf <jay@jayschwa.net>
 Jean-Marc Eurin <jmeurin@google.com>
-Jed Denlea <jed@fastly.com>
 Jeff Hodges <jeff@somethingsimilar.com>
 Jeff R. Allen <jra@nella.org> <jeff.allen@gmail.com>
-Jeff Sickel <jas@corpus-callosum.com>
-Jeff Wendling <jeff@spacemonkey.com>
-Jens Frederich <jfrederich@gmail.com>
-Jeremiah Harmsen <jeremiah@google.com>
 Jeremy Jackins <jeremyjackins@gmail.com>
-Jeremy Schlatter <jeremy.schlatter@gmail.com>
 Jim McGrath <jimmc2@gmail.com>
-Jimmy Zelinskie <jimmyzelinskie@gmail.com>
-Jingcheng Zhang <diogin@gmail.com>
 Joakim Sernbrant <serbaut@gmail.com>
 Joe Poirier <jdpoirier@gmail.com>
-Joe Shaw <joe@joeshaw.org>
 Joel Sing <jsing@google.com>
-Joel Stemmer <stemmertech@gmail.com>
 Johan Euphrosine <proppy@google.com>
 John Asmuth <jasmuth@gmail.com>
 John Beisley <huin@google.com>
-John C Barstow <jbowtie@amathaine.com>
 John DeNero <denero@google.com>
-John Graham-Cumming <jgc@jgc.org> <jgrahamc@gmail.com>
-John Howard Palevich <jack.palevich@gmail.com>
-John Newlin <jnewlin@google.com>
-John Shahid <jvshahid@gmail.com>
-John Tuley <john@tuley.org>
 Jonathan Allie <jonallie@google.com>
-Jonathan Feinberg <feinberg@google.com>
 Jonathan Gold <jgold.bg@gmail.com>
-Jonathan Hseu <jhseu@google.com>
 Jonathan Mark <jhmark@xenops.com> <jhmark000@gmail.com>
-Jonathan Nieder <jrn@google.com>
 Jonathan Pittman <jmpittman@google.com> <jonathan.mark.pittman@gmail.com>
-Jonathan Rudenberg <jonathan@titanous.com>
 Jonathan Wills <runningwild@gmail.com>
 Jongmin Kim <atomaths@gmail.com>
 Jos Visser <josv@google.com>
 Jose Luis Vázquez González <josvazg@gmail.com>
-Joseph Bonneau <jcb@google.com>
-Joseph Holsten <joseph@josephholsten.com>
-Josh Bleecher Snyder <josharian@gmail.com>
 Josh Goebel <dreamer3@gmail.com>
-Josh Hoak <jhoak@google.com>
-Josh Holland <jrh@joshh.co.uk>
-Joshua Chase <jcjoshuachase@gmail.com>
-JP Sugarbroad <jpsugar@google.com>
-JT Olds <jtolds@xnet5.com>
 Jukka-Pekka Kekkonen <karatepekka@gmail.com>
 Julian Phillips <julian@quantumfyre.co.uk>
 Julien Schmidt <google@julienschmidt.com>
 Kai Backman <kaib@golang.org>
-Kamil Kisiel <kamil@kamilkisiel.net> <kamil.kisiel@gmail.com>
-Katrina Owen <katrina.owen@gmail.com>
-Kay Zhu <kayzhu@google.com>
 Kei Son <hey.calmdown@gmail.com>
-Keith Randall <khr@golang.org>
 Keith Rarick <kr@xph.us>
-Kelsey Hightower <kelsey.hightower@gmail.com>
-Kelvin Foo Chuan Lyi <vmirage@gmail.com>
 Ken Friedenbach <kenliz@cruzio.com>
 Ken Rockot <ken@oz.gs> <ken.rockot@gmail.com>
 Ken Thompson <ken@golang.org>
 Kevin Ballard <kevin@sb.org>
-Kevin Klues <klueska@gmail.com> <klueska@google.com>
 Kirklin McDonald <kirklin.mcdonald@gmail.com>
 Kyle Consalus <consalus@gmail.com>
-Kyle Isom <kyle@gokyle.net>
 Kyle Lemons <kyle@kylelemons.net> <kevlar@google.com>
 L Campbell <unpantsu@gmail.com>
 Lai Jiangshan <eag0628@gmail.com>
@@ -378,247 +216,129 @@ Louis Kruger <louisk@google.com>
 Luca Greco <luca.greco@alcacoop.it>
 Lucio De Re <lucio.dere@gmail.com>
 Luit van Drongelen <luitvd@gmail.com>
-Luka Zakrajšek <tr00.g33k@gmail.com>
-Luke Curley <qpingu@gmail.com>
 Luuk van Dijk <lvd@golang.org> <lvd@google.com>
-Manoj Dayaram <platform-dev@moovweb.com> <manoj.dayaram@moovweb.com>
 Manu Garg <manugarg@google.com>
-Manuel Mendez <mmendez534@gmail.com>
-Marc Weistroff <marc@weistroff.net>
 Marcel van Lohuizen <mpvl@golang.org>
-Marco Hennings <marco.hennings@freiheit.com>
-Mark Theunissen <mark.theunissen@gmail.com>
 Mark Zavislak <zavislak@google.com>
-Marko Juhani Silokunnas <marko.silokunnas@gmail.com>
-Marko Mikulicic <mkm@google.com>
-Marko Tiikkaja <marko@joh.to>
 Markus Duft <markus.duft@salomon.at>
 Markus Sonderegger <marraison@gmail.com>
-Markus Zimmermann <zimmski@gmail.com>
 Martin Neubauer <m.ne@gmx.net>
-Martin Olsson <martin@minimum.se>
 Mateusz Czapliński <czapkofan@gmail.com>
 Mathieu Lonjaret <mathieu.lonjaret@gmail.com>
 Mats Lidell <mats.lidell@cag.se> <mats.lidell@gmail.com>
-Matt Aimonetti <mattaimonetti@gmail.com>
-Matt Brown <mdbrown@google.com>
-Matt Jibson <matt.jibson@gmail.com>
-Matt Joiner <anacrolix@gmail.com>
 Matt Jones <mrjones@google.com>
-Matt Reiferson <mreiferson@gmail.com>
-Matthew Cottingham <mattcottingham@gmail.com>
-Matthew Dempsky <mdempsky@google.com>
+Matt Jibson <matt.jibson@gmail.com>
 Matthew Horsnell <matthew.horsnell@gmail.com>
-Maxim Khitrov <max@mxcrypt.com>
 Maxim Pimenov <mpimenov@google.com>
 Maxim Ushakov <ushakov@google.com>
 Micah Stetson <micah.stetson@gmail.com>
 Michael Chaten <mchaten@gmail.com>
 Michael Elkins <michael.elkins@gmail.com>
-Michael Fraenkel <michael.fraenkel@gmail.com>
-Michael Gehring <mg@ebfe.org> <gnirheg.leahcim@gmail.com>
+Michael Gehring <mg@ebfe.org>
 Michael Hoisie <hoisie@gmail.com>
-Michael Hudson-Doyle <michael.hudson@linaro.org>
-Michael Kelly <mjk@google.com>
 Michael Lewis <mikelikespie@gmail.com>
-Michael MacInnis <Michael.P.MacInnis@gmail.com>
-Michael Matloob <matloob@google.com>
-Michael Pearson <mipearson@gmail.com>
-Michael Piatek <piatek@google.com>
 Michael Shields <mshields@google.com>
 Michael Stapelberg <michael@stapelberg.de> <mstplbrg@googlemail.com>
 Michael T. Jones <mtj@google.com> <michael.jones@gmail.com>
-Michael Teichgräber <mteichgraeber@gmx.de> <mt4swm@googlemail.com>
 Michał Derkacz <ziutek@lnet.pl>
 Miek Gieben <miek@miek.nl> <remigius.gieben@gmail.com>
-Mihai Borobocea <MihaiBorobocea@gmail.com>
 Mikael Tillenius <mikti42@gmail.com>
-Mike Andrews <mra@xoba.com>
 Mike Rosset <mike.rosset@gmail.com>
 Mike Samuel <mikesamuel@gmail.com>
 Mike Solomon <msolo@gmail.com>
-Mikhail Panchenko <m@mihasya.com>
 Miki Tebeka <miki.tebeka@gmail.com>
 Mikio Hara <mikioh.mikioh@gmail.com>
 Mikkel Krautz <mikkel@krautz.dk> <krautz@gmail.com>
-Miquel Sabaté Solà <mikisabate@gmail.com>
 Moriyoshi Koizumi <mozo@mozo.jp>
 Môshe van der Sterre <moshevds@gmail.com>
-Mrunal Patel <mrunalp@gmail.com>
-Nan Deng <monnand@gmail.com>
-Nathan John Youngman <nj@nathany.com>
-Nathan P Finch <nate.finch@gmail.com>
-Nicholas Katsaros <nick@nickkatsaros.com>
-Nicholas Presta <nick@nickpresta.ca> <nick1presta@gmail.com>
-Nicholas Sullivan <nicholas.sullivan@gmail.com>
 Nicholas Waples <nwaples@gmail.com>
-Nick Cooper <nmvc@google.com>
-Nick Craig-Wood <nick@craig-wood.com> <nickcw@gmail.com>
-Nicolas Kaiser <nikai@nikai.net>
-Nicolas Owens <mischief@offblast.org>
 Nigel Kerr <nigel.kerr@gmail.com>
 Nigel Tao <nigeltao@golang.org>
-Noah Campbell <noahcampbell@gmail.com>
 Oling Cat <olingcat@gmail.com>
-Oliver Hookins <ohookins@gmail.com>
 Olivier Antoine <olivier.antoine@gmail.com>
 Olivier Duperray <duperray.olivier@gmail.com>
-Olivier Saingre <osaingre@gmail.com>
 Padraig Kitterick <padraigkitterick@gmail.com>
 Paolo Giarrusso <p.giarrusso@gmail.com>
 Pascal S. de Kloe <pascal@quies.net>
 Patrick Crosby <patrick@stathat.com>
 Patrick Gavlin <pgavlin@gmail.com>
 Patrick Higgins <patrick.allen.higgins@gmail.com>
-Patrick Mézard <patrick@mezard.eu>
 Patrick Mylund Nielsen <patrick@patrickmn.com>
-Patrick Riley <pfr@google.com>
-Patrick Smith <pat42smith@gmail.com>
-Paul A Querna <paul.querna@gmail.com>
 Paul Borman <borman@google.com>
-Paul Chang <paulchang@google.com>
-Paul Hammond <paul@paulhammond.org>
 Paul Lalonde <paul.a.lalonde@gmail.com>
-Paul Nasrat <pnasrat@google.com>
 Paul Sbarra <Sbarra.Paul@gmail.com>
-Paul van Brouwershaven <paul@vanbrouwershaven.com>
-Pavel Zinovkin <pavel.zinovkin@gmail.com>
-Pawel Szczur <filemon@google.com>
-Percy Wegmann <ox.to.a.cart@gmail.com>
 Petar Maymounkov <petarm@gmail.com>
 Peter Armitage <peter.armitage@gmail.com>
-Peter Collingbourne <pcc@google.com>
 Peter Froehlich <peter.hans.froehlich@gmail.com>
 Peter Kleiweg <pkleiweg@xs4all.nl>
 Peter McKenzie <petermck@google.com>
 Peter Mundy <go.peter.90@gmail.com>
-Péter Surányi <speter.go1@gmail.com>
 Péter Szabó <pts@google.com>
-Péter Szilágyi <peterke@gmail.com>
-Peter Waller <peter.waller@gmail.com>
 Peter Weinberger <pjw@golang.org>
 Peter Williams <pwil3058@gmail.com>
 Phil Pennock <pdp@golang.org>
-Philip K. Warren <pkwarren@gmail.com>
 Pieter Droogendijk <pieter@binky.org.uk>
-Pietro Gagliardi <pietro10@mac.com>
-Preetam Jinka <pj@preet.am>
 Quan Yong Zhai <qyzhai@gmail.com>
 Raif S. Naffah <go@naffah-raif.name>
 Raph Levien <raph@google.com>
-Raul Silvera <rsilvera@google.com>
 Rémy Oudompheng <oudomphe@phare.normalesup.org> <remyoudompheng@gmail.com>
-Richard Crowley <r@rcrowley.org>
-Richard Eric Gavaletz <gavaletz@gmail.com>
-Richard Musiol <mail@richard-musiol.de> <neelance@gmail.com>
-Rick Arnold <rickarnoldjr@gmail.com>
-Rick Hudson <rlh@golang.org>
 Risto Jaakko Saarelma <rsaarelm@gmail.com>
 Rob Pike <r@golang.org>
-Robert Daniel Kortschak <dan.kortschak@adelaide.edu.au>
-Robert Dinu <r@varp.se>
 Robert Figueiredo <robfig@gmail.com>
 Robert Griesemer <gri@golang.org>
 Robert Hencke <robert.hencke@gmail.com>
-Robert Obryk <robryk@gmail.com>
-Robert Sesek <rsesek@google.com>
-Robert Snedegar <roberts@google.com>
-Robin Eklind <r.eklind.87@gmail.com>
-Rodrigo Moraes de Oliveira <rodrigo.moraes@gmail.com>
-Rodrigo Rafael Monti Kochenburger <divoxx@gmail.com>
 Roger Pau Monné <royger@gmail.com>
 Roger Peppe <rogpeppe@gmail.com>
-Ron Hashimoto <mail@h2so5.net>
 Ron Minnich <rminnich@gmail.com>
 Ross Light <rlight2@gmail.com>
-Rowan Worth <sqweek@gmail.com>
-Rui Ueyama <ruiu@google.com>
 Russ Cox <rsc@golang.org>
 Ryan Barrett <ryanb@google.com>
 Ryan Hitchman <hitchmanr@gmail.com>
-Ryan Slade <ryanslade@gmail.com>
-S.Çağlar Onur <caglar@10ur.org>
 Sam Thorogood <thorogood@google.com> <sam.thorogood@gmail.com>
 Sameer Ajmani <sameer@golang.org> <ajmani@gmail.com>
 Sanjay Menakuru <balasanjay@gmail.com>
-Scott Ferguson <scottwferg@gmail.com>
 Scott Lawrence <bytbox@gmail.com>
 Scott Schwartz <scotts@golang.org>
-Sean Burford <sburford@google.com>
 Sebastien Binet	<seb.binet@gmail.com>
 Sébastien Paolacci <sebastien.paolacci@gmail.com>
 Sergei Skorobogatov <skorobo@rambler.ru>
 Sergey 'SnakE' Gromov <snake.scaly@gmail.com>
-Sergio Luis O. B. Correia <sergio@correia.cc>
-Shane Hansen <shanemhansen@gmail.com>
-Shawn Ledbetter <sledbetter@google.com>
+Sergio Luis O. B. Correia <sergio@larces.uece.br>
 Shawn Smith <shawn.p.smith@gmail.com>
-Shenghou Ma <minux@golang.org> <minux.ma@gmail.com>
-Shivakumar GN <shivakumar.gn@gmail.com>
-Simon Whitehead <chemnova@gmail.com>
-Sokolov Yura <funny.falcon@gmail.com>
+Shenghou Ma <minux.ma@gmail.com>
 Spring Mc <heresy.mc@gmail.com>
-StalkR <stalkr@stalkr.net>
 Stefan Nilsson <snilsson@nada.kth.se> <trolleriprofessorn@gmail.com>
 Stéphane Travostino <stephane.travostino@gmail.com>
 Stephen Ma <stephenm@golang.org>
-Stephen McQuay <stephen@mcquay.me>
 Stephen Weinberg <stephen@q5comm.com>
-Steve McCoy <mccoyst@gmail.com>
-Steven Elliot Harris <seharris@gmail.com>
-Steven Hartland <steven.hartland@multiplay.co.uk>
 Sugu Sougoumarane <ssougou@gmail.com>
 Sven Almgren <sven@tras.se>
 Szabolcs Nagy <nsz@port70.net>
-Tad Glines <tad.glines@gmail.com>
-Taj Khattra <taj.khattra@gmail.com>
 Tarmigan Casebolt <tarmigan@gmail.com>
 Taru Karttunen <taruti@taruti.net>
-Tetsuo Kiso <tetsuokiso9@gmail.com>
-Thiago Fransosi Farina <thiago.farina@gmail.com> <tfarina@chromium.org>
 Thomas Alan Copeland <talan.copeland@gmail.com>
-Thomas Habets <habets@google.com>
-Thomas Kappler <tkappler@gmail.com>
 Timo Savola <timo.savola@gmail.com>
-Timo Truyts <alkaloid.btx@gmail.com>
 Tobias Columbus <tobias.columbus@gmail.com> <tobias.columbus@googlemail.com>
-Todd Wang <toddwang@gmail.com>
-Tom Linford <tomlinford@gmail.com>
 Tom Szymanski <tgs@google.com>
 Tor Andersson <tor.andersson@gmail.com>
-Travis Cline <travis.cline@gmail.com>
 Trevor Strohman <trevor.strohman@gmail.com>
-Tudor Golubenco <tudor.g@gmail.com>
-Tw <tw19881113@gmail.com>
-Tyler Bunnell <tylerbunnell@gmail.com>
 Ugorji Nwoke <ugorji@gmail.com>
-Ulf Holm Nielsen <doktor@dyregod.dk>
 Uriel Mangado <uriel@berlinblue.org>
 Vadim Vygonets <unixdj@gmail.com>
-Vega Garcia Luis Alfonso <vegacom@gmail.com>
 Vincent Ambo <tazjin@googlemail.com>
 Vincent Vanackere <vincent.vanackere@gmail.com>
 Vinu Rajashekhar <vinutheraj@gmail.com>
 Vish Subramanian <vish@google.com>
-Vladimir Nikishenko <vova616@gmail.com>
 Volker Dobler <dr.volker.dobler@gmail.com>
 Wei Guangjing <vcc.163@gmail.com>
-Will Norris <willnorris@google.com>
-Willem van der Schyff <willemvds@gmail.com>
 William Chan <willchan@chromium.org>
 William Josephson <wjosephson@gmail.com>
-William Orr <will@worrbase.com> <ay1244@gmail.com>
-Xia Bin <snyh@snyh.org>
 Xing Xing <mikespook@gmail.com>
-Yan Zou <yzou@google.com>
 Yasuhiro Matsumoto <mattn.jp@gmail.com>
 Yissakhar Z. Beck <yissakhar.beck@gmail.com>
 Yongjian Xu <i3dmaster@gmail.com>
 Yoshiyuki Kanno <nekotaroh@gmail.com> <yoshiyuki.kanno@stoic.co.jp>
-Yusuke Kagiwada <block.rxckin.beats@gmail.com>
 Yuusei Kuwana <kuwana@kumama.org>
 Yuval Pavel Zholkover <paulzhol@gmail.com>
 Yves Junqueira <yves.junqueira@gmail.com>
 Ziad Hatahet <hatahet@gmail.com>
-Zorion Arrizabalaga <zorionk@gmail.com>
-申习之 <bronze1man@gmail.com>
--- a/31
+++ b/31
@@ -0,0 +1,31 @@
+This is the source code repository for the Go programming language.  
+
+For documentation about how to install and use Go,
+visit http://golang.org/ or load doc/install.html in your web browser.
+
+After installing Go, you can view a nicely formatted
+doc/install.html by running godoc --http=:6060
+and then visiting http://localhost:6060/doc/install.html.
+
+Unless otherwise noted, the Go source files are distributed
+under the BSD-style license found in the LICENSE file.
+
+--
+
+Binary Distribution Notes
+
+If you have just untarred a binary Go distribution, you need to set
+the environment variable $GOROOT to the full path of the go
+directory (the one containing this README).  You can omit the
+variable if you unpack it into /usr/local/go, or if you rebuild
+from sources by running all.bash (see doc/install.html).
+You should also add the Go binary directory $GOROOT/bin
+to your shell's path.
+
+For example, if you extracted the tar file into $HOME/go, you might
+put the following in your .profile:
+
+    export GOROOT=$HOME/go
+    export PATH=$PATH:$GOROOT/bin
+
+See doc/install.html for more details.
--- a/README.md
+++ b/README.md
@@ -1,45 +0,0 @@
-# The Go Programming Language
-
-Go is an open source programming language that makes it easy to build simple,
-reliable, and efficient software.
-
-![Gopher image](doc/gopher/fiveyears.jpg)
-
-For documentation about how to install and use Go,
-visit https://golang.org/ or load doc/install-source.html
-in your web browser.
-
-Our canonical Git repository is located at https://go.googlesource.com/go.
-There is a mirror of the repository at https://github.com/golang/go.
-
-Please report issues here: https://golang.org/issue/new
-
-Go is the work of hundreds of contributors. We appreciate your help!
-
-To contribute, please read the contribution guidelines:
-	https://golang.org/doc/contribute.html
-
-##### Please note that we do not use pull requests.
-
-Unless otherwise noted, the Go source files are distributed
-under the BSD-style license found in the LICENSE file.
-
--
-
-## Binary Distribution Notes
-
-If you have just untarred a binary Go distribution, you need to set
-the environment variable $GOROOT to the full path of the go
-directory (the one containing this file).  You can omit the
-variable if you unpack it into /usr/local/go, or if you rebuild
-from sources by running all.bash (see doc/install-source.html).
-You should also add the Go binary directory $GOROOT/bin
-to your shell's path.
-
-For example, if you extracted the tar file into $HOME/go, you might
-put the following in your .profile:
-
-	export GOROOT=$HOME/go
-	export PATH=$PATH:$GOROOT/bin
-
-See https://golang.org/doc/install or doc/install.html for more details.
--- a/1
+++ b/1
@@ -0,0 +1 @@
+go1.0.3
--- a/api/README
+++ b/api/README
@@ -5,9 +5,6 @@ Each file is a list of of API features, one per line.
 go1.txt (and similarly named files) are frozen once a version has been
 shipped. Each file adds new lines but does not remove any.

-except.txt lists features that may disappear without breaking true
-compatibility.
-
 next.txt is the only file intended to be mutated. It's a list of
 features that may be added to the next version. It only affects
 warning output from the go api tool.
--- a/api/except.txt
+++ b/api/except.txt
@@ -1,330 +0,0 @@
-pkg net, func ListenUnixgram(string, *UnixAddr) (*UDPConn, error)
-pkg syscall (darwin-386), func Fchflags(string, int) error
-pkg syscall (darwin-386-cgo), func Fchflags(string, int) error
-pkg syscall (darwin-amd64), func Fchflags(string, int) error
-pkg syscall (darwin-amd64-cgo), func Fchflags(string, int) error
-pkg syscall (freebsd-386), func Fchflags(string, int) error
-pkg syscall (freebsd-amd64), func Fchflags(string, int) error
-pkg syscall (freebsd-arm), func Fchflags(string, int) error
-pkg syscall (freebsd-arm-cgo), func Fchflags(string, int) error
-pkg syscall (netbsd-arm), func Fchflags(string, int) error
-pkg syscall (netbsd-arm-cgo), func Fchflags(string, int) error
-pkg testing, func RegisterCover(Cover)
-pkg text/template/parse, type DotNode bool
-pkg text/template/parse, type Node interface { Copy, String, Type }
-pkg os (linux-arm), const O_SYNC = 4096
-pkg os (linux-arm-cgo), const O_SYNC = 4096
-pkg syscall (darwin-386), const ImplementsGetwd = false
-pkg syscall (darwin-386-cgo), const ImplementsGetwd = false
-pkg syscall (darwin-amd64), const ImplementsGetwd = false
-pkg syscall (darwin-amd64-cgo), const ImplementsGetwd = false
-pkg syscall (openbsd-386), const BIOCGRTIMEOUT = 1074283118
-pkg syscall (openbsd-386), const BIOCSRTIMEOUT = 2148024941
-pkg syscall (openbsd-386), const RTF_FMASK = 63496
-pkg syscall (openbsd-386), const RTM_VERSION = 4
-pkg syscall (openbsd-386), const SIOCBRDGDADDR = 2150132039
-pkg syscall (openbsd-386), const SIOCBRDGGPARAM = 3224922456
-pkg syscall (openbsd-386), const SIOCBRDGSADDR = 3223873860
-pkg syscall (openbsd-386), const SYS_CLOCK_GETRES = 234
-pkg syscall (openbsd-386), const SYS_CLOCK_GETTIME = 232
-pkg syscall (openbsd-386), const SYS_CLOCK_SETTIME = 233
-pkg syscall (openbsd-386), const SYS_FHSTATFS = 309
-pkg syscall (openbsd-386), const SYS_FSTAT = 292
-pkg syscall (openbsd-386), const SYS_FSTATAT = 316
-pkg syscall (openbsd-386), const SYS_FSTATFS = 308
-pkg syscall (openbsd-386), const SYS_FUTIMENS = 327
-pkg syscall (openbsd-386), const SYS_FUTIMES = 206
-pkg syscall (openbsd-386), const SYS_GETDIRENTRIES = 312
-pkg syscall (openbsd-386), const SYS_GETDIRENTRIES ideal-int
-pkg syscall (openbsd-386), const SYS_GETFSSTAT = 306
-pkg syscall (openbsd-386), const SYS_GETITIMER = 86
-pkg syscall (openbsd-386), const SYS_GETRUSAGE = 117
-pkg syscall (openbsd-386), const SYS_GETTIMEOFDAY = 116
-pkg syscall (openbsd-386), const SYS_KEVENT = 270
-pkg syscall (openbsd-386), const SYS_LSTAT = 293
-pkg syscall (openbsd-386), const SYS_NANOSLEEP = 240
-pkg syscall (openbsd-386), const SYS_SELECT = 93
-pkg syscall (openbsd-386), const SYS_SETITIMER = 83
-pkg syscall (openbsd-386), const SYS_SETTIMEOFDAY = 122
-pkg syscall (openbsd-386), const SYS_STAT = 291
-pkg syscall (openbsd-386), const SYS_STATFS = 307
-pkg syscall (openbsd-386), const SYS_UTIMENSAT = 326
-pkg syscall (openbsd-386), const SYS_UTIMES = 138
-pkg syscall (openbsd-386), const SYS_WAIT4 = 7
-pkg syscall (openbsd-386), const SYS___THRSLEEP = 300
-pkg syscall (openbsd-386), const SizeofIfData = 208
-pkg syscall (openbsd-386), const SizeofIfMsghdr = 232
-pkg syscall (openbsd-386), const SizeofRtMetrics = 48
-pkg syscall (openbsd-386), const SizeofRtMsghdr = 88
-pkg syscall (openbsd-386), const TIOCGTSTAMP = 1074295899
-pkg syscall (openbsd-386), type Dirent struct, Fileno uint32
-pkg syscall (openbsd-386), type FdSet struct, Bits [32]int32
-pkg syscall (openbsd-386), type Kevent_t struct, Data int32
-pkg syscall (openbsd-386), type Mclpool struct, Grown uint32
-pkg syscall (openbsd-386), type RtMetrics struct, Expire uint32
-pkg syscall (openbsd-386), type Stat_t struct, Ino uint32
-pkg syscall (openbsd-386), type Stat_t struct, Lspare0 int32
-pkg syscall (openbsd-386), type Stat_t struct, Lspare1 int32
-pkg syscall (openbsd-386), type Stat_t struct, Qspare [2]int64
-pkg syscall (openbsd-386), type Statfs_t struct, F_ctime uint32
-pkg syscall (openbsd-386), type Statfs_t struct, F_spare [3]uint32
-pkg syscall (openbsd-386), type Timespec struct, Sec int32
-pkg syscall (openbsd-386), type Timeval struct, Sec int32
-pkg syscall (openbsd-386-cgo), const BIOCGRTIMEOUT = 1074283118
-pkg syscall (openbsd-386-cgo), const BIOCSRTIMEOUT = 2148024941
-pkg syscall (openbsd-386-cgo), const RTF_FMASK = 63496
-pkg syscall (openbsd-386-cgo), const RTM_VERSION = 4
-pkg syscall (openbsd-386-cgo), const SIOCBRDGDADDR = 2150132039
-pkg syscall (openbsd-386-cgo), const SIOCBRDGGPARAM = 3224922456
-pkg syscall (openbsd-386-cgo), const SIOCBRDGSADDR = 3223873860
-pkg syscall (openbsd-386-cgo), const SYS_CLOCK_GETRES = 234
-pkg syscall (openbsd-386-cgo), const SYS_CLOCK_GETTIME = 232
-pkg syscall (openbsd-386-cgo), const SYS_CLOCK_SETTIME = 233
-pkg syscall (openbsd-386-cgo), const SYS_FHSTATFS = 309
-pkg syscall (openbsd-386-cgo), const SYS_FSTAT = 292
-pkg syscall (openbsd-386-cgo), const SYS_FSTATAT = 316
-pkg syscall (openbsd-386-cgo), const SYS_FSTATFS = 308
-pkg syscall (openbsd-386-cgo), const SYS_FUTIMENS = 327
-pkg syscall (openbsd-386-cgo), const SYS_FUTIMES = 206
-pkg syscall (openbsd-386-cgo), const SYS_GETDIRENTRIES = 312
-pkg syscall (openbsd-386-cgo), const SYS_GETDIRENTRIES ideal-int
-pkg syscall (openbsd-386-cgo), const SYS_GETFSSTAT = 306
-pkg syscall (openbsd-386-cgo), const SYS_GETITIMER = 86
-pkg syscall (openbsd-386-cgo), const SYS_GETRUSAGE = 117
-pkg syscall (openbsd-386-cgo), const SYS_GETTIMEOFDAY = 116
-pkg syscall (openbsd-386-cgo), const SYS_KEVENT = 270
-pkg syscall (openbsd-386-cgo), const SYS_LSTAT = 293
-pkg syscall (openbsd-386-cgo), const SYS_NANOSLEEP = 240
-pkg syscall (openbsd-386-cgo), const SYS_SELECT = 93
-pkg syscall (openbsd-386-cgo), const SYS_SETITIMER = 83
-pkg syscall (openbsd-386-cgo), const SYS_SETTIMEOFDAY = 122
-pkg syscall (openbsd-386-cgo), const SYS_STAT = 291
-pkg syscall (openbsd-386-cgo), const SYS_STATFS = 307
-pkg syscall (openbsd-386-cgo), const SYS_UTIMENSAT = 326
-pkg syscall (openbsd-386-cgo), const SYS_UTIMES = 138
-pkg syscall (openbsd-386-cgo), const SYS_WAIT4 = 7
-pkg syscall (openbsd-386-cgo), const SYS___THRSLEEP = 300
-pkg syscall (openbsd-386-cgo), const SizeofIfData = 208
-pkg syscall (openbsd-386-cgo), const SizeofIfMsghdr = 232
-pkg syscall (openbsd-386-cgo), const SizeofRtMetrics = 48
-pkg syscall (openbsd-386-cgo), const SizeofRtMsghdr = 88
-pkg syscall (openbsd-386-cgo), const TIOCGTSTAMP = 1074295899
-pkg syscall (openbsd-386-cgo), type Dirent struct, Fileno uint32
-pkg syscall (openbsd-386-cgo), type FdSet struct, Bits [32]int32
-pkg syscall (openbsd-386-cgo), type Kevent_t struct, Data int32
-pkg syscall (openbsd-386-cgo), type Mclpool struct, Grown uint32
-pkg syscall (openbsd-386-cgo), type RtMetrics struct, Expire uint32
-pkg syscall (openbsd-386-cgo), type Stat_t struct, Ino uint32
-pkg syscall (openbsd-386-cgo), type Stat_t struct, Lspare0 int32
-pkg syscall (openbsd-386-cgo), type Stat_t struct, Lspare1 int32
-pkg syscall (openbsd-386-cgo), type Stat_t struct, Qspare [2]int64
-pkg syscall (openbsd-386-cgo), type Statfs_t struct, F_ctime uint32
-pkg syscall (openbsd-386-cgo), type Statfs_t struct, F_spare [3]uint32
-pkg syscall (openbsd-386-cgo), type Timespec struct, Sec int32
-pkg syscall (openbsd-386-cgo), type Timeval struct, Sec int32
-pkg syscall (openbsd-amd64), const CCR0_FLUSH = 16
-pkg syscall (openbsd-amd64), const CCR0_FLUSH ideal-int
-pkg syscall (openbsd-amd64), const CPUID_CFLUSH = 524288
-pkg syscall (openbsd-amd64), const CPUID_CFLUSH ideal-int
-pkg syscall (openbsd-amd64), const EFER_LMA = 1024
-pkg syscall (openbsd-amd64), const EFER_LMA ideal-int
-pkg syscall (openbsd-amd64), const EFER_LME = 256
-pkg syscall (openbsd-amd64), const EFER_LME ideal-int
-pkg syscall (openbsd-amd64), const EFER_NXE = 2048
-pkg syscall (openbsd-amd64), const EFER_NXE ideal-int
-pkg syscall (openbsd-amd64), const EFER_SCE = 1
-pkg syscall (openbsd-amd64), const EFER_SCE ideal-int
-pkg syscall (openbsd-amd64), const PMC5_PIPELINE_FLUSH = 21
-pkg syscall (openbsd-amd64), const PMC5_PIPELINE_FLUSH ideal-int
-pkg syscall (openbsd-amd64), const RTF_FMASK = 63496
-pkg syscall (openbsd-amd64), const RTM_VERSION = 4
-pkg syscall (openbsd-amd64), const SIOCBRDGDADDR = 2150132039
-pkg syscall (openbsd-amd64), const SIOCBRDGSADDR = 3223873860
-pkg syscall (openbsd-amd64), const SYS_CLOCK_GETRES = 234
-pkg syscall (openbsd-amd64), const SYS_CLOCK_GETTIME = 232
-pkg syscall (openbsd-amd64), const SYS_CLOCK_SETTIME = 233
-pkg syscall (openbsd-amd64), const SYS_FHSTATFS = 309
-pkg syscall (openbsd-amd64), const SYS_FSTAT = 292
-pkg syscall (openbsd-amd64), const SYS_FSTATAT = 316
-pkg syscall (openbsd-amd64), const SYS_FSTATFS = 308
-pkg syscall (openbsd-amd64), const SYS_FUTIMENS = 327
-pkg syscall (openbsd-amd64), const SYS_FUTIMES = 206
-pkg syscall (openbsd-amd64), const SYS_GETDIRENTRIES = 312
-pkg syscall (openbsd-amd64), const SYS_GETDIRENTRIES ideal-int
-pkg syscall (openbsd-amd64), const SYS_GETFSSTAT = 306
-pkg syscall (openbsd-amd64), const SYS_GETITIMER = 86
-pkg syscall (openbsd-amd64), const SYS_GETRUSAGE = 117
-pkg syscall (openbsd-amd64), const SYS_GETTIMEOFDAY = 116
-pkg syscall (openbsd-amd64), const SYS_KEVENT = 270
-pkg syscall (openbsd-amd64), const SYS_LSTAT = 293
-pkg syscall (openbsd-amd64), const SYS_NANOSLEEP = 240
-pkg syscall (openbsd-amd64), const SYS_SELECT = 93
-pkg syscall (openbsd-amd64), const SYS_SETITIMER = 83
-pkg syscall (openbsd-amd64), const SYS_SETTIMEOFDAY = 122
-pkg syscall (openbsd-amd64), const SYS_STAT = 291
-pkg syscall (openbsd-amd64), const SYS_STATFS = 307
-pkg syscall (openbsd-amd64), const SYS_UTIMENSAT = 326
-pkg syscall (openbsd-amd64), const SYS_UTIMES = 138
-pkg syscall (openbsd-amd64), const SYS_WAIT4 = 7
-pkg syscall (openbsd-amd64), const SYS___THRSLEEP = 300
-pkg syscall (openbsd-amd64), const SizeofRtMetrics = 48
-pkg syscall (openbsd-amd64), const SizeofRtMsghdr = 88
-pkg syscall (openbsd-amd64), type Dirent struct, Fileno uint32
-pkg syscall (openbsd-amd64), type FdSet struct, Bits [32]int32
-pkg syscall (openbsd-amd64), type Kevent_t struct, Data int32
-pkg syscall (openbsd-amd64), type Kevent_t struct, Ident uint32
-pkg syscall (openbsd-amd64), type Mclpool struct, Grown uint32
-pkg syscall (openbsd-amd64), type RtMetrics struct, Expire uint32
-pkg syscall (openbsd-amd64), type Stat_t struct, Ino uint32
-pkg syscall (openbsd-amd64), type Stat_t struct, Lspare0 int32
-pkg syscall (openbsd-amd64), type Stat_t struct, Lspare1 int32
-pkg syscall (openbsd-amd64), type Stat_t struct, Qspare [2]int64
-pkg syscall (openbsd-amd64), type Statfs_t struct, F_ctime uint32
-pkg syscall (openbsd-amd64), type Statfs_t struct, F_spare [3]uint32
-pkg syscall (openbsd-amd64), type Statfs_t struct, Pad_cgo_1 [4]uint8
-pkg syscall (openbsd-amd64), type Timespec struct, Pad_cgo_0 [4]uint8
-pkg syscall (openbsd-amd64), type Timespec struct, Sec int32
-pkg syscall (openbsd-amd64-cgo), const CCR0_FLUSH = 16
-pkg syscall (openbsd-amd64-cgo), const CCR0_FLUSH ideal-int
-pkg syscall (openbsd-amd64-cgo), const CPUID_CFLUSH = 524288
-pkg syscall (openbsd-amd64-cgo), const CPUID_CFLUSH ideal-int
-pkg syscall (openbsd-amd64-cgo), const EFER_LMA = 1024
-pkg syscall (openbsd-amd64-cgo), const EFER_LMA ideal-int
-pkg syscall (openbsd-amd64-cgo), const EFER_LME = 256
-pkg syscall (openbsd-amd64-cgo), const EFER_LME ideal-int
-pkg syscall (openbsd-amd64-cgo), const EFER_NXE = 2048
-pkg syscall (openbsd-amd64-cgo), const EFER_NXE ideal-int
-pkg syscall (openbsd-amd64-cgo), const EFER_SCE = 1
-pkg syscall (openbsd-amd64-cgo), const EFER_SCE ideal-int
-pkg syscall (openbsd-amd64-cgo), const PMC5_PIPELINE_FLUSH = 21
-pkg syscall (openbsd-amd64-cgo), const PMC5_PIPELINE_FLUSH ideal-int
-pkg syscall (openbsd-amd64-cgo), const RTF_FMASK = 63496
-pkg syscall (openbsd-amd64-cgo), const RTM_VERSION = 4
-pkg syscall (openbsd-amd64-cgo), const SIOCBRDGDADDR = 2150132039
-pkg syscall (openbsd-amd64-cgo), const SIOCBRDGSADDR = 3223873860
-pkg syscall (openbsd-amd64-cgo), const SYS_CLOCK_GETRES = 234
-pkg syscall (openbsd-amd64-cgo), const SYS_CLOCK_GETTIME = 232
-pkg syscall (openbsd-amd64-cgo), const SYS_CLOCK_SETTIME = 233
-pkg syscall (openbsd-amd64-cgo), const SYS_FHSTATFS = 309
-pkg syscall (openbsd-amd64-cgo), const SYS_FSTAT = 292
-pkg syscall (openbsd-amd64-cgo), const SYS_FSTATAT = 316
-pkg syscall (openbsd-amd64-cgo), const SYS_FSTATFS = 308
-pkg syscall (openbsd-amd64-cgo), const SYS_FUTIMENS = 327
-pkg syscall (openbsd-amd64-cgo), const SYS_FUTIMES = 206
-pkg syscall (openbsd-amd64-cgo), const SYS_GETDIRENTRIES = 312
-pkg syscall (openbsd-amd64-cgo), const SYS_GETDIRENTRIES ideal-int
-pkg syscall (openbsd-amd64-cgo), const SYS_GETFSSTAT = 306
-pkg syscall (openbsd-amd64-cgo), const SYS_GETITIMER = 86
-pkg syscall (openbsd-amd64-cgo), const SYS_GETRUSAGE = 117
-pkg syscall (openbsd-amd64-cgo), const SYS_GETTIMEOFDAY = 116
-pkg syscall (openbsd-amd64-cgo), const SYS_KEVENT = 270
-pkg syscall (openbsd-amd64-cgo), const SYS_LSTAT = 293
-pkg syscall (openbsd-amd64-cgo), const SYS_NANOSLEEP = 240
-pkg syscall (openbsd-amd64-cgo), const SYS_SELECT = 93
-pkg syscall (openbsd-amd64-cgo), const SYS_SETITIMER = 83
-pkg syscall (openbsd-amd64-cgo), const SYS_SETTIMEOFDAY = 122
-pkg syscall (openbsd-amd64-cgo), const SYS_STAT = 291
-pkg syscall (openbsd-amd64-cgo), const SYS_STATFS = 307
-pkg syscall (openbsd-amd64-cgo), const SYS_UTIMENSAT = 326
-pkg syscall (openbsd-amd64-cgo), const SYS_UTIMES = 138
-pkg syscall (openbsd-amd64-cgo), const SYS_WAIT4 = 7
-pkg syscall (openbsd-amd64-cgo), const SYS___THRSLEEP = 300
-pkg syscall (openbsd-amd64-cgo), const SizeofRtMetrics = 48
-pkg syscall (openbsd-amd64-cgo), const SizeofRtMsghdr = 88
-pkg syscall (openbsd-amd64-cgo), type Dirent struct, Fileno uint32
-pkg syscall (openbsd-amd64-cgo), type FdSet struct, Bits [32]int32
-pkg syscall (openbsd-amd64-cgo), type Kevent_t struct, Data int32
-pkg syscall (openbsd-amd64-cgo), type Kevent_t struct, Ident uint32
-pkg syscall (openbsd-amd64-cgo), type Mclpool struct, Grown uint32
-pkg syscall (openbsd-amd64-cgo), type RtMetrics struct, Expire uint32
-pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Ino uint32
-pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Lspare0 int32
-pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Lspare1 int32
-pkg syscall (openbsd-amd64-cgo), type Stat_t struct, Qspare [2]int64
-pkg syscall (openbsd-amd64-cgo), type Statfs_t struct, F_ctime uint32
-pkg syscall (openbsd-amd64-cgo), type Statfs_t struct, F_spare [3]uint32
-pkg syscall (openbsd-amd64-cgo), type Statfs_t struct, Pad_cgo_1 [4]uint8
-pkg syscall (openbsd-amd64-cgo), type Timespec struct, Pad_cgo_0 [4]uint8
-pkg syscall (openbsd-amd64-cgo), type Timespec struct, Sec int32
-pkg unicode, const Version = "6.2.0"
-pkg syscall (freebsd-386), const AF_MAX = 38
-pkg syscall (freebsd-386), const DLT_MATCHING_MAX = 242
-pkg syscall (freebsd-386), const ELAST = 94
-pkg syscall (freebsd-386), const O_CLOEXEC = 0
-pkg syscall (freebsd-386-cgo), const AF_MAX = 38
-pkg syscall (freebsd-386-cgo), const DLT_MATCHING_MAX = 242
-pkg syscall (freebsd-386-cgo), const ELAST = 94
-pkg syscall (freebsd-386-cgo), const O_CLOEXEC = 0
-pkg syscall (freebsd-amd64), const AF_MAX = 38
-pkg syscall (freebsd-amd64), const DLT_MATCHING_MAX = 242
-pkg syscall (freebsd-amd64), const ELAST = 94
-pkg syscall (freebsd-amd64), const O_CLOEXEC = 0
-pkg syscall (freebsd-amd64-cgo), const AF_MAX = 38
-pkg syscall (freebsd-amd64-cgo), const DLT_MATCHING_MAX = 242
-pkg syscall (freebsd-amd64-cgo), const ELAST = 94
-pkg syscall (freebsd-amd64-cgo), const O_CLOEXEC = 0
-pkg syscall (freebsd-arm), const AF_MAX = 38
-pkg syscall (freebsd-arm), const BIOCGRTIMEOUT = 1074545262
-pkg syscall (freebsd-arm), const BIOCSRTIMEOUT = 2148287085
-pkg syscall (freebsd-arm), const ELAST = 94
-pkg syscall (freebsd-arm), const O_CLOEXEC = 0
-pkg syscall (freebsd-arm), const SIOCAIFADDR = 2151967019
-pkg syscall (freebsd-arm), const SIOCGIFSTATUS = 3274991931
-pkg syscall (freebsd-arm), const SIOCSIFPHYADDR = 2151967046
-pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_GET = 537
-pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_GET ideal-int
-pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_LIMIT = 536
-pkg syscall (freebsd-arm), const SYS_CAP_FCNTLS_LIMIT ideal-int
-pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_GET = 535
-pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_GET ideal-int
-pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_LIMIT = 534
-pkg syscall (freebsd-arm), const SYS_CAP_IOCTLS_LIMIT ideal-int
-pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_GET = 515
-pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_GET ideal-int
-pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_LIMIT = 533
-pkg syscall (freebsd-arm), const SYS_CAP_RIGHTS_LIMIT ideal-int
-pkg syscall (freebsd-arm), const SizeofBpfHdr = 24
-pkg syscall (freebsd-arm), const SizeofIfData = 88
-pkg syscall (freebsd-arm), const SizeofIfMsghdr = 104
-pkg syscall (freebsd-arm), const SizeofSockaddrDatalink = 56
-pkg syscall (freebsd-arm), const SizeofSockaddrUnix = 108
-pkg syscall (freebsd-arm), const TIOCTIMESTAMP = 1074558041
-pkg syscall (freebsd-arm), type BpfHdr struct, Pad_cgo_0 [2]uint8
-pkg syscall (freebsd-arm), type RawSockaddrDatalink struct, Pad_cgo_0 [2]uint8
-pkg syscall (freebsd-arm), type RawSockaddrUnix struct, Pad_cgo_0 [2]uint8
-pkg syscall (freebsd-arm), type Stat_t struct, Pad_cgo_0 [4]uint8
-pkg syscall (freebsd-arm-cgo), const AF_MAX = 38
-pkg syscall (freebsd-arm-cgo), const BIOCGRTIMEOUT = 1074545262
-pkg syscall (freebsd-arm-cgo), const BIOCSRTIMEOUT = 2148287085
-pkg syscall (freebsd-arm-cgo), const ELAST = 94
-pkg syscall (freebsd-arm-cgo), const O_CLOEXEC = 0
-pkg syscall (freebsd-arm-cgo), const SIOCAIFADDR = 2151967019
-pkg syscall (freebsd-arm-cgo), const SIOCGIFSTATUS = 3274991931
-pkg syscall (freebsd-arm-cgo), const SIOCSIFPHYADDR = 2151967046
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_GET = 537
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_GET ideal-int
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_LIMIT = 536
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_FCNTLS_LIMIT ideal-int
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_GET = 535
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_GET ideal-int
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_LIMIT = 534
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_IOCTLS_LIMIT ideal-int
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_GET = 515
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_GET ideal-int
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_LIMIT = 533
-pkg syscall (freebsd-arm-cgo), const SYS_CAP_RIGHTS_LIMIT ideal-int
-pkg syscall (freebsd-arm-cgo), const SizeofBpfHdr = 24
-pkg syscall (freebsd-arm-cgo), const SizeofIfData = 88
-pkg syscall (freebsd-arm-cgo), const SizeofIfMsghdr = 104
-pkg syscall (freebsd-arm-cgo), const SizeofSockaddrDatalink = 56
-pkg syscall (freebsd-arm-cgo), const SizeofSockaddrUnix = 108
-pkg syscall (freebsd-arm-cgo), const TIOCTIMESTAMP = 1074558041
-pkg syscall (freebsd-arm-cgo), type BpfHdr struct, Pad_cgo_0 [2]uint8
-pkg syscall (freebsd-arm-cgo), type RawSockaddrDatalink struct, Pad_cgo_0 [2]uint8
-pkg syscall (freebsd-arm-cgo), type RawSockaddrUnix struct, Pad_cgo_0 [2]uint8
-pkg syscall (freebsd-arm-cgo), type Stat_t struct, Pad_cgo_0 [4]uint8
-pkg syscall (netbsd-arm), const SizeofIfData = 132
-pkg syscall (netbsd-arm), type IfMsghdr struct, Pad_cgo_1 [4]uint8
-pkg syscall (netbsd-arm-cgo), const SizeofIfData = 132
-pkg syscall (netbsd-arm-cgo), type IfMsghdr struct, Pad_cgo_1 [4]uint8
-pkg unicode, const Version = "6.3.0"
--- a/api/go1.1.txt
+++ b/api/go1.1.txt
--- a/api/go1.2.txt
+++ b/api/go1.2.txt
--- a/api/go1.3.txt
+++ b/api/go1.3.txt
--- a/api/go1.4.txt
+++ b/api/go1.4.txt
@@ -1,604 +0,0 @@
-# CL 134210043 archive/zip: add Writer.Flush, Brad Fitzpatrick <bradfitz@golang.org>
-pkg archive/zip, method (*Writer) Flush() error
-
-# CL 97140043 compress/flate: add Reset() to allow reusing large buffers to compress multiple buffers, James Robinson <jamesr@google.com>
-pkg compress/flate, type Resetter interface { Reset }
-pkg compress/flate, type Resetter interface, Reset(io.Reader, []uint8) error
-pkg compress/zlib, type Resetter interface { Reset }
-pkg compress/zlib, type Resetter interface, Reset(io.Reader, []uint8) error
-
-# CL 159120044 compress/gzip: allow stopping at end of first stream, Russ Cox <rsc@golang.org>
-pkg compress/gzip, method (*Reader) Multistream(bool)
-
-# CL 138800043 crypto: Add SHA3 functions in go.crypto/sha3 to the Hash enum., David Leon Gil <coruus@gmail.com>
-pkg crypto, const SHA3_224 = 10
-pkg crypto, const SHA3_224 Hash
-pkg crypto, const SHA3_256 = 11
-pkg crypto, const SHA3_256 Hash
-pkg crypto, const SHA3_384 = 12
-pkg crypto, const SHA3_384 Hash
-pkg crypto, const SHA3_512 = 13
-pkg crypto, const SHA3_512 Hash
-
-# CL 114680043 crypto: add Signer, Adam Langley <agl@golang.org>
-pkg crypto, method (Hash) HashFunc() Hash
-pkg crypto, type Signer interface { Public, Sign }
-pkg crypto, type Signer interface, Public() PublicKey
-pkg crypto, type Signer interface, Sign(io.Reader, []uint8, SignerOpts) ([]uint8, error)
-pkg crypto, type SignerOpts interface { HashFunc }
-pkg crypto, type SignerOpts interface, HashFunc() Hash
-pkg crypto/ecdsa, method (*PrivateKey) Public() crypto.PublicKey
-pkg crypto/ecdsa, method (*PrivateKey) Sign(io.Reader, []uint8, crypto.SignerOpts) ([]uint8, error)
-pkg crypto/rsa, method (*PSSOptions) HashFunc() crypto.Hash
-pkg crypto/rsa, method (*PrivateKey) Public() crypto.PublicKey
-pkg crypto/rsa, method (*PrivateKey) Sign(io.Reader, []uint8, crypto.SignerOpts) ([]uint8, error)
-pkg crypto/rsa, type PSSOptions struct, Hash crypto.Hash
-
-# CL 157090043 crypto/tls: support TLS_FALLBACK_SCSV as a server., Adam Langley <agl@golang.org>
-pkg crypto/tls, const TLS_FALLBACK_SCSV = 22016
-pkg crypto/tls, const TLS_FALLBACK_SCSV uint16
-
-# CL 107400043 crypto/tls: Added dynamic alternative to NameToCertificate map for SNI, Percy Wegmann <ox.to.a.cart@gmail.com>
-pkg crypto/tls, type ClientHelloInfo struct
-pkg crypto/tls, type ClientHelloInfo struct, CipherSuites []uint16
-pkg crypto/tls, type ClientHelloInfo struct, ServerName string
-pkg crypto/tls, type ClientHelloInfo struct, SupportedCurves []CurveID
-pkg crypto/tls, type ClientHelloInfo struct, SupportedPoints []uint8
-pkg crypto/tls, type Config struct, GetCertificate func(*ClientHelloInfo) (*Certificate, error)
-pkg crypto/tls, type ConnectionState struct, TLSUnique []uint8
-
-# CL 153420045 crypto/x509: continue to recognise MaxPathLen of zero as "no value"., Adam Langley <agl@golang.org>
-pkg crypto/x509, type Certificate struct, MaxPathLenZero bool
-
-# CL 158950043 database/sql: add Drivers, returning list of registered drivers, Russ Cox <rsc@golang.org>
-pkg database/sql, func Drivers() []string
-
-# CL 117280043 debug/dwarf: fix Reader panic on DW_TAG_unspecified_type, Derek Parker <parkerderek86@gmail.com>
-pkg debug/dwarf, method (*UnspecifiedType) Basic() *BasicType
-pkg debug/dwarf, method (*UnspecifiedType) Common() *CommonType
-pkg debug/dwarf, method (*UnspecifiedType) Size() int64
-pkg debug/dwarf, method (*UnspecifiedType) String() string
-pkg debug/dwarf, type UnspecifiedType struct
-pkg debug/dwarf, type UnspecifiedType struct, embedded BasicType
-
-# CL 132000043 debug/elf: support arm64 relocations, Michael Hudson-Doyle <michael.hudson@linaro.org>
-pkg debug/elf, const EM_AARCH64 = 183
-pkg debug/elf, const EM_AARCH64 Machine
-pkg debug/elf, const R_AARCH64_ABS16 = 259
-pkg debug/elf, const R_AARCH64_ABS16 R_AARCH64
-pkg debug/elf, const R_AARCH64_ABS32 = 258
-pkg debug/elf, const R_AARCH64_ABS32 R_AARCH64
-pkg debug/elf, const R_AARCH64_ABS64 = 257
-pkg debug/elf, const R_AARCH64_ABS64 R_AARCH64
-pkg debug/elf, const R_AARCH64_ADD_ABS_LO12_NC = 277
-pkg debug/elf, const R_AARCH64_ADD_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_ADR_GOT_PAGE = 311
-pkg debug/elf, const R_AARCH64_ADR_GOT_PAGE R_AARCH64
-pkg debug/elf, const R_AARCH64_ADR_PREL_LO21 = 274
-pkg debug/elf, const R_AARCH64_ADR_PREL_LO21 R_AARCH64
-pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21 = 275
-pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21 R_AARCH64
-pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21_NC = 276
-pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_CALL26 = 283
-pkg debug/elf, const R_AARCH64_CALL26 R_AARCH64
-pkg debug/elf, const R_AARCH64_CONDBR19 = 280
-pkg debug/elf, const R_AARCH64_CONDBR19 R_AARCH64
-pkg debug/elf, const R_AARCH64_COPY = 1024
-pkg debug/elf, const R_AARCH64_COPY R_AARCH64
-pkg debug/elf, const R_AARCH64_GLOB_DAT = 1025
-pkg debug/elf, const R_AARCH64_GLOB_DAT R_AARCH64
-pkg debug/elf, const R_AARCH64_GOT_LD_PREL19 = 309
-pkg debug/elf, const R_AARCH64_GOT_LD_PREL19 R_AARCH64
-pkg debug/elf, const R_AARCH64_IRELATIVE = 1032
-pkg debug/elf, const R_AARCH64_IRELATIVE R_AARCH64
-pkg debug/elf, const R_AARCH64_JUMP26 = 282
-pkg debug/elf, const R_AARCH64_JUMP26 R_AARCH64
-pkg debug/elf, const R_AARCH64_JUMP_SLOT = 1026
-pkg debug/elf, const R_AARCH64_JUMP_SLOT R_AARCH64
-pkg debug/elf, const R_AARCH64_LD64_GOT_LO12_NC = 312
-pkg debug/elf, const R_AARCH64_LD64_GOT_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_LDST128_ABS_LO12_NC = 299
-pkg debug/elf, const R_AARCH64_LDST128_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_LDST16_ABS_LO12_NC = 284
-pkg debug/elf, const R_AARCH64_LDST16_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_LDST32_ABS_LO12_NC = 285
-pkg debug/elf, const R_AARCH64_LDST32_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_LDST64_ABS_LO12_NC = 286
-pkg debug/elf, const R_AARCH64_LDST64_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_LDST8_ABS_LO12_NC = 278
-pkg debug/elf, const R_AARCH64_LDST8_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_LD_PREL_LO19 = 273
-pkg debug/elf, const R_AARCH64_LD_PREL_LO19 R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_SABS_G0 = 270
-pkg debug/elf, const R_AARCH64_MOVW_SABS_G0 R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_SABS_G1 = 271
-pkg debug/elf, const R_AARCH64_MOVW_SABS_G1 R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_SABS_G2 = 272
-pkg debug/elf, const R_AARCH64_MOVW_SABS_G2 R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G0 = 263
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G0 R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G0_NC = 264
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G0_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G1 = 265
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G1 R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G1_NC = 266
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G1_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G2 = 267
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G2 R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G2_NC = 268
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G2_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G3 = 269
-pkg debug/elf, const R_AARCH64_MOVW_UABS_G3 R_AARCH64
-pkg debug/elf, const R_AARCH64_NONE = 0
-pkg debug/elf, const R_AARCH64_NONE R_AARCH64
-pkg debug/elf, const R_AARCH64_NULL = 256
-pkg debug/elf, const R_AARCH64_NULL R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_ABS16 = 2
-pkg debug/elf, const R_AARCH64_P32_ABS16 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_ABS32 = 1
-pkg debug/elf, const R_AARCH64_P32_ABS32 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_ADD_ABS_LO12_NC = 12
-pkg debug/elf, const R_AARCH64_P32_ADD_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_ADR_GOT_PAGE = 26
-pkg debug/elf, const R_AARCH64_P32_ADR_GOT_PAGE R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_ADR_PREL_LO21 = 10
-pkg debug/elf, const R_AARCH64_P32_ADR_PREL_LO21 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_ADR_PREL_PG_HI21 = 11
-pkg debug/elf, const R_AARCH64_P32_ADR_PREL_PG_HI21 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_CALL26 = 21
-pkg debug/elf, const R_AARCH64_P32_CALL26 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_CONDBR19 = 19
-pkg debug/elf, const R_AARCH64_P32_CONDBR19 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_COPY = 180
-pkg debug/elf, const R_AARCH64_P32_COPY R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_GLOB_DAT = 181
-pkg debug/elf, const R_AARCH64_P32_GLOB_DAT R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_GOT_LD_PREL19 = 25
-pkg debug/elf, const R_AARCH64_P32_GOT_LD_PREL19 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_IRELATIVE = 188
-pkg debug/elf, const R_AARCH64_P32_IRELATIVE R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_JUMP26 = 20
-pkg debug/elf, const R_AARCH64_P32_JUMP26 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_JUMP_SLOT = 182
-pkg debug/elf, const R_AARCH64_P32_JUMP_SLOT R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_LD32_GOT_LO12_NC = 27
-pkg debug/elf, const R_AARCH64_P32_LD32_GOT_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_LDST128_ABS_LO12_NC = 17
-pkg debug/elf, const R_AARCH64_P32_LDST128_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_LDST16_ABS_LO12_NC = 14
-pkg debug/elf, const R_AARCH64_P32_LDST16_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_LDST32_ABS_LO12_NC = 15
-pkg debug/elf, const R_AARCH64_P32_LDST32_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_LDST64_ABS_LO12_NC = 16
-pkg debug/elf, const R_AARCH64_P32_LDST64_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_LDST8_ABS_LO12_NC = 13
-pkg debug/elf, const R_AARCH64_P32_LDST8_ABS_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_LD_PREL_LO19 = 9
-pkg debug/elf, const R_AARCH64_P32_LD_PREL_LO19 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_MOVW_SABS_G0 = 8
-pkg debug/elf, const R_AARCH64_P32_MOVW_SABS_G0 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0 = 5
-pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0_NC = 6
-pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G1 = 7
-pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G1 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_PREL16 = 4
-pkg debug/elf, const R_AARCH64_P32_PREL16 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_PREL32 = 3
-pkg debug/elf, const R_AARCH64_P32_PREL32 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_RELATIVE = 183
-pkg debug/elf, const R_AARCH64_P32_RELATIVE R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSDESC = 187
-pkg debug/elf, const R_AARCH64_P32_TLSDESC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADD_LO12_NC = 126
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADD_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PAGE21 = 124
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PAGE21 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PREL21 = 123
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PREL21 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_CALL = 127
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_CALL R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD32_LO12_NC = 125
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD32_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD_PREL19 = 122
-pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD_PREL19 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSGD_ADD_LO12_NC = 82
-pkg debug/elf, const R_AARCH64_P32_TLSGD_ADD_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSGD_ADR_PAGE21 = 81
-pkg debug/elf, const R_AARCH64_P32_TLSGD_ADR_PAGE21 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSIE_ADR_GOTTPREL_PAGE21 = 103
-pkg debug/elf, const R_AARCH64_P32_TLSIE_ADR_GOTTPREL_PAGE21 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC = 104
-pkg debug/elf, const R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSIE_LD_GOTTPREL_PREL19 = 105
-pkg debug/elf, const R_AARCH64_P32_TLSIE_LD_GOTTPREL_PREL19 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_HI12 = 109
-pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_HI12 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12 = 110
-pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12_NC = 111
-pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0 = 107
-pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0_NC = 108
-pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G1 = 106
-pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G1 R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLS_DTPMOD = 184
-pkg debug/elf, const R_AARCH64_P32_TLS_DTPMOD R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLS_DTPREL = 185
-pkg debug/elf, const R_AARCH64_P32_TLS_DTPREL R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TLS_TPREL = 186
-pkg debug/elf, const R_AARCH64_P32_TLS_TPREL R_AARCH64
-pkg debug/elf, const R_AARCH64_P32_TSTBR14 = 18
-pkg debug/elf, const R_AARCH64_P32_TSTBR14 R_AARCH64
-pkg debug/elf, const R_AARCH64_PREL16 = 262
-pkg debug/elf, const R_AARCH64_PREL16 R_AARCH64
-pkg debug/elf, const R_AARCH64_PREL32 = 261
-pkg debug/elf, const R_AARCH64_PREL32 R_AARCH64
-pkg debug/elf, const R_AARCH64_PREL64 = 260
-pkg debug/elf, const R_AARCH64_PREL64 R_AARCH64
-pkg debug/elf, const R_AARCH64_RELATIVE = 1027
-pkg debug/elf, const R_AARCH64_RELATIVE R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC = 1031
-pkg debug/elf, const R_AARCH64_TLSDESC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_ADD = 568
-pkg debug/elf, const R_AARCH64_TLSDESC_ADD R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_ADD_LO12_NC = 564
-pkg debug/elf, const R_AARCH64_TLSDESC_ADD_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PAGE21 = 562
-pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PAGE21 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PREL21 = 561
-pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PREL21 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_CALL = 569
-pkg debug/elf, const R_AARCH64_TLSDESC_CALL R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_LD64_LO12_NC = 563
-pkg debug/elf, const R_AARCH64_TLSDESC_LD64_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_LDR = 567
-pkg debug/elf, const R_AARCH64_TLSDESC_LDR R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_LD_PREL19 = 560
-pkg debug/elf, const R_AARCH64_TLSDESC_LD_PREL19 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G0_NC = 566
-pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G0_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G1 = 565
-pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G1 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSGD_ADD_LO12_NC = 514
-pkg debug/elf, const R_AARCH64_TLSGD_ADD_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSGD_ADR_PAGE21 = 513
-pkg debug/elf, const R_AARCH64_TLSGD_ADR_PAGE21 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 = 541
-pkg debug/elf, const R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC = 542
-pkg debug/elf, const R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 = 543
-pkg debug/elf, const R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G0_NC = 540
-pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G0_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G1 = 539
-pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G1 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_HI12 = 549
-pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_HI12 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12 = 550
-pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12_NC = 551
-pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0 = 547
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0_NC = 548
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1 = 545
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1_NC = 546
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1_NC R_AARCH64
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G2 = 544
-pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G2 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLS_DTPMOD64 = 1028
-pkg debug/elf, const R_AARCH64_TLS_DTPMOD64 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLS_DTPREL64 = 1029
-pkg debug/elf, const R_AARCH64_TLS_DTPREL64 R_AARCH64
-pkg debug/elf, const R_AARCH64_TLS_TPREL64 = 1030
-pkg debug/elf, const R_AARCH64_TLS_TPREL64 R_AARCH64
-pkg debug/elf, const R_AARCH64_TSTBR14 = 279
-pkg debug/elf, const R_AARCH64_TSTBR14 R_AARCH64
-pkg debug/elf, method (R_AARCH64) GoString() string
-pkg debug/elf, method (R_AARCH64) String() string
-pkg debug/elf, type R_AARCH64 int
-
-# CL 107530043 debug/elf: add (*File).DynamicSymbols, ErrNoSymbols, and tests for (*File).Symbols and (*File).DynamicSymbols, and formalize symbol order., Pietro Gagliardi <pietro10@mac.com>
-pkg debug/elf, method (*File) DynamicSymbols() ([]Symbol, error)
-pkg debug/elf, var ErrNoSymbols error
-
-# CL 106460044 debug/plan9obj, cmd/addr2line: on Plan 9 use a.out header, Aram Hăvărneanu <aram@mgk.ro>
-pkg debug/plan9obj, type FileHeader struct, HdrSize uint64
-pkg debug/plan9obj, type FileHeader struct, LoadAddress uint64
-
-# CL 122960043 encoding/xml: add InputOffset method to Decoder, Russ Cox <rsc@golang.org>
-pkg encoding/xml, method (*Decoder) InputOffset() int64
-
-# CL 124940043 cmd/go, go/build: implement import comment checking, Russ Cox <rsc@golang.org>
-pkg go/build, const ImportComment = 4
-pkg go/build, const ImportComment ImportMode
-pkg go/build, type Package struct, ImportComment string
-
-# CL 155050043 go/build: Return MultiplePackageError on importing a dir containing multiple packages, Jens Frederich <jfrederich@gmail.com>
-pkg go/build, method (*MultiplePackageError) Error() string
-pkg go/build, type MultiplePackageError struct
-pkg go/build, type MultiplePackageError struct, Dir string
-pkg go/build, type MultiplePackageError struct, Files []string
-pkg go/build, type MultiplePackageError struct, Packages []string
-
-# CL 135110044 go/token: implement PositionFor accessors, Robert Griesemer <gri@golang.org>
-pkg go/token, method (*File) PositionFor(Pos, bool) Position
-pkg go/token, method (*FileSet) PositionFor(Pos, bool) Position
-
-# CL 109000049 image: add RGBAAt, Gray16At, etc., ChaiShushan <chaishushan@gmail.com>
-pkg image, method (*Alpha) AlphaAt(int, int) color.Alpha
-pkg image, method (*Alpha16) Alpha16At(int, int) color.Alpha16
-pkg image, method (*Gray) GrayAt(int, int) color.Gray
-pkg image, method (*Gray16) Gray16At(int, int) color.Gray16
-pkg image, method (*NRGBA) NRGBAAt(int, int) color.NRGBA
-pkg image, method (*NRGBA64) NRGBA64At(int, int) color.NRGBA64
-pkg image, method (*RGBA) RGBAAt(int, int) color.RGBA
-pkg image, method (*RGBA64) RGBA64At(int, int) color.RGBA64
-pkg image, method (*YCbCr) YCbCrAt(int, int) color.YCbCr
-
-# CL 129190043 png: make the encoder configurable, Jeff R. Allen <jra@nella.org>
-pkg image/png, const BestCompression = -3
-pkg image/png, const BestCompression CompressionLevel
-pkg image/png, const BestSpeed = -2
-pkg image/png, const BestSpeed CompressionLevel
-pkg image/png, const DefaultCompression = 0
-pkg image/png, const DefaultCompression CompressionLevel
-pkg image/png, const NoCompression = -1
-pkg image/png, const NoCompression CompressionLevel
-pkg image/png, method (*Encoder) Encode(io.Writer, image.Image) error
-pkg image/png, type CompressionLevel int
-pkg image/png, type Encoder struct
-pkg image/png, type Encoder struct, CompressionLevel CompressionLevel
-
-# CL 101750048 math: implement Nextafter32, Robert Griesemer <gri@golang.org>
-pkg math, func Nextafter32(float32, float32) float32
-
-# CL 93550043 math/big: implement Rat.Float32, Robert Griesemer <gri@golang.org>
-pkg math/big, method (*Rat) Float32() (float32, bool)
-
-# CL 76540043 net/http: add BasicAuth method to *http.Request, Kelsey Hightower <kelsey.hightower@gmail.com>
-pkg net/http, method (*Request) BasicAuth() (string, string, bool)
-
-# CL 137940043 net/http: add Transport.DialTLS hook, Brad Fitzpatrick <bradfitz@golang.org>
-pkg net/http, type Transport struct, DialTLS func(string, string) (net.Conn, error)
-
-# CL 132750043 net/http/httputil: Pass a Logger to ReverseProxy, allowing the user to control logging., Mark Theunissen <mark.theunissen@gmail.com>
-pkg net/http/httputil, type ReverseProxy struct, ErrorLog *log.Logger
-
-# CL 148370043 os, syscall: add Unsetenv, Brad Fitzpatrick <bradfitz@golang.org>
-pkg os, func Unsetenv(string) error
-pkg syscall, func Unsetenv(string) error
-
-# CL 144020043 reflect: add Type.Comparable, Russ Cox <rsc@golang.org>
-pkg reflect, type Type interface, Comparable() bool
-
-# CL 153670043 runtime: add PauseEnd array to MemStats and GCStats, Jens Frederich <jfrederich@gmail.com>
-pkg runtime, type MemStats struct, PauseEnd [256]uint64
-pkg runtime/debug, type GCStats struct, PauseEnd []time.Time
-
-# CL 136710045 sync/atomic: add Value, Dmitriy Vyukov <dvyukov@google.com>
-pkg sync/atomic, method (*Value) Load() interface{}
-pkg sync/atomic, method (*Value) Store(interface{})
-pkg sync/atomic, type Value struct
-
-# CL 126190043 syscall: support UID/GID map files for Linux user namespaces, Mrunal Patel <mrunalp@gmail.com>
-pkg syscall (linux-386), type SysProcAttr struct, GidMappings []SysProcIDMap
-pkg syscall (linux-386), type SysProcAttr struct, UidMappings []SysProcIDMap
-pkg syscall (linux-386), type SysProcIDMap struct
-pkg syscall (linux-386), type SysProcIDMap struct, ContainerID int
-pkg syscall (linux-386), type SysProcIDMap struct, HostID int
-pkg syscall (linux-386), type SysProcIDMap struct, Size int
-pkg syscall (linux-386-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
-pkg syscall (linux-386-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
-pkg syscall (linux-386-cgo), type SysProcIDMap struct
-pkg syscall (linux-386-cgo), type SysProcIDMap struct, ContainerID int
-pkg syscall (linux-386-cgo), type SysProcIDMap struct, HostID int
-pkg syscall (linux-386-cgo), type SysProcIDMap struct, Size int
-pkg syscall (linux-amd64), type SysProcAttr struct, GidMappings []SysProcIDMap
-pkg syscall (linux-amd64), type SysProcAttr struct, UidMappings []SysProcIDMap
-pkg syscall (linux-amd64), type SysProcIDMap struct
-pkg syscall (linux-amd64), type SysProcIDMap struct, ContainerID int
-pkg syscall (linux-amd64), type SysProcIDMap struct, HostID int
-pkg syscall (linux-amd64), type SysProcIDMap struct, Size int
-pkg syscall (linux-amd64-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
-pkg syscall (linux-amd64-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
-pkg syscall (linux-amd64-cgo), type SysProcIDMap struct
-pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, ContainerID int
-pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, HostID int
-pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, Size int
-pkg syscall (linux-arm), type SysProcAttr struct, GidMappings []SysProcIDMap
-pkg syscall (linux-arm), type SysProcAttr struct, UidMappings []SysProcIDMap
-pkg syscall (linux-arm), type SysProcIDMap struct
-pkg syscall (linux-arm), type SysProcIDMap struct, ContainerID int
-pkg syscall (linux-arm), type SysProcIDMap struct, HostID int
-pkg syscall (linux-arm), type SysProcIDMap struct, Size int
-pkg syscall (linux-arm-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
-pkg syscall (linux-arm-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
-pkg syscall (linux-arm-cgo), type SysProcIDMap struct
-pkg syscall (linux-arm-cgo), type SysProcIDMap struct, ContainerID int
-pkg syscall (linux-arm-cgo), type SysProcIDMap struct, HostID int
-pkg syscall (linux-arm-cgo), type SysProcIDMap struct, Size int
-
-# CL 122200043 net: fix CNAME resolving on Windows, Egon Elbre <egonelbre@gmail.com>
-pkg syscall (windows-386), const DNS_INFO_NO_RECORDS = 9501
-pkg syscall (windows-386), const DNS_INFO_NO_RECORDS ideal-int
-pkg syscall (windows-386), const DnsSectionAdditional = 3
-pkg syscall (windows-386), const DnsSectionAdditional ideal-int
-pkg syscall (windows-386), const DnsSectionAnswer = 1
-pkg syscall (windows-386), const DnsSectionAnswer ideal-int
-pkg syscall (windows-386), const DnsSectionAuthority = 2
-pkg syscall (windows-386), const DnsSectionAuthority ideal-int
-pkg syscall (windows-386), const DnsSectionQuestion = 0
-pkg syscall (windows-386), const DnsSectionQuestion ideal-int
-pkg syscall (windows-386), func DnsNameCompare(*uint16, *uint16) bool
-pkg syscall (windows-amd64), const DNS_INFO_NO_RECORDS = 9501
-pkg syscall (windows-amd64), const DNS_INFO_NO_RECORDS ideal-int
-pkg syscall (windows-amd64), const DnsSectionAdditional = 3
-pkg syscall (windows-amd64), const DnsSectionAdditional ideal-int
-pkg syscall (windows-amd64), const DnsSectionAnswer = 1
-pkg syscall (windows-amd64), const DnsSectionAnswer ideal-int
-pkg syscall (windows-amd64), const DnsSectionAuthority = 2
-pkg syscall (windows-amd64), const DnsSectionAuthority ideal-int
-pkg syscall (windows-amd64), const DnsSectionQuestion = 0
-pkg syscall (windows-amd64), const DnsSectionQuestion ideal-int
-pkg syscall (windows-amd64), func DnsNameCompare(*uint16, *uint16) bool
-
-# CL 86160044 os: Implement symlink support for Windows, Michael Fraenkel <michael.fraenkel@gmail.com>
-pkg syscall (windows-386), const ERROR_PRIVILEGE_NOT_HELD = 1314
-pkg syscall (windows-386), const ERROR_PRIVILEGE_NOT_HELD Errno
-pkg syscall (windows-amd64), const ERROR_PRIVILEGE_NOT_HELD = 1314
-pkg syscall (windows-amd64), const ERROR_PRIVILEGE_NOT_HELD Errno
-
-# CL 86160044 os: Implement symlink support for Windows, Michael Fraenkel <michael.fraenkel@gmail.com>
-pkg syscall (windows-386), const FILE_ATTRIBUTE_REPARSE_POINT = 1024
-pkg syscall (windows-386), const FILE_ATTRIBUTE_REPARSE_POINT ideal-int
-pkg syscall (windows-386), const FILE_FLAG_OPEN_REPARSE_POINT = 2097152
-pkg syscall (windows-386), const FILE_FLAG_OPEN_REPARSE_POINT ideal-int
-pkg syscall (windows-386), const FSCTL_GET_REPARSE_POINT = 589992
-pkg syscall (windows-386), const FSCTL_GET_REPARSE_POINT ideal-int
-pkg syscall (windows-386), const IO_REPARSE_TAG_SYMLINK = 2684354572
-pkg syscall (windows-386), const IO_REPARSE_TAG_SYMLINK ideal-int
-pkg syscall (windows-386), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE = 16384
-pkg syscall (windows-386), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE ideal-int
-pkg syscall (windows-386), const SYMBOLIC_LINK_FLAG_DIRECTORY = 1
-pkg syscall (windows-386), const SYMBOLIC_LINK_FLAG_DIRECTORY ideal-int
-pkg syscall (windows-386), func CreateHardLink(*uint16, *uint16, uintptr) error
-pkg syscall (windows-386), func CreateSymbolicLink(*uint16, *uint16, uint32) error
-pkg syscall (windows-386), func DeviceIoControl(Handle, uint32, *uint8, uint32, *uint8, uint32, *uint32, *Overlapped) error
-pkg syscall (windows-386), func LoadCreateSymbolicLink() error
-pkg syscall (windows-amd64), const FILE_ATTRIBUTE_REPARSE_POINT = 1024
-pkg syscall (windows-amd64), const FILE_ATTRIBUTE_REPARSE_POINT ideal-int
-pkg syscall (windows-amd64), const FILE_FLAG_OPEN_REPARSE_POINT = 2097152
-pkg syscall (windows-amd64), const FILE_FLAG_OPEN_REPARSE_POINT ideal-int
-pkg syscall (windows-amd64), const FSCTL_GET_REPARSE_POINT = 589992
-pkg syscall (windows-amd64), const FSCTL_GET_REPARSE_POINT ideal-int
-pkg syscall (windows-amd64), const IO_REPARSE_TAG_SYMLINK = 2684354572
-pkg syscall (windows-amd64), const IO_REPARSE_TAG_SYMLINK ideal-int
-pkg syscall (windows-amd64), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE = 16384
-pkg syscall (windows-amd64), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE ideal-int
-pkg syscall (windows-amd64), const SYMBOLIC_LINK_FLAG_DIRECTORY = 1
-pkg syscall (windows-amd64), const SYMBOLIC_LINK_FLAG_DIRECTORY ideal-int
-pkg syscall (windows-amd64), func CreateHardLink(*uint16, *uint16, uintptr) error
-pkg syscall (windows-amd64), func CreateSymbolicLink(*uint16, *uint16, uint32) error
-pkg syscall (windows-amd64), func DeviceIoControl(Handle, uint32, *uint8, uint32, *uint8, uint32, *uint32, *Overlapped) error
-pkg syscall (windows-amd64), func LoadCreateSymbolicLink() error
-
-# CL 149510043 net: disable SIO_UDP_CONNRESET behavior on windows., Ron Hashimoto <mail@h2so5.net>
-pkg syscall (windows-386), const SIO_UDP_CONNRESET = 2550136844
-pkg syscall (windows-386), const SIO_UDP_CONNRESET ideal-int
-pkg syscall (windows-amd64), const SIO_UDP_CONNRESET = 2550136844
-pkg syscall (windows-amd64), const SIO_UDP_CONNRESET ideal-int
-
-# CL 102320044 syscall: implement syscall.Getppid() on Windows, Alan Shreve <alan@inconshreveable.com>
-pkg syscall (windows-386), const TH32CS_INHERIT = 2147483648
-pkg syscall (windows-386), const TH32CS_INHERIT ideal-int
-pkg syscall (windows-386), const TH32CS_SNAPALL = 15
-pkg syscall (windows-386), const TH32CS_SNAPALL ideal-int
-pkg syscall (windows-386), const TH32CS_SNAPHEAPLIST = 1
-pkg syscall (windows-386), const TH32CS_SNAPHEAPLIST ideal-int
-pkg syscall (windows-386), const TH32CS_SNAPMODULE = 8
-pkg syscall (windows-386), const TH32CS_SNAPMODULE ideal-int
-pkg syscall (windows-386), const TH32CS_SNAPMODULE32 = 16
-pkg syscall (windows-386), const TH32CS_SNAPMODULE32 ideal-int
-pkg syscall (windows-386), const TH32CS_SNAPPROCESS = 2
-pkg syscall (windows-386), const TH32CS_SNAPPROCESS ideal-int
-pkg syscall (windows-386), const TH32CS_SNAPTHREAD = 4
-pkg syscall (windows-386), const TH32CS_SNAPTHREAD ideal-int
-pkg syscall (windows-386), func CreateToolhelp32Snapshot(uint32, uint32) (Handle, error)
-pkg syscall (windows-386), func Process32First(Handle, *ProcessEntry32) error
-pkg syscall (windows-386), func Process32Next(Handle, *ProcessEntry32) error
-pkg syscall (windows-386), type ProcessEntry32 struct
-pkg syscall (windows-386), type ProcessEntry32 struct, DefaultHeapID uintptr
-pkg syscall (windows-386), type ProcessEntry32 struct, ExeFile [260]uint16
-pkg syscall (windows-386), type ProcessEntry32 struct, Flags uint32
-pkg syscall (windows-386), type ProcessEntry32 struct, ModuleID uint32
-pkg syscall (windows-386), type ProcessEntry32 struct, ParentProcessID uint32
-pkg syscall (windows-386), type ProcessEntry32 struct, PriClassBase int32
-pkg syscall (windows-386), type ProcessEntry32 struct, ProcessID uint32
-pkg syscall (windows-386), type ProcessEntry32 struct, Size uint32
-pkg syscall (windows-386), type ProcessEntry32 struct, Threads uint32
-pkg syscall (windows-386), type ProcessEntry32 struct, Usage uint32
-pkg syscall (windows-amd64), const TH32CS_INHERIT = 2147483648
-pkg syscall (windows-amd64), const TH32CS_INHERIT ideal-int
-pkg syscall (windows-amd64), const TH32CS_SNAPALL = 15
-pkg syscall (windows-amd64), const TH32CS_SNAPALL ideal-int
-pkg syscall (windows-amd64), const TH32CS_SNAPHEAPLIST = 1
-pkg syscall (windows-amd64), const TH32CS_SNAPHEAPLIST ideal-int
-pkg syscall (windows-amd64), const TH32CS_SNAPMODULE = 8
-pkg syscall (windows-amd64), const TH32CS_SNAPMODULE ideal-int
-pkg syscall (windows-amd64), const TH32CS_SNAPMODULE32 = 16
-pkg syscall (windows-amd64), const TH32CS_SNAPMODULE32 ideal-int
-pkg syscall (windows-amd64), const TH32CS_SNAPPROCESS = 2
-pkg syscall (windows-amd64), const TH32CS_SNAPPROCESS ideal-int
-pkg syscall (windows-amd64), const TH32CS_SNAPTHREAD = 4
-pkg syscall (windows-amd64), const TH32CS_SNAPTHREAD ideal-int
-pkg syscall (windows-amd64), func CreateToolhelp32Snapshot(uint32, uint32) (Handle, error)
-pkg syscall (windows-amd64), func Process32First(Handle, *ProcessEntry32) error
-pkg syscall (windows-amd64), func Process32Next(Handle, *ProcessEntry32) error
-pkg syscall (windows-amd64), type ProcessEntry32 struct
-pkg syscall (windows-amd64), type ProcessEntry32 struct, DefaultHeapID uintptr
-pkg syscall (windows-amd64), type ProcessEntry32 struct, ExeFile [260]uint16
-pkg syscall (windows-amd64), type ProcessEntry32 struct, Flags uint32
-pkg syscall (windows-amd64), type ProcessEntry32 struct, ModuleID uint32
-pkg syscall (windows-amd64), type ProcessEntry32 struct, ParentProcessID uint32
-pkg syscall (windows-amd64), type ProcessEntry32 struct, PriClassBase int32
-pkg syscall (windows-amd64), type ProcessEntry32 struct, ProcessID uint32
-pkg syscall (windows-amd64), type ProcessEntry32 struct, Size uint32
-pkg syscall (windows-amd64), type ProcessEntry32 struct, Threads uint32
-pkg syscall (windows-amd64), type ProcessEntry32 struct, Usage uint32
-
-# CL 127740043 os: make SameFile handle paths like c:a.txt properly, Alex Brainman <alex.brainman@gmail.com>
-pkg syscall (windows-386), func FullPath(string) (string, error)
-pkg syscall (windows-amd64), func FullPath(string) (string, error)
-
-# CL 98150043 testing: add Coverage function, Russ Cox <rsc@golang.org>
-pkg testing, func Coverage() float64
-
-# CL 148770043 cmd/go, testing: add TestMain support, Russ Cox <rsc@golang.org>
-pkg testing, func MainStart(func(string, string) (bool, error), []InternalTest, []InternalBenchmark, []InternalExample) *M
-pkg testing, method (*M) Run() int
-pkg testing, type M struct
-
-# CL 108030044 text/scanner: provide facility for custom identifiers, Robert Griesemer <gri@golang.org>
-pkg text/scanner, type Scanner struct, IsIdentRune func(int32, int) bool
-
-# CL 130620043 text/template: add back pointer to Nodes for better error generation, Rob Pike <r@golang.org>
-pkg text/template/parse, type DotNode struct, embedded NodeType
-pkg text/template/parse, type NilNode struct, embedded NodeType
-pkg text/template/parse, method (*BranchNode) Copy() Node
-pkg text/template/parse, method (*IdentifierNode) SetTree(*Tree) *IdentifierNode
-pkg html/template, type Error struct, Node parse.Node
-
-# CL 127470043 unicode: strconv: regexp: Upgrade to Unicode 7.0.0., Marcel van Lohuizen <mpvl@golang.org>
-pkg unicode, const Version = "7.0.0"
-pkg unicode, var Bassa_Vah *RangeTable
-pkg unicode, var Caucasian_Albanian *RangeTable
-pkg unicode, var Duployan *RangeTable
-pkg unicode, var Elbasan *RangeTable
-pkg unicode, var Grantha *RangeTable
-pkg unicode, var Khojki *RangeTable
-pkg unicode, var Khudawadi *RangeTable
-pkg unicode, var Linear_A *RangeTable
-pkg unicode, var Mahajani *RangeTable
-pkg unicode, var Manichaean *RangeTable
-pkg unicode, var Mende_Kikakui *RangeTable
-pkg unicode, var Modi *RangeTable
-pkg unicode, var Mro *RangeTable
-pkg unicode, var Nabataean *RangeTable
-pkg unicode, var Old_North_Arabian *RangeTable
-pkg unicode, var Old_Permic *RangeTable
-pkg unicode, var Pahawh_Hmong *RangeTable
-pkg unicode, var Palmyrene *RangeTable
-pkg unicode, var Pau_Cin_Hau *RangeTable
-pkg unicode, var Psalter_Pahlavi *RangeTable
-pkg unicode, var Siddham *RangeTable
-pkg unicode, var Tirhuta *RangeTable
-pkg unicode, var Warang_Citi *RangeTable
--- a/api/go1.txt
+++ b/api/go1.txt
--- a/api/next.txt
+++ b/api/next.txt
@@ -1,249 +1,428 @@
-pkg debug/elf, const R_PPC64_ADDR14 = 7
-pkg debug/elf, const R_PPC64_ADDR14 R_PPC64
-pkg debug/elf, const R_PPC64_ADDR14_BRNTAKEN = 9
-pkg debug/elf, const R_PPC64_ADDR14_BRNTAKEN R_PPC64
-pkg debug/elf, const R_PPC64_ADDR14_BRTAKEN = 8
-pkg debug/elf, const R_PPC64_ADDR14_BRTAKEN R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16 = 3
-pkg debug/elf, const R_PPC64_ADDR16 R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_DS = 56
-pkg debug/elf, const R_PPC64_ADDR16_DS R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_HA = 6
-pkg debug/elf, const R_PPC64_ADDR16_HA R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_HI = 5
-pkg debug/elf, const R_PPC64_ADDR16_HI R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_HIGHER = 39
-pkg debug/elf, const R_PPC64_ADDR16_HIGHER R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_HIGHERA = 40
-pkg debug/elf, const R_PPC64_ADDR16_HIGHERA R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_HIGHEST = 41
-pkg debug/elf, const R_PPC64_ADDR16_HIGHEST R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_HIGHESTA = 42
-pkg debug/elf, const R_PPC64_ADDR16_HIGHESTA R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_LO = 4
-pkg debug/elf, const R_PPC64_ADDR16_LO R_PPC64
-pkg debug/elf, const R_PPC64_ADDR16_LO_DS = 57
-pkg debug/elf, const R_PPC64_ADDR16_LO_DS R_PPC64
-pkg debug/elf, const R_PPC64_ADDR24 = 2
-pkg debug/elf, const R_PPC64_ADDR24 R_PPC64
-pkg debug/elf, const R_PPC64_ADDR32 = 1
-pkg debug/elf, const R_PPC64_ADDR32 R_PPC64
-pkg debug/elf, const R_PPC64_ADDR64 = 38
-pkg debug/elf, const R_PPC64_ADDR64 R_PPC64
-pkg debug/elf, const R_PPC64_DTPMOD64 = 68
-pkg debug/elf, const R_PPC64_DTPMOD64 R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16 = 74
-pkg debug/elf, const R_PPC64_DTPREL16 R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_DS = 101
-pkg debug/elf, const R_PPC64_DTPREL16_DS R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_HA = 77
-pkg debug/elf, const R_PPC64_DTPREL16_HA R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_HI = 76
-pkg debug/elf, const R_PPC64_DTPREL16_HI R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHER = 103
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHER R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHERA = 104
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHERA R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHEST = 105
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHEST R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHESTA = 106
-pkg debug/elf, const R_PPC64_DTPREL16_HIGHESTA R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_LO = 75
-pkg debug/elf, const R_PPC64_DTPREL16_LO R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL16_LO_DS = 102
-pkg debug/elf, const R_PPC64_DTPREL16_LO_DS R_PPC64
-pkg debug/elf, const R_PPC64_DTPREL64 = 78
-pkg debug/elf, const R_PPC64_DTPREL64 R_PPC64
-pkg debug/elf, const R_PPC64_GOT16 = 14
-pkg debug/elf, const R_PPC64_GOT16 R_PPC64
-pkg debug/elf, const R_PPC64_GOT16_DS = 58
-pkg debug/elf, const R_PPC64_GOT16_DS R_PPC64
-pkg debug/elf, const R_PPC64_GOT16_HA = 17
-pkg debug/elf, const R_PPC64_GOT16_HA R_PPC64
-pkg debug/elf, const R_PPC64_GOT16_HI = 16
-pkg debug/elf, const R_PPC64_GOT16_HI R_PPC64
-pkg debug/elf, const R_PPC64_GOT16_LO = 15
-pkg debug/elf, const R_PPC64_GOT16_LO R_PPC64
-pkg debug/elf, const R_PPC64_GOT16_LO_DS = 59
-pkg debug/elf, const R_PPC64_GOT16_LO_DS R_PPC64
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_DS = 91
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_DS R_PPC64
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_HA = 94
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_HA R_PPC64
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_HI = 93
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_HI R_PPC64
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_LO_DS = 92
-pkg debug/elf, const R_PPC64_GOT_DTPREL16_LO_DS R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSGD16 = 79
-pkg debug/elf, const R_PPC64_GOT_TLSGD16 R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSGD16_HA = 82
-pkg debug/elf, const R_PPC64_GOT_TLSGD16_HA R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSGD16_HI = 81
-pkg debug/elf, const R_PPC64_GOT_TLSGD16_HI R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSGD16_LO = 80
-pkg debug/elf, const R_PPC64_GOT_TLSGD16_LO R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSLD16 = 83
-pkg debug/elf, const R_PPC64_GOT_TLSLD16 R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSLD16_HA = 86
-pkg debug/elf, const R_PPC64_GOT_TLSLD16_HA R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSLD16_HI = 85
-pkg debug/elf, const R_PPC64_GOT_TLSLD16_HI R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TLSLD16_LO = 84
-pkg debug/elf, const R_PPC64_GOT_TLSLD16_LO R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TPREL16_DS = 87
-pkg debug/elf, const R_PPC64_GOT_TPREL16_DS R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TPREL16_HA = 90
-pkg debug/elf, const R_PPC64_GOT_TPREL16_HA R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TPREL16_HI = 89
-pkg debug/elf, const R_PPC64_GOT_TPREL16_HI R_PPC64
-pkg debug/elf, const R_PPC64_GOT_TPREL16_LO_DS = 88
-pkg debug/elf, const R_PPC64_GOT_TPREL16_LO_DS R_PPC64
-pkg debug/elf, const R_PPC64_JMP_SLOT = 21
-pkg debug/elf, const R_PPC64_JMP_SLOT R_PPC64
-pkg debug/elf, const R_PPC64_NONE = 0
-pkg debug/elf, const R_PPC64_NONE R_PPC64
-pkg debug/elf, const R_PPC64_REL14 = 11
-pkg debug/elf, const R_PPC64_REL14 R_PPC64
-pkg debug/elf, const R_PPC64_REL14_BRNTAKEN = 13
-pkg debug/elf, const R_PPC64_REL14_BRNTAKEN R_PPC64
-pkg debug/elf, const R_PPC64_REL14_BRTAKEN = 12
-pkg debug/elf, const R_PPC64_REL14_BRTAKEN R_PPC64
-pkg debug/elf, const R_PPC64_REL16 = 249
-pkg debug/elf, const R_PPC64_REL16 R_PPC64
-pkg debug/elf, const R_PPC64_REL16_HA = 252
-pkg debug/elf, const R_PPC64_REL16_HA R_PPC64
-pkg debug/elf, const R_PPC64_REL16_HI = 251
-pkg debug/elf, const R_PPC64_REL16_HI R_PPC64
-pkg debug/elf, const R_PPC64_REL16_LO = 250
-pkg debug/elf, const R_PPC64_REL16_LO R_PPC64
-pkg debug/elf, const R_PPC64_REL24 = 10
-pkg debug/elf, const R_PPC64_REL24 R_PPC64
-pkg debug/elf, const R_PPC64_REL32 = 26
-pkg debug/elf, const R_PPC64_REL32 R_PPC64
-pkg debug/elf, const R_PPC64_REL64 = 44
-pkg debug/elf, const R_PPC64_REL64 R_PPC64
-pkg debug/elf, const R_PPC64_TLS = 67
-pkg debug/elf, const R_PPC64_TLS R_PPC64
-pkg debug/elf, const R_PPC64_TLSGD = 107
-pkg debug/elf, const R_PPC64_TLSGD R_PPC64
-pkg debug/elf, const R_PPC64_TLSLD = 108
-pkg debug/elf, const R_PPC64_TLSLD R_PPC64
-pkg debug/elf, const R_PPC64_TOC = 51
-pkg debug/elf, const R_PPC64_TOC R_PPC64
-pkg debug/elf, const R_PPC64_TOC16 = 47
-pkg debug/elf, const R_PPC64_TOC16 R_PPC64
-pkg debug/elf, const R_PPC64_TOC16_DS = 63
-pkg debug/elf, const R_PPC64_TOC16_DS R_PPC64
-pkg debug/elf, const R_PPC64_TOC16_HA = 50
-pkg debug/elf, const R_PPC64_TOC16_HA R_PPC64
-pkg debug/elf, const R_PPC64_TOC16_HI = 49
-pkg debug/elf, const R_PPC64_TOC16_HI R_PPC64
-pkg debug/elf, const R_PPC64_TOC16_LO = 48
-pkg debug/elf, const R_PPC64_TOC16_LO R_PPC64
-pkg debug/elf, const R_PPC64_TOC16_LO_DS = 64
-pkg debug/elf, const R_PPC64_TOC16_LO_DS R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16 = 69
-pkg debug/elf, const R_PPC64_TPREL16 R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_DS = 95
-pkg debug/elf, const R_PPC64_TPREL16_DS R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_HA = 72
-pkg debug/elf, const R_PPC64_TPREL16_HA R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_HI = 71
-pkg debug/elf, const R_PPC64_TPREL16_HI R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_HIGHER = 97
-pkg debug/elf, const R_PPC64_TPREL16_HIGHER R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_HIGHERA = 98
-pkg debug/elf, const R_PPC64_TPREL16_HIGHERA R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_HIGHEST = 99
-pkg debug/elf, const R_PPC64_TPREL16_HIGHEST R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_HIGHESTA = 100
-pkg debug/elf, const R_PPC64_TPREL16_HIGHESTA R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_LO = 70
-pkg debug/elf, const R_PPC64_TPREL16_LO R_PPC64
-pkg debug/elf, const R_PPC64_TPREL16_LO_DS = 96
-pkg debug/elf, const R_PPC64_TPREL16_LO_DS R_PPC64
-pkg debug/elf, const R_PPC64_TPREL64 = 73
-pkg debug/elf, const R_PPC64_TPREL64 R_PPC64
-pkg debug/elf, method (R_PPC64) GoString() string
-pkg debug/elf, method (R_PPC64) String() string
-pkg debug/elf, type R_PPC64 int
-pkg runtime (openbsd-386), const CLOCK_MONOTONIC = 3
-pkg runtime (openbsd-386), const CLOCK_MONOTONIC ideal-int
-pkg runtime (openbsd-386), const CLOCK_PROF = 2
-pkg runtime (openbsd-386), const CLOCK_PROF ideal-int
-pkg runtime (openbsd-386), const CLOCK_REALTIME = 0
-pkg runtime (openbsd-386), const CLOCK_REALTIME ideal-int
-pkg runtime (openbsd-386), const CLOCK_VIRTUAL = 1
-pkg runtime (openbsd-386), const CLOCK_VIRTUAL ideal-int
-pkg runtime (openbsd-386), const CTL_HW = 6
-pkg runtime (openbsd-386), const CTL_HW ideal-int
-pkg runtime (openbsd-386), const EAGAIN = 35
-pkg runtime (openbsd-386), const EAGAIN ideal-int
-pkg runtime (openbsd-386), const ENOTSUP = 91
-pkg runtime (openbsd-386), const ENOTSUP ideal-int
-pkg runtime (openbsd-386), const ESRCH = 3
-pkg runtime (openbsd-386), const ESRCH ideal-int
-pkg runtime (openbsd-386), const EWOULDBLOCK = 35
-pkg runtime (openbsd-386), const EWOULDBLOCK ideal-int
-pkg runtime (openbsd-386), const HW_NCPU = 3
-pkg runtime (openbsd-386), const HW_NCPU ideal-int
-pkg runtime (openbsd-386-cgo), const CLOCK_MONOTONIC = 3
-pkg runtime (openbsd-386-cgo), const CLOCK_MONOTONIC ideal-int
-pkg runtime (openbsd-386-cgo), const CLOCK_PROF = 2
-pkg runtime (openbsd-386-cgo), const CLOCK_PROF ideal-int
-pkg runtime (openbsd-386-cgo), const CLOCK_REALTIME = 0
-pkg runtime (openbsd-386-cgo), const CLOCK_REALTIME ideal-int
-pkg runtime (openbsd-386-cgo), const CLOCK_VIRTUAL = 1
-pkg runtime (openbsd-386-cgo), const CLOCK_VIRTUAL ideal-int
-pkg runtime (openbsd-386-cgo), const CTL_HW = 6
-pkg runtime (openbsd-386-cgo), const CTL_HW ideal-int
-pkg runtime (openbsd-386-cgo), const EAGAIN = 35
-pkg runtime (openbsd-386-cgo), const EAGAIN ideal-int
-pkg runtime (openbsd-386-cgo), const ENOTSUP = 91
-pkg runtime (openbsd-386-cgo), const ENOTSUP ideal-int
-pkg runtime (openbsd-386-cgo), const ESRCH = 3
-pkg runtime (openbsd-386-cgo), const ESRCH ideal-int
-pkg runtime (openbsd-386-cgo), const EWOULDBLOCK = 35
-pkg runtime (openbsd-386-cgo), const EWOULDBLOCK ideal-int
-pkg runtime (openbsd-386-cgo), const HW_NCPU = 3
-pkg runtime (openbsd-386-cgo), const HW_NCPU ideal-int
-pkg runtime (openbsd-amd64), const CLOCK_MONOTONIC = 3
-pkg runtime (openbsd-amd64), const CLOCK_MONOTONIC ideal-int
-pkg runtime (openbsd-amd64), const CLOCK_PROF = 2
-pkg runtime (openbsd-amd64), const CLOCK_PROF ideal-int
-pkg runtime (openbsd-amd64), const CLOCK_REALTIME = 0
-pkg runtime (openbsd-amd64), const CLOCK_REALTIME ideal-int
-pkg runtime (openbsd-amd64), const CLOCK_VIRTUAL = 1
-pkg runtime (openbsd-amd64), const CLOCK_VIRTUAL ideal-int
-pkg runtime (openbsd-amd64), const CTL_HW = 6
-pkg runtime (openbsd-amd64), const CTL_HW ideal-int
-pkg runtime (openbsd-amd64), const EAGAIN = 35
-pkg runtime (openbsd-amd64), const EAGAIN ideal-int
-pkg runtime (openbsd-amd64), const ENOTSUP = 91
-pkg runtime (openbsd-amd64), const ENOTSUP ideal-int
-pkg runtime (openbsd-amd64), const ESRCH = 3
-pkg runtime (openbsd-amd64), const ESRCH ideal-int
-pkg runtime (openbsd-amd64), const EWOULDBLOCK = 35
-pkg runtime (openbsd-amd64), const EWOULDBLOCK ideal-int
-pkg runtime (openbsd-amd64), const HW_NCPU = 3
-pkg runtime (openbsd-amd64), const HW_NCPU ideal-int
-pkg runtime (openbsd-amd64-cgo), const CLOCK_MONOTONIC = 3
-pkg runtime (openbsd-amd64-cgo), const CLOCK_MONOTONIC ideal-int
-pkg runtime (openbsd-amd64-cgo), const CLOCK_PROF = 2
-pkg runtime (openbsd-amd64-cgo), const CLOCK_PROF ideal-int
-pkg runtime (openbsd-amd64-cgo), const CLOCK_REALTIME = 0
-pkg runtime (openbsd-amd64-cgo), const CLOCK_REALTIME ideal-int
-pkg runtime (openbsd-amd64-cgo), const CLOCK_VIRTUAL = 1
-pkg runtime (openbsd-amd64-cgo), const CLOCK_VIRTUAL ideal-int
-pkg runtime (openbsd-amd64-cgo), const CTL_HW = 6
-pkg runtime (openbsd-amd64-cgo), const CTL_HW ideal-int
-pkg runtime (openbsd-amd64-cgo), const EAGAIN = 35
-pkg runtime (openbsd-amd64-cgo), const EAGAIN ideal-int
-pkg runtime (openbsd-amd64-cgo), const ENOTSUP = 91
-pkg runtime (openbsd-amd64-cgo), const ENOTSUP ideal-int
-pkg runtime (openbsd-amd64-cgo), const ESRCH = 3
-pkg runtime (openbsd-amd64-cgo), const ESRCH ideal-int
-pkg runtime (openbsd-amd64-cgo), const EWOULDBLOCK = 35
-pkg runtime (openbsd-amd64-cgo), const EWOULDBLOCK ideal-int
-pkg runtime (openbsd-amd64-cgo), const HW_NCPU = 3
-pkg runtime (openbsd-amd64-cgo), const HW_NCPU ideal-int
+pkg crypto/tls, const TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA uint16
+pkg crypto/tls, const TLS_RSA_WITH_AES_256_CBC_SHA uint16
+pkg crypto/x509, const ECDSA PublicKeyAlgorithm
+pkg crypto/x509, const ECDSAWithSHA1 SignatureAlgorithm
+pkg crypto/x509, const ECDSAWithSHA256 SignatureAlgorithm
+pkg crypto/x509, const ECDSAWithSHA384 SignatureAlgorithm
+pkg crypto/x509, const ECDSAWithSHA512 SignatureAlgorithm
+pkg debug/elf, type FileHeader struct, Entry uint64
+pkg go/doc, var IllegalPrefixes []string
+pkg math/big, method (*Int) MarshalJSON() ([]byte, error)
+pkg math/big, method (*Int) UnmarshalJSON([]byte) error
+pkg regexp/syntax, const ErrUnexpectedParen ErrorCode
+pkg syscall (darwin-386), const B0 ideal-int
+pkg syscall (darwin-386), const B110 ideal-int
+pkg syscall (darwin-386), const B115200 ideal-int
+pkg syscall (darwin-386), const B1200 ideal-int
+pkg syscall (darwin-386), const B134 ideal-int
+pkg syscall (darwin-386), const B14400 ideal-int
+pkg syscall (darwin-386), const B150 ideal-int
+pkg syscall (darwin-386), const B1800 ideal-int
+pkg syscall (darwin-386), const B19200 ideal-int
+pkg syscall (darwin-386), const B200 ideal-int
+pkg syscall (darwin-386), const B230400 ideal-int
+pkg syscall (darwin-386), const B2400 ideal-int
+pkg syscall (darwin-386), const B28800 ideal-int
+pkg syscall (darwin-386), const B300 ideal-int
+pkg syscall (darwin-386), const B38400 ideal-int
+pkg syscall (darwin-386), const B4800 ideal-int
+pkg syscall (darwin-386), const B50 ideal-int
+pkg syscall (darwin-386), const B57600 ideal-int
+pkg syscall (darwin-386), const B600 ideal-int
+pkg syscall (darwin-386), const B7200 ideal-int
+pkg syscall (darwin-386), const B75 ideal-int
+pkg syscall (darwin-386), const B76800 ideal-int
+pkg syscall (darwin-386), const B9600 ideal-int
+pkg syscall (darwin-386), const BRKINT ideal-int
+pkg syscall (darwin-386), const CFLUSH ideal-int
+pkg syscall (darwin-386), const CLOCAL ideal-int
+pkg syscall (darwin-386), const CREAD ideal-int
+pkg syscall (darwin-386), const CS5 ideal-int
+pkg syscall (darwin-386), const CS6 ideal-int
+pkg syscall (darwin-386), const CS7 ideal-int
+pkg syscall (darwin-386), const CS8 ideal-int
+pkg syscall (darwin-386), const CSIZE ideal-int
+pkg syscall (darwin-386), const CSTART ideal-int
+pkg syscall (darwin-386), const CSTATUS ideal-int
+pkg syscall (darwin-386), const CSTOP ideal-int
+pkg syscall (darwin-386), const CSTOPB ideal-int
+pkg syscall (darwin-386), const CSUSP ideal-int
+pkg syscall (darwin-386), const FLUSHO ideal-int
+pkg syscall (darwin-386), const HUPCL ideal-int
+pkg syscall (darwin-386), const ICANON ideal-int
+pkg syscall (darwin-386), const ICRNL ideal-int
+pkg syscall (darwin-386), const IEXTEN ideal-int
+pkg syscall (darwin-386), const IGNBRK ideal-int
+pkg syscall (darwin-386), const IGNCR ideal-int
+pkg syscall (darwin-386), const IGNPAR ideal-int
+pkg syscall (darwin-386), const IMAXBEL ideal-int
+pkg syscall (darwin-386), const INLCR ideal-int
+pkg syscall (darwin-386), const INPCK ideal-int
+pkg syscall (darwin-386), const ISIG ideal-int
+pkg syscall (darwin-386), const ISTRIP ideal-int
+pkg syscall (darwin-386), const IUTF8 ideal-int
+pkg syscall (darwin-386), const IXANY ideal-int
+pkg syscall (darwin-386), const IXOFF ideal-int
+pkg syscall (darwin-386), const IXON ideal-int
+pkg syscall (darwin-386), const NOFLSH ideal-int
+pkg syscall (darwin-386), const OCRNL ideal-int
+pkg syscall (darwin-386), const OFDEL ideal-int
+pkg syscall (darwin-386), const OFILL ideal-int
+pkg syscall (darwin-386), const ONLCR ideal-int
+pkg syscall (darwin-386), const ONLRET ideal-int
+pkg syscall (darwin-386), const ONOCR ideal-int
+pkg syscall (darwin-386), const ONOEOT ideal-int
+pkg syscall (darwin-386), const OPOST ideal-int
+pkg syscall (darwin-386), const PARENB ideal-int
+pkg syscall (darwin-386), const PARMRK ideal-int
+pkg syscall (darwin-386), const PARODD ideal-int
+pkg syscall (darwin-386), const PENDIN ideal-int
+pkg syscall (darwin-386), const TCIFLUSH ideal-int
+pkg syscall (darwin-386), const TCIOFLUSH ideal-int
+pkg syscall (darwin-386), const TCOFLUSH ideal-int
+pkg syscall (darwin-386), const TCSAFLUSH ideal-int
+pkg syscall (darwin-386), const TOSTOP ideal-int
+pkg syscall (darwin-386), const VDISCARD ideal-int
+pkg syscall (darwin-386), const VDSUSP ideal-int
+pkg syscall (darwin-386), const VEOF ideal-int
+pkg syscall (darwin-386), const VEOL ideal-int
+pkg syscall (darwin-386), const VEOL2 ideal-int
+pkg syscall (darwin-386), const VERASE ideal-int
+pkg syscall (darwin-386), const VINTR ideal-int
+pkg syscall (darwin-386), const VKILL ideal-int
+pkg syscall (darwin-386), const VLNEXT ideal-int
+pkg syscall (darwin-386), const VMIN ideal-int
+pkg syscall (darwin-386), const VQUIT ideal-int
+pkg syscall (darwin-386), const VREPRINT ideal-int
+pkg syscall (darwin-386), const VSTART ideal-int
+pkg syscall (darwin-386), const VSTATUS ideal-int
+pkg syscall (darwin-386), const VSTOP ideal-int
+pkg syscall (darwin-386), const VSUSP ideal-int
+pkg syscall (darwin-386), const VT0 ideal-int
+pkg syscall (darwin-386), const VT1 ideal-int
+pkg syscall (darwin-386), const VTDLY ideal-int
+pkg syscall (darwin-386), const VTIME ideal-int
+pkg syscall (darwin-386), const VWERASE ideal-int
+pkg syscall (darwin-386), type Termios struct
+pkg syscall (darwin-386), type Termios struct, Cc [20]uint8
+pkg syscall (darwin-386), type Termios struct, Cflag uint32
+pkg syscall (darwin-386), type Termios struct, Iflag uint32
+pkg syscall (darwin-386), type Termios struct, Ispeed uint32
+pkg syscall (darwin-386), type Termios struct, Lflag uint32
+pkg syscall (darwin-386), type Termios struct, Oflag uint32
+pkg syscall (darwin-386), type Termios struct, Ospeed uint32
+pkg syscall (darwin-386-cgo), const B0 ideal-int
+pkg syscall (darwin-386-cgo), const B110 ideal-int
+pkg syscall (darwin-386-cgo), const B115200 ideal-int
+pkg syscall (darwin-386-cgo), const B1200 ideal-int
+pkg syscall (darwin-386-cgo), const B134 ideal-int
+pkg syscall (darwin-386-cgo), const B14400 ideal-int
+pkg syscall (darwin-386-cgo), const B150 ideal-int
+pkg syscall (darwin-386-cgo), const B1800 ideal-int
+pkg syscall (darwin-386-cgo), const B19200 ideal-int
+pkg syscall (darwin-386-cgo), const B200 ideal-int
+pkg syscall (darwin-386-cgo), const B230400 ideal-int
+pkg syscall (darwin-386-cgo), const B2400 ideal-int
+pkg syscall (darwin-386-cgo), const B28800 ideal-int
+pkg syscall (darwin-386-cgo), const B300 ideal-int
+pkg syscall (darwin-386-cgo), const B38400 ideal-int
+pkg syscall (darwin-386-cgo), const B4800 ideal-int
+pkg syscall (darwin-386-cgo), const B50 ideal-int
+pkg syscall (darwin-386-cgo), const B57600 ideal-int
+pkg syscall (darwin-386-cgo), const B600 ideal-int
+pkg syscall (darwin-386-cgo), const B7200 ideal-int
+pkg syscall (darwin-386-cgo), const B75 ideal-int
+pkg syscall (darwin-386-cgo), const B76800 ideal-int
+pkg syscall (darwin-386-cgo), const B9600 ideal-int
+pkg syscall (darwin-386-cgo), const BRKINT ideal-int
+pkg syscall (darwin-386-cgo), const CFLUSH ideal-int
+pkg syscall (darwin-386-cgo), const CLOCAL ideal-int
+pkg syscall (darwin-386-cgo), const CREAD ideal-int
+pkg syscall (darwin-386-cgo), const CS5 ideal-int
+pkg syscall (darwin-386-cgo), const CS6 ideal-int
+pkg syscall (darwin-386-cgo), const CS7 ideal-int
+pkg syscall (darwin-386-cgo), const CS8 ideal-int
+pkg syscall (darwin-386-cgo), const CSIZE ideal-int
+pkg syscall (darwin-386-cgo), const CSTART ideal-int
+pkg syscall (darwin-386-cgo), const CSTATUS ideal-int
+pkg syscall (darwin-386-cgo), const CSTOP ideal-int
+pkg syscall (darwin-386-cgo), const CSTOPB ideal-int
+pkg syscall (darwin-386-cgo), const CSUSP ideal-int
+pkg syscall (darwin-386-cgo), const FLUSHO ideal-int
+pkg syscall (darwin-386-cgo), const HUPCL ideal-int
+pkg syscall (darwin-386-cgo), const ICANON ideal-int
+pkg syscall (darwin-386-cgo), const ICRNL ideal-int
+pkg syscall (darwin-386-cgo), const IEXTEN ideal-int
+pkg syscall (darwin-386-cgo), const IGNBRK ideal-int
+pkg syscall (darwin-386-cgo), const IGNCR ideal-int
+pkg syscall (darwin-386-cgo), const IGNPAR ideal-int
+pkg syscall (darwin-386-cgo), const IMAXBEL ideal-int
+pkg syscall (darwin-386-cgo), const INLCR ideal-int
+pkg syscall (darwin-386-cgo), const INPCK ideal-int
+pkg syscall (darwin-386-cgo), const ISIG ideal-int
+pkg syscall (darwin-386-cgo), const ISTRIP ideal-int
+pkg syscall (darwin-386-cgo), const IUTF8 ideal-int
+pkg syscall (darwin-386-cgo), const IXANY ideal-int
+pkg syscall (darwin-386-cgo), const IXOFF ideal-int
+pkg syscall (darwin-386-cgo), const IXON ideal-int
+pkg syscall (darwin-386-cgo), const NOFLSH ideal-int
+pkg syscall (darwin-386-cgo), const OCRNL ideal-int
+pkg syscall (darwin-386-cgo), const OFDEL ideal-int
+pkg syscall (darwin-386-cgo), const OFILL ideal-int
+pkg syscall (darwin-386-cgo), const ONLCR ideal-int
+pkg syscall (darwin-386-cgo), const ONLRET ideal-int
+pkg syscall (darwin-386-cgo), const ONOCR ideal-int
+pkg syscall (darwin-386-cgo), const ONOEOT ideal-int
+pkg syscall (darwin-386-cgo), const OPOST ideal-int
+pkg syscall (darwin-386-cgo), const PARENB ideal-int
+pkg syscall (darwin-386-cgo), const PARMRK ideal-int
+pkg syscall (darwin-386-cgo), const PARODD ideal-int
+pkg syscall (darwin-386-cgo), const PENDIN ideal-int
+pkg syscall (darwin-386-cgo), const TCIFLUSH ideal-int
+pkg syscall (darwin-386-cgo), const TCIOFLUSH ideal-int
+pkg syscall (darwin-386-cgo), const TCOFLUSH ideal-int
+pkg syscall (darwin-386-cgo), const TCSAFLUSH ideal-int
+pkg syscall (darwin-386-cgo), const TOSTOP ideal-int
+pkg syscall (darwin-386-cgo), const VDISCARD ideal-int
+pkg syscall (darwin-386-cgo), const VDSUSP ideal-int
+pkg syscall (darwin-386-cgo), const VEOF ideal-int
+pkg syscall (darwin-386-cgo), const VEOL ideal-int
+pkg syscall (darwin-386-cgo), const VEOL2 ideal-int
+pkg syscall (darwin-386-cgo), const VERASE ideal-int
+pkg syscall (darwin-386-cgo), const VINTR ideal-int
+pkg syscall (darwin-386-cgo), const VKILL ideal-int
+pkg syscall (darwin-386-cgo), const VLNEXT ideal-int
+pkg syscall (darwin-386-cgo), const VMIN ideal-int
+pkg syscall (darwin-386-cgo), const VQUIT ideal-int
+pkg syscall (darwin-386-cgo), const VREPRINT ideal-int
+pkg syscall (darwin-386-cgo), const VSTART ideal-int
+pkg syscall (darwin-386-cgo), const VSTATUS ideal-int
+pkg syscall (darwin-386-cgo), const VSTOP ideal-int
+pkg syscall (darwin-386-cgo), const VSUSP ideal-int
+pkg syscall (darwin-386-cgo), const VT0 ideal-int
+pkg syscall (darwin-386-cgo), const VT1 ideal-int
+pkg syscall (darwin-386-cgo), const VTDLY ideal-int
+pkg syscall (darwin-386-cgo), const VTIME ideal-int
+pkg syscall (darwin-386-cgo), const VWERASE ideal-int
+pkg syscall (darwin-386-cgo), type Termios struct
+pkg syscall (darwin-386-cgo), type Termios struct, Cc [20]uint8
+pkg syscall (darwin-386-cgo), type Termios struct, Cflag uint32
+pkg syscall (darwin-386-cgo), type Termios struct, Iflag uint32
+pkg syscall (darwin-386-cgo), type Termios struct, Ispeed uint32
+pkg syscall (darwin-386-cgo), type Termios struct, Lflag uint32
+pkg syscall (darwin-386-cgo), type Termios struct, Oflag uint32
+pkg syscall (darwin-386-cgo), type Termios struct, Ospeed uint32
+pkg syscall (darwin-amd64), const B0 ideal-int
+pkg syscall (darwin-amd64), const B110 ideal-int
+pkg syscall (darwin-amd64), const B115200 ideal-int
+pkg syscall (darwin-amd64), const B1200 ideal-int
+pkg syscall (darwin-amd64), const B134 ideal-int
+pkg syscall (darwin-amd64), const B14400 ideal-int
+pkg syscall (darwin-amd64), const B150 ideal-int
+pkg syscall (darwin-amd64), const B1800 ideal-int
+pkg syscall (darwin-amd64), const B19200 ideal-int
+pkg syscall (darwin-amd64), const B200 ideal-int
+pkg syscall (darwin-amd64), const B230400 ideal-int
+pkg syscall (darwin-amd64), const B2400 ideal-int
+pkg syscall (darwin-amd64), const B28800 ideal-int
+pkg syscall (darwin-amd64), const B300 ideal-int
+pkg syscall (darwin-amd64), const B38400 ideal-int
+pkg syscall (darwin-amd64), const B4800 ideal-int
+pkg syscall (darwin-amd64), const B50 ideal-int
+pkg syscall (darwin-amd64), const B57600 ideal-int
+pkg syscall (darwin-amd64), const B600 ideal-int
+pkg syscall (darwin-amd64), const B7200 ideal-int
+pkg syscall (darwin-amd64), const B75 ideal-int
+pkg syscall (darwin-amd64), const B76800 ideal-int
+pkg syscall (darwin-amd64), const B9600 ideal-int
+pkg syscall (darwin-amd64), const BRKINT ideal-int
+pkg syscall (darwin-amd64), const CFLUSH ideal-int
+pkg syscall (darwin-amd64), const CLOCAL ideal-int
+pkg syscall (darwin-amd64), const CREAD ideal-int
+pkg syscall (darwin-amd64), const CS5 ideal-int
+pkg syscall (darwin-amd64), const CS6 ideal-int
+pkg syscall (darwin-amd64), const CS7 ideal-int
+pkg syscall (darwin-amd64), const CS8 ideal-int
+pkg syscall (darwin-amd64), const CSIZE ideal-int
+pkg syscall (darwin-amd64), const CSTART ideal-int
+pkg syscall (darwin-amd64), const CSTATUS ideal-int
+pkg syscall (darwin-amd64), const CSTOP ideal-int
+pkg syscall (darwin-amd64), const CSTOPB ideal-int
+pkg syscall (darwin-amd64), const CSUSP ideal-int
+pkg syscall (darwin-amd64), const FLUSHO ideal-int
+pkg syscall (darwin-amd64), const HUPCL ideal-int
+pkg syscall (darwin-amd64), const ICANON ideal-int
+pkg syscall (darwin-amd64), const ICRNL ideal-int
+pkg syscall (darwin-amd64), const IEXTEN ideal-int
+pkg syscall (darwin-amd64), const IGNBRK ideal-int
+pkg syscall (darwin-amd64), const IGNCR ideal-int
+pkg syscall (darwin-amd64), const IGNPAR ideal-int
+pkg syscall (darwin-amd64), const IMAXBEL ideal-int
+pkg syscall (darwin-amd64), const INLCR ideal-int
+pkg syscall (darwin-amd64), const INPCK ideal-int
+pkg syscall (darwin-amd64), const ISIG ideal-int
+pkg syscall (darwin-amd64), const ISTRIP ideal-int
+pkg syscall (darwin-amd64), const IUTF8 ideal-int
+pkg syscall (darwin-amd64), const IXANY ideal-int
+pkg syscall (darwin-amd64), const IXOFF ideal-int
+pkg syscall (darwin-amd64), const IXON ideal-int
+pkg syscall (darwin-amd64), const NOFLSH ideal-int
+pkg syscall (darwin-amd64), const OCRNL ideal-int
+pkg syscall (darwin-amd64), const OFDEL ideal-int
+pkg syscall (darwin-amd64), const OFILL ideal-int
+pkg syscall (darwin-amd64), const ONLCR ideal-int
+pkg syscall (darwin-amd64), const ONLRET ideal-int
+pkg syscall (darwin-amd64), const ONOCR ideal-int
+pkg syscall (darwin-amd64), const ONOEOT ideal-int
+pkg syscall (darwin-amd64), const OPOST ideal-int
+pkg syscall (darwin-amd64), const PARENB ideal-int
+pkg syscall (darwin-amd64), const PARMRK ideal-int
+pkg syscall (darwin-amd64), const PARODD ideal-int
+pkg syscall (darwin-amd64), const PENDIN ideal-int
+pkg syscall (darwin-amd64), const TCIFLUSH ideal-int
+pkg syscall (darwin-amd64), const TCIOFLUSH ideal-int
+pkg syscall (darwin-amd64), const TCOFLUSH ideal-int
+pkg syscall (darwin-amd64), const TCSAFLUSH ideal-int
+pkg syscall (darwin-amd64), const TOSTOP ideal-int
+pkg syscall (darwin-amd64), const VDISCARD ideal-int
+pkg syscall (darwin-amd64), const VDSUSP ideal-int
+pkg syscall (darwin-amd64), const VEOF ideal-int
+pkg syscall (darwin-amd64), const VEOL ideal-int
+pkg syscall (darwin-amd64), const VEOL2 ideal-int
+pkg syscall (darwin-amd64), const VERASE ideal-int
+pkg syscall (darwin-amd64), const VINTR ideal-int
+pkg syscall (darwin-amd64), const VKILL ideal-int
+pkg syscall (darwin-amd64), const VLNEXT ideal-int
+pkg syscall (darwin-amd64), const VMIN ideal-int
+pkg syscall (darwin-amd64), const VQUIT ideal-int
+pkg syscall (darwin-amd64), const VREPRINT ideal-int
+pkg syscall (darwin-amd64), const VSTART ideal-int
+pkg syscall (darwin-amd64), const VSTATUS ideal-int
+pkg syscall (darwin-amd64), const VSTOP ideal-int
+pkg syscall (darwin-amd64), const VSUSP ideal-int
+pkg syscall (darwin-amd64), const VT0 ideal-int
+pkg syscall (darwin-amd64), const VT1 ideal-int
+pkg syscall (darwin-amd64), const VTDLY ideal-int
+pkg syscall (darwin-amd64), const VTIME ideal-int
+pkg syscall (darwin-amd64), const VWERASE ideal-int
+pkg syscall (darwin-amd64), type Termios struct
+pkg syscall (darwin-amd64), type Termios struct, Cc [20]uint8
+pkg syscall (darwin-amd64), type Termios struct, Cflag uint64
+pkg syscall (darwin-amd64), type Termios struct, Iflag uint64
+pkg syscall (darwin-amd64), type Termios struct, Ispeed uint64
+pkg syscall (darwin-amd64), type Termios struct, Lflag uint64
+pkg syscall (darwin-amd64), type Termios struct, Oflag uint64
+pkg syscall (darwin-amd64), type Termios struct, Ospeed uint64
+pkg syscall (darwin-amd64), type Termios struct, Pad_cgo_0 [4]byte
+pkg syscall (darwin-amd64-cgo), const B0 ideal-int
+pkg syscall (darwin-amd64-cgo), const B110 ideal-int
+pkg syscall (darwin-amd64-cgo), const B115200 ideal-int
+pkg syscall (darwin-amd64-cgo), const B1200 ideal-int
+pkg syscall (darwin-amd64-cgo), const B134 ideal-int
+pkg syscall (darwin-amd64-cgo), const B14400 ideal-int
+pkg syscall (darwin-amd64-cgo), const B150 ideal-int
+pkg syscall (darwin-amd64-cgo), const B1800 ideal-int
+pkg syscall (darwin-amd64-cgo), const B19200 ideal-int
+pkg syscall (darwin-amd64-cgo), const B200 ideal-int
+pkg syscall (darwin-amd64-cgo), const B230400 ideal-int
+pkg syscall (darwin-amd64-cgo), const B2400 ideal-int
+pkg syscall (darwin-amd64-cgo), const B28800 ideal-int
+pkg syscall (darwin-amd64-cgo), const B300 ideal-int
+pkg syscall (darwin-amd64-cgo), const B38400 ideal-int
+pkg syscall (darwin-amd64-cgo), const B4800 ideal-int
+pkg syscall (darwin-amd64-cgo), const B50 ideal-int
+pkg syscall (darwin-amd64-cgo), const B57600 ideal-int
+pkg syscall (darwin-amd64-cgo), const B600 ideal-int
+pkg syscall (darwin-amd64-cgo), const B7200 ideal-int
+pkg syscall (darwin-amd64-cgo), const B75 ideal-int
+pkg syscall (darwin-amd64-cgo), const B76800 ideal-int
+pkg syscall (darwin-amd64-cgo), const B9600 ideal-int
+pkg syscall (darwin-amd64-cgo), const BRKINT ideal-int
+pkg syscall (darwin-amd64-cgo), const CFLUSH ideal-int
+pkg syscall (darwin-amd64-cgo), const CLOCAL ideal-int
+pkg syscall (darwin-amd64-cgo), const CREAD ideal-int
+pkg syscall (darwin-amd64-cgo), const CS5 ideal-int
+pkg syscall (darwin-amd64-cgo), const CS6 ideal-int
+pkg syscall (darwin-amd64-cgo), const CS7 ideal-int
+pkg syscall (darwin-amd64-cgo), const CS8 ideal-int
+pkg syscall (darwin-amd64-cgo), const CSIZE ideal-int
+pkg syscall (darwin-amd64-cgo), const CSTART ideal-int
+pkg syscall (darwin-amd64-cgo), const CSTATUS ideal-int
+pkg syscall (darwin-amd64-cgo), const CSTOP ideal-int
+pkg syscall (darwin-amd64-cgo), const CSTOPB ideal-int
+pkg syscall (darwin-amd64-cgo), const CSUSP ideal-int
+pkg syscall (darwin-amd64-cgo), const FLUSHO ideal-int
+pkg syscall (darwin-amd64-cgo), const HUPCL ideal-int
+pkg syscall (darwin-amd64-cgo), const ICANON ideal-int
+pkg syscall (darwin-amd64-cgo), const ICRNL ideal-int
+pkg syscall (darwin-amd64-cgo), const IEXTEN ideal-int
+pkg syscall (darwin-amd64-cgo), const IGNBRK ideal-int
+pkg syscall (darwin-amd64-cgo), const IGNCR ideal-int
+pkg syscall (darwin-amd64-cgo), const IGNPAR ideal-int
+pkg syscall (darwin-amd64-cgo), const IMAXBEL ideal-int
+pkg syscall (darwin-amd64-cgo), const INLCR ideal-int
+pkg syscall (darwin-amd64-cgo), const INPCK ideal-int
+pkg syscall (darwin-amd64-cgo), const ISIG ideal-int
+pkg syscall (darwin-amd64-cgo), const ISTRIP ideal-int
+pkg syscall (darwin-amd64-cgo), const IUTF8 ideal-int
+pkg syscall (darwin-amd64-cgo), const IXANY ideal-int
+pkg syscall (darwin-amd64-cgo), const IXOFF ideal-int
+pkg syscall (darwin-amd64-cgo), const IXON ideal-int
+pkg syscall (darwin-amd64-cgo), const NOFLSH ideal-int
+pkg syscall (darwin-amd64-cgo), const OCRNL ideal-int
+pkg syscall (darwin-amd64-cgo), const OFDEL ideal-int
+pkg syscall (darwin-amd64-cgo), const OFILL ideal-int
+pkg syscall (darwin-amd64-cgo), const ONLCR ideal-int
+pkg syscall (darwin-amd64-cgo), const ONLRET ideal-int
+pkg syscall (darwin-amd64-cgo), const ONOCR ideal-int
+pkg syscall (darwin-amd64-cgo), const ONOEOT ideal-int
+pkg syscall (darwin-amd64-cgo), const OPOST ideal-int
+pkg syscall (darwin-amd64-cgo), const PARENB ideal-int
+pkg syscall (darwin-amd64-cgo), const PARMRK ideal-int
+pkg syscall (darwin-amd64-cgo), const PARODD ideal-int
+pkg syscall (darwin-amd64-cgo), const PENDIN ideal-int
+pkg syscall (darwin-amd64-cgo), const TCIFLUSH ideal-int
+pkg syscall (darwin-amd64-cgo), const TCIOFLUSH ideal-int
+pkg syscall (darwin-amd64-cgo), const TCOFLUSH ideal-int
+pkg syscall (darwin-amd64-cgo), const TCSAFLUSH ideal-int
+pkg syscall (darwin-amd64-cgo), const TOSTOP ideal-int
+pkg syscall (darwin-amd64-cgo), const VDISCARD ideal-int
+pkg syscall (darwin-amd64-cgo), const VDSUSP ideal-int
+pkg syscall (darwin-amd64-cgo), const VEOF ideal-int
+pkg syscall (darwin-amd64-cgo), const VEOL ideal-int
+pkg syscall (darwin-amd64-cgo), const VEOL2 ideal-int
+pkg syscall (darwin-amd64-cgo), const VERASE ideal-int
+pkg syscall (darwin-amd64-cgo), const VINTR ideal-int
+pkg syscall (darwin-amd64-cgo), const VKILL ideal-int
+pkg syscall (darwin-amd64-cgo), const VLNEXT ideal-int
+pkg syscall (darwin-amd64-cgo), const VMIN ideal-int
+pkg syscall (darwin-amd64-cgo), const VQUIT ideal-int
+pkg syscall (darwin-amd64-cgo), const VREPRINT ideal-int
+pkg syscall (darwin-amd64-cgo), const VSTART ideal-int
+pkg syscall (darwin-amd64-cgo), const VSTATUS ideal-int
+pkg syscall (darwin-amd64-cgo), const VSTOP ideal-int
+pkg syscall (darwin-amd64-cgo), const VSUSP ideal-int
+pkg syscall (darwin-amd64-cgo), const VT0 ideal-int
+pkg syscall (darwin-amd64-cgo), const VT1 ideal-int
+pkg syscall (darwin-amd64-cgo), const VTDLY ideal-int
+pkg syscall (darwin-amd64-cgo), const VTIME ideal-int
+pkg syscall (darwin-amd64-cgo), const VWERASE ideal-int
+pkg syscall (darwin-amd64-cgo), type Termios struct
+pkg syscall (darwin-amd64-cgo), type Termios struct, Cc [20]uint8
+pkg syscall (darwin-amd64-cgo), type Termios struct, Cflag uint64
+pkg syscall (darwin-amd64-cgo), type Termios struct, Iflag uint64
+pkg syscall (darwin-amd64-cgo), type Termios struct, Ispeed uint64
+pkg syscall (darwin-amd64-cgo), type Termios struct, Lflag uint64
+pkg syscall (darwin-amd64-cgo), type Termios struct, Oflag uint64
+pkg syscall (darwin-amd64-cgo), type Termios struct, Ospeed uint64
+pkg syscall (darwin-amd64-cgo), type Termios struct, Pad_cgo_0 [4]byte
+pkg syscall (windows-386), const CREATE_NEW_PROCESS_GROUP ideal-int
+pkg syscall (windows-386), const CTRL_BREAK_EVENT ideal-int
+pkg syscall (windows-386), const CTRL_C_EVENT ideal-int
+pkg syscall (windows-386), func GetCurrentProcessId() uint32
+pkg syscall (windows-386), type SysProcAttr struct, CreationFlags uint32
+pkg syscall (windows-amd64), const CREATE_NEW_PROCESS_GROUP ideal-int
+pkg syscall (windows-amd64), const CTRL_BREAK_EVENT ideal-int
+pkg syscall (windows-amd64), const CTRL_C_EVENT ideal-int
+pkg syscall (windows-amd64), func GetCurrentProcessId() uint32
+pkg syscall (windows-amd64), type SysProcAttr struct, CreationFlags uint32
--- a/doc/ExpressivenessOfGo.pdf
+++ b/doc/ExpressivenessOfGo.pdf
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -0,0 +1,27 @@
+# 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.
+
+RAWHTML=\
+	articles/defer_panic_recover.rawhtml\
+	articles/error_handling.rawhtml\
+	articles/slices_usage_and_internals.rawhtml\
+	articles/laws_of_reflection.rawhtml\
+	articles/c_go_cgo.rawhtml\
+	articles/concurrency_patterns.rawhtml\
+	articles/godoc_documenting_go_code.rawhtml\
+	articles/gobs_of_data.rawhtml\
+	articles/json_and_go.rawhtml\
+	articles/json_rpc_tale_of_interfaces.rawhtml\
+	articles/image_draw.rawhtml\
+	articles/image_package.rawhtml\
+	effective_go.rawhtml\
+	go1.rawhtml\
+
+all: $(RAWHTML)
+
+%.rawhtml: %.html
+	godoc -url /doc/$< >$@
+
+clean:
+	rm -f $(RAWHTML)
--- a/doc/articles/c_go_cgo.html
+++ b/doc/articles/c_go_cgo.html
@@ -0,0 +1,180 @@
+<!--{
+"Title": "C? Go? Cgo!",
+"Template": true
+}-->
+
+<p>
+Cgo lets Go packages call C code. Given a Go source file written with some
+special features, cgo outputs Go and C files that can be combined into a
+single Go package.
+</p>
+
+<p>
+To lead with an example, here's a Go package that provides two functions -
+<code>Random</code> and <code>Seed</code> - that wrap C's <code>random</code>
+and <code>srandom</code> functions.
+</p>
+
+{{code "/doc/progs/cgo1.go" `/package rand/` `/END/`}}
+
+<p>
+Let's look at what's happening here, starting with the import statement.
+</p>
+
+<p>
+The <code>rand</code> package imports <code>"C"</code>, but you'll find there's
+no such package in the standard Go library. That's because <code>C</code> is a
+"pseudo-package", a special name interpreted by cgo as a reference to C's
+name space.
+</p>
+
+<p>
+The <code>rand</code> package contains four references to the <code>C</code>
+package: the calls to <code>C.random</code> and <code>C.srandom</code>, the
+conversion <code>C.uint(i)</code>, and the <code>import</code> statement.
+</p>
+
+<p>
+The <code>Random</code> function calls the standard C library's <code>random</code>
+function and returns the result.  In C, <code>random</code> returns a value of the
+C type <code>long</code>, which cgo represents as the type <code>C.long</code>.
+It must be converted to a Go type before it can be used by Go code outside this
+package, using an ordinary Go type conversion:
+</p>
+
+{{code "/doc/progs/cgo1.go" `/func Random/` `/STOP/`}}
+
+<p>
+Here's an equivalent function that uses a temporary variable to illustrate
+the type conversion more explicitly:
+</p>
+
+{{code "/doc/progs/cgo2.go" `/func Random/` `/STOP/`}}
+
+<p>
+The <code>Seed</code> function does the reverse, in a way. It takes a
+regular Go <code>int</code>, converts it to the C <code>unsigned int</code>
+type, and passes it to the C function <code>srandom</code>.
+</p>
+
+{{code "/doc/progs/cgo1.go" `/func Seed/` `/END/`}}
+
+<p>
+Note that cgo knows the <code>unsigned int</code> type as <code>C.uint</code>;
+see the <a href="/cmd/cgo">cgo documentation</a> for a complete list of
+these numeric type names.
+</p>
+
+<p>
+The one detail of this example we haven't examined yet is the comment
+above the <code>import</code> statement.
+</p>
+
+{{code "/doc/progs/cgo1.go" `/\/\*/` `/STOP/`}}
+
+<p>
+Cgo recognizes this comment.  Any lines starting
+with <code>#cgo</code>
+followed
+by a space character are removed; these become directives for cgo.
+The remaining lines are used as a header when compiling the C parts of
+the package.  In this case those lines are just a
+single <code>#include</code>
+statement, but they can be almost any C code.  The <code>#cgo</code>
+directives are
+used to provide flags for the compiler and linker when building the C
+parts of the package.
+</p>
+
+<p>
+There is a limitation: if your program uses any <code>//export</code>
+directives, then the C code in the comment may only include declarations
+(<code>extern int f();</code>), not definitions (<code>int f() {
+return 1; }</code>).  You can use <code>//export</code> directives to
+make Go functions accessible to C code.
+</p>
+
+<p>
+The <code>#cgo</code> and <code>//export</code> directives are
+documented in
+the <a href="/cmd/cgo/">cgo documentation</a>.
+</p>
+
+<p>
+<b>Strings and things</b>
+</p>
+
+<p>
+Unlike Go, C doesn't have an explicit string type. Strings in C are
+represented by a zero-terminated array of chars.
+</p>
+
+<p>
+Conversion between Go and C strings is done with the
+<code>C.CString</code>, <code>C.GoString</code>, and
+<code>C.GoStringN</code> functions. These conversions make a copy of the
+string data.
+</p>
+
+<p>
+This next example implements a <code>Print</code> function that writes a
+string to standard output using C's <code>fputs</code> function from the
+<code>stdio</code> library:
+</p>
+
+{{code "/doc/progs/cgo3.go" `/package print/` `/END/`}}
+
+<p>
+Memory allocations made by C code are not known to Go's memory manager.
+When you create a C string with <code>C.CString</code> (or any C memory
+allocation) you must remember to free the memory when you're done with it
+by calling <code>C.free</code>.
+</p>
+
+<p>
+The call to <code>C.CString</code> returns a pointer to the start of the
+char array, so before the function exits we convert it to an
+<a href="/pkg/unsafe/#Pointer"><code>unsafe.Pointer</code></a> and release
+the memory allocation with <code>C.free</code>. A common idiom in cgo programs
+is to <a href="/doc/articles/defer_panic_recover.html"><code>defer</code></a>
+the free immediately after allocating (especially when the code that follows
+is more complex than a single function call), as in this rewrite of
+<code>Print</code>:
+</p>
+
+{{code "/doc/progs/cgo4.go" `/func Print/` `/END/`}}
+
+<p>
+<b>Building cgo packages</b>
+</p>
+
+<p>
+To build cgo packages, just use <a href="/cmd/go/#Compile_packages_and_dependencies">"
+<code>go build</code>"</a> or
+<a href="/cmd/go/#Compile_and_install_packages_and_dependencies">"<code>go install</code>
+"</a> as usual. The go tool recognizes the special <code>"C"</code> import and automatically
+uses cgo for those files.
+</p>
+
+<p>
+<b>More cgo resources</b>
+</p>
+
+<p>
+The <a href="/cmd/cgo/">cgo command</a> documentation has more detail about
+the C pseudo-package and the build process. The <a href="/misc/cgo/">cgo examples</a>
+in the Go tree demonstrate more advanced concepts.
+</p>
+
+<p>
+For a simple, idiomatic example of a cgo-based package, see Russ Cox's <a
+href="http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go">gosqlite</a>.
+Also, the Go Project Dashboard lists <a
+href="https://godashboard.appspot.com/project?tag=cgo">several other
+cgo packages</a>.
+</p>
+
+<p>
+Finally, if you're curious as to how all this works internally, take a look
+at the introductory comment of the runtime package's <a href="/src/pkg/runtime/cgocall.c">cgocall.c</a>.
+</p>
--- a/doc/articles/concurrency_patterns.html
+++ b/doc/articles/concurrency_patterns.html
@@ -0,0 +1,79 @@
+<!--{
+"Title": "Go Concurrency Patterns: Timing out, moving on",
+"Template": true
+}-->
+
+<p>
+Concurrent programming has its own idioms. A good example is timeouts. Although
+Go's channels do not support them directly, they are easy to implement. Say we
+want to receive from the channel <code>ch</code>, but want to wait at most one
+second for the value to arrive. We would start by creating a signalling channel
+and launching a goroutine that sleeps before sending on the channel:
+</p>
+
+{{code "/doc/progs/timeout1.go" `/timeout :=/` `/STOP/`}}
+
+<p>
+We can then use a <code>select</code> statement to receive from either
+<code>ch</code> or <code>timeout</code>. If nothing arrives on <code>ch</code>
+after one second, the timeout case is selected and the attempt to read from
+<code>ch</code> is abandoned.
+</p>
+
+{{code "/doc/progs/timeout1.go" `/select {/` `/STOP/`}}
+
+<p>
+The <code>timeout</code> channel is buffered with space for 1 value, allowing
+the timeout goroutine to send to the channel and then exit. The goroutine
+doesn't know (or care) whether the value is received. This means the goroutine
+won't hang around forever if the <code>ch</code> receive happens before the
+timeout is reached. The <code>timeout</code> channel will eventually be
+deallocated by the garbage collector.
+</p>
+
+<p>
+(In this example we used <code>time.Sleep</code> to demonstrate the mechanics
+of goroutines and channels. In real programs you should use <code>
+<a href="/pkg/time/#After">time.After</a></code>, a function that returns
+a channel and sends on that channel after the specified duration.)
+</p>
+
+<p>
+Let's look at another variation of this pattern. In this example we have a
+program that reads from multiple replicated databases simultaneously. The
+program needs only one of the answers, and it should accept the answer that
+arrives first.
+</p>
+
+<p>
+The function <code>Query</code> takes a slice of database connections and a
+<code>query</code> string. It queries each of the databases in parallel and
+returns the first response it receives:
+</p>
+
+{{code "/doc/progs/timeout2.go" `/func Query/` `/STOP/`}}
+
+<p>
+In this example, the closure does a non-blocking send, which it achieves by
+using the send operation in <code>select</code> statement with a
+<code>default</code> case. If the send cannot go through immediately the
+default case will be selected. Making the send non-blocking guarantees that
+none of the goroutines launched in the loop will hang around. However, if the
+result arrives before the main function has made it to the receive, the send
+could fail since no one is ready.
+</p>
+
+<p>
+This problem is a textbook example of what is known as a
+<a href="https://en.wikipedia.org/wiki/Race_condition">race condition</a>, but
+the fix is trivial. We just make sure to buffer the channel <code>ch</code> (by
+adding the buffer length as the second argument to <a href="/pkg/builtin/#make">make</a>),
+guaranteeing that the first send has a place to put the value. This ensures the
+send will always succeed, and the first value to arrive will be retrieved
+regardless of the order of execution.
+</p>
+
+<p>
+These two examples demonstrate the simplicity with which Go can express complex
+interactions between goroutines.
+</p>
--- a/doc/articles/defer_panic_recover.html
+++ b/doc/articles/defer_panic_recover.html
@@ -0,0 +1,197 @@
+<!--{
+	"Title": "Defer, Panic, and Recover",
+	"Template": true
+}-->
+
+<p>
+Go has the usual mechanisms for control flow: if, for, switch, goto.  It also
+has the go statement to run code in a separate goroutine.  Here I'd like to
+discuss some of the less common ones: defer, panic, and recover.
+</p>
+ 
+<p>
+A <b>defer statement</b> pushes a function call onto a list. The list of saved
+calls is executed after the surrounding function returns. Defer is commonly
+used to simplify functions that perform various clean-up actions.
+</p>
+ 
+<p>
+For example, let's look at a function that opens two files and copies the
+contents of one file to the other:
+</p>
+ 
+{{code "/doc/progs/defer.go" `/func CopyFile/` `/STOP/`}}
+
+<p>
+This works, but there is a bug. If the call to os.Create fails, the
+function will return without closing the source file. This can be easily
+remedied by putting a call to src.Close before the second return statement,
+but if the function were more complex the problem might not be so easily
+noticed and resolved. By introducing defer statements we can ensure that the
+files are always closed:
+</p>
+ 
+{{code "/doc/progs/defer2.go" `/func CopyFile/` `/STOP/`}}
+
+<p>
+Defer statements allow us to think about closing each file right after opening
+it, guaranteeing that, regardless of the number of return statements in the
+function, the files <i>will</i> be closed.
+</p>
+ 
+<p>
+The behavior of defer statements is straightforward and predictable. There are
+three simple rules:
+</p>
+ 
+<p>
+1. <i>A deferred function's arguments are evaluated when the defer statement is
+evaluated.</i> 
+</p>
+ 
+<p>
+In this example, the expression "i" is evaluated when the Println call is
+deferred. The deferred call will print "0" after the function returns.
+</p>
+ 
+{{code "/doc/progs/defer.go" `/func a/` `/STOP/`}}
+
+<p>
+2. <i>Deferred function calls are executed in Last In First Out order
+</i>after<i> the surrounding function returns.</i> 
+</p>
+ 
+<p>
+This function prints "3210":
+</p>
+
+{{code "/doc/progs/defer.go" `/func b/` `/STOP/`}}
+ 
+<p>
+3. <i>Deferred functions may read and assign to the returning function's named
+return values.</i> 
+</p>
+ 
+<p>
+In this example, a deferred function increments the return value i <i>after</i>
+the surrounding function returns. Thus, this function returns 2:
+</p>
+
+{{code "/doc/progs/defer.go" `/func c/` `/STOP/`}}
+ 
+<p>
+This is convenient for modifying the error return value of a function; we will
+see an example of this shortly.
+</p>
+ 
+<p>
+<b>Panic</b> is a built-in function that stops the ordinary flow of control and
+begins <i>panicking</i>. When the function F calls panic, execution of F stops,
+any deferred functions in F are executed normally, and then F returns to its
+caller. To the caller, F then behaves like a call to panic. The process
+continues up the stack until all functions in the current goroutine have
+returned, at which point the program crashes. Panics can be initiated by
+invoking panic directly. They can also be caused by runtime errors, such as
+out-of-bounds array accesses.
+</p>
+ 
+<p>
+<b>Recover</b> is a built-in function that regains control of a panicking
+goroutine. Recover is only useful inside deferred functions. During normal
+execution, a call to recover will return nil and have no other effect. If the
+current goroutine is panicking, a call to recover will capture the value given
+to panic and resume normal execution.
+</p>
+ 
+<p>
+Here's an example program that demonstrates the mechanics of panic and defer:
+</p>
+
+{{code "/doc/progs/defer2.go" `/package main/` `/STOP/`}}
+ 
+<p>
+The function g takes the int i, and panics if i is greater than 3, or else it
+calls itself with the argument i+1. The function f defers a function that calls
+recover and prints the recovered value (if it is non-nil). Try to picture what
+the output of this program might be before reading on.
+</p>
+ 
+<p>
+The program will output:
+</p>
+ 
+<pre>Calling g.
+Printing in g 0
+Printing in g 1
+Printing in g 2
+Printing in g 3
+Panicking!
+Defer in g 3
+Defer in g 2
+Defer in g 1
+Defer in g 0
+Recovered in f 4
+Returned normally from f.</pre> 
+
+<p>
+If we remove the deferred function from f the panic is not recovered and
+reaches the top of the goroutine's call stack, terminating the program. This
+modified program will output:
+</p>
+ 
+<pre>Calling g.
+Printing in g 0
+Printing in g 1
+Printing in g 2
+Printing in g 3
+Panicking!
+Defer in g 3
+Defer in g 2
+Defer in g 1
+Defer in g 0
+panic: 4
+ 
+panic PC=0x2a9cd8
+[stack trace omitted]</pre> 
+
+<p>
+For a real-world example of <b>panic</b> and <b>recover</b>, see the
+<a href="/pkg/encoding/json/">json package</a> from the Go standard library.
+It decodes JSON-encoded data with a set of recursive functions.
+When malformed JSON is encountered, the parser calls panic to unwind the
+stack to the top-level function call, which recovers from the panic and returns
+an appropriate error value (see the 'error' and 'unmarshal' methods of
+the decodeState type in
+<a href="/src/pkg/encoding/json/decode.go">decode.go</a>).
+</p>
+
+<p>
+The convention in the Go libraries is that even when a package uses panic
+internally, its external API still presents explicit error return values.
+</p>
+ 
+<p>
+Other uses of <b>defer</b> (beyond the file.Close example given earlier)
+include releasing a mutex:
+</p>
+
+<pre>mu.Lock()
+defer mu.Unlock()</pre> 
+
+<p>
+printing a footer:
+</p>
+ 
+<pre>printHeader()
+defer printFooter()</pre> 
+
+<p>
+and more.
+</p>
+ 
+<p>
+In summary, the defer statement (with or without panic and recover) provides an
+unusual and powerful mechanism for control flow.  It can be used to model a
+number of features implemented by special-purpose structures in other
+programming languages. Try it out.
+</p>
--- a/doc/articles/error_handling.html
+++ b/doc/articles/error_handling.html
@@ -0,0 +1,316 @@
+<!--{
+	"Title": "Error Handling and Go",
+	"Template": true
+}-->
+
+<p>
+If you have written any Go code you have probably encountered the built-in
+<code>error</code> type. Go code uses <code>error</code> values to
+indicate an abnormal state. For example, the <code>os.Open</code> function
+returns a non-nil <code>error</code> value when it fails to open a file.
+</p>
+
+{{code "/doc/progs/error.go" `/func Open/`}}
+
+<p>
+The following code uses <code>os.Open</code> to open a file. If an error
+occurs it calls <code>log.Fatal</code> to print the error message and stop.
+</p>
+
+{{code "/doc/progs/error.go" `/func openFile/` `/STOP/`}}
+
+<p>
+You can get a lot done in Go knowing just this about the <code>error</code>
+type, but in this article we'll take a closer look at <code>error</code> and
+discuss some good practices for error handling in Go.
+</p>
+
+<p>
+<b>The error type</b>
+</p>
+
+<p>
+The <code>error</code> type is an interface type. An <code>error</code>
+variable represents any value that can describe itself as a string. Here is the
+interface's declaration:
+</p>
+
+<pre>type error interface {
+    Error() string
+}</pre>
+
+<p>
+The <code>error</code> type, as with all built in types, is
+<a href="/doc/go_spec.html#Predeclared_identifiers">predeclared</a> in the
+<a href="/doc/go_spec.html#Blocks">universe block</a>.
+</p>
+
+<p>
+The most commonly-used <code>error</code> implementation is the
+<a href="/pkg/errors/">errors</a> package's unexported <code>errorString</code> type.
+</p>
+
+{{code "/doc/progs/error.go" `/errorString/` `/STOP/`}}
+
+<p>
+You can construct one of these values with the <code>errors.New</code>
+function. It takes a string that it converts to an <code>errors.errorString</code>
+and returns as an <code>error</code> value.
+</p>
+
+{{code "/doc/progs/error.go" `/New/` `/STOP/`}}
+
+<p>
+Here's how you might use <code>errors.New</code>:
+</p>
+
+{{code "/doc/progs/error.go" `/func Sqrt/` `/STOP/`}}
+
+<p>
+A caller passing a negative argument to <code>Sqrt</code> receives a non-nil
+<code>error</code> value (whose concrete representation is an
+<code>errors.errorString</code> value). The caller can access the error string
+("math: square root of...") by calling the <code>error</code>'s
+<code>Error</code> method, or by just printing it:
+</p>
+
+{{code "/doc/progs/error.go" `/func printErr/` `/STOP/`}}
+
+<p>
+The <a href="/pkg/fmt/">fmt</a> package formats an <code>error</code> value
+by calling its <code>Error() string</code> method.
+</p>
+
+<p>
+It is the error implementation's responsibility to summarize the context.
+The error returned by <code>os.Open</code> formats as "open /etc/passwd:
+permission denied," not just "permission denied."  The error returned by our
+<code>Sqrt</code> is missing information about the invalid argument.
+</p>
+
+<p>
+To add that information, a useful function is the <code>fmt</code> package's
+<code>Errorf</code>. It formats a string according to <code>Printf</code>'s
+rules and returns it as an <code>error</code> created by
+<code>errors.New</code>.
+</p>
+
+{{code "/doc/progs/error.go" `/fmtError/` `/STOP/`}}
+
+<p>
+In many cases <code>fmt.Errorf</code> is good enough, but since
+<code>error</code> is an interface, you can use arbitrary data structures as
+error values, to allow callers to inspect the details of the error.
+</p>
+
+<p>
+For instance, our hypothetical callers might want to recover the invalid
+argument passed to <code>Sqrt</code>. We can enable that by defining a new
+error implementation instead of using <code>errors.errorString</code>:
+</p>
+
+{{code "/doc/progs/error.go" `/type NegativeSqrtError/` `/STOP/`}}
+
+<p>
+A sophisticated caller can then use a
+<a href="/doc/go_spec.html#Type_assertions">type assertion</a> to check for a
+<code>NegativeSqrtError</code> and handle it specially, while callers that just
+pass the error to <code>fmt.Println</code> or <code>log.Fatal</code> will see
+no change in behavior.
+</p>
+
+<p>
+As another example, the <a href="/pkg/encoding/json/">json</a> package specifies a
+<code>SyntaxError</code> type that the <code>json.Decode</code> function
+returns when it encounters a syntax error parsing a JSON blob.
+</p>
+
+{{code "/doc/progs/error.go" `/type SyntaxError/` `/STOP/`}}
+
+<p>
+The <code>Offset</code> field isn't even shown in the default formatting of the
+error, but callers can use it to add file and line information to their error
+messages:
+</p>
+
+{{code "/doc/progs/error.go" `/func decodeError/` `/STOP/`}}
+
+<p>
+(This is a slightly simplified version of some
+<a href="http://camlistore.org/code/?p=camlistore.git;a=blob;f=lib/go/camli/jsonconfig/eval.go#l68">actual code</a>
+from the <a href="http://camlistore.org">Camlistore</a> project.)
+</p>
+
+<p>
+The <code>error</code> interface requires only a <code>Error</code> method;
+specific error implementations might have additional methods. For instance, the
+<a href="/pkg/net/">net</a> package returns errors of type
+<code>error</code>, following the usual convention, but some of the error
+implementations have additional methods defined by the <code>net.Error</code>
+interface:
+</p>
+
+<pre>package net
+
+type Error interface {
+    error
+    Timeout() bool   // Is the error a timeout?
+    Temporary() bool // Is the error temporary?
+}</pre>
+
+<p>
+Client code can test for a <code>net.Error</code> with a type assertion and
+then distinguish transient network errors from permanent ones. For instance, a
+web crawler might sleep and retry when it encounters a temporary error and give
+up otherwise.
+</p>
+
+{{code "/doc/progs/error.go" `/func netError/` `/STOP/`}}
+
+<p>
+<b>Simplifying repetitive error handling</b>
+</p>
+
+<p>
+In Go, error handling is important. The language's design and conventions
+encourage you to explicitly check for errors where they occur (as distinct from
+the convention in other languages of throwing exceptions and sometimes catching
+them). In some cases this makes Go code verbose, but fortunately there are some
+techniques you can use to minimize repetitive error handling.
+</p>
+
+<p>
+Consider an <a href="http://code.google.com/appengine/docs/go/">App Engine</a>
+application with an HTTP handler that retrieves a record from the datastore and
+formats it with a template.
+</p>
+
+{{code "/doc/progs/error2.go" `/func init/` `/STOP/`}}
+
+<p>
+This function handles errors returned by the <code>datastore.Get</code>
+function and <code>viewTemplate</code>'s <code>Execute</code> method. In both
+cases, it presents a simple error message to the user with the HTTP status code
+500 ("Internal Server Error"). This looks like a manageable amount of code, but
+add some more HTTP handlers and you quickly end up with many copies of
+identical error handling code.
+</p>
+
+<p>
+To reduce the repetition we can define our own HTTP <code>appHandler</code>
+type that includes an <code>error</code> return value:
+</p>
+
+{{code "/doc/progs/error3.go" `/type appHandler/`}}
+
+<p>
+Then we can change our <code>viewRecord</code> function to return errors:
+</p>
+
+{{code "/doc/progs/error3.go" `/func viewRecord/` `/STOP/`}}
+
+<p>
+This is simpler than the original version, but the <a
+href="/pkg/net/http/">http</a> package doesn't understand functions that return
+<code>error</code>.
+To fix this we can implement the <code>http.Handler</code> interface's
+<code>ServeHTTP</code> method on <code>appHandler</code>:
+</p>
+
+{{code "/doc/progs/error3.go" `/ServeHTTP/` `/STOP/`}}
+
+<p>
+The <code>ServeHTTP</code> method calls the <code>appHandler</code> function
+and displays the returned error (if any) to the user.  Notice that the method's
+receiver, <code>fn</code>, is a function. (Go can do that!) The method invokes
+the function by calling the receiver in the expression <code>fn(w, r)</code>.
+</p>
+
+<p>
+Now when registering <code>viewRecord</code> with the http package we use the
+<code>Handle</code> function (instead of <code>HandleFunc</code>) as
+<code>appHandler</code> is an <code>http.Handler</code> (not an
+<code>http.HandlerFunc</code>). 
+</p>
+
+{{code "/doc/progs/error3.go" `/func init/` `/STOP/`}}
+
+<p>
+With this basic error handling infrastructure in place, we can make it more
+user friendly. Rather than just displaying the error string, it would be better
+to give the user a simple error message with an appropriate HTTP status code,
+while logging the full error to the App Engine developer console for debugging
+purposes.
+</p>
+
+<p>
+To do this we create an <code>appError</code> struct containing an
+<code>error</code> and some other fields:
+</p>
+
+{{code "/doc/progs/error4.go" `/type appError/` `/STOP/`}}
+
+<p>
+Next we modify the appHandler type to return <code>*appError</code> values:
+</p>
+
+{{code "/doc/progs/error4.go" `/type appHandler/`}}
+
+<p>
+(It's usually a mistake to pass back the concrete type of an error rather than
+<code>error</code>,
+for reasons discussed in <a href="/doc/go_faq.html#nil_error">the Go FAQ</a>,
+but it's the right thing to do here because <code>ServeHTTP</code> is the only
+place that sees the value and uses its contents.)
+</p>
+
+<p>
+And make <code>appHandler</code>'s <code>ServeHTTP</code> method display the
+<code>appError</code>'s <code>Message</code> to the user with the correct HTTP
+status <code>Code</code> and log the full <code>Error</code> to the developer
+console:
+</p>
+
+{{code "/doc/progs/error4.go" `/ServeHTTP/` `/STOP/`}}
+
+<p>
+Finally, we update <code>viewRecord</code> to the new function signature and
+have it return more context when it encounters an error: 
+</p>
+
+{{code "/doc/progs/error4.go" `/func viewRecord/` `/STOP/`}}
+
+<p>
+This version of <code>viewRecord</code> is the same length as the original, but
+now each of those lines has specific meaning and we are providing a friendlier
+user experience.
+</p>
+
+<p>
+It doesn't end there; we can further improve the error handling in our
+application. Some ideas:
+</p>
+
+<ul>
+<li>give the error handler a pretty HTML template,
+<li>make debugging easier by writing the stack trace to the HTTP response when
+the user is an administrator,
+<li>write a constructor function for <code>appError</code> that stores the
+stack trace for easier debugging, 
+<li>recover from panics inside the <code>appHandler</code>, logging the error
+to the console as "Critical," while telling the user "a serious error
+has occurred." This is a nice touch to avoid exposing the user to inscrutable
+error messages caused by programming errors.
+See the <a href="defer_panic_recover.html">Defer, Panic, and Recover</a>
+article for more details.
+</ul>
+
+<p>
+<b>Conclusion</b>
+</p>
+
+<p>
+Proper error handling is an essential requirement of good software. By
+employing the techniques described in this post you should be able to write
+more reliable and succinct Go code.
+</p>
--- a/doc/articles/go_command.html
+++ b/doc/articles/go_command.html
@@ -48,9 +48,9 @@ had to be installed in certain places, under certain names, using certain build
 tools, in order to be used. That's understandable: that's the way it works in
 most other languages. Over the last few years we consistently reminded people
 about the <code>goinstall</code> command
-(now replaced by <a href="/cmd/go/#hdr-Download_and_install_packages_and_dependencies"><code>go get</code></a>)
+(now replaced by <a href="/cmd/go/#Download_and_install_packages_and_dependencies"><code>go get</code></a>)
 and its conventions: first, that the import path is derived in a known way from
-the URL of the source code; second, that the place to store the sources in
+the URL of the source code; second, that that the place to store the sources in
 the local file system is derived in a known way from the import path; third,
 that each directory in a source tree corresponds to a single package; and
 fourth, that the package is built using only information in the source code.
@@ -78,18 +78,17 @@ well-established conventions.</p>
 source code.  For Bitbucket, GitHub, Google Code, and Launchpad, the
 root directory of the repository is identified by the repository's
 main URL, without the <code>http://</code> prefix.  Subdirectories are named by
-adding to that path.
-For example, the Go example programs are obtained by running</p>
+adding to that path.  For example, the supplemental networking
+libraries for Go are obtained by running</p>

 <pre>
-git clone https://github.com/golang/example
+hg clone http://code.google.com/p/go.net
 </pre>

 <p>and thus the import path for the root directory of that repository is
-"<code>github.com/golang/example</code>".
-The <a href="https://godoc.org/github.com/golang/example/stringutil">stringutil</a>
-package is stored in a subdirectory, so its import path is
-"<code>github.com/golang/example/stringutil</code>".</p>
+"<code>code.google.com/p/go.net</code>".  The websocket package is stored in a
+subdirectory, so its import path is
+"<code>code.google.com/p/go.net/websocket</code>".</p>

 <p>These paths are on the long side, but in exchange we get an
 automatically managed name space for import paths and the ability for
@@ -100,7 +99,7 @@ deduce where to obtain the source code.</p>
 in a known way from the import path.  Specifically, the first choice
 is <code>$GOPATH/src/&lt;import-path&gt;</code>.  If <code>$GOPATH</code> is
 unset, the go command will fall back to storing source code alongside the
-standard Go packages, in <code>$GOROOT/src/&lt;import-path&gt;</code>.
+standard Go packages, in <code>$GOROOT/src/pkg/&lt;import-path&gt;</code>.
 If <code>$GOPATH</code> is set to a list of paths, the go command tries
 <code>&lt;dir&gt;/src/&lt;import-path&gt;</code> for each of the directories in
 that list.</p>
--- a/doc/articles/gobs_of_data.html
+++ b/doc/articles/gobs_of_data.html
@@ -0,0 +1,315 @@
+<!--{
+"Title": "Gobs of data",
+"Template": true
+}-->
+
+<p>
+To transmit a data structure across a network or to store it in a file, it must
+be encoded and then decoded again. There are many encodings available, of
+course: <a href="http://www.json.org/">JSON</a>,
+<a href="http://www.w3.org/XML/">XML</a>, Google's
+<a href="http://code.google.com/p/protobuf">protocol buffers</a>, and more.
+And now there's another, provided by Go's <a href="/pkg/encoding/gob/">gob</a>
+package.
+</p>
+
+<p>
+Why define a new encoding? It's a lot of work and redundant at that. Why not
+just use one of the existing formats? Well, for one thing, we do! Go has
+<a href="/pkg/">packages</a> supporting all the encodings just mentioned (the
+<a href="http://code.google.com/p/goprotobuf">protocol buffer package</a> is in
+a separate repository but it's one of the most frequently downloaded). And for
+many purposes, including communicating with tools and systems written in other
+languages, they're the right choice.
+</p>
+
+<p>
+But for a Go-specific environment, such as communicating between two servers
+written in Go, there's an opportunity to build something much easier to use and
+possibly more efficient.
+</p>
+
+<p>
+Gobs work with the language in a way that an externally-defined,
+language-independent encoding cannot. At the same time, there are lessons to be
+learned from the existing systems.
+</p>
+
+<p>
+<b>Goals</b>
+</p>
+
+<p>
+The gob package was designed with a number of goals in mind.
+</p>
+
+<p>
+First, and most obvious, it had to be very easy to use. First, because Go has
+reflection, there is no need for a separate interface definition language or
+"protocol compiler". The data structure itself is all the package should need
+to figure out how to encode and decode it. On the other hand, this approach
+means that gobs will never work as well with other languages, but that's OK:
+gobs are unashamedly Go-centric.
+</p>
+
+<p>
+Efficiency is also important. Textual representations, exemplified by XML and
+JSON, are too slow to put at the center of an efficient communications network.
+A binary encoding is necessary.
+</p>
+
+<p>
+Gob streams must be self-describing. Each gob stream, read from the beginning,
+contains sufficient information that the entire stream can be parsed by an
+agent that knows nothing a priori about its contents. This property means that
+you will always be able to decode a gob stream stored in a file, even long
+after you've forgotten what data it represents.
+</p>
+
+<p>
+There were also some things to learn from our experiences with Google protocol
+buffers.
+</p>
+
+<p>
+<b>Protocol buffer misfeatures</b>
+</p>
+
+<p>
+Protocol buffers had a major effect on the design of gobs, but have three
+features that were deliberately avoided. (Leaving aside the property that
+protocol buffers aren't self-describing: if you don't know the data definition
+used to encode a protocol buffer, you might not be able to parse it.)
+</p>
+
+<p>
+First, protocol buffers only work on the data type we call a struct in Go. You
+can't encode an integer or array at the top level, only a struct with fields
+inside it. That seems a pointless restriction, at least in Go. If all you want
+to send is an array of integers, why should you have to put it into a
+struct first?
+</p>
+
+<p>
+Next, a protocol buffer definition may specify that fields <code>T.x</code> and
+<code>T.y</code> are required to be present whenever a value of type
+<code>T</code> is encoded or decoded.  Although such required fields may seem
+like a good idea, they are costly to implement because the codec must maintain a
+separate data structure while encoding and decoding, to be able to report when
+required fields are missing.  They're also a maintenance problem. Over time, one
+may want to modify the data definition to remove a required field, but that may
+cause existing clients of the data to crash. It's better not to have them in the
+encoding at all.  (Protocol buffers also have optional fields. But if we don't
+have required fields, all fields are optional and that's that. There will be
+more to say about optional fields a little later.)
+</p>
+
+<p>
+The third protocol buffer misfeature is default values. If a protocol buffer
+omits the value for a "defaulted" field, then the decoded structure behaves as
+if the field were set to that value. This idea works nicely when you have
+getter and setter methods to control access to the field, but is harder to
+handle cleanly when the container is just a plain idiomatic struct. Required
+fields are also tricky to implement: where does one define the default values,
+what types do they have (is text UTF-8? uninterpreted bytes? how many bits in a
+float?) and despite the apparent simplicity, there were a number of
+complications in their design and implementation for protocol buffers. We
+decided to leave them out of gobs and fall back to Go's trivial but effective
+defaulting rule: unless you set something otherwise, it has the "zero value"
+for that type - and it doesn't need to be transmitted.
+</p>
+
+<p>
+So gobs end up looking like a sort of generalized, simplified protocol buffer.
+How do they work?
+</p>
+
+<p>
+<b>Values</b>
+</p>
+
+<p>
+The encoded gob data isn't about <code>int8</code>s and <code>uint16</code>s.
+Instead, somewhat analogous to constants in Go, its integer values are abstract,
+sizeless numbers, either signed or unsigned. When you encode an
+<code>int8</code>, its value is transmitted as an unsized, variable-length
+integer. When you encode an <code>int64</code>, its value is also transmitted as
+an unsized, variable-length integer. (Signed and unsigned are treated
+distinctly, but the same unsized-ness applies to unsigned values too.) If both
+have the value 7, the bits sent on the wire will be identical. When the receiver
+decodes that value, it puts it into the receiver's variable, which may be of
+arbitrary integer type. Thus an encoder may send a 7 that came from an
+<code>int8</code>, but the receiver may store it in an <code>int64</code>. This
+is fine: the value is an integer and as a long as it fits, everything works. (If
+it doesn't fit, an error results.) This decoupling from the size of the variable
+gives some flexibility to the encoding: we can expand the type of the integer
+variable as the software evolves, but still be able to decode old data.
+</p>
+
+<p>
+This flexibility also applies to pointers. Before transmission, all pointers are
+flattened. Values of type <code>int8</code>, <code>*int8</code>,
+<code>**int8</code>, <code>****int8</code>, etc. are all transmitted as an
+integer value, which may then be stored in <code>int</code> of any size, or
+<code>*int</code>, or <code>******int</code>, etc. Again, this allows for
+flexibility.
+</p>
+
+<p>
+Flexibility also happens because, when decoding a struct, only those fields
+that are sent by the encoder are stored in the destination. Given the value
+</p>
+
+{{code "/doc/progs/gobs1.go" `/type T/` `/STOP/`}}
+
+<p>
+the encoding of <code>t</code> sends only the 7 and 8. Because it's zero, the
+value of <code>Y</code> isn't even sent; there's no need to send a zero value.
+</p>
+
+<p>
+The receiver could instead decode the value into this structure:
+</p>
+
+{{code "/doc/progs/gobs1.go" `/type U/` `/STOP/`}}
+
+<p>
+and acquire a value of <code>u</code> with only <code>X</code> set (to the
+address of an <code>int8</code> variable set to 7); the <code>Z</code> field is
+ignored - where would you put it? When decoding structs, fields are matched by
+name and compatible type, and only fields that exist in both are affected. This
+simple approach finesses the "optional field" problem: as the type
+<code>T</code> evolves by adding fields, out of date receivers will still
+function with the part of the type they recognize. Thus gobs provide the
+important result of optional fields - extensibility - without any additional
+mechanism or notation.
+</p>
+
+<p>
+From integers we can build all the other types: bytes, strings, arrays, slices,
+maps, even floats. Floating-point values are represented by their IEEE 754
+floating-point bit pattern, stored as an integer, which works fine as long as
+you know their type, which we always do. By the way, that integer is sent in
+byte-reversed order because common values of floating-point numbers, such as
+small integers, have a lot of zeros at the low end that we can avoid
+transmitting.
+</p>
+
+<p>
+One nice feature of gobs that Go makes possible is that they allow you to define
+your own encoding by having your type satisfy the
+<a href="/pkg/encoding/gob/#GobEncoder">GobEncoder</a> and
+<a href="/pkg/encoding/gob/#GobDecoder">GobDecoder</a> interfaces, in a manner
+analogous to the <a href="/pkg/encoding/json/">JSON</a> package's
+<a href="/pkg/encoding/json/#Marshaler">Marshaler</a> and
+<a href="/pkg/encoding/json/#Unmarshaler">Unmarshaler</a> and also to the
+<a href="/pkg/fmt/#Stringer">Stringer</a> interface from
+<a href="/pkg/fmt/">package fmt</a>. This facility makes it possible to
+represent special features, enforce constraints, or hide secrets when you
+transmit data. See the <a href="/pkg/encoding/gob/">documentation</a> for
+details.
+</p>
+
+<p>
+<b>Types on the wire</b>
+</p>
+
+<p>
+The first time you send a given type, the gob package includes in the data
+stream a description of that type. In fact, what happens is that the encoder is
+used to encode, in the standard gob encoding format, an internal struct that
+describes the type and gives it a unique number. (Basic types, plus the layout
+of the type description structure, are predefined by the software for
+bootstrapping.) After the type is described, it can be referenced by its type
+number.
+</p>
+
+<p>
+Thus when we send our first type <code>T</code>, the gob encoder sends a
+description of <code>T</code> and tags it with a type number, say 127. All
+values, including the first, are then prefixed by that number, so a stream of
+<code>T</code> values looks like:
+</p>
+
+<pre>
+("define type id" 127, definition of type T)(127, T value)(127, T value), ...
+</pre>
+
+<p>
+These type numbers make it possible to describe recursive types and send values
+of those types. Thus gobs can encode types such as trees:
+</p>
+
+{{code "/doc/progs/gobs1.go" `/type Node/` `/STOP/`}}
+
+<p>
+(It's an exercise for the reader to discover how the zero-defaulting rule makes
+this work, even though gobs don't represent pointers.)
+</p>
+
+<p>
+With the type information, a gob stream is fully self-describing except for the
+set of bootstrap types, which is a well-defined starting point.
+</p>
+
+<p>
+<b>Compiling a machine</b>
+</p>
+
+<p>
+The first time you encode a value of a given type, the gob package builds a
+little interpreted machine specific to that data type. It uses reflection on
+the type to construct that machine, but once the machine is built it does not
+depend on reflection. The machine uses package unsafe and some trickery to
+convert the data into the encoded bytes at high speed. It could use reflection
+and avoid unsafe, but would be significantly slower. (A similar high-speed
+approach is taken by the protocol buffer support for Go, whose design was
+influenced by the implementation of gobs.) Subsequent values of the same type
+use the already-compiled machine, so they can be encoded right away.
+</p>
+
+<p>
+Decoding is similar but harder. When you decode a value, the gob package holds
+a byte slice representing a value of a given encoder-defined type to decode,
+plus a Go value into which to decode it. The gob package builds a machine for
+that pair: the gob type sent on the wire crossed with the Go type provided for
+decoding. Once that decoding machine is built, though, it's again a
+reflectionless engine that uses unsafe methods to get maximum speed.
+</p>
+
+<p>
+<b>Use</b>
+</p>
+
+<p>
+There's a lot going on under the hood, but the result is an efficient,
+easy-to-use encoding system for transmitting data. Here's a complete example
+showing differing encoded and decoded types. Note how easy it is to send and
+receive values; all you need to do is present values and variables to the
+<a href="/pkg/encoding/gob/">gob package</a> and it does all the work.
+</p>
+
+{{code "/doc/progs/gobs2.go" `/package main/` `$`}}
+
+<p>
+You can compile and run this example code in the
+<a href="http://play.golang.org/p/_-OJV-rwMq">Go Playground</a>.
+</p>
+
+<p>
+The <a href="/pkg/net/rpc/">rpc package</a> builds on gobs to turn this
+encode/decode automation into transport for method calls across the network.
+That's a subject for another article.
+</p>
+
+<p>
+<b>Details</b>
+</p>
+
+<p>
+The <a href="/pkg/encoding/gob/">gob package documentation</a>, especially the
+file <a href="/src/pkg/encoding/gob/doc.go">doc.go</a>, expands on many of the
+details described here and includes a full worked example showing how the
+encoding represents data. If you are interested in the innards of the gob
+implementation, that's a good place to start.
+</p>
--- a/doc/articles/godoc_documenting_go_code.html
+++ b/doc/articles/godoc_documenting_go_code.html
@@ -0,0 +1,139 @@
+<!--{
+"Title": "Godoc: documenting Go code",
+"Template": true
+}-->
+
+<p>
+The Go project takes documentation seriously. Documentation is a huge part of
+making software accessible and maintainable. Of course it must be well-written
+and accurate, but it also must be easy to write and to maintain. Ideally, it
+should be coupled to the code itself so the documentation evolves along with the
+code. The easier it is for programmers to produce good documentation, the better
+for everyone.
+</p>
+
+<p>
+To that end, we have developed the <a href="/cmd/godoc/">godoc</a> documentation
+tool. This article describes godoc's approach to documentation, and explains how
+you can use our conventions and tools to write good documentation for your own
+projects.
+</p>
+
+<p>
+Godoc parses Go source code - including comments - and produces documentation as
+HTML or plain text. The end result is documentation tightly coupled with the
+code it documents. For example, through godoc's web interface you can navigate
+from a function's <a href="/pkg/strings/#HasPrefix">documentation</a> to its
+<a href="/src/pkg/strings/strings.go?#L312">implementation</a> with one click.
+</p>
+
+<p>
+Godoc is conceptually related to Python's
+<a href="http://www.python.org/dev/peps/pep-0257/">Docstring</a> and Java's
+<a href="http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html">Javadoc</a>,
+but its design is simpler. The comments read by godoc are not language
+constructs (as with Docstring) nor must they have their own machine-readable
+syntax (as with Javadoc). Godoc comments are just good comments, the sort you
+would want to read even if godoc didn't exist.
+</p>
+
+<p>
+The convention is simple: to document a type, variable, constant, function, or
+even a package, write a regular comment directly preceding its declaration, with
+no intervening blank line. Godoc will then present that comment as text
+alongside the item it documents. For example, this is the documentation for the
+<code>fmt</code> package's <a href="/pkg/fmt/#Fprint"><code>Fprint</code></a>
+function:
+</p>
+
+{{code "/src/pkg/fmt/print.go" `/Fprint formats using the default/` `/func Fprint/`}}
+
+<p>
+Notice this comment is a complete sentence that begins with the name of the
+element it describes. This important convention allows us to generate
+documentation in a variety of formats, from plain text to HTML to UNIX man
+pages, and makes it read better when tools truncate it for brevity, such as when
+they extract the first line or sentence.
+</p>
+
+<p>
+Comments on package declarations should provide general package documentation.
+These comments can be short, like the <a href="/pkg/sort/"><code>sort</code></a>
+package's brief description:
+</p>
+
+{{code "/src/pkg/sort/sort.go" `/Package sort provides/` `/package sort/`}}
+
+<p>
+They can also be detailed like the <a href="/pkg/encoding/gob/">gob package</a>'s
+overview. That package uses another convention for packages
+that need large amounts of introductory documentation: the package comment is
+placed in its own file, <a href="/src/pkg/encoding/gob/doc.go">doc.go</a>, which
+contains only those comments and a package clause.
+</p>
+
+<p>
+When writing package comments of any size, keep in mind that their first
+sentence will appear in godoc's <a href="/pkg/">package list</a>.
+</p>
+
+<p>
+Comments that are not adjacent to a top-level declaration are omitted from
+godoc's output, with one notable exception. Top-level comments that begin with
+the word <code>"BUG(who)”</code> are recognized as known bugs, and included in
+the "Bugs” section of the package documentation. The "who” part should be the
+user name of someone who could provide more information. For example, this is a
+known issue from the <a href="/pkg/bytes/#bugs">bytes package</a>:
+</p>
+
+<pre>
+// BUG(r): The rule Title uses for word boundaries does not handle Unicode punctuation properly.
+</pre>
+
+<p>
+Godoc treats executable commands somewhat differently. Instead of inspecting the
+command source code, it looks for a Go source file belonging to the special
+package "documentation”. The comment on the "package documentation” clause is
+used as the command's documentation. For example, see the
+<a href="/cmd/godoc/">godoc documentation</a> and its corresponding
+<a href="/src/cmd/godoc/doc.go">doc.go</a> file.
+</p>
+
+<p>
+There are a few formatting rules that Godoc uses when converting comments to
+HTML:
+</p>
+
+<ul>
+<li>
+Subsequent lines of text are considered part of the same paragraph; you must
+leave a blank line to separate paragraphs.
+</li>
+<li>
+Pre-formatted text must be indented relative to the surrounding comment text
+(see gob's <a href="/src/pkg/encoding/gob/doc.go">doc.go</a> for an example).
+</li>
+<li>
+URLs will be converted to HTML links; no special markup is necessary.
+</li>
+</ul>
+
+<p>
+Note that none of these rules requires you to do anything out of the ordinary.
+</p>
+
+<p>
+In fact, the best thing about godoc's minimal approach is how easy it is to use.
+As a result, a lot of Go code, including all of the standard library, already
+follows the conventions.
+</p>
+
+<p>
+Your own code can present good documentation just by having comments as
+described above. Any Go packages installed inside <code>$GOROOT/src/pkg</code>
+and any <code>GOPATH</code> work spaces will already be accessible via godoc's
+command-line and HTTP interfaces, and you can specify additional paths for
+indexing via the <code>-path</code> flag or just by running <code>"godoc ."</code>
+in the source directory. See the <a href="/cmd/godoc/">godoc documentation</a>
+for more details.
+</p>
--- a/doc/articles/gos_declaration_syntax.html
+++ b/doc/articles/gos_declaration_syntax.html
@@ -0,0 +1,348 @@
+<!--{
+"Title": "Go's Declaration Syntax"
+}-->
+
+<p>
+Newcomers to Go wonder why the declaration syntax is different from the
+tradition established in the C family. In this post we'll compare the
+two approaches and explain why Go's declarations look as they do.
+</p>
+
+<p>
+<b>C syntax</b>
+</p>
+
+<p>
+First, let's talk about C syntax. C took an unusual and clever approach
+to declaration syntax. Instead of describing the types with special
+syntax, one writes an expression involving the item being declared, and
+states what type that expression will have. Thus
+</p>
+
+<pre>
+int x;
+</pre>
+
+<p>
+declares x to be an int: the expression 'x' will have type int. In
+general, to figure out how to write the type of a new variable, write an
+expression involving that variable that evaluates to a basic type, then
+put the basic type on the left and the expression on the right.
+</p>
+
+<p>
+Thus, the declarations
+</p>
+
+<pre>
+int *p;
+int a[3];
+</pre>
+
+<p>
+state that p is a pointer to int because '*p' has type int, and that a
+is an array of ints because a[3] (ignoring the particular index value,
+which is punned to be the size of the array) has type int.
+</p>
+
+<p>
+What about functions? Originally, C's function declarations wrote the
+types of the arguments outside the parens, like this:
+</p>
+
+<pre>
+int main(argc, argv)
+    int argc;
+    char *argv[];
+{ /* ... */ }
+</pre>
+
+<p>
+Again, we see that main is a function because the expression main(argc,
+argv) returns an int. In modern notation we'd write
+</p>
+
+<pre>
+int main(int argc, char *argv[]) { /* ... */ }
+</pre>
+
+<p>
+but the basic structure is the same.
+</p>
+
+<p>
+This is a clever syntactic idea that works well for simple types but can
+get confusing fast. The famous example is declaring a function pointer.
+Follow the rules and you get this:
+</p>
+
+<pre>
+int (*fp)(int a, int b);
+</pre>
+
+<p>
+Here, fp is a pointer to a function because if you write the expression
+(*fp)(a, b) you'll call a function that returns int. What if one of fp's
+arguments is itself a function?
+</p>
+
+<pre>
+int (*fp)(int (*ff)(int x, int y), int b)
+</pre>
+
+<p>
+That's starting to get hard to read.
+</p>
+
+<p>
+Of course, we can leave out the name of the parameters when we declare a
+function, so main can be declared
+</p>
+
+<pre>
+int main(int, char *[])
+</pre>
+
+<p>
+Recall that argv is declared like this,
+</p>
+
+<pre>
+char *argv[]
+</pre>
+
+<p>
+so you drop the name from the <em>middle</em> of its declaration to construct
+its type. It's not obvious, though, that you declare something of type
+char *[] by putting its name in the middle.
+</p>
+
+<p>
+And look what happens to fp's declaration if you don't name the
+parameters:
+</p>
+
+<pre>
+int (*fp)(int (*)(int, int), int)
+</pre>
+
+<p>
+Not only is it not obvious where to put the name inside
+</p>
+
+<pre>
+int (*)(int, int)
+</pre>
+
+<p>
+it's not exactly clear that it's a function pointer declaration at all.
+And what if the return type is a function pointer?
+</p>
+
+<pre>
+int (*(*fp)(int (*)(int, int), int))(int, int)
+</pre>
+
+<p>
+It's hard even to see that this declaration is about fp.
+</p>
+
+<p>
+You can construct more elaborate examples but these should illustrate
+some of the difficulties that C's declaration syntax can introduce.
+</p>
+
+<p>
+There's one more point that needs to be made, though. Because type and
+declaration syntax are the same, it can be difficult to parse
+expressions with types in the middle. This is why, for instance, C casts
+always parenthesize the type, as in
+</p>
+
+<pre>
+(int)M_PI
+</pre>
+
+<p>
+<b>Go syntax</b>
+</p>
+
+<p>
+Languages outside the C family usually use a distinct type syntax in
+declarations. Although it's a separate point, the name usually comes
+first, often followed by a colon. Thus our examples above become
+something like (in a fictional but illustrative language)
+</p>
+
+<pre>
+x: int
+p: pointer to int
+a: array[3] of int
+</pre>
+
+<p>
+These declarations are clear, if verbose - you just read them left to
+right. Go takes its cue from here, but in the interests of brevity it
+drops the colon and removes some of the keywords:
+</p>
+
+<pre>
+x int
+p *int
+a [3]int
+</pre>
+
+<p>
+There is no direct correspondence between the look of [3]int and how to
+use a in an expression. (We'll come back to pointers in the next
+section.) You gain clarity at the cost of a separate syntax.
+</p>
+
+<p>
+Now consider functions. Let's transcribe the declaration for main, even
+though the main function in Go takes no arguments:
+</p>
+
+<pre>
+func main(argc int, argv *[]byte) int
+</pre>
+
+<p>
+Superficially that's not much different from C, but it reads well from
+left to right:
+</p>
+
+<p>
+<em>function main takes an int and a pointer to a slice of bytes and returns an int.</em>
+</p>
+
+<p>
+Drop the parameter names and it's just as clear - they're always first
+so there's no confusion.
+</p>
+
+<pre>
+func main(int, *[]byte) int
+</pre>
+
+<p>
+One value of this left-to-right style is how well it works as the types
+become more complex. Here's a declaration of a function variable
+(analogous to a function pointer in C):
+</p>
+
+<pre>
+f func(func(int,int) int, int) int
+</pre>
+
+<p>
+Or if f returns a function:
+</p>
+
+<pre>
+f func(func(int,int) int, int) func(int, int) int
+</pre>
+
+<p>
+It still reads clearly, from left to right, and it's always obvious
+which name is being declared - the name comes first.
+</p>
+
+<p>
+The distinction between type and expression syntax makes it easy to
+write and invoke closures in Go:
+</p>
+
+<pre>
+sum := func(a, b int) int { return a+b } (3, 4)
+</pre>
+
+<p>
+<b>Pointers</b>
+</p>
+
+<p>
+Pointers are the exception that proves the rule. Notice that in arrays
+and slices, for instance, Go's type syntax puts the brackets on the left
+of the type but the expression syntax puts them on the right of the
+expression:
+</p>
+
+<pre>
+var a []int
+x = a[1]
+</pre>
+
+<p>
+For familiarity, Go's pointers use the * notation from C, but we could
+not bring ourselves to make a similar reversal for pointer types. Thus
+pointers work like this
+</p>
+
+<pre>
+var p *int
+x = *p
+</pre>
+
+<p>
+We couldn't say
+</p>
+
+<pre>
+var p *int
+x = p*
+</pre>
+
+<p>
+because that postfix * would conflate with multiplication. We could have
+used the Pascal ^, for example:
+</p>
+
+<pre>
+var p ^int
+x = p^
+</pre>
+
+<p>
+and perhaps we should have (and chosen another operator for xor),
+because the prefix asterisk on both types and expressions complicates
+things in a number of ways. For instance, although one can write
+</p>
+
+<pre>
+[]int("hi")
+</pre>
+
+<p>
+as a conversion, one must parenthesize the type if it starts with a *:
+</p>
+
+<pre>
+(*int)(nil)
+</pre>
+
+<p>
+Had we been willing to give up * as pointer syntax, those parentheses
+would be unnecessary.
+</p>
+
+<p>
+So Go's pointer syntax is tied to the familiar C form, but those ties
+mean that we cannot break completely from using parentheses to
+disambiguate types and expressions in the grammar.
+</p>
+
+<p>
+Overall, though, we believe Go's type syntax is easier to understand
+than C's, especially when things get complicated.
+</p>
+
+<p>
+<b>Notes</b>
+</p>
+
+<p>
+Go's declarations read left to right. It's been pointed out that C's
+read in a spiral! See <a href="http://c-faq.com/decl/spiral.anderson.html">
+The "Clockwise/Spiral Rule"</a> by David Anderson.
+</p>
--- a/doc/articles/image-20.png
+++ b/doc/articles/image-20.png
--- a/doc/articles/image-2a.png
+++ b/doc/articles/image-2a.png
--- a/doc/articles/image-2b.png
+++ b/doc/articles/image-2b.png
--- a/doc/articles/image-2c.png
+++ b/doc/articles/image-2c.png
--- a/doc/articles/image-2d.png
+++ b/doc/articles/image-2d.png
--- a/doc/articles/image-2e.png
+++ b/doc/articles/image-2e.png
--- a/doc/articles/image-2f.png
+++ b/doc/articles/image-2f.png
--- a/doc/articles/image-package-01.png
+++ b/doc/articles/image-package-01.png
--- a/doc/articles/image-package-02.png
+++ b/doc/articles/image-package-02.png
--- a/doc/articles/image-package-03.png
+++ b/doc/articles/image-package-03.png
--- a/doc/articles/image-package-04.png
+++ b/doc/articles/image-package-04.png
--- a/doc/articles/image-package-05.png
+++ b/doc/articles/image-package-05.png
--- a/doc/articles/image_draw.html
+++ b/doc/articles/image_draw.html
@@ -0,0 +1,222 @@
+<!--{
+	"Title": "The Go image/draw package",
+	"Template": true
+}-->
+
+<p>
+<a href="/pkg/image/draw/">Package image/draw</a> defines
+only one operation: drawing a source image onto a destination
+image, through an optional mask image. This one operation is
+surprisingly versatile and can perform a number of common image
+manipulation tasks elegantly and efficiently.  
+</p>
+
+<p>
+Composition is performed pixel by pixel in the style of the Plan 9
+graphics library and the X Render extension. The model is based on
+the classic "Compositing Digital Images" paper by Porter and Duff,
+with an additional mask parameter: <code>dst = (src IN mask) OP dst</code>.
+For a fully opaque mask, this reduces to the original Porter-Duff
+formula: <code>dst = src OP dst</code>. In Go, a nil mask image is equivalent
+to an infinitely sized, fully opaque mask image.
+</p>
+
+<p>
+The Porter-Duff paper presented
+<a href="http://www.w3.org/TR/SVGCompositing/examples/compop-porterduff-examples.png">12 different composition operators</a>,
+but with an explicit mask, only 2 of these are needed in practice:
+source-over-destination and source. In Go, these operators are
+represented by the <code>Over</code> and <code>Src</code> constants. The <code>Over</code> operator
+performs the natural layering of a source image over a destination
+image: the change to the destination image is smaller where the
+source (after masking) is more transparent (that is, has lower
+alpha). The <code>Src</code> operator merely copies the source (after masking)
+with no regard for the destination image's original content. For
+fully opaque source and mask images, the two operators produce the
+same output, but the <code>Src</code> operator is usually faster.
+</p>
+
+<p><b>Geometric Alignment</b></p>
+
+<p>  
+Composition requires associating destination pixels with source and
+mask pixels. Obviously, this requires destination, source and mask
+images, and a composition operator, but it also requires specifying
+what rectangle of each image to use. Not every drawing should write
+to the entire destination: when updating an animating image, it is
+more efficient to only draw the parts of the image that have
+changed. Not every drawing should read from the entire source: when
+using a sprite that combines many small images into one large one,
+only a part of the image is needed. Not every drawing should read
+from the entire mask: a mask image that collects a font's glyphs is
+similar to a sprite. Thus, drawing also needs to know three
+rectangles, one for each image. Since each rectangle has the same
+width and height, it suffices to pass a destination rectangle `r`
+and two points <code>sp</code> and <code>mp</code>: the source rectangle is equal to <code>r</code>
+translated so that <code>r.Min</code> in the destination image aligns with 
+<code>sp</code> in the source image, and similarly for <code>mp</code>. The effective
+rectangle is also clipped to each image's bounds in their
+respective co-ordinate space.
+</p>
+
+<p>
+<img src="image-20.png">
+</p>
+
+<p>
+The <a href="/pkg/image/draw/#DrawMask"><code>DrawMask</code></a>
+function takes seven arguments, but an explicit mask and mask-point
+are usually unnecessary, so the
+<a href="/pkg/image/draw/#Draw"><code>Draw</code></a> function takes five:
+</p>
+
+<pre>
+// Draw calls DrawMask with a nil mask.
+func Draw(dst Image, r image.Rectangle, src image.Image, sp image.Point, op Op)
+func DrawMask(dst Image, r image.Rectangle, src image.Image, sp image.Point,
+	mask image.Image, mp image.Point, op Op)
+</pre>
+
+<p>
+The destination image must be mutable, so the image/draw package
+defines a <a href="/pkg/image/draw/#Image"><code>draw.Image</code></a>
+interface which has a <code>Set</code> method.
+</p>
+
+{{code "../src/pkg/image/draw/draw.go" `/type Image/` `/}/`}}
+  
+<p><b>Filling a Rectangle</b></p>
+
+<p>
+To fill a rectangle with a solid color, use an <code>image.Uniform</code>
+source. The <code>Uniform</code> type re-interprets a <code>Color</code> as a
+practically infinite-sized <code>Image</code> of that color. For those
+familiar with the design of Plan 9's draw library, there is no need
+for an explicit "repeat bit" in Go's slice-based image types; the
+concept is subsumed by <code>Uniform</code>.
+</p>
+
+{{code "/doc/progs/image_draw.go" `/ZERO/` `/STOP/`}}
+
+<p>
+To initialize a new image to all-blue:
+</p>
+
+{{code "/doc/progs/image_draw.go" `/BLUE/` `/STOP/`}}
+
+<p>
+To reset an image to transparent (or black, if the destination
+image's color model cannot represent transparency), use
+<code>image.Transparent</code>, which is an <code>image.Uniform</code>:
+</p>
+
+{{code "/doc/progs/image_draw.go" `/RESET/` `/STOP/`}}
+  
+<p>
+<img src="image-2a.png">
+</p>
+
+ 
+<p><b>Copying an Image</b></p>
+
+<p>
+To copy from a rectangle <code>sr</code> in the source image to a rectangle
+starting at a point <code>dp</code> in the destination, convert the source
+rectangle into the destination image's co-ordinate space:
+</p>
+
+{{code "/doc/progs/image_draw.go" `/RECT/` `/STOP/`}}
+  
+<p>
+Alternatively:
+</p>
+
+{{code "/doc/progs/image_draw.go" `/RECT2/` `/STOP/`}}
+  
+<p>
+To copy the entire source image, use <code>sr = src.Bounds()</code>.
+</p>
+  
+<p>
+<img src="image-2b.png">
+</p>
+ 
+<p><b>Scrolling an Image</b></p>
+
+<p>
+Scrolling an image is just copying an image to itself, with
+different destination and source rectangles. Overlapping
+destination and source images are perfectly valid, just as Go's
+built-in copy function can handle overlapping destination and
+source slices. To scroll an image m by 20 pixels:
+</p>
+
+{{code "/doc/progs/image_draw.go" `/SCROLL/` `/STOP/`}}
+  
+<p><img src="image-2c.png"></p>
+ 
+<p><b>Converting an Image to RGBA</b></p>
+
+<p>
+The result of decoding an image format might not be an
+<code>image.RGBA</code>: decoding a GIF results in an <code>image.Paletted</code>,
+decoding a JPEG results in a <code>ycbcr.YCbCr</code>, and the result of
+decoding a PNG depends on the image data. To convert any image to
+an <code>image.RGBA</code>:
+</p>
+
+{{code "/doc/progs/image_draw.go" `/CONV/` `/STOP/`}}
+  
+<p>
+<img src="image-2d.png">
+</p>
+
+<p><b>Drawing Through a Mask</b></p>
+
+<p>
+To draw an image through a circular mask with center <code>p</code> and radius
+<code>r</code>:
+</p>
+
+{{code "/doc/progs/image_draw.go" `/CIRCLESTRUCT/` `/STOP/`}}
+{{code "/doc/progs/image_draw.go" `/CIRCLE2/` `/STOP/`}}
+  
+<p>
+<img src="image-2e.png">
+</p>
+
+<p><b>Drawing Font Glyphs</b></p>
+
+<p> 
+To draw a font glyph in blue starting from a point <code>p</code>, draw with
+an <code>image.Uniform</code> source and an <code>image.Alpha mask</code>. For
+simplicity, we aren't performing any sub-pixel positioning or
+rendering, or correcting for a font's height above a baseline.
+</p>
+
+{{code "/doc/progs/image_draw.go" `/GLYPH/` `/STOP/`}}
+
+<p>
+<img src="image-2f.png">
+</p>
+  
+<p><b>Performance</b></p>
+
+<p>
+The image/draw package implementation demonstrates how to provide
+an image manipulation function that is both general purpose, yet
+efficient for common cases. The <code>DrawMask</code> function takes arguments
+of interface types, but immediately makes type assertions that its
+arguments are of specific struct types, corresponding to common
+operations like drawing one <code>image.RGBA</code> image onto another, or
+drawing an <code>image.Alpha</code> mask (such as a font glyph) onto an
+<code>image.RGBA</code> image. If a type assertion succeeds, that type
+information is used to run a specialized implementation of the
+general algorithm. If the assertions fail, the fallback code path
+uses the generic <code>At</code> and <code>Set</code> methods. The fast-paths are purely
+a performance optimization; the resultant destination image is the
+same either way. In practice, only a small number of special cases
+are necessary to support typical applications.  
+</p>
+
+
--- a/doc/articles/image_package.html
+++ b/doc/articles/image_package.html
@@ -0,0 +1,312 @@
+<!--{
+	"Title": "The Go image package",
+	"Template": true
+}-->
+
+<p>
+The <a href="/pkg/image/">image</a> and
+<a href="/pkg/image/color/">image/color</a> packages define a number of types:
+<code>color.Color</code> and <code>color.Model</code> describe colors,
+<code>image.Point</code> and <code>image.Rectangle</code> describe basic 2-D
+geometry, and <code>image.Image</code> brings the two concepts together to
+represent a rectangular grid of colors. A
+<a href="/doc/articles/image_draw.html">separate article</a> covers image
+composition with the <a href="/pkg/image/draw/">image/draw</a> package.
+</p>
+
+<p>
+<b>Colors and Color Models</b>
+</p>
+
+<p>
+<a href="/pkg/image/color/#Color">Color</a> is an interface that defines the minimal
+method set of any type that can be considered a color: one that can be converted
+to red, green, blue and alpha values. The conversion may be lossy, such as
+converting from CMYK or YCbCr color spaces.
+</p>
+
+{{code "/src/pkg/image/color/color.go" `/type Color interface/` `/^}/`}}
+
+<p>
+There are three important subtleties about the return values. First, the red,
+green and blue are alpha-premultiplied: a fully saturated red that is also 25%
+transparent is represented by RGBA returning a 75% r. Second, the channels have
+a 16-bit effective range: 100% red is represented by RGBA returning an r of
+65535, not 255, so that converting from CMYK or YCbCr is not as lossy. Third,
+the type returned is <code>uint32</code>, even though the maximum value is 65535, to
+guarantee that multiplying two values together won't overflow. Such
+multiplications occur when blending two colors according to an alpha mask from a
+third color, in the style of
+<a href="https://en.wikipedia.org/wiki/Alpha_compositing">Porter and Duff's</a>
+classic algebra:
+</p>
+
+<pre>
+dstr, dstg, dstb, dsta := dst.RGBA()
+srcr, srcg, srcb, srca := src.RGBA()
+_, _, _, m := mask.RGBA()
+const M = 1&lt;&lt;16 - 1
+// The resultant red value is a blend of dstr and srcr, and ranges in [0, M].
+// The calculation for green, blue and alpha is similar.
+dstr = (dstr*(M-m) + srcr*m) / M
+</pre>
+
+<p>
+The last line of that code snippet would have been more complicated if we worked
+with non-alpha-premultiplied colors, which is why <code>Color</code> uses
+alpha-premultiplied values.
+</p>
+
+<p>
+The image/color package also defines a number of concrete types that implement
+the <code>Color</code> interface. For example,
+<a href="/pkg/image/color/#RGBA"><code>RGBA</code></a> is a struct that represents
+the classic "8 bits per channel" color.
+</p>
+
+{{code "/src/pkg/image/color/color.go" `/type RGBA struct/` `/^}/`}}
+
+<p>
+Note that the <code>R</code> field of an <code>RGBA</code> is an 8-bit
+alpha-premultiplied color in the range [0, 255]. <code>RGBA</code> satisfies the
+<code>Color</code> interface by multiplying that value by 0x101 to generate a
+16-bit alpha-premultiplied color in the range [0, 65535]. Similarly, the
+<a href="/pkg/image/color/#NRGBA"><code>NRGBA</code></a> struct type represents
+an 8-bit non-alpha-premultiplied color, as used by the PNG image format. When
+manipulating an <code>NRGBA</code>'s fields directly, the values are
+non-alpha-premultiplied, but when calling the <code>RGBA</code> method, the
+return values are alpha-premultiplied.
+</p>
+
+<p>
+A <a href="/pkg/image/color/#Model"><code>Model</code></a> is simply
+something that can convert <code>Color</code>s to other <code>Color</code>s, possibly lossily. For
+example, the <code>GrayModel</code> can convert any <code>Color</code> to a
+desaturated <a href="/pkg/image/color/#Gray"><code>Gray</code></a>. A
+<code>Palette</code> can convert any <code>Color</code> to one from a
+limited palette.
+</p>
+
+{{code "/src/pkg/image/color/color.go" `/type Model interface/` `/^}/`}}
+
+{{code "/src/pkg/image/color/color.go" `/type Palette \[\]Color/`}}
+
+<p>
+<b>Points and Rectangles</b>
+</p>
+
+<p>
+A <a href="/pkg/image/#Point"><code>Point</code></a> is an (x, y) co-ordinate
+on the integer grid, with axes increasing right and down. It is neither a pixel
+nor a grid square. A <code>Point</code> has no intrinsic width, height or
+color, but the visualizations below use a small colored square.
+</p>
+
+{{code "/src/pkg/image/geom.go" `/type Point struct/` `/^}/`}}
+
+<p>
+<img src="image-package-01.png" width="400" height="300">
+</p>
+
+{{code "/doc/progs/image_package1.go" `/p := image.Point/`}}
+
+<p>
+A <a href="/pkg/image/#Rectangle"><code>Rectangle</code></a> is an axis-aligned
+rectangle on the integer grid, defined by its top-left and bottom-right
+<code>Point</code>.  A <code>Rectangle</code> also has no intrinsic color, but
+the visualizations below outline rectangles with a thin colored line, and call
+out their <code>Min</code> and <code>Max</code> <code>Point</code>s.
+</p>
+
+{{code "/src/pkg/image/geom.go" `/type Rectangle struct/` `/^}/`}}
+
+<p>
+For convenience, <code>image.Rect(x0, y0, x1, y1)</code> is equivalent to
+<code>image.Rectangle{image.Point{x0, y0}, image.Point{x1, y1}}</code>, but is
+much easier to type.
+</p>
+
+<p>
+A <code>Rectangle</code> is inclusive at the top-left and exclusive at the
+bottom-right. For a <code>Point p</code> and a <code>Rectangle r</code>,
+<code>p.In(r)</code> if and only if
+<code>r.Min.X &lt;= p.X &amp;&amp; p.X &lt; r.Max.X</code>, and similarly for <code>Y</code>. This is analagous to how
+a slice <code>s[i0:i1]</code> is inclusive at the low end and exclusive at the
+high end. (Unlike arrays and slices, a <code>Rectangle</code> often has a
+non-zero origin.)
+</p>
+
+<p>
+<img src="image-package-02.png" width="400" height="300">
+</p>
+
+{{code "/doc/progs/image_package2.go" `/r := image.Rect/` `/fmt.Println/`}}
+
+<p>
+Adding a <code>Point</code> to a <code>Rectangle</code> translates the
+<code>Rectangle</code>. Points and Rectangles are not restricted to be in the
+bottom-right quadrant.
+</p>
+
+<p>
+<img src="image-package-03.png" width="400" height="300">
+</p>
+
+{{code "/doc/progs/image_package3.go" `/r := image.Rect/` `/fmt.Println/`}}
+
+<p>
+Intersecting two Rectangles yields another Rectangle, which may be empty.
+</p>
+
+<p>
+<img src="image-package-04.png" width="400" height="300">
+</p>
+
+{{code "/doc/progs/image_package4.go" `/r := image.Rect/` `/fmt.Printf/`}}
+
+<p>
+Points and Rectangles are passed and returned by value. A function that takes a
+<code>Rectangle</code> argument will be as efficient as a function that takes
+two <code>Point</code> arguments, or four <code>int</code> arguments.
+</p>
+
+<p>
+<b>Images</b>
+</p>
+
+<p>
+An <a href="/pkg/image/#Image">Image</a> maps every grid square in a
+<code>Rectangle</code> to a <code>Color</code> from a <code>Model</code>.
+"The pixel at (x, y)" refers to the color of the grid square defined by the
+points (x, y), (x+1, y), (x+1, y+1) and (x, y+1).
+</p>
+
+{{code "/src/pkg/image/image.go" `/type Image interface/` `/^}/`}}
+
+<p>
+A common mistake is assuming that an <code>Image</code>'s bounds start at (0,
+0). For example, an animated GIF contains a sequence of Images, and each
+<code>Image</code> after the first typically only holds pixel data for the area
+that changed, and that area doesn't necessarily start at (0, 0). The correct
+way to iterate over an <code>Image</code> m's pixels looks like:
+</p>
+
+<pre>
+b := m.Bounds()
+for y := b.Min.Y; y &lt; b.Max.Y; y++ {
+	for x := b.Min.X; y &lt; b.Max.X; x++ {
+		doStuffWith(m.At(x, y))
+	}
+}
+</pre>
+
+<p>
+<code>Image</code> implementations do not have to be based on an in-memory
+slice of pixel data. For example, a
+<a href="/pkg/image/#Uniform"><code>Uniform</code></a> is an
+<code>Image</code> of enormous bounds and uniform color, whose in-memory
+representation is simply that color.
+</p>
+
+{{code "/src/pkg/image/names.go" `/type Uniform struct/` `/^}/`}}
+
+<p>
+Typically, though, programs will want an image based on a slice. Struct types
+like <a href="/pkg/image/#RGBA"><code>RGBA</code></a> and
+<a href="/pkg/image/#Gray"><code>Gray</code></a> (which other packages refer
+to as <code>image.RGBA</code> and <code>image.Gray</code>) hold slices of pixel
+data and implement the <code>Image</code> interface.
+</p>
+
+{{code "/src/pkg/image/image.go" `/type RGBA struct/` `/^}/`}}
+
+<p>
+These types also provide a <code>Set(x, y int, c color.Color)</code> method
+that allows modifying the image one pixel at a time.
+</p>
+
+{{code "/doc/progs/image_package5.go" `/m := image.New/` `/m.Set/`}}
+
+<p>
+If you're reading or writing a lot of pixel data, it can be more efficient, but
+more complicated, to access these struct type's <code>Pix</code> field directly.
+</p>
+
+<p>
+The slice-based <code>Image</code> implementations also provide a
+<code>SubImage</code> method, which returns an <code>Image</code> backed by the
+same array. Modifying the pixels of a sub-image will affect the pixels of the
+original image, analagous to how modifying the contents of a sub-slice
+<code>s[i0:i1]</code> will affect the contents of the original slice
+<code>s</code>.
+</p>
+
+<img src="image-package-05.png" width="400" height="300">
+
+{{code "/doc/progs/image_package6.go" `/m0 := image.New/` `/fmt.Println\(m0.Stride/`}}
+
+<p>
+For low-level code that works on an image's <code>Pix</code> field, be aware
+that ranging over <code>Pix</code> can affect pixels outside an image's bounds.
+In the example above, the pixels covered by <code>m1.Pix</code> are shaded in
+blue. Higher-level code, such as the <code>At</code> and <code>Set</code>
+methods or the <a href="/pkg/image/draw/">image/draw package</a>, will clip
+their operations to the image's bounds.
+</p>
+
+<p>
+<b>Image Formats</b>
+</p>
+
+<p>
+The standard package library supports a number of common image formats, such as
+GIF, JPEG and PNG. If you know the format of a source image file, you can
+decode from an <a href="/pkg/io/#Reader"><code>io.Reader</code></a> directly.
+</p>
+
+<pre>
+import (
+	"image/jpeg"
+	"image/png"
+	"io"
+)
+
+// convertJPEGToPNG converts from JPEG to PNG.
+func convertJPEGToPNG(w io.Writer, r io.Reader) error {
+	img, err := jpeg.Decode(r)
+	if err != nil {
+		return err
+	}
+	return png.Encode(w, img)
+}
+</pre>
+
+<p>
+If you have image data of unknown format, the
+<a href="/pkg/image/#Decode"><code>image.Decode</code></a> function can detect
+the format. The set of recognized formats is constructed at run time and is not
+limited to those in the standard package library. An image format package
+typically registers its format in an init function, and the main package will
+"underscore import" such a package solely for the side effect of format
+registration.
+</p>
+
+<pre>
+import (
+	"image"
+	"image/png"
+	"io"
+
+	_ "code.google.com/p/vp8-go/webp"
+	_ "image/jpeg"
+)
+
+// convertToPNG converts from any recognized format to PNG.
+func convertToPNG(w io.Writer, r io.Reader) error {
+	img, _, err := image.Decode(r)
+	if err != nil {
+		return err
+	}
+	return png.Encode(w, img)
+}
+</pre>
--- a/doc/articles/index.html
+++ b/doc/articles/index.html
@@ -3,6 +3,5 @@
 }-->

 <p>
-See the <a href="/doc/#articles">Documents page</a> and the
-<a href="/blog/index">Blog index</a> for a complete list of Go articles.
+See the <a href="/doc/#articles">Documents page</a> for a complete list of Go articles.
 </p>
--- a/doc/articles/json_and_go.html
+++ b/doc/articles/json_and_go.html
@@ -0,0 +1,356 @@
+<!--{
+"Title": "JSON and Go",
+"Template": true
+}-->
+
+<p>
+JSON (JavaScript Object Notation) is a simple data interchange format.
+Syntactically it resembles the objects and lists of JavaScript. It is most
+commonly used for communication between web back-ends and JavaScript programs
+running in the browser, but it is used in many other places, too. Its home page,
+<a href="http://json.org">json.org</a>, provides a wonderfully clear and concise
+definition of the standard.
+</p>
+
+<p>
+With the <a href="/pkg/encoding/json/">json package</a> it's a snap to read and
+write JSON data from your Go programs.
+</p>
+
+<p>
+<b>Encoding</b>
+</p>
+
+<p>
+To encode JSON data we use the
+<a href="/pkg/encoding/json/#Marshal"><code>Marshal</code></a> function.
+</p>
+
+<pre>
+func Marshal(v interface{}) ([]byte, error)
+</pre>
+
+<p>
+Given the Go data structure, <code>Message</code>,
+</p>
+
+{{code "/doc/progs/json1.go" `/type Message/` `/STOP/`}}
+
+<p>
+and an instance of <code>Message</code>
+</p>
+
+{{code "/doc/progs/json1.go" `/m :=/`}}
+
+<p>
+we can marshal a JSON-encoded version of m using <code>json.Marshal</code>:
+</p>
+
+{{code "/doc/progs/json1.go" `/b, err :=/`}}
+
+<p>
+If all is well, <code>err</code> will be <code>nil</code> and <code>b</code>
+will be a <code>[]byte</code> containing this JSON data:
+</p>
+
+<pre>
+b == []byte(`{"Name":"Alice","Body":"Hello","Time":1294706395881547000}`)
+</pre>
+
+<p>
+Only data structures that can be represented as valid JSON will be encoded:
+</p>
+
+<ul>
+<li>
+JSON objects only support strings as keys; to encode a Go map type it must be
+of the form <code>map[string]T</code> (where <code>T</code> is any Go type
+supported by the json package).
+</li>
+<li>
+Channel, complex, and function types cannot be encoded.
+</li>
+<li>
+Cyclic data structures are not supported; they will cause <code>Marshal</code>
+to go into an infinite loop.
+</li>
+<li>
+Pointers will be encoded as the values they point to (or 'null' if the pointer
+is <code>nil</code>).
+</li>
+</ul>
+
+<p>
+The json package only accesses the exported fields of struct types (those that
+begin with an uppercase letter). Therefore only the exported fields of a struct
+will be present in the JSON output.
+</p>
+
+<p>
+<b>Decoding</b>
+</p>
+
+<p>
+To decode JSON data we use the
+<a href="/pkg/encoding/json/#Unmarshal"><code>Unmarshal</code></a> function.
+</p>
+
+<pre>
+func Unmarshal(data []byte, v interface{}) error
+</pre>
+
+<p>
+We must first create a place where the decoded data will be stored
+</p>
+
+{{code "/doc/progs/json1.go" `/var m Message/`}}
+
+<p>
+and call <code>json.Unmarshal</code>, passing it a <code>[]byte</code> of JSON
+data and a pointer to <code>m</code>
+</p>
+
+{{code "/doc/progs/json1.go" `/err := json.Unmarshal/`}}
+
+<p>
+If <code>b</code> contains valid JSON that fits in <code>m</code>, after the
+call <code>err</code> will be <code>nil</code> and the data from <code>b</code>
+will have been stored in the struct <code>m</code>, as if by an assignment
+like:
+</p>
+
+{{code "/doc/progs/json1.go" `/m = Message/` `/STOP/`}}
+
+<p>
+How does <code>Unmarshal</code> identify the fields in which to store the
+decoded data? For a given JSON key <code>"Foo"</code>, <code>Unmarshal</code>
+will look through the destination struct's fields to find (in order of
+preference):
+</p>
+
+<ul>
+<li>
+An exported field with a tag of <code>"Foo"</code> (see the
+<a href="/ref/spec#Struct_types">Go spec</a> for more on struct tags),
+</li>
+<li>
+An exported field named <code>"Foo"</code>, or
+</li>
+<li>
+An exported field named <code>"FOO"</code> or <code>"FoO"</code> or some other
+case-insensitive match of <code>"Foo"</code>.
+</li>
+</ul>
+
+<p>
+What happens when the structure of the JSON data doesn't exactly match the Go
+type?
+</p>
+
+{{code "/doc/progs/json1.go" `/"Food":"Pickle"/` `/STOP/`}}
+
+<p>
+<code>Unmarshal</code> will decode only the fields that it can find in the
+destination type.  In this case, only the Name field of m will be populated,
+and the Food field will be ignored. This behavior is particularly useful when
+you wish to pick only a few specific fields out of a large JSON blob. It also
+means that any unexported fields in the destination struct will be unaffected
+by <code>Unmarshal</code>.
+</p>
+
+<p>
+But what if you don't know the structure of your JSON data beforehand?
+</p>
+
+<p>
+<b>Generic JSON with interface{}</b>
+</p>
+
+<p>
+The <code>interface{}</code> (empty interface) type describes an interface with
+zero methods.  Every Go type implements at least zero methods and therefore
+satisfies the empty interface.
+</p>
+
+<p>
+The empty interface serves as a general container type:
+</p>
+
+{{code "/doc/progs/json2.go" `/var i interface{}/` `/STOP/`}}
+
+<p>
+A type assertion accesses the underlying concrete type:
+</p>
+
+{{code "/doc/progs/json2.go" `/r := i/` `/STOP/`}}
+
+<p>
+Or, if the underlying type is unknown, a type switch determines the type:
+</p>
+
+{{code "/doc/progs/json2.go" `/switch v/` `/STOP/`}}
+
+
+The json package uses <code>map[string]interface{}</code> and
+<code>[]interface{}</code> values to store arbitrary JSON objects and arrays;
+it will happily unmarshal any valid JSON blob into a plain
+<code>interface{}</code> value.  The default concrete Go types are:
+
+<ul>
+<li>
+<code>bool</code> for JSON booleans,
+</li>
+<li>
+<code>float64</code> for JSON numbers,
+</li>
+<li>
+<code>string</code> for JSON strings, and
+</li>
+<li>
+<code>nil</code> for JSON null.
+</li>
+</ul>
+
+<p>
+<b>Decoding arbitrary data</b>
+</p>
+
+<p>
+Consider this JSON data, stored in the variable <code>b</code>:
+</p>
+
+{{code "/doc/progs/json3.go" `/b :=/`}}
+
+<p>
+Without knowing this data's structure, we can decode it into an
+<code>interface{}</code> value with <code>Unmarshal</code>:
+</p>
+
+{{code "/doc/progs/json3.go" `/var f interface/` `/STOP/`}}
+
+<p>
+At this point the Go value in <code>f</code> would be a map whose keys are
+strings and whose values are themselves stored as empty interface values:
+</p>
+
+{{code "/doc/progs/json3.go" `/f = map/` `/STOP/`}}
+
+<p>
+To access this data we can use a type assertion to access <code>f</code>'s
+underlying <code>map[string]interface{}</code>:
+</p>
+
+{{code "/doc/progs/json3.go" `/m := f/`}}
+
+<p>
+We can then iterate through the map with a range statement and use a type switch
+to access its values as their concrete types:
+</p>
+
+{{code "/doc/progs/json3.go" `/for k, v/` `/STOP/`}}
+
+<p>
+In this way you can work with unknown JSON data while still enjoying the
+benefits of type safety.
+</p>
+
+<p>
+<b>Reference Types</b>
+</p>
+
+<p>
+Let's define a Go type to contain the data from the previous example:
+</p>
+
+{{code "/doc/progs/json4.go" `/type FamilyMember/` `/STOP/`}}
+
+{{code "/doc/progs/json4.go" `/var m FamilyMember/` `/STOP/`}}
+
+<p>
+Unmarshaling that data into a <code>FamilyMember</code> value works as
+expected, but if we look closely we can see a remarkable thing has happened.
+With the var statement we allocated a <code>FamilyMember</code> struct, and
+then provided a pointer to that value to <code>Unmarshal</code>, but at that
+time the <code>Parents</code> field was a <code>nil</code> slice value. To
+populate the <code>Parents</code> field, <code>Unmarshal</code> allocated a new
+slice behind the scenes. This is typical of how <code>Unmarshal</code> works
+with the supported reference types (pointers, slices, and maps).
+</p>
+
+<p>
+Consider unmarshaling into this data structure:
+</p>
+
+<pre>
+type Foo struct {
+    Bar *Bar
+}
+</pre>
+
+<p>
+If there were a <code>Bar</code> field in the JSON object,
+<code>Unmarshal</code> would allocate a new <code>Bar</code> and populate it.
+If not, <code>Bar</code> would be left as a <code>nil</code> pointer.
+</p>
+
+<p>
+From this a useful pattern arises: if you have an application that receives a
+few distinct message types, you might define "receiver" structure like
+</p>
+
+<pre>
+type IncomingMessage struct {
+    Cmd *Command
+    Msg *Message
+}
+</pre>
+
+<p>
+and the sending party can populate the <code>Cmd</code> field and/or the
+<code>Msg</code> field of the top-level JSON object, depending on the type of
+message they want to communicate. <code>Unmarshal</code>, when decoding the
+JSON into an <code>IncomingMessage</code> struct, will only allocate the data
+structures present in the JSON data. To know which messages to process, the
+programmer need simply test that either <code>Cmd</code> or <code>Msg</code> is
+not <code>nil</code>.
+</p>
+
+<p>
+<b>Streaming Encoders and Decoders</b>
+</p>
+
+<p>
+The json package provides <code>Decoder</code> and <code>Encoder</code> types
+to support the common operation of reading and writing streams of JSON data.
+The <code>NewDecoder</code> and <code>NewEncoder</code> functions wrap the
+<a href="/pkg/io/#Reader"><code>io.Reader</code></a> and
+<a href="/pkg/io/#Writer"><code>io.Writer</code></a> interface types.
+</p>
+
+<pre>
+func NewDecoder(r io.Reader) *Decoder
+func NewEncoder(w io.Writer) *Encoder
+</pre>
+
+<p>
+Here's an example program that reads a series of JSON objects from standard
+input, removes all but the <code>Name</code> field from each object, and then
+writes the objects to standard output:
+</p>
+
+{{code "/doc/progs/json5.go" `/package main/` `$`}}
+
+<p>
+Due to the ubiquity of Readers and Writers, these <code>Encoder</code> and
+<code>Decoder</code> types can be used in a broad range of scenarios, such as
+reading and writing to HTTP connections, WebSockets, or files.
+</p>
+
+<p>
+<b>References</b>
+</p>
+
+<p>
+For more information see the <a href="/pkg/encoding/json/">json package documentation</a>. For an example usage of
+json see the source files of the <a href="/pkg/net/rpc/jsonrpc/">jsonrpc package</a>.
+</p>
--- a/doc/articles/json_rpc_tale_of_interfaces.html
+++ b/doc/articles/json_rpc_tale_of_interfaces.html
@@ -0,0 +1,78 @@
+<!--{
+"Title": "JSON-RPC: a tale of interfaces"
+}-->
+
+<p>
+Here we present an example where Go's
+<a href="/doc/effective_go.html#interfaces_and_types">interfaces</a> made it
+easy to refactor some existing code to make it more flexible and extensible.
+Originally, the standard library's <a href="/pkg/net/rpc/">RPC package</a> used
+a custom wire format called <a href="/pkg/encoding/gob/">gob</a>. For a
+particular application, we wanted to use <a href="/pkg/encoding/json/">JSON</a>
+as an alternate wire format.
+</p>
+
+<p>
+We first defined a pair of interfaces to describe the functionality of the
+existing wire format, one for the client, and one for the server (depicted
+below).
+</p>
+
+<pre>
+type ServerCodec interface {
+	ReadRequestHeader(*Request) error
+	ReadRequestBody(interface{}) error
+	WriteResponse(*Response, interface{}) error
+	Close() error
+}
+</pre>
+
+<p>
+On the server side, we then changed two internal function signatures to accept
+the <code>ServerCodec</code> interface instead of our existing
+<code>gob.Encoder</code>. Here's one of them:
+</p>
+
+<pre>
+func sendResponse(sending *sync.Mutex, req *Request,
+	reply interface{}, enc *gob.Encoder, errmsg string)
+</pre>
+
+<p>
+became
+</p>
+
+<pre>
+func sendResponse(sending *sync.Mutex, req *Request,
+		reply interface{}, enc ServerCodec, errmsg string)
+</pre>
+
+<p>
+We then wrote a trivial <code>gobServerCodec</code> wrapper to reproduce the
+original functionality. From there it is simple to build a
+<code>jsonServerCodec</code>.
+</p>
+
+<p>
+After some similar changes to the client side, this was the full extent of the
+work we needed to do on the RPC package. This whole exercise took about 20
+minutes! After tidying up and testing the new code, the
+<a href="http://code.google.com/p/go/source/diff?spec=svn9daf796ebf1cae97b2fcf760a4ab682f1f063f29&amp;r=9daf796ebf1cae97b2fcf760a4ab682f1f063f29&amp;format=side&amp;path=/src/pkg/rpc/server.go">final changeset</a>
+was submitted.
+</p>
+
+<p>
+In an inheritance-oriented language like Java or C++, the obvious path would be
+to generalize the RPC class, and create JsonRPC and GobRPC subclasses. However,
+this approach becomes tricky if you want to make a further generalization
+orthogonal to that hierarchy. (For example, if you were to implement an
+alternate RPC standard). In our Go package, we took a route that is both
+conceptually simpler and requires less code be written or changed.
+</p>
+
+<p>
+A vital quality for any codebase is maintainability. As needs change, it is
+essential to adapt your code easily and cleanly, lest it become unwieldy to work
+with. We believe Go's lightweight, composition-oriented type system provides a
+means of structuring code that scales.
+</p>
--- a/doc/articles/laws_of_reflection.html
+++ b/doc/articles/laws_of_reflection.html
@@ -0,0 +1,649 @@
+<!--{
+	"Title": "The Laws of Reflection",
+	"Template": true
+}-->
+
+<p>
+Reflection in computing is the
+ability of a program to examine its own structure, particularly
+through types; it's a form of metaprogramming. It's also a great
+source of confusion.
+</p>
+
+<p>
+In this article we attempt to clarify things by explaining how
+reflection works in Go. Each language's reflection model is
+different (and many languages don't support it at all), but
+this article is about Go, so for the rest of this article the word
+"reflection" should be taken to mean "reflection in Go".
+</p>
+
+<p><b>Types and interfaces</b></p>
+
+<p>
+Because reflection builds on the type system, let's start with a
+refresher about types in Go.
+</p>
+
+<p>
+Go is statically typed. Every variable has a static type, that is,
+exactly one type known and fixed at compile time: <code>int</code>,
+<code>float32</code>, <code>*MyType</code>, <code>[]byte</code>,
+and so on. If we declare
+</p>
+
+{{code "/doc/progs/interface.go" `/type MyInt/` `/STOP/`}}
+
+<p>
+then <code>i</code> has type <code>int</code> and <code>j</code>
+has type <code>MyInt</code>. The variables <code>i</code> and
+<code>j</code> have distinct static types and, although they have
+the same underlying type, they cannot be assigned to one another
+without a conversion.
+</p>
+
+<p>
+One important category of type is interface types, which represent
+fixed sets of methods. An interface variable can store any concrete
+(non-interface) value as long as that value implements the
+interface's methods. A well-known pair of examples is
+<code>io.Reader</code> and <code>io.Writer</code>, the types
+<code>Reader</code> and <code>Writer</code> from the
+<a href="/pkg/io/">io package</a>:
+</p>
+
+{{code "/doc/progs/interface.go" `/// Reader/` `/STOP/`}}
+
+<p>
+Any type that implements a <code>Read</code> (or
+<code>Write</code>) method with this signature is said to implement
+<code>io.Reader</code> (or <code>io.Writer</code>). For the
+purposes of this discussion, that means that a variable of type
+<code>io.Reader</code> can hold any value whose type has a
+<code>Read</code> method:
+</p>
+
+{{code "/doc/progs/interface.go" `/func readers/` `/STOP/`}}
+
+<p>
+It's important to be clear that whatever concrete value
+<code>r</code> may hold, <code>r</code>'s type is always
+<code>io.Reader</code>: Go is statically typed and the static type
+of <code>r</code> is <code>io.Reader</code>.</p>
+
+<p>
+An extremely important example of an interface type is the empty
+interface:
+</p>
+
+<pre>
+interface{}
+</pre>
+
+<p>
+It represents the empty set of methods and is satisfied by any
+value at all, since any value has zero or more methods.
+</p>
+
+<p>
+Some people say that Go's interfaces are dynamically typed, but
+that is misleading. They are statically typed: a variable of
+interface type always has the same static type, and even though at
+run time the value stored in the interface variable may change
+type, that value will always satisfy the interface.
+</p>
+
+<p>
+We need to be precise about all this because reflection and
+interfaces are closely related.
+</p>
+
+<p><b>The representation of an interface</b></p>
+
+<p>
+Russ Cox has written a
+<a href="http://research.swtch.com/2009/12/go-data-structures-interfaces.html">detailed blog post</a>
+about the representation of interface values in Go. It's not necessary to
+repeat the full story here, but a simplified summary is in order.
+</p>
+
+<p>
+A variable of interface type stores a pair: the concrete value
+assigned to the variable, and that value's type descriptor.
+To be more precise, the value is the underlying concrete data item
+that implements the interface and the type describes the full type
+of that item. For instance, after
+</p>
+
+{{code "/doc/progs/interface.go" `/func typeAssertions/` `/STOP/`}}
+
+<p>
+<code>r</code> contains, schematically, the (value, type) pair,
+(<code>tty</code>, <code>*os.File</code>). Notice that the type
+<code>*os.File</code> implements methods other than
+<code>Read</code>; even though the interface value provides access
+only to the <code>Read</code> method, the value inside carries all
+the type information about that value. That's why we can do things
+like this:
+</p>
+
+{{code "/doc/progs/interface.go" `/var w io.Writer/` `/STOP/`}}
+
+<p>
+The expression in this assignment is a type assertion; what it
+asserts is that the item inside <code>r</code> also implements
+<code>io.Writer</code>, and so we can assign it to <code>w</code>.
+After the assignment, <code>w</code> will contain the pair
+(<code>tty</code>, <code>*os.File</code>). That's the same pair as
+was held in <code>r</code>. The static type of the interface
+determines what methods may be invoked with an interface variable,
+even though the concrete value inside may have a larger set of
+methods.
+</p>
+
+<p>
+Continuing, we can do this:
+</p>
+
+{{code "/doc/progs/interface.go" `/var empty interface{}/` `/STOP/`}}
+
+<p>
+and our empty interface value <code>e</code> will again contain
+that same pair, (<code>tty</code>, <code>*os.File</code>). That's
+handy: an empty interface can hold any value and contains all the
+information we could ever need about that value.
+</p>
+
+<p>
+(We don't need a type assertion here because it's known statically
+that <code>w</code> satisfies the empty interface. In the example
+where we moved a value from a <code>Reader</code> to a
+<code>Writer</code>, we needed to be explicit and use a type
+assertion because <code>Writer</code>'s methods are not a
+subset of <code>Reader</code>'s.)
+</p>
+
+<p>
+One important detail is that the pair inside an interface always
+has the form (value, concrete type) and cannot have the form
+(value, interface type). Interfaces do not hold interface
+values.
+</p>
+
+<p>
+Now we're ready to reflect.
+</p>
+
+<p><b>The first law of reflection</b></p>
+
+<p><b>1. Reflection goes from interface value to reflection object.</b></p>
+
+<p>
+At the basic level, reflection is just a mechanism to examine the
+type and value pair stored inside an interface variable. To get
+started, there are two types we need to know about in
+<a href="/pkg/reflect/">package reflect</a>:
+<a href="/pkg/reflect/#Type">Type</a> and
+<a href="/pkg/reflect/#Value">Value</a>. Those two types
+give access to the contents of an interface variable, and two
+simple functions, called <code>reflect.TypeOf</code> and
+<code>reflect.ValueOf</code>, retrieve <code>reflect.Type</code>
+and <code>reflect.Value</code> pieces out of an interface value.
+(Also, from the <code>reflect.Value</code> it's easy to get
+to the <code>reflect.Type</code>, but let's keep the
+<code>Value</code> and <code>Type</code> concepts separate for
+now.)
+</p>
+
+<p>
+Let's start with <code>TypeOf</code>:
+</p>
+
+{{code "/doc/progs/interface2.go" `/package main/` `/STOP main/`}}
+
+<p>
+This program prints
+</p>
+
+<pre>
+type: float64
+</pre>
+
+<p>
+You might be wondering where the interface is here, since the program looks
+like it's passing the <code>float64</code> variable <code>x</code>, not an
+interface value, to <code>reflect.TypeOf</code>. But it's there; as
+<a href="/pkg/reflect/#Type.TypeOf">godoc reports</a>, the signature of
+<code>reflect.TypeOf</code> includes an empty interface:
+</p>
+
+<pre>
+// TypeOf returns the reflection Type of the value in the interface{}.
+func TypeOf(i interface{}) Type
+</pre>
+
+<p>
+When we call <code>reflect.TypeOf(x)</code>, <code>x</code> is
+first stored in an empty interface, which is then passed as the
+argument; <code>reflect.TypeOf</code> unpacks that empty interface
+to recover the type information.
+</p>
+
+<p>
+The <code>reflect.ValueOf</code> function, of course, recovers the
+value (from here on we'll elide the boilerplate and focus just on
+the executable code):
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f9/` `/STOP/`}}
+
+<p>
+prints
+</p>
+
+<pre>
+value: &lt;float64 Value&gt;
+</pre>
+
+<p>
+Both <code>reflect.Type</code> and <code>reflect.Value</code> have
+lots of methods to let us examine and manipulate them. One
+important example is that <code>Value</code> has a
+<code>Type</code> method that returns the <code>Type</code> of a
+<code>reflect.Value</code>. Another is that both <code>Type</code>
+and <code>Value</code> have a <code>Kind</code> method that returns
+a constant indicating what sort of item is stored:
+<code>Uint</code>, <code>Float64</code>, <code>Slice</code>, and so
+on. Also methods on <code>Value</code> with names like
+<code>Int</code> and <code>Float</code> let us grab values (as
+<code>int64</code> and <code>float64</code>) stored inside:
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f1/` `/STOP/`}}
+
+<p>
+prints
+</p>
+
+<pre>
+type: float64
+kind is float64: true
+value: 3.4
+</pre>
+
+<p>
+There are also methods like <code>SetInt</code> and
+<code>SetFloat</code> but to use them we need to understand
+settability, the subject of the third law of reflection, discussed
+below.
+</p>
+
+<p>
+The reflection library has a couple of properties worth singling
+out. First, to keep the API simple, the "getter" and "setter"
+methods of <code>Value</code> operate on the largest type that can
+hold the value: <code>int64</code> for all the signed integers, for
+instance. That is, the <code>Int</code> method of
+<code>Value</code> returns an <code>int64</code> and the
+<code>SetInt</code> value takes an <code>int64</code>; it may be
+necessary to convert to the actual type involved:
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f2/` `/STOP/`}}
+
+<p>
+The second property is that the <code>Kind</code> of a reflection
+object describes the underlying type, not the static type. If a
+reflection object contains a value of a user-defined integer type,
+as in
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f3/` `/STOP/`}}
+
+<p>
+the <code>Kind</code> of <code>v</code> is still
+<code>reflect.Int</code>, even though the static type of
+<code>x</code> is <code>MyInt</code>, not <code>int</code>. In
+other words, the <code>Kind</code> cannot discriminate an int from
+a <code>MyInt</code> even though the <code>Type</code> can.
+</p>
+
+<p><b>The second law of reflection</b></p>
+
+<p><b>2. Reflection goes from reflection object to interface
+value.</b></p>
+
+<p>
+Like physical reflection, reflection in Go generates its own
+inverse.
+</p>
+
+<p>
+Given a <code>reflect.Value</code> we can recover an interface
+value using the <code>Interface</code> method; in effect the method
+packs the type and value information back into an interface
+representation and returns the result:
+</p>
+
+<pre>
+// Interface returns v's value as an interface{}.
+func (v Value) Interface() interface{}
+</pre>
+
+<p>
+As a consequence we can say
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f3b/` `/STOP/`}}
+
+<p>
+to print the <code>float64</code> value represented by the
+reflection object <code>v</code>.
+</p>
+
+<p>
+We can do even better, though. The arguments to
+<code>fmt.Println</code>, <code>fmt.Printf</code> and so on are all
+passed as empty interface values, which are then unpacked by the
+<code>fmt</code> package internally just as we have been doing in
+the previous examples. Therefore all it takes to print the contents
+of a <code>reflect.Value</code> correctly is to pass the result of
+the <code>Interface</code> method to the formatted print
+routine:
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f3c/` `/STOP/`}}
+
+<p>
+(Why not <code>fmt.Println(v)</code>? Because <code>v</code> is a
+<code>reflect.Value</code>; we want the concrete value it holds.)
+Since our value is a <code>float64</code>, we can even use a
+floating-point format if we want:
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f3d/` `/STOP/`}}
+
+<p>
+and get in this case
+</p>
+
+<pre>
+3.4e+00
+</pre>
+
+<p>
+Again, there's no need to type-assert the result of
+<code>v.Interface()</code> to <code>float64</code>; the empty
+interface value has the concrete value's type information inside
+and <code>Printf</code> will recover it.
+</p>
+
+<p>
+In short, the <code>Interface</code> method is the inverse of the
+<code>ValueOf</code> function, except that its result is always of
+static type <code>interface{}</code>.
+</p>
+
+<p>
+Reiterating: Reflection goes from interface values to reflection
+objects and back again.
+</p>
+
+<p><b>The third law of reflection</b></p>
+
+<p><b>3. To modify a reflection object, the value must be settable.</b></p>
+
+<p>
+The third law is the most subtle and confusing, but it's easy
+enough to understand if we start from first principles.
+</p>
+
+<p>
+Here is some code that does not work, but is worth studying.
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f4/` `/STOP/`}}
+
+<p>
+If you run this code, it will panic with the cryptic message
+</p>
+
+<pre>
+panic: reflect.Value.SetFloat using unaddressable value
+</pre>
+
+<p>
+The problem is not that the value <code>7.1</code> is not
+addressable; it's that <code>v</code> is not settable. Settability
+is a property of a reflection <code>Value</code>, and not all
+reflection <code>Values</code> have it.
+</p>
+
+<p>
+The <code>CanSet</code> method of <code>Value</code> reports the
+settability of a <code>Value</code>; in our case,
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f5/` `/STOP/`}}
+
+<p>
+prints
+</p>
+
+<pre>
+settability of v: false
+</pre>
+
+<p>
+It is an error to call a <code>Set</code> method on an non-settable
+<code>Value</code>. But what is settability?
+</p>
+
+<p>
+Settability is a bit like addressability, but stricter. It's the
+property that a reflection object can modify the actual storage
+that was used to create the reflection object. Settability is
+determined by whether the reflection object holds the original
+item. When we say
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f6/` `/STOP/`}}
+
+<p>
+we pass a <em>copy</em> of <code>x</code> to
+<code>reflect.ValueOf</code>, so the interface value created as the
+argument to <code>reflect.ValueOf</code> is a <em>copy</em> of
+<code>x</code>, not <code>x</code> itself. Thus, if the
+statement
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f6b/` `/STOP/`}}
+
+<p>
+were allowed to succeed, it would not update <code>x</code>, even
+though <code>v</code> looks like it was created from
+<code>x</code>. Instead, it would update the copy of <code>x</code>
+stored inside the reflection value and <code>x</code> itself would
+be unaffected. That would be confusing and useless, so it is
+illegal, and settability is the property used to avoid this
+issue.
+</p>
+
+<p>
+If this seems bizarre, it's not. It's actually a familiar situation
+in unusual garb. Think of passing <code>x</code> to a
+function:
+</p>
+
+<pre>
+f(x)
+</pre>
+
+<p>
+We would not expect <code>f</code> to be able to modify
+<code>x</code> because we passed a copy of <code>x</code>'s value,
+not <code>x</code> itself. If we want <code>f</code> to modify
+<code>x</code> directly we must pass our function the address of
+<code>x</code> (that is, a pointer to <code>x</code>):</p>
+
+<p>
+<code>f(&amp;x)</code>
+</p>
+
+<p>
+This is straightforward and familiar, and reflection works the same
+way. If we want to modify <code>x</code> by reflection, we must
+give the reflection library a pointer to the value we want to
+modify.
+</p>
+
+<p>
+Let's do that. First we initialize <code>x</code> as usual
+and then create a reflection value that points to it, called
+<code>p</code>.
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f7/` `/STOP/`}}
+
+<p>
+The output so far is
+</p>
+
+<pre>
+type of p: *float64
+settability of p: false
+</pre>
+
+<p>
+The reflection object <code>p</code> isn't settable, but it's not
+<code>p</code> we want to set, it's (in effect) <code>*p</code>. To
+get to what <code>p</code> points to, we call the <code>Elem</code>
+method of <code>Value</code>, which indirects through the pointer,
+and save the result in a reflection <code>Value</code> called
+<code>v</code>:
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f7b/` `/STOP/`}}
+
+<p>
+Now <code>v</code> is a settable reflection object, as the output
+demonstrates,
+</p>
+
+<pre>
+settability of v: true
+</pre>
+
+<p>
+and since it represents <code>x</code>, we are finally able to use
+<code>v.SetFloat</code> to modify the value of
+<code>x</code>:
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f7c/` `/STOP/`}}
+
+<p>
+The output, as expected, is
+</p>
+
+<pre>
+7.1
+7.1
+</pre>
+
+<p>
+Reflection can be hard to understand but it's doing exactly what
+the language does, albeit through reflection <code>Types</code> and
+<code>Values</code> that can disguise what's going on. Just keep in
+mind that reflection Values need the address of something in order
+to modify what they represent.
+</p>
+
+<p><b>Structs</b></p>
+
+<p>
+In our previous example <code>v</code> wasn't a pointer itself, it
+was just derived from one. A common way for this situation to arise
+is when using reflection to modify the fields of a structure. As
+long as we have the address of the structure, we can modify its
+fields.
+</p>
+
+<p>
+Here's a simple example that analyzes a struct value, <code>t</code>. We create
+the reflection object with the address of the struct because we'll want to
+modify it later. Then we set <code>typeOfT</code> to its type and iterate over
+the fields using straightforward method calls
+(see <a href="/pkg/reflect/">package reflect</a> for details).
+Note that we extract the names of the fields from the struct type, but the
+fields themselves are regular <code>reflect.Value</code> objects.
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f8/` `/STOP/`}}
+
+<p>
+The output of this program is
+</p>
+
+<pre>
+0: A int = 23
+1: B string = skidoo
+</pre>
+
+<p>
+There's one more point about settability introduced in
+passing here: the field names of <code>T</code> are upper case
+(exported) because only exported fields of a struct are
+settable.
+</p>
+
+<p>
+Because <code>s</code> contains a settable reflection object, we
+can modify the fields of the structure.
+</p>
+
+{{code "/doc/progs/interface2.go" `/START f8b/` `/STOP/`}}
+
+<p>
+And here's the result:
+</p>
+
+<pre>
+t is now {77 Sunset Strip}
+</pre>
+
+<p>
+If we modified the program so that <code>s</code> was created from
+<code>t</code>, not <code>&amp;t</code>, the calls to
+<code>SetInt</code> and <code>SetString</code> would fail as the
+fields of <code>t</code> would not be settable.
+</p>
+
+<p><b>Conclusion</b></p>
+
+<p>
+Here again are the laws of reflection:
+</p>
+
+<ol>
+<li>Reflection goes from interface value to reflection
+object.</li>
+<li>Reflection goes from reflection object to interface
+value.</li>
+<li>To modify a reflection object, the value must be settable.</li>
+</ol>
+
+<p>
+Once you understand these laws reflection in Go becomes much easier
+to use, although it remains subtle. It's a powerful tool that
+should be used with care and avoided unless strictly
+necessary.
+</p>
+
+<p>
+There's plenty more to reflection that we haven't covered &mdash;
+sending and receiving on channels, allocating memory, using slices
+and maps, calling methods and functions &mdash; but this post is
+long enough. We'll cover some of those topics in a later
+article.
+</p>
--- a/doc/articles/race_detector.html
+++ b/doc/articles/race_detector.html
@@ -1,389 +0,0 @@
-<!--{
-	"Title": "Data Race Detector",
-	"Template": true
-}-->
-
-<h2 id="Introduction">Introduction</h2>
-
-<p>
-Data races are among the most common and hardest to debug types of bugs in concurrent systems.
-A data race occurs when two goroutines access the same variable concurrently and at least one of the accesses is a write.
-See the <a href="/ref/mem/">The Go Memory Model</a> for details.
-</p>
-
-<p>
-Here is an example of a data race that can lead to crashes and memory corruption:
-</p>
-
-<pre>
-func main() {
-	c := make(chan bool)
-	m := make(map[string]string)
-	go func() {
-		m["1"] = "a" // First conflicting access.
-		c &lt;- true
-	}()
-	m["2"] = "b" // Second conflicting access.
-	&lt;-c
-	for k, v := range m {
-		fmt.Println(k, v)
-	}
-}
-</pre>
-
-<h2 id="Usage">Usage</h2>
-
-<p>
-To help diagnose such bugs, Go includes a built-in data race detector.
-To use it, add the <code>-race</code> flag to the go command:
-</p>
-
-<pre>
-$ go test -race mypkg    // to test the package
-$ go run -race mysrc.go  // to run the source file
-$ go build -race mycmd   // to build the command
-$ go install -race mypkg // to install the package
-</pre>
-
-<h2 id="Report_Format">Report Format</h2>
-
-<p>
-When the race detector finds a data race in the program, it prints a report.
-The report contains stack traces for conflicting accesses, as well as stacks where the involved goroutines were created.
-Here is an example:
-</p>
-
-<pre>
-WARNING: DATA RACE
-Read by goroutine 185:
-  net.(*pollServer).AddFD()
-      src/net/fd_unix.go:89 +0x398
-  net.(*pollServer).WaitWrite()
-      src/net/fd_unix.go:247 +0x45
-  net.(*netFD).Write()
-      src/net/fd_unix.go:540 +0x4d4
-  net.(*conn).Write()
-      src/net/net.go:129 +0x101
-  net.func·060()
-      src/net/timeout_test.go:603 +0xaf
-
-Previous write by goroutine 184:
-  net.setWriteDeadline()
-      src/net/sockopt_posix.go:135 +0xdf
-  net.setDeadline()
-      src/net/sockopt_posix.go:144 +0x9c
-  net.(*conn).SetDeadline()
-      src/net/net.go:161 +0xe3
-  net.func·061()
-      src/net/timeout_test.go:616 +0x3ed
-
-Goroutine 185 (running) created at:
-  net.func·061()
-      src/net/timeout_test.go:609 +0x288
-
-Goroutine 184 (running) created at:
-  net.TestProlongTimeout()
-      src/net/timeout_test.go:618 +0x298
-  testing.tRunner()
-      src/testing/testing.go:301 +0xe8
-</pre>
-
-<h2 id="Options">Options</h2>
-
-<p>
-The <code>GORACE</code> environment variable sets race detector options.
-The format is:
-</p>
-
-<pre>
-GORACE="option1=val1 option2=val2"
-</pre>
-
-<p>
-The options are:
-</p>
-
-<ul>
-<li>
-<code>log_path</code> (default <code>stderr</code>): The race detector writes
-its report to a file named <code>log_path.<em>pid</em></code>.
-The special names <code>stdout</code>
-and <code>stderr</code> cause reports to be written to standard output and
-standard error, respectively.
-</li>
-
-<li>
-<code>exitcode</code> (default <code>66</code>): The exit status to use when
-exiting after a detected race.
-</li>
-
-<li>
-<code>strip_path_prefix</code> (default <code>""</code>): Strip this prefix
-from all reported file paths, to make reports more concise.
-</li>
-
-<li>
-<code>history_size</code> (default <code>1</code>): The per-goroutine memory
-access history is <code>32K * 2**history_size elements</code>.
-Increasing this value can avoid a "failed to restore the stack" error in reports, at the
-cost of increased memory usage.
-</li>
-
-<li>
-<code>halt_on_error</code> (default <code>0</code>): Controls whether the program
-exits after reporting first data race.
-</li>
-</ul>
-
-<p>
-Example:
-</p>
-
-<pre>
-$ GORACE="log_path=/tmp/race/report strip_path_prefix=/my/go/sources/" go test -race
-</pre>
-
-<h2 id="Excluding_Tests">Excluding Tests</h2>
-
-<p>
-When you build with <code>-race</code> flag, the <code>go</code> command defines additional
-<a href="/pkg/go/build/#hdr-Build_Constraints">build tag</a> <code>race</code>.
-You can use the tag to exclude some code and tests when running the race detector.
-Some examples:
-</p>
-
-<pre>
-// +build !race
-
-package foo
-
-// The test contains a data race. See issue 123.
-func TestFoo(t *testing.T) {
-	// ...
-}
-
-// The test fails under the race detector due to timeouts.
-func TestBar(t *testing.T) {
-	// ...
-}
-
-// The test takes too long under the race detector.
-func TestBaz(t *testing.T) {
-	// ...
-}
-</pre>
-
-<h2 id="How_To_Use">How To Use</h2>
-
-<p>
-To start, run your tests using the race detector (<code>go test -race</code>).
-The race detector only finds races that happen at runtime, so it can't find
-races in code paths that are not executed.
-If your tests have incomplete coverage,
-you may find more races by running a binary built with <code>-race</code> under a realistic
-workload.
-</p>
-
-<h2 id="Typical_Data_Races">Typical Data Races</h2>
-
-<p>
-Here are some typical data races.  All of them can be detected with the race detector.
-</p>
-
-<h3 id="Race_on_loop_counter">Race on loop counter</h3>
-
-<pre>
-func main() {
-	var wg sync.WaitGroup
-	wg.Add(5)
-	for i := 0; i < 5; i++ {
-		go func() {
-			fmt.Println(i) // Not the 'i' you are looking for.
-			wg.Done()
-		}()
-	}
-	wg.Wait()
-}
-</pre>
-
-<p>
-The variable <code>i</code> in the function literal is the same variable used by the loop, so
-the read in the goroutine races with the loop increment.
-(This program typically prints 55555, not 01234.)
-The program can be fixed by making a copy of the variable:
-</p>
-
-<pre>
-func main() {
-	var wg sync.WaitGroup
-	wg.Add(5)
-	for i := 0; i < 5; i++ {
-		go func(j int) {
-			fmt.Println(j) // Good. Read local copy of the loop counter.
-			wg.Done()
-		}(i)
-	}
-	wg.Wait()
-}
-</pre>
-
-<h3 id="Accidentally_shared_variable">Accidentally shared variable</h3>
-
-<pre>
-// ParallelWrite writes data to file1 and file2, returns the errors.
-func ParallelWrite(data []byte) chan error {
-	res := make(chan error, 2)
-	f1, err := os.Create("file1")
-	if err != nil {
-		res &lt;- err
-	} else {
-		go func() {
-			// This err is shared with the main goroutine,
-			// so the write races with the write below.
-			_, err = f1.Write(data)
-			res &lt;- err
-			f1.Close()
-		}()
-	}
-	f2, err := os.Create("file2") // The second conflicting write to err.
-	if err != nil {
-		res &lt;- err
-	} else {
-		go func() {
-			_, err = f2.Write(data)
-			res &lt;- err
-			f2.Close()
-		}()
-	}
-	return res
-}
-</pre>
-
-<p>
-The fix is to introduce new variables in the goroutines (note the use of <code>:=</code>):
-</p>
-
-<pre>
-			...
-			_, err := f1.Write(data)
-			...
-			_, err := f2.Write(data)
-			...
-</pre>
-
-<h3 id="Unprotected_global_variable">Unprotected global variable</h3>
-
-<p>
-If the following code is called from several goroutines, it leads to races on the <code>service</code> map.
-Concurrent reads and writes of the same map are not safe:
-</p>
-
-<pre>
-var service map[string]net.Addr
-
-func RegisterService(name string, addr net.Addr) {
-	service[name] = addr
-}
-
-func LookupService(name string) net.Addr {
-	return service[name]
-}
-</pre>
-
-<p>
-To make the code safe, protect the accesses with a mutex:
-</p>
-
-<pre>
-var (
-	service   map[string]net.Addr
-	serviceMu sync.Mutex
-)
-
-func RegisterService(name string, addr net.Addr) {
-	serviceMu.Lock()
-	defer serviceMu.Unlock()
-	service[name] = addr
-}
-
-func LookupService(name string) net.Addr {
-	serviceMu.Lock()
-	defer serviceMu.Unlock()
-	return service[name]
-}
-</pre>
-
-<h3 id="Primitive_unprotected_variable">Primitive unprotected variable</h3>
-
-<p>
-Data races can happen on variables of primitive types as well (<code>bool</code>, <code>int</code>, <code>int64</code>, etc.),
-as in this example:
-</p>
-
-<pre>
-type Watchdog struct{ last int64 }
-
-func (w *Watchdog) KeepAlive() {
-	w.last = time.Now().UnixNano() // First conflicting access.
-}
-
-func (w *Watchdog) Start() {
-	go func() {
-		for {
-			time.Sleep(time.Second)
-			// Second conflicting access.
-			if w.last < time.Now().Add(-10*time.Second).UnixNano() {
-				fmt.Println("No keepalives for 10 seconds. Dying.")
-				os.Exit(1)
-			}
-		}
-	}()
-}
-</pre>
-
-<p>
-Even such "innocent" data races can lead to hard-to-debug problems caused by
-non-atomicity of the memory accesses,
-interference with compiler optimizations,
-or reordering issues accessing processor memory .
-</p>
-
-<p>
-A typical fix for this race is to use a channel or a mutex.
-To preserve the lock-free behavior, one can also use the
-<a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package.
-</p>
-
-<pre>
-type Watchdog struct{ last int64 }
-
-func (w *Watchdog) KeepAlive() {
-	atomic.StoreInt64(&amp;w.last, time.Now().UnixNano())
-}
-
-func (w *Watchdog) Start() {
-	go func() {
-		for {
-			time.Sleep(time.Second)
-			if atomic.LoadInt64(&amp;w.last) < time.Now().Add(-10*time.Second).UnixNano() {
-				fmt.Println("No keepalives for 10 seconds. Dying.")
-				os.Exit(1)
-			}
-		}
-	}()
-}
-</pre>
-
-<h2 id="Supported_Systems">Supported Systems</h2>
-
-<p>
-The race detector runs on <code>darwin/amd64</code>, <code>freebsd/amd64</code>,
-<code>linux/amd64</code>, and <code>windows/amd64</code>.
-</p>
-
-<h2 id="Runtime_Overheads">Runtime Overhead</h2>
-
-<p>
-The cost of race detection varies by program, but for a typical program, memory
-usage may increase by 5-10x and execution time by 2-20x.
-</p>
--- a/doc/articles/slice-1.png
+++ b/doc/articles/slice-1.png
--- a/doc/articles/slice-2.png
+++ b/doc/articles/slice-2.png
--- a/doc/articles/slice-3.png
+++ b/doc/articles/slice-3.png
--- a/doc/articles/slice-array.png
+++ b/doc/articles/slice-array.png
--- a/doc/articles/slice-struct.png
+++ b/doc/articles/slice-struct.png
--- a/doc/articles/slices_usage_and_internals.html
+++ b/doc/articles/slices_usage_and_internals.html
@@ -0,0 +1,438 @@
+<!--{
+	"Title": "Slices: usage and internals",
+	"Template": true
+}-->
+
+<p>
+Go's slice type provides a convenient and efficient means of working with
+sequences of typed data. Slices are analogous to arrays in other languages, but
+have some unusual properties. This article will look at what slices are and how
+they are used.
+</p>
+
+<p>
+<b>Arrays</b>
+</p>
+
+<p>
+The slice type is an abstraction built on top of Go's array type, and so to
+understand slices we must first understand arrays.
+</p>
+
+<p>
+An array type definition specifies a length and an element type. For example,
+the type <code>[4]int</code> represents an array of four integers. An array's
+size is fixed; its length is part of its type (<code>[4]int</code> and
+<code>[5]int</code> are distinct, incompatible types). Arrays can be indexed in
+the usual way, so the expression <code>s[n]</code> accesses the <i>n</i>th
+element:
+</p>
+
+<pre>
+var a [4]int
+a[0] = 1
+i := a[0]
+// i == 1
+</pre>
+
+<p>
+Arrays do not need to be initialized explicitly; the zero value of an array is
+a ready-to-use array whose elements are themselves zeroed:
+</p>
+
+<pre>
+// a[2] == 0, the zero value of the int type
+</pre>
+
+<p>
+The in-memory representation of <code>[4]int</code> is just four integer values laid out sequentially:
+</p>
+
+<p>
+<img src="slice-array.png">
+</p>
+
+<p>
+Go's arrays are values. An array variable denotes the entire array; it is not a
+pointer to the first array element (as would be the case in C).  This means
+that when you assign or pass around an array value you will make a copy of its
+contents. (To avoid the copy you could pass a <i>pointer</i> to the array, but
+then that's a pointer to an array, not an array.) One way to think about arrays
+is as a sort of struct but with indexed rather than named fields: a fixed-size
+composite value.
+</p>
+
+<p>
+An array literal can be specified like so:
+</p>
+
+<pre>
+b := [2]string{"Penn", "Teller"}
+</pre>
+
+<p>
+Or, you can have the compiler count the array elements for you:
+</p>
+
+<pre>
+b := [...]string{"Penn", "Teller"}
+</pre>
+
+<p>
+In both cases, the type of <code>b</code> is <code>[2]string</code>.
+</p>
+
+<p>
+<b>Slices</b>
+</p>
+
+<p>
+Arrays have their place, but they're a bit inflexible, so you don't see them
+too often in Go code. Slices, though, are everywhere. They build on arrays to
+provide great power and convenience.
+</p>
+
+<p>
+The type specification for a slice is <code>[]T</code>, where <code>T</code> is
+the type of the elements of the slice. Unlike an array type, a slice type has
+no specified length.
+</p>
+
+<p>
+A slice literal is declared just like an array literal, except you leave out
+the element count:
+</p>
+
+<pre>
+letters := []string{"a", "b", "c", "d"}
+</pre>
+
+<p>
+A slice can be created with the built-in function called <code>make</code>,
+which has the signature,
+</p>
+
+<pre>
+func make([]T, len, cap) []T
+</pre>
+
+<p>
+where T stands for the element type of the slice to be created. The
+<code>make</code> function takes a type, a length, and an optional capacity.
+When called, <code>make</code> allocates an array and returns a slice that
+refers to that array.
+</p>
+
+<pre>
+var s []byte
+s = make([]byte, 5, 5)
+// s == []byte{0, 0, 0, 0, 0}
+</pre>
+
+<p>
+When the capacity argument is omitted, it defaults to the specified length.
+Here's a more succinct version of the same code:
+</p>
+
+<pre>
+s := make([]byte, 5)
+</pre>
+
+<p>
+The length and capacity of a slice can be inspected using the built-in
+<code>len</code> and <code>cap</code> functions.
+</p>
+
+<pre>
+len(s) == 5
+cap(s) == 5
+</pre>
+
+<p>
+The next two sections discuss the relationship between length and capacity.
+</p>
+
+<p>
+The zero value of a slice is <code>nil</code>. The <code>len</code> and
+<code>cap</code> functions will both return 0 for a nil slice.
+</p>
+
+<p>
+A slice can also be formed by "slicing" an existing slice or array. Slicing is
+done by specifying a half-open range with two indices separated by a colon. For
+example, the expression <code>b[1:4]</code> creates a slice including elements
+1 through 3 of <code>b</code> (the indices of the resulting slice will be 0
+through 2).
+</p>
+
+<pre>
+b := []byte{'g', 'o', 'l', 'a', 'n', 'g'}
+// b[1:4] == []byte{'o', 'l', 'a'}, sharing the same storage as b
+</pre>
+
+<p>
+The start and end indices of a slice expression are optional; they default to zero and the slice's length respectively:
+</p>
+
+<pre>
+// b[:2] == []byte{'g', 'o'}
+// b[2:] == []byte{'l', 'a', 'n', 'g'}
+// b[:] == b
+</pre>
+
+<p>
+This is also the syntax to create a slice given an array:
+</p>
+
+<pre>
+x := [3]string{"Лайка", "Белка", "Стрелка"}
+s := x[:] // a slice referencing the storage of x
+</pre>
+
+<p>
+<b>Slice internals</b>
+</p>
+
+<p>
+A slice is a descriptor of an array segment. It consists of a pointer to the
+array, the length of the segment, and its capacity (the maximum length of the
+segment).
+</p>
+
+<p>
+<img src="slice-struct.png">
+</p>
+
+<p>
+Our variable <code>s</code>, created earlier by <code>make([]byte, 5)</code>,
+is structured like this:
+</p>
+
+<p>
+<img src="slice-1.png">
+</p>
+
+<p>
+The length is the number of elements referred to by the slice. The capacity is
+the number of elements in the underlying array (beginning at the element
+referred to by the slice pointer). The distinction between length and capacity
+will be made clear as we walk through the next few examples.
+</p>
+
+<p>
+As we slice <code>s</code>, observe the changes in the slice data structure and
+their relation to the underlying array:
+</p>
+
+<pre>
+s = s[2:4]
+</pre>
+
+<p>
+<img src="slice-2.png">
+</p>
+
+<p>
+Slicing does not copy the slice's data. It creates a new slice value that
+points to the original array. This makes slice operations as efficient as
+manipulating array indices. Therefore, modifying the <i>elements</i> (not the
+slice itself) of a re-slice modifies the elements of the original slice:
+</p>
+
+<pre>
+d := []byte{'r', 'o', 'a', 'd'}
+e := d[2:] 
+// e == []byte{'a', 'd'}
+e[1] = 'm'
+// e == []byte{'a', 'm'}
+// d == []byte{'r', 'o', 'a', 'm'}
+</pre>
+
+<p>
+Earlier we sliced <code>s</code> to a length shorter than its capacity. We can
+grow s to its capacity by slicing it again:
+</p>
+
+<pre>
+s = s[:cap(s)]
+</pre>
+
+<p>
+<img src="slice-3.png">
+</p>
+
+<p>
+A slice cannot be grown beyond its capacity. Attempting to do so will cause a
+runtime panic, just as when indexing outside the bounds of a slice or array.
+Similarly, slices cannot be re-sliced below zero to access earlier elements in
+the array.
+</p>
+
+<p>
+<b>Growing slices (the copy and append functions)</b>
+</p>
+
+<p>
+To increase the capacity of a slice one must create a new, larger slice and
+copy the contents of the original slice into it. This technique is how dynamic
+array implementations from other languages work behind the scenes. The next
+example doubles the capacity of <code>s</code> by making a new slice,
+<code>t</code>, copying the contents of <code>s</code> into <code>t</code>, and
+then assigning the slice value <code>t</code> to <code>s</code>:
+</p>
+
+<pre>
+t := make([]byte, len(s), (cap(s)+1)*2) // +1 in case cap(s) == 0
+for i := range s {
+        t[i] = s[i]
+}
+s = t
+</pre>
+
+<p>
+The looping piece of this common operation is made easier by the built-in copy
+function. As the name suggests, copy copies data from a source slice to a
+destination slice. It returns the number of elements copied.
+</p>
+
+<pre>
+func copy(dst, src []T) int
+</pre>
+
+<p>
+The <code>copy</code> function supports copying between slices of different
+lengths (it will copy only up to the smaller number of elements). In addition,
+<code>copy</code> can handle source and destination slices that share the same
+underlying array, handling overlapping slices correctly.
+</p>
+
+<p>
+Using <code>copy</code>, we can simplify the code snippet above:
+</p>
+
+<pre>
+t := make([]byte, len(s), (cap(s)+1)*2)
+copy(t, s)
+s = t
+</pre>
+
+<p>
+A common operation is to append data to the end of a slice. This function
+appends byte elements to a slice of bytes, growing the slice if necessary, and
+returns the updated slice value:
+</p>
+
+{{code "/doc/progs/slices.go" `/AppendByte/` `/STOP/`}}
+
+<p>
+One could use <code>AppendByte</code> like this:
+</p>
+
+<pre>
+p := []byte{2, 3, 5}
+p = AppendByte(p, 7, 11, 13)
+// p == []byte{2, 3, 5, 7, 11, 13}
+</pre>
+
+<p>
+Functions like <code>AppendByte</code> are useful because they offer complete
+control over the way the slice is grown. Depending on the characteristics of
+the program, it may be desirable to allocate in smaller or larger chunks, or to
+put a ceiling on the size of a reallocation.
+</p>
+
+<p>
+But most programs don't need complete control, so Go provides a built-in
+<code>append</code> function that's good for most purposes; it has the
+signature
+</p>
+
+<pre>
+func append(s []T, x ...T) []T 
+</pre>
+
+<p>
+The <code>append</code> function appends the elements <code>x</code> to the end
+of the slice <code>s</code>, and grows the slice if a greater capacity is
+needed.
+</p>
+
+<pre>
+a := make([]int, 1)
+// a == []int{0}
+a = append(a, 1, 2, 3)
+// a == []int{0, 1, 2, 3}
+</pre>
+
+<p>
+To append one slice to another, use <code>...</code> to expand the second
+argument to a list of arguments.
+</p>
+
+<pre>
+a := []string{"John", "Paul"}
+b := []string{"George", "Ringo", "Pete"}
+a = append(a, b...) // equivalent to "append(a, b[0], b[1], b[2])"
+// a == []string{"John", "Paul", "George", "Ringo", "Pete"}
+</pre>
+
+<p>
+Since the zero value of a slice (<code>nil</code>) acts like a zero-length
+slice, you can declare a slice variable and then append to it in a loop:
+</p>
+
+{{code "/doc/progs/slices.go" `/Filter/` `/STOP/`}}
+
+<p>
+<b>A possible "gotcha"</b>
+</p>
+
+<p>
+As mentioned earlier, re-slicing a slice doesn't make a copy of the underlying
+array. The full array will be kept in memory until it is no longer referenced.
+Occasionally this can cause the program to hold all the data in memory when
+only a small piece of it is needed.
+</p>
+
+<p>
+For example, this <code>FindDigits</code> function loads a file into memory and
+searches it for the first group of consecutive numeric digits, returning them
+as a new slice.
+</p>
+
+{{code "/doc/progs/slices.go" `/digit/` `/STOP/`}}
+
+<p>
+This code behaves as advertised, but the returned <code>[]byte</code> points
+into an array containing the entire file. Since the slice references the
+original array, as long as the slice is kept around the garbage collector can't
+release the array; the few useful bytes of the file keep the entire contents in
+memory.
+</p>
+
+<p>
+To fix this problem one can copy the interesting data to a new slice before
+returning it:
+</p>
+
+{{code "/doc/progs/slices.go" `/CopyDigits/` `/STOP/`}}
+
+<p>
+A more concise version of this function could be constructed by using
+<code>append</code>. This is left as an exercise for the reader.
+</p>
+
+<p>
+<b>Further Reading</b>
+</p>
+
+<p>
+<a href="/doc/effective_go.html">Effective Go</a> contains an
+in-depth treatment of <a href="/doc/effective_go.html#slices">slices</a>
+and <a href="/doc/effective_go.html#arrays">arrays</a>, 
+and the Go <a href="/doc/go_spec.html">language specification</a>
+defines <a href="/doc/go_spec.html#Slice_types">slices</a> and their
+<a href="/doc/go_spec.html#Length_and_capacity">associated</a>
+<a href="/doc/go_spec.html#Making_slices_maps_and_channels">helper</a>
+<a href="/doc/go_spec.html#Appending_and_copying_slices">functions</a>.
+</p>
--- a/doc/articles/wiki/Makefile
+++ b/doc/articles/wiki/Makefile
@@ -0,0 +1,20 @@
+# Copyright 2010 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.
+
+all: index.html
+
+CLEANFILES:=srcextract.bin htmlify.bin get.bin
+
+index.html: wiki.html srcextract.bin htmlify.bin
+	PATH=.:$$PATH awk '/^!/{system(substr($$0,2)); next} {print}' < wiki.html | tr -d '\r' > index.html
+
+test: get.bin
+	bash ./test.sh
+	rm -f get.6 get.bin
+
+%.bin: %.go
+	go build -o $@ $^
+
+clean:
+	rm -f $(CLEANFILES)
--- a/doc/articles/wiki/final-noclosure.go
+++ b/doc/articles/wiki/final-noclosure.go
@@ -83,15 +83,17 @@ func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
 	}
 }

-var validPath = regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
+const lenPath = len("/view/")

-func getTitle(w http.ResponseWriter, r *http.Request) (string, error) {
-	m := validPath.FindStringSubmatch(r.URL.Path)
-	if m == nil {
+var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")
+
+func getTitle(w http.ResponseWriter, r *http.Request) (title string, err error) {
+	title = r.URL.Path[lenPath:]
+	if !titleValidator.MatchString(title) {
 		http.NotFound(w, r)
-		return "", errors.New("Invalid Page Title")
+		err = errors.New("Invalid Page Title")
 	}
-	return m[2], nil // The title is the second subexpression.
+	return
 }

 func main() {
--- a/doc/articles/wiki/final-noerror.go
+++ b/doc/articles/wiki/final-noerror.go
@@ -29,8 +29,10 @@ func loadPage(title string) (*Page, error) {
 	return &Page{Title: title, Body: body}, nil
 }

+const lenPath = len("/view/")
+
 func editHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/edit/"):]
+	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &Page{Title: title}
@@ -40,7 +42,7 @@ func editHandler(w http.ResponseWriter, r *http.Request) {
 }

 func viewHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/view/"):]
+	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
 	t, _ := template.ParseFiles("view.html")
 	t.Execute(w, p)
--- a/doc/articles/wiki/final-parsetemplate.go
+++ b/doc/articles/wiki/final-parsetemplate.go
@@ -70,16 +70,18 @@ func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
 	}
 }

-var validPath = regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
+const lenPath = len("/view/")
+
+var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")

 func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
 	return func(w http.ResponseWriter, r *http.Request) {
-		m := validPath.FindStringSubmatch(r.URL.Path)
-		if m == nil {
+		title := r.URL.Path[lenPath:]
+		if !titleValidator.MatchString(title) {
 			http.NotFound(w, r)
 			return
 		}
-		fn(w, r, m[2])
+		fn(w, r, title)
 	}
 }

--- a/doc/articles/wiki/final-template.go
+++ b/doc/articles/wiki/final-template.go
@@ -29,8 +29,10 @@ func loadPage(title string) (*Page, error) {
 	return &Page{Title: title, Body: body}, nil
 }

+const lenPath = len("/view/")
+
 func editHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/edit/"):]
+	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &Page{Title: title}
@@ -39,13 +41,13 @@ func editHandler(w http.ResponseWriter, r *http.Request) {
 }

 func viewHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/view/"):]
+	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
 	renderTemplate(w, "view", p)
 }

 func saveHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/save/"):]
+	title := r.URL.Path[lenPath:]
 	body := r.FormValue("body")
 	p := &Page{Title: title, Body: []byte(body)}
 	p.save()
--- a/doc/articles/wiki/final.go
+++ b/doc/articles/wiki/final.go
@@ -5,19 +5,12 @@
 package main

 import (
-	"flag"
 	"html/template"
 	"io/ioutil"
-	"log"
-	"net"
 	"net/http"
 	"regexp"
 )

-var (
-	addr = flag.Bool("addr", false, "find open address and print to final-port.txt")
-)
-
 type Page struct {
 	Title string
 	Body  []byte
@@ -74,38 +67,24 @@ func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
 	}
 }

-var validPath = regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
+const lenPath = len("/view/")
+
+var titleValidator = regexp.MustCompile("^[a-zA-Z0-9]+$")

 func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
 	return func(w http.ResponseWriter, r *http.Request) {
-		m := validPath.FindStringSubmatch(r.URL.Path)
-		if m == nil {
+		title := r.URL.Path[lenPath:]
+		if !titleValidator.MatchString(title) {
 			http.NotFound(w, r)
 			return
 		}
-		fn(w, r, m[2])
+		fn(w, r, title)
 	}
 }

 func main() {
-	flag.Parse()
 	http.HandleFunc("/view/", makeHandler(viewHandler))
 	http.HandleFunc("/edit/", makeHandler(editHandler))
 	http.HandleFunc("/save/", makeHandler(saveHandler))
-
-	if *addr {
-		l, err := net.Listen("tcp", "127.0.0.1:0")
-		if err != nil {
-			log.Fatal(err)
-		}
-		err = ioutil.WriteFile("final-port.txt", []byte(l.Addr().String()), 0644)
-		if err != nil {
-			log.Fatal(err)
-		}
-		s := &http.Server{}
-		s.Serve(l)
-		return
-	}
-
 	http.ListenAndServe(":8080", nil)
 }
--- a/doc/articles/wiki/get.go
+++ b/doc/articles/wiki/get.go
@@ -13,13 +13,11 @@ import (
 	"net/http"
 	"os"
 	"strings"
-	"time"
 )

 var (
 	post = flag.String("post", "", "urlencoded form data to POST")
 	addr = flag.Bool("addr", false, "find open address and print to stdout")
-	wait = flag.Duration("wait_for_port", 0, "if non-zero, the amount of time to wait for the address to become available")
 )

 func main() {
@@ -39,18 +37,11 @@ func main() {
 	}
 	var r *http.Response
 	var err error
-	loopUntil := time.Now().Add(*wait)
-	for {
-		if *post != "" {
-			b := strings.NewReader(*post)
-			r, err = http.Post(url, "application/x-www-form-urlencoded", b)
-		} else {
-			r, err = http.Get(url)
-		}
-		if err == nil || *wait == 0 || time.Now().After(loopUntil) {
-			break
-		}
-		time.Sleep(100 * time.Millisecond)
+	if *post != "" {
+		b := strings.NewReader(*post)
+		r, err = http.Post(url, "application/x-www-form-urlencoded", b)
+	} else {
+		r, err = http.Get(url)
 	}
 	if err != nil {
 		log.Fatal(err)
--- a/doc/articles/wiki/htmlify.go
+++ b/doc/articles/wiki/htmlify.go
@@ -0,0 +1,16 @@
+// Copyright 2010 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.
+
+package main
+
+import (
+	"io/ioutil"
+	"os"
+	"text/template"
+)
+
+func main() {
+	b, _ := ioutil.ReadAll(os.Stdin)
+	template.HTMLEscape(os.Stdout, b)
+}
--- a/doc/articles/wiki/index.html
+++ b/doc/articles/wiki/index.html
@@ -46,7 +46,7 @@ $ cd gowiki
 </pre>

 <p>
-Create a file named <code>wiki.go</code>, open it in your favorite editor, and
+Create a file named <code>wiki.go</code>, open it in your favorite editor, and 
 add the following lines:
 </p>

@@ -60,8 +60,8 @@ import (
 </pre>

 <p>
-We import the <code>fmt</code> and <code>ioutil</code> packages from the Go
-standard library. Later, as we implement additional functionality, we will
+We import the <code>fmt</code> and <code>ioutil</code> packages from the Go 
+standard library. Later, as we implement additional functionality, we will 
 add more packages to this <code>import</code> declaration.
 </p>

@@ -77,7 +77,7 @@ the title and body.
 {{code "doc/articles/wiki/part1.go" `/^type Page/` `/}/`}}

 <p>
-The type <code>[]byte</code> means "a <code>byte</code> slice".
+The type <code>[]byte</code> means "a <code>byte</code> slice". 
 (See <a href="/doc/articles/slices_usage_and_internals.html">Slices: usage and
 internals</a> for more on slices.)
 The <code>Body</code> element is a <code>[]byte</code> rather than
@@ -86,8 +86,8 @@ libraries we will use, as you'll see below.
 </p>

 <p>
-The <code>Page</code> struct describes how page data will be stored in memory.
-But what about persistent storage? We can address that by creating a
+The <code>Page</code> struct describes how page data will be stored in memory. 
+But what about persistent storage? We can address that by creating a 
 <code>save</code> method on <code>Page</code>:
 </p>

@@ -96,11 +96,11 @@ But what about persistent storage? We can address that by creating a
 <p>
 This method's signature reads: "This is a method named <code>save</code> that
 takes as its receiver <code>p</code>, a pointer to <code>Page</code> . It takes
-no parameters, and returns a value of type <code>error</code>."
+no parameters, and returns a value of type <code>error</code>." 
 </p>

 <p>
-This method will save the <code>Page</code>'s <code>Body</code> to a text
+This method will save the <code>Page</code>'s <code>Body</code> to a text 
 file. For simplicity, we will use the <code>Title</code> as the file name.
 </p>

@@ -110,36 +110,35 @@ that is the return type of <code>WriteFile</code> (a standard library function
 that writes a byte slice to a file).  The <code>save</code> method returns the
 error value, to let the application handle it should anything go wrong while
 writing the file.  If all goes well, <code>Page.save()</code> will return
-<code>nil</code> (the zero-value for pointers, interfaces, and some other
+<code>nil</code> (the zero-value for pointers, interfaces, and some other 
 types).
 </p>

 <p>
-The octal integer literal <code>0600</code>, passed as the third parameter to
+The octal integer constant <code>0600</code>, passed as the third parameter to
 <code>WriteFile</code>, indicates that the file should be created with
 read-write permissions for the current user only. (See the Unix man page
 <code>open(2)</code> for details.)
 </p>

 <p>
-In addition to saving pages, we will want to load pages, too:
+We will want to load pages, too:
 </p>

 {{code "doc/articles/wiki/part1-noerror.go" `/^func loadPage/` `/^}/`}}

 <p>
-The function <code>loadPage</code> constructs the file name from the title
-parameter, reads the file's contents into a new variable <code>body</code>, and
-returns a pointer to a <code>Page</code> literal constructed with the proper
-title and body values.
+The function <code>loadPage</code> constructs the file name from
+<code>Title</code>, reads the file's contents into a new
+<code>Page</code>, and returns a pointer to that new <code>page</code>.
 </p>

 <p>
-Functions can return multiple values. The standard library function
-<code>io.ReadFile</code> returns <code>[]byte</code> and <code>error</code>.
+Functions can return multiple values. The standard library function 
+<code>io.ReadFile</code> returns <code>[]byte</code> and <code>error</code>. 
 In <code>loadPage</code>, error isn't being handled yet; the "blank identifier"
 represented by the underscore (<code>_</code>) symbol is used to throw away the
-error return value (in essence, assigning the value to nothing).
+error return value (in essence, assigning the value to nothing). 
 </p>

 <p>
@@ -153,7 +152,7 @@ function to return <code>*Page</code> and <code>error</code>.
 <p>
 Callers of this function can now check the second parameter; if it is
 <code>nil</code> then it has successfully loaded a Page. If not, it will be an
-<code>error</code> that can be handled by the caller (see the
+<code>error</code> that can be handled by the caller (see the 
 <a href="/ref/spec#Errors">language specification</a> for details).
 </p>

@@ -173,7 +172,7 @@ printed to the screen.
 </p>

 <p>
-You can compile and run the program like this:
+You can compile and run the program like this: 
 </p>

 <pre>
@@ -183,7 +182,7 @@ This is a sample page.
 </pre>

 <p>
-(If you're using Windows you must type "<code>wiki</code>" without the
+(If you're using Windows you must type "<code>wiki</code>" without the 
 "<code>./</code>" to run the program.)
 </p>

@@ -200,10 +199,10 @@ Here's a full working example of a simple web server:
 {{code "doc/articles/wiki/http-sample.go"}}

 <p>
-The <code>main</code> function begins with a call to
-<code>http.HandleFunc</code>, which tells the <code>http</code> package to
-handle all requests to the web root (<code>"/"</code>) with
-<code>handler</code>.
+The <code>main</code> function begins with a call to 
+<code>http.HandleFunc</code>, which tells the <code>http</code> package to 
+handle all requests to the web root (<code>"/"</code>) with 
+<code>handler</code>. 
 </p>

 <p>
@@ -220,20 +219,20 @@ its arguments.
 </p>

 <p>
-An <code>http.ResponseWriter</code> value assembles the HTTP server's response; 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>

 <p>
 An <code>http.Request</code> is a data structure that represents the client
-HTTP request. <code>r.URL.Path</code> is the path component
-of the request URL. The trailing <code>[1:]</code> means
-"create a sub-slice of <code>Path</code> from the 1st character to the end."
+HTTP request.  The string <code>r.URL.Path</code> is the path component
+of the request URL.  The trailing <code>[1:]</code> means
+"create a sub-slice of <code>Path</code> from the 1st character to the end." 
 This drops the leading "/" from the path name.
 </p>

 <p>
-If you run this program and access the URL:
+If you run this program and access the URL: 
 </p>
 <pre>http://localhost:8080/monkeys</pre>
 <p>
@@ -250,41 +249,43 @@ To use the <code>net/http</code> package, it must be imported:
 <pre>
 import (
 	"fmt"
-	"io/ioutil"
 	<b>"net/http"</b>
+	"io/ioutil"
 )
 </pre>

 <p>
-Let's create a handler, <code>viewHandler</code> that will allow users to
-view a wiki page. It will handle URLs prefixed with "/view/".
+Let's create a handler to view a wiki page: 
 </p>

+{{code "doc/articles/wiki/part2.go" `/^const lenPath/`}}
+
 {{code "doc/articles/wiki/part2.go" `/^func viewHandler/` `/^}/`}}

 <p>
 First, this function extracts the page title from <code>r.URL.Path</code>,
-the path component of the request URL.
-The <code>Path</code> is re-sliced with <code>[len("/view/"):]</code> to drop
-the leading <code>"/view/"</code> component of the request path.
-This is because the path will invariably begin with <code>"/view/"</code>,
-which is not part of the page's title.
+the path component of the request URL. The global constant 
+<code>lenPath</code> is the length of the leading <code>"/view/"</code>
+component of the request path.
+The <code>Path</code> is re-sliced with <code>[lenPath:]</code> to drop the 
+first 6 characters of the string. This is because the path will invariably 
+begin with <code>"/view/"</code>, which is not part of the page title.
 </p>

 <p>
-The function then loads the page data, formats the page with a string of simple
-HTML, and writes it to <code>w</code>, the <code>http.ResponseWriter</code>.
+The function then loads the page data, formats the page with a string of simple 
+HTML, and writes it to <code>w</code>, the <code>http.ResponseWriter</code>. 
 </p>

 <p>
-Again, note the use of <code>_</code> to ignore the <code>error</code>
+Again, note the use of <code>_</code> to ignore the <code>error</code> 
 return value from <code>loadPage</code>. This is done here for simplicity
 and generally considered bad practice. We will attend to this later.
 </p>

 <p>
-To use this handler, we rewrite our <code>main</code> function to
-initialize <code>http</code> using the <code>viewHandler</code> to handle
+To use this handler, we create a <code>main</code> function that
+initializes <code>http</code> using the <code>viewHandler</code> to handle
 any requests under the path <code>/view/</code>.
 </p>

@@ -309,11 +310,6 @@ $ go build wiki.go
 $ ./wiki
 </pre>

-<p>
-(If you're using Windows you must type "<code>wiki</code>" without the
-"<code>./</code>" to run the program.)
-</p>
-
 <p>
 With this web server running, a visit to <code><a
 href="http://localhost:8080/view/test">http://localhost:8080/view/test</a></code>
@@ -330,14 +326,14 @@ form.
 </p>

 <p>
-First, we add them to <code>main()</code>:
+First, we add them to <code>main()</code>: 
 </p>

 {{code "doc/articles/wiki/final-noclosure.go" `/^func main/` `/^}/`}}

 <p>
-The function <code>editHandler</code> loads the page
-(or, if it doesn't exist, create an empty <code>Page</code> struct),
+The function <code>editHandler</code> loads the page 
+(or, if it doesn't exist, create an empty <code>Page</code> struct), 
 and displays an HTML form.
 </p>

@@ -347,7 +343,7 @@ and displays an HTML form.
 This function will work fine, but all that hard-coded HTML is ugly.
 Of course, there is a better way.
 </p>
-
+ 
 <h2>The <code>html/template</code> package</h2>

 <p>
@@ -358,20 +354,20 @@ underlying Go code.
 </p>

 <p>
-First, we must add <code>html/template</code> to the list of imports. We
-also won't be using <code>fmt</code> anymore, so we have to remove that.
+First, we must add <code>html/template</code> to the list of imports:
 </p>

 <pre>
 import (
 	<b>"html/template"</b>
+	"http"
 	"io/ioutil"
-	"net/http"
+	"os"
 )
 </pre>

 <p>
-Let's create a template file containing the HTML form.
+Let's create a template file containing the HTML form. 
 Open a new file named <code>edit.html</code>, and add the following lines:
 </p>

@@ -385,8 +381,8 @@ HTML:
 {{code "doc/articles/wiki/final-noerror.go" `/^func editHandler/` `/^}/`}}

 <p>
-The function <code>template.ParseFiles</code> will read the contents of
-<code>edit.html</code> and return a <code>*template.Template</code>.
+The function <code>template.ParseFiles</code> will read the contents of 
+<code>edit.html</code> and return a <code>*template.Template</code>. 
 </p>

 <p>
@@ -409,7 +405,12 @@ HTML.
 </p>

 <p>
-Since we're working with templates now, let's create a template for our
+Now that we've removed the <code>fmt.Fprintf</code> statement, we can remove
+<code>"fmt"</code> from the <code>import</code> list.
+</p>
+
+<p>
+While we're working with templates, let's create a template for our
 <code>viewHandler</code> called <code>view.html</code>:
 </p>

@@ -427,36 +428,28 @@ handlers. Let's remove this duplication by moving the templating code
 to its own function:
 </p>

+{{code "doc/articles/wiki/final-template.go" `/^func viewHandler/` `/^}/`}}
+{{code "doc/articles/wiki/final-template.go" `/^func editHandler/` `/^}/`}}
 {{code "doc/articles/wiki/final-template.go" `/^func renderTemplate/` `/^}/`}}

 <p>
-And modify the handlers to use that function:
-</p>
-
-{{code "doc/articles/wiki/final-template.go" `/^func viewHandler/` `/^}/`}}
-{{code "doc/articles/wiki/final-template.go" `/^func editHandler/` `/^}/`}}
-
-<p>
-If we comment out the registration of our unimplemented save handler in
-<code>main</code>, we can once again build and test our program.
-<a href="part3.go">Click here to view the code we've written so far.</a>
+The handlers are now shorter and simpler. 
 </p>

 <h2>Handling non-existent pages</h2>

 <p>
 What if you visit <a href="http://localhost:8080/view/APageThatDoesntExist">
-<code>/view/APageThatDoesntExist</code></a>? You'll see a page containing
-HTML. This is because it ignores the error return value from
-<code>loadPage</code> and continues to try and fill out the template
-with no data. Instead, if the requested Page doesn't exist, it should
-redirect the client to the edit Page so the content may be created:
+<code>/view/APageThatDoesntExist</code></a>? The program will crash. This is 
+because it ignores the error return value from <code>loadPage</code>. Instead,
+if the requested Page doesn't exist, it should redirect the client to the edit
+Page so the content may be created:
 </p>

-{{code "doc/articles/wiki/part3-errorhandling.go" `/^func viewHandler/` `/^}/`}}
+{{code "doc/articles/wiki/final-noclosure.go" `/^func viewHandler/` `/^}/`}}

 <p>
-The <code>http.Redirect</code> function adds an HTTP status code of
+The <code>http.Redirect</code> function adds an HTTP status code of 
 <code>http.StatusFound</code> (302) and a <code>Location</code>
 header to the HTTP response.
 </p>
@@ -464,24 +457,22 @@ header to the HTTP response.
 <h2>Saving Pages</h2>

 <p>
-The function <code>saveHandler</code> will handle the submission of forms
-located on the edit pages. After uncommenting the related line in
-<code>main</code>, let's implement the handler:
+The function <code>saveHandler</code> will handle the form submission. 
 </p>

 {{code "doc/articles/wiki/final-template.go" `/^func saveHandler/` `/^}/`}}

 <p>
-The page title (provided in the URL) and the form's only field,
-<code>Body</code>, are stored in a new <code>Page</code>.
+The page title (provided in the URL) and the form's only field, 
+<code>Body</code>, are stored in a new <code>Page</code>. 
 The <code>save()</code> method is then called to write the data to a file,
 and the client is redirected to the <code>/view/</code> page.
 </p>

 <p>
 The value returned by <code>FormValue</code> is of type <code>string</code>.
-We must convert that value to <code>[]byte</code> before it will fit into
-the <code>Page</code> struct. We use <code>[]byte(body)</code> to perform
+We must convert that value to <code>[]byte</code> before it will fit into 
+the <code>Page</code> struct.  We use <code>[]byte(body)</code> to perform
 the conversion.
 </p>

@@ -490,9 +481,9 @@ the conversion.
 <p>
 There are several places in our program where errors are being ignored.  This
 is bad practice, not least because when an error does occur the program will
-have unintended behavior. A better solution is to handle the errors and return
-an error message to the user. That way if something does go wrong, the server
-will function exactly how we want and the user can be notified.
+crash.  A better solution is to handle the errors and return an error message
+to the user. That way if something does go wrong, the server will continue to
+function and the user will be notified.
 </p>

 <p>
@@ -502,7 +493,7 @@ First, let's handle the errors in <code>renderTemplate</code>:
 {{code "doc/articles/wiki/final-parsetemplate.go" `/^func renderTemplate/` `/^}/`}}

 <p>
-The <code>http.Error</code> function sends a specified HTTP response code
+The <code>http.Error</code> function sends a specified HTTP response code 
 (in this case "Internal Server Error") and error message.
 Already the decision to put this in a separate function is paying off.
 </p>
@@ -511,18 +502,18 @@ Already the decision to put this in a separate function is paying off.
 Now let's fix up <code>saveHandler</code>:
 </p>

-{{code "doc/articles/wiki/part3-errorhandling.go" `/^func saveHandler/` `/^}/`}}
+{{code "doc/articles/wiki/final-noclosure.go" `/^func saveHandler/` `/^}/`}}

 <p>
-Any errors that occur during <code>p.save()</code> will be reported
+Any errors that occur during <code>p.save()</code> will be reported 
 to the user.
 </p>

 <h2>Template caching</h2>

 <p>
-There is an inefficiency in this code: <code>renderTemplate</code> calls
-<code>ParseFiles</code> every time a page is rendered.
+There is an inefficiency in this code: <code>renderTemplate</code> calls 
+<code>ParseFiles</code> every time a page is rendered. 
 A better approach would be to call <code>ParseFiles</code> once at program
 initialization, parsing all templates into a single <code>*Template</code>.
 Then we can use the
@@ -545,11 +536,10 @@ can't be loaded the only sensible thing to do is exit the program.
 </p>

 <p>
-The <code>ParseFiles</code> function takes any number of string arguments that
-identify our template files, and parses those files into templates that are
-named after the base file name. If we were to add more templates to our
-program, we would add their names to the <code>ParseFiles</code> call's
-arguments.
+A <code>for</code> loop is used with a <code>range</code> statement to iterate 
+over an array constant containing the names of the templates we want parsed.
+If we were to add more templates to our program, we would add their names to 
+that array.
 </p>

 <p>
@@ -575,33 +565,31 @@ this, we can write a function to validate the title with a regular expression.

 <p>
 First, add <code>"regexp"</code> to the <code>import</code> list.
-Then we can create a global variable to store our validation 
-expression:
+Then we can create a global variable to store our validation regexp:
 </p>

-{{code "doc/articles/wiki/final-noclosure.go" `/^var validPath/`}}
+{{code "doc/articles/wiki/final-noclosure.go" `/^var titleValidator/`}}

 <p>
-The function <code>regexp.MustCompile</code> will parse and compile the
-regular expression, and return a <code>regexp.Regexp</code>.
+The function <code>regexp.MustCompile</code> will parse and compile the 
+regular expression, and return a <code>regexp.Regexp</code>. 
 <code>MustCompile</code> is distinct from <code>Compile</code> in that it will
 panic if the expression compilation fails, while <code>Compile</code> returns
-an <code>error</code> as a second parameter.
+an <code>error</code> as a second parameter. 
 </p>

 <p>
-Now, let's write a function that uses the <code>validPath</code>
-expression to validate path and extract the page title:
+Now, let's write a function that extracts the title string from the request 
+URL, and tests it against our <code>TitleValidator</code> expression:
 </p>

 {{code "doc/articles/wiki/final-noclosure.go" `/func getTitle/` `/^}/`}}

 <p>
 If the title is valid, it will be returned along with a <code>nil</code>
-error value. If the title is invalid, the function will write a
-"404 Not Found" error to the HTTP connection, and return an error to the
-handler. To create a new error, we have to import the <code>errors</code>
-package.
+error value.  If the title is invalid, the function will write a 
+"404 Not Found" error to the HTTP connection, and return an error to the 
+handler. 
 </p>

 <p>
@@ -616,10 +604,10 @@ Let's put a call to <code>getTitle</code> in each of the handlers:

 <p>
 Catching the error condition in each handler introduces a lot of repeated code.
-What if we could wrap each of the handlers in a function that does this
-validation and error checking? Go's
-<a href="/ref/spec#Function_literals">function
-literals</a> provide a powerful means of abstracting functionality
+What if we could wrap each of the handlers in a function that does this 
+validation and error checking? Go's 
+<a href="/ref/spec#Function_declarations">function 
+literals</a> provide a powerful means of abstracting functionality 
 that can help us here.
 </p>

@@ -666,19 +654,19 @@ 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.ResponseWriter</code> and <code>http.Request</code> (in other
-words, an <code>http.HandlerFunc</code>).
+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>ResponseWriter</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>ResponseWriter</code>,
 <code>Request</code>, and <code>title</code> as arguments.
 </p>

 <p>
-Now we can wrap the handler functions with <code>makeHandler</code> in
-<code>main</code>, before they are registered with the <code>http</code>
+Now we can wrap the handler functions with <code>makeHandler</code> in 
+<code>main</code>, before they are registered with the <code>http</code> 
 package:
 </p>

@@ -710,7 +698,7 @@ $ ./wiki

 <p>
 Visiting <a href="http://localhost:8080/view/ANewPage">http://localhost:8080/view/ANewPage</a>
-should present you with the page edit form. You should then be able to
+should present you with the page edit form. You should then be able to 
 enter some text, click 'Save', and be redirected to the newly created page.
 </p>

@@ -722,11 +710,11 @@ Here are some simple tasks you might want to tackle on your own:

 <ul>
 <li>Store templates in <code>tmpl/</code> and page data in <code>data/</code>.
-<li>Add a handler to make the web root redirect to
+<li>Add a handler to make the web root redirect to 
 	<code>/view/FrontPage</code>.</li>
 <li>Spruce up the page templates by making them valid HTML and adding some
 	CSS rules.</li>
-<li>Implement inter-page linking by converting instances of
+<li>Implement inter-page linking by converting instances of 
 	<code>[PageName]</code> to <br>
 	<code>&lt;a href="/view/PageName"&gt;PageName&lt;/a&gt;</code>.
 	(hint: you could use <code>regexp.ReplaceAllFunc</code> to do this)
--- a/doc/articles/wiki/notemplate.go
+++ b/doc/articles/wiki/notemplate.go
@@ -29,14 +29,16 @@ func loadPage(title string) (*Page, error) {
 	return &Page{Title: title, Body: body}, nil
 }

+const lenPath = len("/view/")
+
 func viewHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/view/"):]
+	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
 	fmt.Fprintf(w, "<h1>%s</h1><div>%s</div>", p.Title, p.Body)
 }

 func editHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/edit/"):]
+	title := r.URL.Path[lenPath:]
 	p, err := loadPage(title)
 	if err != nil {
 		p = &Page{Title: title}
--- a/doc/articles/wiki/part2.go
+++ b/doc/articles/wiki/part2.go
@@ -29,8 +29,10 @@ func loadPage(title string) (*Page, error) {
 	return &Page{Title: title, Body: body}, nil
 }

+const lenPath = len("/view/")
+
 func viewHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/view/"):]
+	title := r.URL.Path[lenPath:]
 	p, _ := loadPage(title)
 	fmt.Fprintf(w, "<h1>%s</h1><div>%s</div>", p.Title, p.Body)
 }
--- a/doc/articles/wiki/part3-errorhandling.go
+++ b/doc/articles/wiki/part3-errorhandling.go
@@ -1,73 +0,0 @@
-// Copyright 2010 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.
-
-package main
-
-import (
-	"html/template"
-	"io/ioutil"
-	"net/http"
-)
-
-type Page struct {
-	Title string
-	Body  []byte
-}
-
-func (p *Page) save() error {
-	filename := p.Title + ".txt"
-	return ioutil.WriteFile(filename, p.Body, 0600)
-}
-
-func loadPage(title string) (*Page, error) {
-	filename := title + ".txt"
-	body, err := ioutil.ReadFile(filename)
-	if err != nil {
-		return nil, err
-	}
-	return &Page{Title: title, Body: body}, nil
-}
-
-func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
-	t, _ := template.ParseFiles(tmpl + ".html")
-	t.Execute(w, p)
-}
-
-func viewHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/view/"):]
-	p, err := loadPage(title)
-	if err != nil {
-		http.Redirect(w, r, "/edit/"+title, http.StatusFound)
-		return
-	}
-	renderTemplate(w, "view", p)
-}
-
-func editHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/edit/"):]
-	p, err := loadPage(title)
-	if err != nil {
-		p = &Page{Title: title}
-	}
-	renderTemplate(w, "edit", p)
-}
-
-func saveHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/save/"):]
-	body := r.FormValue("body")
-	p := &Page{Title: title, Body: []byte(body)}
-	err := p.save()
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-	http.Redirect(w, r, "/view/"+title, http.StatusFound)
-}
-
-func main() {
-	http.HandleFunc("/view/", viewHandler)
-	http.HandleFunc("/edit/", editHandler)
-	http.HandleFunc("/save/", saveHandler)
-	http.ListenAndServe(":8080", nil)
-}
--- a/doc/articles/wiki/part3.go
+++ b/doc/articles/wiki/part3.go
@@ -1,57 +0,0 @@
-// Copyright 2010 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.
-
-package main
-
-import (
-	"html/template"
-	"io/ioutil"
-	"net/http"
-)
-
-type Page struct {
-	Title string
-	Body  []byte
-}
-
-func (p *Page) save() error {
-	filename := p.Title + ".txt"
-	return ioutil.WriteFile(filename, p.Body, 0600)
-}
-
-func loadPage(title string) (*Page, error) {
-	filename := title + ".txt"
-	body, err := ioutil.ReadFile(filename)
-	if err != nil {
-		return nil, err
-	}
-	return &Page{Title: title, Body: body}, nil
-}
-
-func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
-	t, _ := template.ParseFiles(tmpl + ".html")
-	t.Execute(w, p)
-}
-
-func viewHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/view/"):]
-	p, _ := loadPage(title)
-	renderTemplate(w, "view", p)
-}
-
-func editHandler(w http.ResponseWriter, r *http.Request) {
-	title := r.URL.Path[len("/edit/"):]
-	p, err := loadPage(title)
-	if err != nil {
-		p = &Page{Title: title}
-	}
-	renderTemplate(w, "edit", p)
-}
-
-func main() {
-	http.HandleFunc("/view/", viewHandler)
-	http.HandleFunc("/edit/", editHandler)
-	//http.HandleFunc("/save/", saveHandler)
-	http.ListenAndServe(":8080", nil)
-}
--- a/doc/articles/wiki/srcextract.go
+++ b/doc/articles/wiki/srcextract.go
@@ -0,0 +1,76 @@
+// Copyright 2010 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.
+
+package main
+
+import (
+	"bytes"
+	"flag"
+	"go/ast"
+	"go/parser"
+	"go/printer"
+	"go/token"
+	"log"
+	"os"
+	"text/template"
+)
+
+var (
+	srcFn   = flag.String("src", "", "source filename")
+	getName = flag.String("name", "", "func/type name to output")
+	html    = flag.Bool("html", true, "output HTML")
+	showPkg = flag.Bool("pkg", false, "show package in output")
+)
+
+func main() {
+	// handle input
+	flag.Parse()
+	if *srcFn == "" || *getName == "" {
+		flag.Usage()
+		os.Exit(2)
+	}
+	// load file
+	fs := token.NewFileSet()
+	file, err := parser.ParseFile(fs, *srcFn, nil, 0)
+	if err != nil {
+		log.Fatal(err)
+	}
+	// create filter
+	filter := func(name string) bool {
+		return name == *getName
+	}
+	// filter
+	if !ast.FilterFile(file, filter) {
+		os.Exit(1)
+	}
+	// print the AST
+	var b bytes.Buffer
+	printer.Fprint(&b, fs, file)
+	// drop package declaration
+	if !*showPkg {
+		for {
+			c, err := b.ReadByte()
+			if c == '\n' || err != nil {
+				break
+			}
+		}
+	}
+	// drop leading newlines
+	for {
+		b, err := b.ReadByte()
+		if err != nil {
+			break
+		}
+		if b != '\n' {
+			os.Stdout.Write([]byte{b})
+			break
+		}
+	}
+	// output
+	if *html {
+		template.HTMLEscape(os.Stdout, b.Bytes())
+	} else {
+		b.WriteTo(os.Stdout)
+	}
+}
--- a/doc/articles/wiki/test.bash
+++ b/doc/articles/wiki/test.bash
@@ -7,42 +7,22 @@ set -e
 wiki_pid=
 cleanup() {
 	kill $wiki_pid
-	rm -f test_*.out Test.txt final.bin final-port.txt a.out get.bin
+	rm -f test_*.out Test.txt final-test.bin final-test.go
 }
 trap cleanup 0 INT

-rm -f get.bin final.bin a.out
-
-# If called with -all, check that all code snippets compile.
-if [ "$1" == "-all" ]; then
-	for fn in *.go; do
-		go build -o a.out $fn
-	done
-fi
-
 go build -o get.bin get.go
-go build -o final.bin final.go
-(./final.bin --addr) &
+addr=$(./get.bin -addr)
+sed s/:8080/$addr/ < final.go > final-test.go
+go build -o final-test.bin final-test.go
+(./final-test.bin) &
 wiki_pid=$!

-l=0
-while [ ! -f ./final-port.txt ]
-do
-	l=$(($l+1))
-	if [ "$l" -gt 5 ]
-	then
-		echo "port not available within 5 seconds"
-		exit 1
-		break
-	fi
-	sleep 1
-done
+sleep 1

-addr=$(cat final-port.txt)
 ./get.bin http://$addr/edit/Test > test_edit.out
 diff -u test_edit.out test_edit.good
-./get.bin -post=body=some%20content http://$addr/save/Test > test_save.out
-diff -u test_save.out test_view.good # should be the same as viewing
+./get.bin -post=body=some%20content http://$addr/save/Test
 diff -u Test.txt test_Test.txt.good
 ./get.bin http://$addr/view/Test > test_view.out
 diff -u test_view.out test_view.good
--- a/doc/asm.html
+++ b/doc/asm.html
@@ -1,541 +0,0 @@
-<!--{
-	"Title": "A Quick Guide to Go's Assembler",
-	"Path":  "/doc/asm"
-}-->
-
-<h2 id="introduction">A Quick Guide to Go's Assembler</h2>
-
-<p>
-This document is a quick outline of the unusual form of assembly language used by the <code>gc</code>
-suite of Go compilers (<code>6g</code>, <code>8g</code>, etc.).
-The document is not comprehensive.
-</p>
-
-<p>
-The assembler is based on the input to the Plan 9 assemblers, which is documented in detail
-<a href="http://plan9.bell-labs.com/sys/doc/asm.html">on the Plan 9 site</a>.
-If you plan to write assembly language, you should read that document although much of it is Plan 9-specific.
-This document provides a summary of the syntax and
-describes the peculiarities that apply when writing assembly code to interact with Go.
-</p>
-
-<p>
-The most important thing to know about Go's assembler is that it is not a direct representation of the underlying machine.
-Some of the details map precisely to the machine, but some do not.
-This is because the compiler suite (see
-<a href="http://plan9.bell-labs.com/sys/doc/compiler.html">this description</a>)
-needs no assembler pass in the usual pipeline.
-Instead, the compiler emits a kind of incompletely defined instruction set, in binary form, which the linker
-then completes.
-In particular, the linker does instruction selection, so when you see an instruction like <code>MOV</code>
-what the linker actually generates for that operation might not be a move instruction at all, perhaps a clear or load.
-Or it might correspond exactly to the machine instruction with that name.
-In general, machine-specific operations tend to appear as themselves, while more general concepts like
-memory move and subroutine call and return are more abstract.
-The details vary with architecture, and we apologize for the imprecision; the situation is not well-defined.
-</p>
-
-<p>
-The assembler program is a way to generate that intermediate, incompletely defined instruction sequence
-as input for the linker.
-If you want to see what the instructions look like in assembly for a given architecture, say amd64, there
-are many examples in the sources of the standard library, in packages such as
-<a href="/pkg/runtime/"><code>runtime</code></a> and
-<a href="/pkg/math/big/"><code>math/big</code></a>.
-You can also examine what the compiler emits as assembly code:
-</p>
-
-<pre>
-$ cat x.go
-package main
-
-func main() {
-	println(3)
-}
-$ go tool 6g -S x.go        # or: go build -gcflags -S x.go
-
--- prog list "main" ---
-0000 (x.go:3) TEXT    main+0(SB),$8-0
-0001 (x.go:3) FUNCDATA $0,gcargs·0+0(SB)
-0002 (x.go:3) FUNCDATA $1,gclocals·0+0(SB)
-0003 (x.go:4) MOVQ    $3,(SP)
-0004 (x.go:4) PCDATA  $0,$8
-0005 (x.go:4) CALL    ,runtime.printint+0(SB)
-0006 (x.go:4) PCDATA  $0,$-1
-0007 (x.go:4) PCDATA  $0,$0
-0008 (x.go:4) CALL    ,runtime.printnl+0(SB)
-0009 (x.go:4) PCDATA  $0,$-1
-0010 (x.go:5) RET     ,
-...
-</pre>
-
-<p>
-The <code>FUNCDATA</code> and <code>PCDATA</code> directives contain information
-for use by the garbage collector; they are introduced by the compiler.
-</p> 
-
-<!-- Commenting out because the feature is gone but it's popular and may come back.
-
-<p>
-To see what gets put in the binary after linking, add the <code>-a</code> flag to the linker:
-</p>
-
-<pre>
-$ go tool 6l -a x.6        # or: go build -ldflags -a x.go
-codeblk [0x2000,0x1d059) at offset 0x1000
-002000	main.main            | (3)	TEXT	main.main+0(SB),$8
-002000	65488b0c25a0080000   | (3)	MOVQ	2208(GS),CX
-002009	483b21               | (3)	CMPQ	SP,(CX)
-00200c	7707                 | (3)	JHI	,2015
-00200e	e83da20100           | (3)	CALL	,1c250+runtime.morestack00
-002013	ebeb                 | (3)	JMP	,2000
-002015	4883ec08             | (3)	SUBQ	$8,SP
-002019	                     | (3)	FUNCDATA	$0,main.gcargs·0+0(SB)
-002019	                     | (3)	FUNCDATA	$1,main.gclocals·0+0(SB)
-002019	48c7042403000000     | (4)	MOVQ	$3,(SP)
-002021	                     | (4)	PCDATA	$0,$8
-002021	e8aad20000           | (4)	CALL	,f2d0+runtime.printint
-002026	                     | (4)	PCDATA	$0,$-1
-002026	                     | (4)	PCDATA	$0,$0
-002026	e865d40000           | (4)	CALL	,f490+runtime.printnl
-00202b	                     | (4)	PCDATA	$0,$-1
-00202b	4883c408             | (5)	ADDQ	$8,SP
-00202f	c3                   | (5)	RET	,
-...
-</pre>
-
-->
-
-<h3 id="symbols">Symbols</h3>
-
-<p>
-Some symbols, such as <code>PC</code>, <code>R0</code> and <code>SP</code>, are predeclared and refer to registers.
-There are two other predeclared symbols, <code>SB</code> (static base) and <code>FP</code> (frame pointer).
-All user-defined symbols other than jump labels are written as offsets to these pseudo-registers.
-</p>
-
-<p>
-The <code>SB</code> pseudo-register can be thought of as the origin of memory, so the symbol <code>foo(SB)</code>
-is the name <code>foo</code> as an address in memory.
-This form is used to name global functions and data.
-Adding <code>&lt;&gt;</code> to the name, as in <code>foo&lt;&gt;(SB)</code>, makes the name
-visible only in the current source file, like a top-level <code>static</code> declaration in a C file.
-</p>
-
-<p>
-The <code>FP</code> pseudo-register is a virtual frame pointer
-used to refer to function arguments.
-The compilers maintain a virtual frame pointer and refer to the arguments on the stack as offsets from that pseudo-register.
-Thus <code>0(FP)</code> is the first argument to the function,
-<code>8(FP)</code> is the second (on a 64-bit machine), and so on.
-When referring to a function argument this way, it is conventional to place the name
-at the beginning, as in <code>first_arg+0(FP)</code> and <code>second_arg+8(FP)</code>.
-Some of the assemblers enforce this convention, rejecting plain <code>0(FP)</code> and <code>8(FP)</code>.
-For assembly functions with Go prototypes, <code>go</code> <code>vet</code> will check that the argument names
-and offsets match.
-On 32-bit systems, the low and high 32 bits of a 64-bit value are distinguished by adding
-a <code>_lo</code> or <code>_hi</code> suffix to the name, as in <code>arg_lo+0(FP)</code> or <code>arg_hi+4(FP)</code>.
-If a Go prototype does not name its result, the expected assembly name is <code>ret</code>.
-</p>
-
-<p>
-The <code>SP</code> pseudo-register is a virtual stack pointer
-used to refer to frame-local variables and the arguments being
-prepared for function calls.
-It points to the top of the local stack frame, so references should use negative offsets
-in the range [−framesize, 0):
-<code>x-8(SP)</code>, <code>y-4(SP)</code>, and so on.
-On architectures with a real register named <code>SP</code>, the name prefix distinguishes
-references to the virtual stack pointer from references to the architectural <code>SP</code> register.
-That is, <code>x-8(SP)</code> and <code>-8(SP)</code> are different memory locations:
-the first refers to the virtual stack pointer pseudo-register, while the second refers to the
-hardware's <code>SP</code> register.
-</p>
-
-<p>
-Instructions, registers, and assembler directives are always in UPPER CASE to remind you
-that assembly programming is a fraught endeavor.
-(Exception: the <code>g</code> register renaming on ARM.)
-</p>
-
-<p>
-In Go object files and binaries, the full name of a symbol is the 
-package path followed by a period and the symbol name:
-<code>fmt.Printf</code> or <code>math/rand.Int</code>.
-Because the assembler's parser treats period and slash as punctuation,
-those strings cannot be used directly as identifier names.
-Instead, the assembler allows the middle dot character U+00B7
-and the division slash U+2215 in identifiers and rewrites them to
-plain period and slash.
-Within an assembler source file, the symbols above are written as
-<code>fmt·Printf</code> and <code>math∕rand·Int</code>.
-The assembly listings generated by the compilers when using the <code>-S</code> flag
-show the period and slash directly instead of the Unicode replacements
-required by the assemblers.
-</p>
-
-<p>
-Most hand-written assembly files do not include the full package path
-in symbol names, because the linker inserts the package path of the current
-object file at the beginning of any name starting with a period:
-in an assembly source file within the math/rand package implementation,
-the package's Int function can be referred to as <code>·Int</code>.
-This convention avoids the need to hard-code a package's import path in its
-own source code, making it easier to move the code from one location to another.
-</p>
-
-<h3 id="directives">Directives</h3>
-
-<p>
-The assembler uses various directives to bind text and data to symbol names.
-For example, here is a simple complete function definition. The <code>TEXT</code>
-directive declares the symbol <code>runtime·profileloop</code> and the instructions
-that follow form the body of the function.
-The last instruction in a <code>TEXT</code> block must be some sort of jump, usually a <code>RET</code> (pseudo-)instruction.
-(If it's not, the linker will append a jump-to-itself instruction; there is no fallthrough in <code>TEXTs</code>.)
-After the symbol, the arguments are flags (see below)
-and the frame size, a constant (but see below):
-</p>
-
-<pre>
-TEXT runtime·profileloop(SB),NOSPLIT,$8
-	MOVQ	$runtime·profileloop1(SB), CX
-	MOVQ	CX, 0(SP)
-	CALL	runtime·externalthreadhandler(SB)
-	RET
-</pre>
-
-<p>
-In the general case, the frame size is followed by an argument size, separated by a minus sign.
-(It's not a subtraction, just idiosyncratic syntax.)
-The frame size <code>$24-8</code> states that the function has a 24-byte frame
-and is called with 8 bytes of argument, which live on the caller's frame.
-If <code>NOSPLIT</code> is not specified for the <code>TEXT</code>,
-the argument size must be provided.
-For assembly functions with Go prototypes, <code>go</code> <code>vet</code> will check that the
-argument size is correct.
-</p>
-
-<p>
-Note that the symbol name uses a middle dot to separate the components and is specified as an offset from the
-static base pseudo-register <code>SB</code>.
-This function would be called from Go source for package <code>runtime</code> using the
-simple name <code>profileloop</code>.
-</p>
-
-<p>
-Global data symbols are defined by a sequence of initializing
-<code>DATA</code> directives followed by a <code>GLOBL</code> directive.
-Each <code>DATA</code> directive initializes a section of the
-corresponding memory.
-The memory not explicitly initialized is zeroed.
-The general form of the <code>DATA</code> directive is
-
-<pre>
-DATA	symbol+offset(SB)/width, value
-</pre>
-
-<p>
-which initializes the symbol memory at the given offset and width with the given value.
-The <code>DATA</code> directives for a given symbol must be written with increasing offsets.
-</p>
-
-<p>
-The <code>GLOBL</code> directive declares a symbol to be global.
-The arguments are optional flags and the size of the data being declared as a global,
-which will have initial value all zeros unless a <code>DATA</code> directive
-has initialized it.
-The <code>GLOBL</code> directive must follow any corresponding <code>DATA</code> directives.
-</p>
-
-<p>
-For example,
-</p>
-
-<pre>
-DATA divtab&lt;&gt;+0x00(SB)/4, $0xf4f8fcff
-DATA divtab&lt;&gt;+0x04(SB)/4, $0xe6eaedf0
-...
-DATA divtab&lt;&gt;+0x3c(SB)/4, $0x81828384
-GLOBL divtab&lt;&gt;(SB), RODATA, $64
-
-GLOBL runtime·tlsoffset(SB), NOPTR, $4
-</pre>
-
-<p>
-declares and initializes <code>divtab&lt;&gt;</code>, a read-only 64-byte table of 4-byte integer values,
-and declares <code>runtime·tlsoffset</code>, a 4-byte, implicitly zeroed variable that
-contains no pointers.
-</p>
-
-<p>
-There may be one or two arguments to the directives.
-If there are two, the first is a bit mask of flags,
-which can be written as numeric expressions, added or or-ed together,
-or can be set symbolically for easier absorption by a human.
-Their values, defined in the standard <code>#include</code>  file <code>textflag.h</code>, are:
-</p>
-
-<ul>
-<li>
-<code>NOPROF</code> = 1
-<br>
-(For <code>TEXT</code> items.)
-Don't profile the marked function.  This flag is deprecated.
-</li>
-<li>
-<code>DUPOK</code> = 2
-<br>
-It is legal to have multiple instances of this symbol in a single binary.
-The linker will choose one of the duplicates to use.
-</li>
-<li>
-<code>NOSPLIT</code> = 4
-<br>
-(For <code>TEXT</code> items.)
-Don't insert the preamble to check if the stack must be split.
-The frame for the routine, plus anything it calls, must fit in the
-spare space at the top of the stack segment.
-Used to protect routines such as the stack splitting code itself.
-</li>
-<li>
-<code>RODATA</code> = 8
-<br>
-(For <code>DATA</code> and <code>GLOBL</code> items.)
-Put this data in a read-only section.
-</li>
-<li>
-<code>NOPTR</code> = 16
-<br>
-(For <code>DATA</code> and <code>GLOBL</code> items.)
-This data contains no pointers and therefore does not need to be
-scanned by the garbage collector.
-</li>
-<li>
-<code>WRAPPER</code>  = 32
-<br>
-(For <code>TEXT</code> items.)
-This is a wrapper function and should not count as disabling <code>recover</code>.
-</li>
-</ul>
-
-<h3 id="runtime">Runtime Coordination</h3>
-
-<p>
-For garbage collection to run correctly, the runtime must know the
-location of pointers in all global data and in most stack frames.
-The Go compiler emits this information when compiling Go source files,
-but assembly programs must define it explicitly.
-</p>
-
-<p>
-A data symbol marked with the <code>NOPTR</code> flag (see above)
-is treated as containing no pointers to runtime-allocated data.
-A data symbol with the <code>RODATA</code> flag
-is allocated in read-only memory and is therefore treated
-as implicitly marked <code>NOPTR</code>.
-A data symbol with a total size smaller than a pointer
-is also treated as implicitly marked <code>NOPTR</code>.
-It is not possible to define a symbol containing pointers in an assembly source file;
-such a symbol must be defined in a Go source file instead.
-Assembly source can still refer to the symbol by name
-even without <code>DATA</code> and <code>GLOBL</code> directives.
-A good general rule of thumb is to define all non-<code>RODATA</code>
-symbols in Go instead of in assembly.
-</p>
-
-<p>
-Each function also needs annotations giving the location of
-live pointers in its arguments, results, and local stack frame.
-For an assembly function with no pointer results and
-either no local stack frame or no function calls,
-the only requirement is to define a Go prototype for the function
-in a Go source file in the same package. The name of the assembly
-function must not contain the package name component (for example,
-function <code>Syscall</code> in package <code>syscall</code> should
-use the name <code>·Syscall</code> instead of the equivalent name
-<code>syscall·Syscall</code> in its <code>TEXT</code> directive).
-For more complex situations, explicit annotation is needed.
-These annotations use pseudo-instructions defined in the standard
-<code>#include</code> file <code>funcdata.h</code>.
-</p>
-
-<p>
-If a function has no arguments and no results,
-the pointer information can be omitted.
-This is indicated by an argument size annotation of <code>$<i>n</i>-0</code>
-on the <code>TEXT</code> instruction.
-Otherwise, pointer information must be provided by
-a Go prototype for the function in a Go source file,
-even for assembly functions not called directly from Go.
-(The prototype will also let <code>go</code> <code>vet</code> check the argument references.)
-At the start of the function, the arguments are assumed
-to be initialized but the results are assumed uninitialized.
-If the results will hold live pointers during a call instruction,
-the function should start by zeroing the results and then 
-executing the pseudo-instruction <code>GO_RESULTS_INITIALIZED</code>.
-This instruction records that the results are now initialized
-and should be scanned during stack movement and garbage collection.
-It is typically easier to arrange that assembly functions do not
-return pointers or do not contain call instructions;
-no assembly functions in the standard library use
-<code>GO_RESULTS_INITIALIZED</code>.
-</p>
-
-<p>
-If a function has no local stack frame,
-the pointer information can be omitted.
-This is indicated by a local frame size annotation of <code>$0-<i>n</i></code>
-on the <code>TEXT</code> instruction.
-The pointer information can also be omitted if the
-function contains no call instructions.
-Otherwise, the local stack frame must not contain pointers,
-and the assembly must confirm this fact by executing the 
-pseudo-instruction <code>NO_LOCAL_POINTERS</code>.
-Because stack resizing is implemented by moving the stack,
-the stack pointer may change during any function call:
-even pointers to stack data must not be kept in local variables.
-</p>
-
-<h2 id="architectures">Architecture-specific details</h2>
-
-<p>
-It is impractical to list all the instructions and other details for each machine.
-To see what instructions are defined for a given machine, say 32-bit Intel x86,
-look in the top-level header file for the corresponding linker, in this case <code>8l</code>.
-That is, the file <code>$GOROOT/src/cmd/8l/8.out.h</code> contains a C enumeration, called <code>as</code>,
-of the instructions and their spellings as known to the assembler and linker for that architecture.
-In that file you'll find a declaration that begins
-</p>
-
-<pre>
-enum	as
-{
-	AXXX,
-	AAAA,
-	AAAD,
-	AAAM,
-	AAAS,
-	AADCB,
-	...
-</pre>
-
-<p>
-Each instruction begins with a  initial capital <code>A</code> in this list, so <code>AADCB</code>
-represents the <code>ADCB</code> (add carry byte) instruction.
-The enumeration is in alphabetical order, plus some late additions (<code>AXXX</code> occupies
-the zero slot as an invalid instruction).
-The sequence has nothing to do with the actual encoding of the machine instructions.
-Again, the linker takes care of that detail.
-</p>
-
-<p>
-One detail evident in the examples from the previous sections is that data in the instructions flows from left to right:
-<code>MOVQ</code> <code>$0,</code> <code>CX</code> clears <code>CX</code>.
-This convention applies even on architectures where the usual mode is the opposite direction.
-</p>
-
-<p>
-Here follows some descriptions of key Go-specific details for the supported architectures.
-</p>
-
-<h3 id="x86">32-bit Intel 386</h3>
-
-<p>
-The runtime pointer to the <code>g</code> structure is maintained
-through the value of an otherwise unused (as far as Go is concerned) register in the MMU.
-A OS-dependent macro <code>get_tls</code> is defined for the assembler if the source includes
-an architecture-dependent header file, like this:
-</p>
-
-<pre>
-#include "zasm_GOOS_GOARCH.h"
-</pre>
-
-<p>
-Within the runtime, the <code>get_tls</code> macro loads its argument register
-with a pointer to the <code>g</code> pointer, and the <code>g</code> struct
-contains the <code>m</code> pointer.
-The sequence to load <code>g</code> and <code>m</code> using <code>CX</code> looks like this:
-</p>
-
-<pre>
-get_tls(CX)
-MOVL	g(CX), AX     // Move g into AX.
-MOVL	g_m(AX), BX   // Move g->m into BX.
-</pre>
-
-<h3 id="amd64">64-bit Intel 386 (a.k.a. amd64)</h3>
-
-<p>
-The assembly code to access the <code>m</code> and <code>g</code>
-pointers is the same as on the 386, except it uses <code>MOVQ</code> rather than
-<code>MOVL</code>:
-</p>
-
-<pre>
-get_tls(CX)
-MOVQ	g(CX), AX     // Move g into AX.
-MOVQ	g_m(AX), BX   // Move g->m into BX.
-</pre>
-
-<h3 id="arm">ARM</h3>
-
-<p>
-The registers <code>R10</code> and <code>R11</code>
-are reserved by the compiler and linker.
-</p>
-
-<p>
-<code>R10</code> points to the <code>g</code> (goroutine) structure.
-Within assembler source code, this pointer must be referred to as <code>g</code>;
-the name <code>R10</code> is not recognized.
-</p>
-
-<p>
-To make it easier for people and compilers to write assembly, the ARM linker
-allows general addressing forms and pseudo-operations like <code>DIV</code> or <code>MOD</code>
-that may not be expressible using a single hardware instruction.
-It implements these forms as multiple instructions, often using the <code>R11</code> register
-to hold temporary values.
-Hand-written assembly can use <code>R11</code>, but doing so requires
-being sure that the linker is not also using it to implement any of the other
-instructions in the function.
-</p>
-
-<p>
-When defining a <code>TEXT</code>, specifying frame size <code>$-4</code>
-tells the linker that this is a leaf function that does not need to save <code>LR</code> on entry.
-</p>
-
-<p>
-The name <code>SP</code> always refers to the virtual stack pointer described earlier.
-For the hardware register, use <code>R13</code>.
-</p>
-
-<h3 id="unsupported_opcodes">Unsupported opcodes</h3>
-
-<p>
-The assemblers are designed to support the compiler so not all hardware instructions
-are defined for all architectures: if the compiler doesn't generate it, it might not be there.
-If you need to use a missing instruction, there are two ways to proceed.
-One is to update the assembler to support that instruction, which is straightforward
-but only worthwhile if it's likely the instruction will be used again.
-Instead, for simple one-off cases, it's possible to use the <code>BYTE</code>
-and <code>WORD</code> directives
-to lay down explicit data into the instruction stream within a <code>TEXT</code>.
-Here's how the 386 runtime defines the 64-bit atomic load function.
-</p>
-
-<pre>
-// uint64 atomicload64(uint64 volatile* addr);
-// so actually
-// void atomicload64(uint64 *res, uint64 volatile *addr);
-TEXT runtime·atomicload64(SB), NOSPLIT, $0-8
-	MOVL	ptr+0(FP), AX
-	LEAL	ret_lo+4(FP), BX
-	BYTE $0x0f; BYTE $0x6f; BYTE $0x00	// MOVQ (%EAX), %MM0
-	BYTE $0x0f; BYTE $0x7f; BYTE $0x03	// MOVQ %MM0, 0(%EBX)
-	BYTE $0x0F; BYTE $0x77			// EMMS
-	RET
-</pre>
--- a/doc/cmd.html
+++ b/doc/cmd.html
@@ -27,9 +27,9 @@ the go <code>tool</code> subcommand.
 </p>

 <p>
-Finally the <code>fmt</code> and <code>godoc</code> commands are installed
-as regular binaries called <code>gofmt</code> and <code>godoc</code> because
-they are so often referenced.
+Finally, two of the commands, <code>fmt</code> and <code>doc</code>, are also
+installed as regular binaries called <code>gofmt</code> and <code>godoc</code>
+because they are so often referenced.
 </p>

 <p>
@@ -61,13 +61,6 @@ details.
 <td>Cgo enables the creation of Go packages that call C code.</td>
 </tr>

-<tr>
-<td><a href="//godoc.org/golang.org/x/tools/cmd/cover/">cover</a></td>
-<td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
-<td>Cover is a program for creating and analyzing the coverage profiles
-generated by <code>"go test -coverprofile"</code>.</td>
-</tr>
-
 <tr>
 <td><a href="/cmd/fix/">fix</a></td>
 <td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
@@ -75,6 +68,13 @@ generated by <code>"go test -coverprofile"</code>.</td>
 and rewrites them to use newer ones.</td>
 </tr>

+<tr>
+<td><a href="/cmd/go/">doc</a></td>
+<td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
+<td>Doc extracts and generates documentation for Go packages, it is also available as
+an independent <a href="/cmd/godoc/">godoc</a> command with more general options.</td>
+</tr>
+
 <tr>
 <td><a href="/cmd/go/">fmt</a></td>
 <td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
@@ -83,13 +83,7 @@ gofmt</a> command with more general options.</td>
 </tr>

 <tr>
-<td><a href="//godoc.org/golang.org/x/tools/cmd/godoc/">godoc</a></td>
-<td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
-<td>Godoc extracts and generates documentation for Go packages.</td>
-</tr>
-
-<tr>
-<td><a href="//godoc.org/golang.org/x/tools/cmd/vet/">vet</a></td>
+<td><a href="/cmd/vet/">vet</a></td>
 <td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
 <td>Vet examines Go source code and reports suspicious constructs, such as Printf
 calls whose arguments do not align with the format string.</td>
--- a/doc/code.html
+++ b/doc/code.html
@@ -6,411 +6,139 @@

 <p>
 This document demonstrates the development of a simple Go package and
-introduces the <a href="/cmd/go/">go tool</a>, the standard way to fetch,
+introduces the <a href="/cmd/go/">go command</a>, the standard way to fetch,
 build, and install Go packages and commands.
 </p>

+
+<h2 id="GOPATH">Code organization</h2>
+
+<h3><code>GOPATH</code> and workspaces</h3>
+
 <p>
-The <code>go</code> tool requires you to organize your code in a specific
-way. Please read this document carefully.
-It explains the simplest way to get up and running with your Go installation.
+One of Go's design goals is to make writing software easier.  To that end, the
+<code>go</code> command doesn't use Makefiles or other configuration files to
+guide program construction. Instead, it uses the source code to find
+dependencies and determine build conditions. This means your source code and
+build scripts are always in sync; they are one and the same.
 </p>

 <p>
-A similar explanation is available as a
-<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>.
-</p>
-
-
-<h2 id="Organization">Code organization</h2>
-
-<h3 id="Workspaces">Workspaces</h3>
-
-<p>
-The <code>go</code> tool is designed to work with open source code maintained
-in public repositories. Although you don't need to publish your code, the model
-for how the environment is set up works the same whether you do or not.
+The one thing you must do is set a <code>GOPATH</code> environment variable.
+<code>GOPATH</code> tells the <code>go</code> command (and other related tools)
+where to find and install the Go packages on your system.
 </p>

 <p>
-Go code must be kept inside a <i>workspace</i>.
-A workspace is a directory hierarchy with three directories at its root:
+<code>GOPATH</code> is a list of paths. It shares the syntax of your system's
+<code>PATH</code> environment variable. A typical <code>GOPATH</code> on
+a Unix system might look like this:
+</p>
+
+<pre>
+GOPATH=/home/user/ext:/home/user/mygo
+</pre>
+
+<p>
+(On a Windows system use semicolons as the path separator instead of colons.)
+</p>
+
+<p>
+Each path in the list (in this case <code>/home/user/ext</code> or
+<code>/home/user/mygo</code>) specifies the location of a <i>workspace</i>.
+A workspace contains Go source files and their associated package objects, and
+command executables. It has a prescribed structure of three subdirectories:
 </p>

 <ul>
-<li><code>src</code> contains Go source files organized into packages (one package per directory),
-<li><code>pkg</code> contains package objects, and
+<li><code>src</code> contains Go source files,
+<li><code>pkg</code> contains compiled package objects, and
 <li><code>bin</code> contains executable commands.
 </ul>

 <p>
-The <code>go</code> tool builds source packages and installs the resulting
-binaries to the <code>pkg</code> and <code>bin</code> directories.
+Subdirectories of the <code>src</code> directory hold independent packages, and
+all source files (<code>.go</code>, <code>.c</code>, <code>.h</code>, and
+<code>.s</code>) in each subdirectory are elements of that subdirectory's
+package.
 </p>

 <p>
-The <code>src</code> subdirectory typically contains multiple version control
-repositories (such as for Git or Mercurial) that track the development of one
-or more source packages.
+When building a program that imports the package "<code>widget</code>" the
+<code>go</code> command looks for <code>src/pkg/widget</code> inside the Go root,
+and then&mdash;if the package source isn't found there&mdash;it searches
+for <code>src/widget</code> inside each workspace in order.
 </p>

 <p>
-To give you an idea of how a workspace looks in practice, here's an example:
+Multiple workspaces can offer some flexibility and convenience, but for now
+we'll concern ourselves with only a single workspace.
+</p>
+
+<p>
+Let's work through a simple example. First, create a <code>$HOME/mygo</code>
+directory and its <code>src</code> subdirectory:
 </p>

 <pre>
-bin/
-    hello                          # command executable
-    outyet                         # command executable
-pkg/
-    linux_amd64/
-        github.com/golang/example/
-            stringutil.a           # package object
-src/
-    <a href="https://github.com/golang/example/">github.com/golang/example/</a>
-        .git/                      # Git repository metadata
-	hello/
-	    hello.go               # command source
-	outyet/
-	    main.go                # command source
-	    main_test.go           # test source
-	stringutil/
-	    reverse.go             # package source
-	    reverse_test.go        # test source
+$ mkdir -p $HOME/mygo/src # create a place to put source code
 </pre>

 <p>
-This workspace contains one repository (<code>example</code>)
-comprising two commands (<code>hello</code> and <code>outyet</code>)
-and one library (<code>stringutil</code>).
-</p>
-
-<p>
-A typical workspace would contain many source repositories containing many
-packages and commands. Most Go programmers keep <i>all</i> their Go source code
-and dependencies in a single workspace.
-</p>
-
-<p>
-Commands and libraries are built from different kinds of source packages.
-We will discuss the distinction <a href="#PackageNames">later</a>.
-</p>
-
-
-<h3 id="GOPATH">The <code>GOPATH</code> environment variable</h3>
-
-<p>
-The <code>GOPATH</code> environment variable specifies the location of your
-workspace. It is likely the only environment variable you'll need to set
-when developing Go code.
-</p>
-
-<p>
-To get started, create a workspace directory and set <code>GOPATH</code>
-accordingly. Your workspace can be located wherever you like, but we'll use
-<code>$HOME/work</code> in this document. Note that this must <b>not</b> be the
-same path as your Go installation.
-(Another common setup is to set <code>GOPATH=$HOME</code>.)
+Next, set it as the <code>GOPATH</code>. You should also add the
+<code>bin</code> subdirectory to your <code>PATH</code> environment variable so
+that you can run the commands therein without specifying their full path.
+To do this, add the following lines to <code>$HOME/.profile</code> (or
+equivalent):
 </p>

 <pre>
-$ <b>mkdir $HOME/work</b>
-$ <b>export GOPATH=$HOME/work</b>
+export GOPATH=$HOME/mygo
+export PATH=$PATH:$HOME/mygo/bin
 </pre>

+
+<h3>Import paths</h3>
+
 <p>
-For convenience, add the workspace's <code>bin</code> subdirectory
-to your <code>PATH</code>:
+The standard packages are given short import paths such as <code>"fmt"</code>
+and <code>"net/http"</code> for convenience. 
+For your own projects, it is important to choose a base import path that is
+unlikely to collide with future additions to the standard library or other
+external libraries.
+</p>
+
+<p>
+The best way to choose an import path is to use the location of your version
+control repository.
+For instance, if your source repository is at <code>example.com</code> 
+or <code>code.google.com/p/example</code>, you should begin your package
+paths with that URL, as in "<code>example.com/foo/bar</code>" or
+"<code>code.google.com/p/example/foo/bar</code>".
+Using this convention, the <code>go</code> command can automatically check out and
+build the source code by its import path alone.
+</p>
+
+<p>
+If you don't intend to install your code in this way, you should at
+least use a unique prefix like "<code>widgets/</code>", as in
+"<code>widgets/foo/bar</code>". A good rule is to use a prefix such as your
+company or project name, since it is unlikely to be used by another group.
+</p>
+
+<p>
+We'll use <code>example/</code> as our base import path:
 </p>

 <pre>
-$ <b>export PATH=$PATH:$GOPATH/bin</b>
-</pre>
-
-<p>
-To learn more about setting up the <code>GOPATH</code> environment variable,
-please see
-<a href="/cmd/go/#hdr-GOPATH_environment_variable"><code>go help gopath</code></a>
-</p>
-
-<h3 id="PackagePaths">Package paths</h3>
-
-<p>
-The packages from the standard library are given short paths such as
-<code>"fmt"</code> and <code>"net/http"</code>.
-For your own packages, you must choose a base path that is unlikely to
-collide with future additions to the standard library or other external
-libraries.
-</p>
-
-<p>
-If you keep your code in a source repository somewhere, then you should use the
-root of that source repository as your base path.
-For instance, if you have a <a href="https://github.com/">GitHub</a> account at
-<code>github.com/user</code>, that should be your base path.
-</p>
-
-<p>
-Note that you don't need to publish your code to a remote repository before you
-can build it. It's just a good habit to organize your code as if you will
-publish it someday. In practice you can choose any arbitrary path name,
-as long as it is unique to the standard library and greater Go ecosystem.
-</p>
-
-<p>
-We'll use <code>github.com/user</code> as our base path. Create a directory
-inside your workspace in which to keep source code:
-</p>
-
-<pre>
-$ <b>mkdir -p $GOPATH/src/github.com/user</b>
+$ mkdir -p $GOPATH/src/example
 </pre>


-<h3 id="Command">Your first program</h3>
+<h3>Package names</h3>

 <p>
-To compile and run a simple program, first choose a package path (we'll use
-<code>github.com/user/hello</code>) and create a corresponding package directory
-inside your workspace:
-</p>
-
-<pre>
-$ <b>mkdir $GOPATH/src/github.com/user/hello</b>
-</pre>
-
-<p>
-Next, create a file named <code>hello.go</code> inside that directory,
-containing the following Go code.
-</p>
-
-<pre>
-package main
-
-import "fmt"
-
-func main() {
-	fmt.Printf("Hello, world.\n")
-}
-</pre>
-
-<p>
-Now you can build and install that program with the <code>go</code> tool:
-</p>
-
-<pre>
-$ <b>go install github.com/user/hello</b>
-</pre>
-
-<p>
-Note that you can run this command from anywhere on your system. The
-<code>go</code> tool finds the source code by looking for the
-<code>github.com/user/hello</code> package inside the workspace specified by
-<code>GOPATH</code>.
-</p>
-
-<p>
-You can also omit the package path if you run <code>go install</code> from the
-package directory:
-</p>
-
-<pre>
-$ <b>cd $GOPATH/src/github.com/user/hello</b>
-$ <b>go install</b>
-</pre>
-
-<p>
-This command builds the <code>hello</code> command, producing an executable
-binary. It then installs that binary to the workspace's <code>bin</code>
-directory as <code>hello</code> (or, under Windows, <code>hello.exe</code>).
-In our example, that will be <code>$GOPATH/bin/hello</code>, which is
-<code>$HOME/work/bin/hello</code>.
-</p>
-
-<p>
-The <code>go</code> tool will only print output when an error occurs, so if
-these commands produce no output they have executed successfully.
-</p>
-
-<p>
-You can now run the program by typing its full path at the command line:
-</p>
-
-<pre>
-$ <b>$GOPATH/bin/hello</b>
-Hello, world.
-</pre>
-
-<p>
-Or, as you have added <code>$GOPATH/bin</code> to your <code>PATH</code>,
-just type the binary name:
-</p>
-
-<pre>
-$ <b>hello</b>
-Hello, world.
-</pre>
-
-<p>
-If you're using a source control system, now would be a good time to initialize
-a repository, add the files, and commit your first change. Again, this step is
-optional: you do not need to use source control to write Go code.
-</p>
-
-<pre>
-$ <b>cd $GOPATH/src/github.com/user/hello</b>
-$ <b>git init</b>
-Initialized empty Git repository in /home/user/work/src/github.com/user/hello/.git/
-$ <b>git add hello.go</b>
-$ <b>git commit -m "initial commit"</b>
-[master (root-commit) 0b4507d] initial commit
- 1 file changed, 1 insertion(+)
-  create mode 100644 hello.go
-</pre>
-
-<p>
-Pushing the code to a remote repository is left as an exercise for the reader.
-</p>
-
-
-<h3 id="Library">Your first library</h3>
-
-<p>
-Let's write a library and use it from the <code>hello</code> program.
-</p>
-
-<p>
-Again, the first step is to choose a package path (we'll use
-<code>github.com/user/stringutil</code>) and create the package directory:
-</p>
-
-<pre>
-$ <b>mkdir $GOPATH/src/github.com/user/stringutil</b>
-</pre>
-
-<p>
-Next, create a file named <code>reverse.go</code> in that directory with the
-following contents.
-</p>
-
-<pre>
-// Package stringutil contains utility functions for working with strings.
-package stringutil
-
-// Reverse returns its argument string reversed rune-wise left to right.
-func Reverse(s string) string {
-	r := []rune(s)
-	for i, j := 0, len(r)-1; i &lt; len(r)/2; i, j = i+1, j-1 {
-		r[i], r[j] = r[j], r[i]
-	}
-	return string(r)
-}
-</pre>
-
-<p>
-Now, test that the package compiles with <code>go build</code>:
-</p>
-
-<pre>
-$ <b>go build github.com/user/stringutil</b>
-</pre>
-
-<p>
-Or, if you are working in the package's source directory, just:
-</p>
-
-<pre>
-$ <b>go build</b>
-</pre>
-
-<p>
-This won't produce an output file. To do that, you must use <code>go
-install</code>, which places the package object inside the <code>pkg</code>
-directory of the workspace.
-</p>
-
-<p>
-After confirming that the <code>stringutil</code> package builds,
-modify your original <code>hello.go</code> (which is in
-<code>$GOPATH/src/github.com/user/hello</code>) to use it:
-</p>
-
-<pre>
-package main
-
-import (
-	"fmt"
-
-	<b>"github.com/user/stringutil"</b>
-)
-
-func main() {
-	fmt.Printf(stringutil.Reverse("!oG ,olleH"))
-}
-</pre>
-
-<p>
-Whenever the <code>go</code> tool installs a package or binary, it also
-installs whatever dependencies it has.
-So when you install the <code>hello</code> program
-</p>
-
-<pre>
-$ <b>go install github.com/user/hello</b>
-</pre>
-
-<p>
-the <code>stringutil</code> package will be installed as well, automatically.
-</p>
-
-<p>
-Running the new version of the program, you should see a new, reversed message:
-</p>
-
-<pre>
-$ <b>hello</b>
-Hello, Go!
-</pre>
-
-<p>
-After the steps above, your workspace should look like this:
-</p>
-
-<pre>
-bin/
-    hello                 # command executable
-pkg/
-    linux_amd64/          # this will reflect your OS and architecture
-        github.com/user/
-            stringutil.a  # package object
-src/
-    github.com/user/
-        hello/
-            hello.go      # command source
-        stringutil/
-            reverse.go    # package source
-</pre>
-
-<p>
-Note that <code>go install</code> placed the <code>stringutil.a</code> object
-in a directory inside <code>pkg/linux_amd64</code> that mirrors its source
-directory.
-This is so that future invocations of the <code>go</code> tool can find the
-package object and avoid recompiling the package unnecessarily.
-The <code>linux_amd64</code> part is there to aid in cross-compilation,
-and will reflect the operating system and architecture of your system.
-</p>
-
-<p>
-Go command executables are statically linked; the package objects need not
-be present to run Go programs.
-</p>
-
-
-<h3 id="PackageNames">Package names</h3>
-
-<p>
-The first statement in a Go source file must be
+The first statement in a Go source file should be
 </p>

 <pre>
@@ -426,24 +154,209 @@ where <code><i>name</i></code> is the package's default name for imports.
 Go's convention is that the package name is the last element of the
 import path: the package imported as "<code>crypto/rot13</code>"
 should be named <code>rot13</code>.
-</p>
-
-<p>
-Executable commands must always use <code>package main</code>.
-</p>
-
-<p>
 There is no requirement that package names be unique
 across all packages linked into a single binary,
 only that the import paths (their full file names) be unique.
 </p>

+<p>
+Create a new package under <code>example</code> called <code>newmath</code>:
+</p>
+
+<pre>
+$ cd $GOPATH/src/example
+$ mkdir newmath
+</pre>
+
+<p>
+Then create a file named <code>$GOPATH/src/example/newmath/sqrt.go</code>
+containing the following Go code:
+</p>
+
+<pre>
+// Package newmath is a trivial example package.
+package newmath
+
+// Sqrt returns an approximation to the square root of x.
+func Sqrt(x float64) float64 {
+        // This is a terrible implementation.
+        // Real code should import "math" and use math.Sqrt.
+        z := 0.0
+        for i := 0; i &lt; 1000; i++ {
+                z -= (z*z - x) / (2 * x)
+        }
+        return z
+}
+</pre>
+
+<p>
+This package is imported by the path name of the directory it's in, starting
+after the <code>src</code> component:
+</p>
+
+<pre>
+import "example/newmath"
+</pre>
+
 <p>
 See <a href="/doc/effective_go.html#names">Effective Go</a> to learn more about
 Go's naming conventions.
 </p>


+<h2>Building and installing</h2>
+
+<p>
+The <code>go</code> command comprises several subcommands, the most central being
+<code>install</code>. Running <code>go install <i>importpath</i></code> builds
+and installs a package and its dependencies.
+</p>
+
+<p>
+To "install a package" means to write the package object or executable command
+to the <code>pkg</code> or <code>bin</code> subdirectory of the workspace in
+which the source resides.
+</p>
+
+<h3>Building a package</h3>
+
+<p>
+To build and install the <code>newmath</code> package, type
+</p>
+
+<pre>
+$ go install example/newmath
+</pre>
+
+<p>
+This command will produce no output if the package and its dependencies
+are built and installed correctly.
+</p>
+
+<p>
+As a convenience, the <code>go</code> command will assume the current directory
+if no import path is specified on the command line. This sequence of commands
+has the same effect as the one above:
+</p>
+
+<pre>
+$ cd $GOPATH/src/example/newmath
+$ go install
+</pre>
+
+<p>
+The resulting workspace directory tree (assuming we're running Linux on a 64-bit
+system) looks like this:
+</p>
+
+<pre>
+pkg/
+    linux_amd64/
+        example/
+            newmath.a  # package object
+src/
+    example/
+        newmath/
+            sqrt.go    # package source
+</pre>
+
+
+<h3>Building a command</h3>
+
+<p>
+The <code>go</code> command treats code belonging to <code>package main</code> as
+an executable command and installs the package binary to the
+<code>GOPATH</code>'s <code>bin</code> subdirectory.
+</p>
+
+<p>
+Add a command named <code>hello</code> to the source tree.
+First create the <code>example/hello</code> directory:
+</p>
+
+<pre>
+$ cd $GOPATH/src/example
+$ mkdir hello
+</pre>
+
+<p>
+Then create the file <code>$GOPATH/src/example/hello/hello.go</code>
+containing the following Go code.
+</p>
+
+<pre>
+// Hello is a trivial example of a main package.
+package main
+
+import (
+        "example/newmath"
+        "fmt"
+)
+
+func main() {
+        fmt.Printf("Hello, world.  Sqrt(2) = %v\n", newmath.Sqrt(2))
+}
+</pre>
+
+<p>
+Next, run <code>go install</code>, which builds and installs the binary to
+<code>$GOPATH/bin</code> (or <code>$GOBIN</code>, if set; to simplify
+presentation, this document assumes <code>GOBIN</code> is unset):
+</p>
+
+<pre>
+$ go install example/hello
+</pre>
+
+<p>
+To run the program, invoke it by name as you would any other command:
+</p>
+
+<pre>
+$ $GOPATH/bin/hello
+Hello, world.  Sqrt(2) = 1.414213562373095
+</pre>
+
+<p>
+If you added <code>$HOME/mygo/bin</code> to your <code>PATH</code>, you may omit
+the path to the executable:
+</p>
+
+<pre>
+$ hello
+Hello, world.  Sqrt(2) = 1.414213562373095
+</pre>
+
+<p>
+The workspace directory tree now looks like this:
+</p>
+
+<pre>
+bin/
+    hello              # command executable
+pkg/
+    linux_amd64/ 
+        example/
+            newmath.a  # package object
+src/
+    example/
+        hello/
+            hello.go   # command source
+        newmath/
+            sqrt.go    # package source
+</pre>
+
+<p>
+The <code>go</code> command also provides a <code>build</code> command, which is
+like <code>install</code> except it builds all objects in a temporary directory
+and does not install them under <code>pkg</code> or <code>bin</code>.
+When building a command an executable named after the last element of the
+import path is written to the current directory. When building a package, 
+<code>go build</code> serves merely to test that the package and its
+dependencies can be built. (The resulting package object is thrown away.)
+</p>
+
+
 <h2 id="Testing">Testing</h2>

 <p>
@@ -461,54 +374,35 @@ if the function calls a failure function such as <code>t.Error</code> or
 </p>

 <p>
-Add a test to the <code>stringutil</code> package by creating the file
-<code>$GOPATH/src/github.com/user/stringutil/reverse_test.go</code> containing
-the following Go code.
+Add a test to the <code>newmath</code> package by creating the file
+<code>$GOPATH/src/example/newmath/sqrt_test.go</code> containing the following
+Go code.
 </p>

 <pre>
-package stringutil
+package newmath

 import "testing"

-func TestReverse(t *testing.T) {
-	cases := []struct {
-		in, want string
-	}{
-		{"Hello, world", "dlrow ,olleH"},
-		{"Hello, 世界", "界世 ,olleH"},
-		{"", ""},
-	}
-	for _, c := range cases {
-		got := Reverse(c.in)
-		if got != c.want {
-			t.Errorf("Reverse(%q) == %q, want %q", c.in, got, c.want)
-		}
-	}
+func TestSqrt(t *testing.T) {
+	const in, out = 4, 2
+	if x := Sqrt(in); x != out {
+		t.Errorf("Sqrt(%v) = %v, want %v", in, x, out)
+        }
 }
 </pre>

 <p>
-Then run the test with <code>go test</code>:
+Now run the test with <code>go test</code>:
 </p>

 <pre>
-$ <b>go test github.com/user/stringutil</b>
-ok  	github.com/user/stringutil 0.165s
+$ go test example/newmath
+ok  	example/newmath 0.165s
 </pre>

 <p>
-As always, if you are running the <code>go</code> tool from the package
-directory, you can omit the package path:
-</p>
-
-<pre>
-$ <b>go test</b>
-ok  	github.com/user/stringutil 0.165s
-</pre>
-
-<p>
-Run <code><a href="/cmd/go/#hdr-Test_packages">go help test</a></code> and see the
+Run <code><a href="/cmd/go/#Test_packages">go help test</a></code> and see the
 <a href="/pkg/testing/">testing package documentation</a> for more detail.
 </p>

@@ -517,19 +411,19 @@ Run <code><a href="/cmd/go/#hdr-Test_packages">go help test</a></code> and see t

 <p>
 An import path can describe how to obtain the package source code using a
-revision control system such as Git or Mercurial. The <code>go</code> tool uses
+revision control system such as Git or Mercurial. The <code>go</code> command uses
 this property to automatically fetch packages from remote repositories.
 For instance, the examples described in this document are also kept in a
-Git repository hosted at GitHub
-<code><a href="https://github.com/golang/example">github.com/golang/example</a></code>.
+Mercurial repository hosted at Google Code,
+<code><a href="http://code.google.com/p/go.example">code.google.com/p/go.example</a></code>.
 If you include the repository URL in the package's import path,
 <code>go get</code> will fetch, build, and install it automatically:
 </p>

 <pre>
-$ <b>go get github.com/golang/example/hello</b>
-$ <b>$GOPATH/bin/hello</b>
-Hello, Go examples!
+$ go get code.google.com/p/go.example/hello
+$ $GOPATH/bin/hello
+Hello, world.  Sqrt(2) = 1.414213562373095
 </pre>

 <p>
@@ -541,67 +435,58 @@ fetch and behaves the same as <code>go install</code>.)

 <p>
 After issuing the above <code>go get</code> command, the workspace directory
-tree should now look like this:
+tree should now now look like this:
 </p>

 <pre>
 bin/
-    hello                           # command executable
+    hello                 # command executable
 pkg/
-    linux_amd64/
-        github.com/golang/example/
-            stringutil.a            # package object
-        github.com/user/
-            stringutil.a            # package object
+    linux_amd64/ 
+        code.google.com/p/go.example/
+            newmath.a     # package object
+        example/
+            newmath.a     # package object
 src/
-    github.com/golang/example/
-	.git/                       # Git repository metadata
+    code.google.com/p/go.example/
        hello/
-            hello.go                # command source
-        stringutil/
-            reverse.go              # package source
-            reverse_test.go         # test source
-    github.com/user/
+            hello.go      # command source
+        newmath/
+            sqrt.go       # package source
+            sqrt_test.go  # test source
+    example/
        hello/
-            hello.go                # command source
-        stringutil/
-            reverse.go              # package source
-            reverse_test.go         # test source
+            hello.go      # command source
+        newmath/
+            sqrt.go       # package source
+            sqrt_test.go  # test source
 </pre>

 <p>
-The <code>hello</code> command hosted at GitHub depends on the
-<code>stringutil</code> package within the same repository. The imports in
-<code>hello.go</code> file use the same import path convention, so the
-<code>go get</code> command is able to locate and install the dependent
-package, too.
+The <code>hello</code> command hosted at Google Code depends on the
+<code>newmath</code> package within the same repository. The imports in
+<code>hello.go</code> file use the same import path convention, so the <code>go
+get</code> command is able to locate and install the dependent package, too.
 </p>

 <pre>
-import "github.com/golang/example/stringutil"
+import "code.google.com/p/go.example/newmath"
 </pre>

 <p>
 This convention is the easiest way to make your Go packages available for
 others to use.
-The <a href="//golang.org/wiki/Projects">Go Wiki</a>
-and <a href="//godoc.org/">godoc.org</a>
-provide lists of external Go projects.
+The <a href="http://godashboard.appspot.com">Go Project Dashboard</a>
+is a list of external Go projects including programs and libraries.
 </p>

 <p>
-For more information on using remote repositories with the <code>go</code> tool, see
-<code><a href="/cmd/go/#hdr-Remote_import_paths">go help importpath</a></code>.
+For more information on using remote repositories with the <code>go</code> command, see
+<code><a href="/cmd/go/#Remote_import_path_syntax">go help remote</a></code>.
 </p>


-<h2 id="next">What's next</h2>
-
-<p>
-Subscribe to the
-<a href="//groups.google.com/group/golang-announce">golang-announce</a>
-mailing list to be notified when a new stable version of Go is released.
-</p>
+<h2 id="more">Further reading</h2>

 <p>
 See <a href="/doc/effective_go.html">Effective Go</a> for tips on writing
@@ -609,7 +494,7 @@ clear, idiomatic Go code.
 </p>

 <p>
-Take <a href="//tour.golang.org/">A Tour of Go</a> to learn the language
+Take <a href="http://tour.golang.org/">A Tour of Go</a> to learn the language
 proper.
 </p>

@@ -617,21 +502,3 @@ proper.
 Visit the <a href="/doc/#articles">documentation page</a> for a set of in-depth
 articles about the Go language and its libraries and tools.
 </p>
-
-
-<h2 id="help">Getting help</h2>
-
-<p>
-For real-time help, ask the helpful gophers in <code>#go-nuts</code> on the
-<a href="http://freenode.net/">Freenode</a> IRC server.
-</p>
-
-<p>
-The official mailing list for discussion of the Go language is
-<a href="//groups.google.com/group/golang-nuts">Go Nuts</a>.
-</p>
-
-<p>
-Report bugs using the
-<a href="//golang.org/issue">Go issue tracker</a>.
-</p>
--- a/doc/codewalk/codewalk.js
+++ b/doc/codewalk/codewalk.js
@@ -296,8 +296,8 @@ CodewalkViewer.prototype.updateHeight = function() {
  this.sizer.height(codeHeight);
 };

-window.initFuncs.push(function() {
-  var viewer = new CodewalkViewer(jQuery('#codewalk-main'));
+jQuery(document).ready(function() {
+  var viewer = new CodewalkViewer(jQuery());
  viewer.selectFirstComment();
  viewer.targetCommentLinksAtBlank();
  viewer.installEventHandlers();
--- a/doc/codewalk/codewalk.xml
+++ b/doc/codewalk/codewalk.xml
@@ -42,7 +42,7 @@
 	its <code>src</code> is just a file name.
 </step>

-<step title="Specifying a source line" src='doc/codewalk/codewalk.xml:/title="Title"/'>
+<step title="Specifiying a source line" src='doc/codewalk/codewalk.xml:/title="Title"/'>
 	The most complex part of the codewalk specification is
 	saying what lines to highlight.
 	Instead of ordinary line numbers,
--- a/doc/codewalk/markov.xml
+++ b/doc/codewalk/markov.xml
@@ -58,7 +58,7 @@ Prefix               Map key
 	this data.
 </step>

-<step title="The NewChain constructor function" src="doc/codewalk/markov.go:/func New/,/\n}/">
+<step title="The NewChain constructor function" src="doc/codewalk/markov.go:/func New/,/}/">
 	The <code>Chain</code> struct has two unexported fields (those that
 	do not begin with an upper case character), and so we write a
 	<code>NewChain</code> constructor function that initializes the
@@ -181,7 +181,7 @@ p == Prefix{"am", "not"}</pre>
 	one index to the left (if you consider zero as the leftmost index).
 	<pre>
 p := Prefix{"I", "am"}
-copy(p, p[1:])
+copy(p, p[:1])
 // p == Prefix{"am", "am"}</pre>
 	We then assign the provided <code>word</code> to the last index
 	of the slice:
--- a/doc/codewalk/pig.go
+++ b/doc/codewalk/pig.go
@@ -23,7 +23,7 @@ type score struct {
 // An action transitions stochastically to a resulting score.
 type action func(current score) (result score, turnIsOver bool)

-// roll returns the (result, turnIsOver) outcome of simulating a die roll.
+// roll returns the (result, turnIsOver) outcome of simulating a die roll. 
 // If the roll value is 1, then thisTurn score is abandoned, and the players'
 // roles swap.  Otherwise, the roll value is added to thisTurn.
 func roll(s score) (score, bool) {
--- a/doc/codewalk/run
+++ b/doc/codewalk/run
@@ -1,21 +0,0 @@
-#!/usr/bin/env bash
-# Copyright 2013 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.
-
-set -e
-
-function fail {
-	echo FAIL: doc/codewalk/$1
-	exit 1
-}
-
-# markov.xml
-echo foo | go run markov.go | grep foo > /dev/null || fail markov
-
-# functions.xml
-go run pig.go | grep 'Wins, losses staying at k = 100: 210/990 (21.2%), 780/990 (78.8%)' > /dev/null || fail pig
-
-# sharemem.xml: only build the example, as it uses the network
-go build urlpoll.go || fail urlpoll
-rm -f urlpoll
--- a/doc/codewalk/sharemem.xml
+++ b/doc/codewalk/sharemem.xml
@@ -171,7 +171,7 @@ and/or writes to a shared map.

 <step title="Conclusion" src="doc/codewalk/urlpoll.go">
 In this codewalk we have explored a simple example of using Go's concurrency
-primitives to share memory through communication.
+primitives to share memory through commmunication.
 <br/><br/>
 This should provide a starting point from which to explore the ways in which
 goroutines and channels can be used to write expressive and concise concurrent
--- a/doc/codewalk/urlpoll.go
+++ b/doc/codewalk/urlpoll.go
@@ -76,7 +76,7 @@ func (r *Resource) Poll() string {
 	return resp.Status
 }

-// Sleep sleeps for an appropriate interval (dependent on error state)
+// Sleep sleeps for an appropriate interval (dependant on error state)
 // before sending the Resource to done.
 func (r *Resource) Sleep(done chan<- *Resource) {
 	time.Sleep(pollInterval + errTimeout*time.Duration(r.errCount))
--- a/doc/contrib.html
+++ b/doc/contrib.html
@@ -9,7 +9,7 @@

 <p>
 Go is an open source project developed by a team at
-<a href="//google.com/">Google</a> and many
+<a href="http://google.com/">Google</a> and many
 <a href="/CONTRIBUTORS">contributors</a> from the open source community.
 </p>

@@ -17,72 +17,49 @@ Go is an open source project developed by a team at
 Go is distributed under a <a href="/LICENSE">BSD-style license</a>.
 </p>

-<h3 id="announce"><a href="//groups.google.com/group/golang-announce">Announcements Mailing List</a></h3>
+<h3 id="announce"><a href="http://groups.google.com/group/golang-announce">Announcements Mailing List</a></h3>
 <p>
 A low traffic mailing list for important announcements, such as new releases.
 </p>
 <p>
 We encourage all Go users to subscribe to
-<a href="//groups.google.com/group/golang-announce">golang-announce</a>.
+<a href="http://groups.google.com/group/golang-announce">golang-announce</a>.
 </p>

-
-<h2 id="go1">Version history</h2>
-
-<h3 id="release"><a href="/doc/devel/release.html">Release History</a></h3>
-
-<p>A <a href="/doc/devel/release.html">summary</a> of the changes between Go releases. Notes for the major releases:</p>
-
-<ul>
-	<li><a href="/doc/go1.4">Go 1.4</a> <small>(December 2014)</small></li>
-	<li><a href="/doc/go1.3">Go 1.3</a> <small>(June 2014)</small></li>
-	<li><a href="/doc/go1.2">Go 1.2</a> <small>(December 2013)</small></li>
-	<li><a href="/doc/go1.1">Go 1.1</a> <small>(May 2013)</small></li>
-	<li><a href="/doc/go1">Go 1</a> <small>(March 2012)</small></li>
-</ul>
-
-<h3 id="go1compat"><a href="/doc/go1compat">Go 1 and the Future of Go Programs</a></h3>
-<p>
-What Go 1 defines and the backwards-compatibility guarantees one can expect as
-Go 1 matures.
-</p>
-
-
 <h2 id="resources">Developer Resources</h2>

-<h3 id="source"><a href="https://golang.org/change">Source Code</a></h3>
+<h3 id="source"><a href="https://code.google.com/p/go/source">Source Code</a></h3>
 <p>Check out the Go source code.</p>

-<h3 id="golang-dev"><a href="https://groups.google.com/group/golang-dev">Developer</a> and
-<a href="https://groups.google.com/group/golang-codereviews">Code Review Mailing List</a></h3>
-<p>The <a href="https://groups.google.com/group/golang-dev">golang-dev</a>
-mailing list is for discussing code changes to the Go project.
-The <a href="https://groups.google.com/group/golang-codereviews">golang-codereviews</a>
-mailing list is for actual reviewing of the code changes (CLs).</p>
+<h3 id="release"><a href="/doc/devel/release.html">Release History</a></h3>
+<p>A summary of the changes between Go releases.</p>

+<h3 id="weekly"><a href="/doc/devel/weekly.html">Weekly Snapshot History</a></h3>
+<p>A summary of the changes between weekly snapshots 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="https://groups.google.com/group/golang-nuts">golang-nuts</a>.</p>
+href="http://groups.google.com/group/golang-nuts">golang-nuts</a>.</p>

-<h3 id="golang-checkins"><a href="https://groups.google.com/group/golang-checkins">Checkins Mailing List</a></h3>
+<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>

-<h3 id="golang-bugs"><a href="https://groups.google.com/group/golang-bugs">Bugs Mailing List</a></h3>
-<p>A mailing list that receives each update to the Go <a href="//golang.org/issue">issue tracker</a>.</p>
-
-<h3 id="build_status"><a href="//build.golang.org/">Build Status</a></h3>
+<h3 id="build_status"><a href="http://build.golang.org/">Build Status</a></h3>
 <p>View the status of Go builds across the supported operating
 systems and architectures.</p>


 <h2 id="howto">How you can help</h2>

-<h3><a href="//golang.org/issue">Reporting issues</a></h3>
+<h3><a href="http://code.google.com/p/go/issues">Reporting issues</a></h3>

 <p>
 If you spot bugs, mistakes, or inconsistencies in the Go project's code or
 documentation, please let us know by
-<a href="//golang.org/issue/new">filing a ticket</a>
-on our <a href="//golang.org/issue">issue tracker</a>.
+<a href="http://code.google.com/p/go/issues/entry">filing a ticket</a>
+on our <a href="http://code.google.com/p/go/issues">issue tracker</a>.
 (Of course, you should check it's not an existing issue before creating
 a new one.)
 </p>
@@ -101,8 +78,31 @@ To get started, read these <a href="/doc/contribute.html">contribution
 guidelines</a> for information on design, testing, and our code review process.
 </p>
 <p>
-Check <a href="//golang.org/issue">the tracker</a> for 
+Check <a href="http://code.google.com/p/go/issues">the tracker</a> for 
 open issues that interest you. Those labeled
-<a href="https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3Ahelpwanted">helpwanted</a>
+<a href="http://code.google.com/p/go/issues/list?q=status=HelpWanted">HelpWanted</a>
 are particularly in need of outside help.
 </p>
+
+
+<h2 id="community">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="projects"><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="plus"><a href="https://plus.google.com/101406623878176903605/posts">The Go Programming Language at Google+</a></h3>
+<p>The Go project's Google+ page.</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>
+
+<h3 id="blog"><a href="http://blog.golang.org/">The Go Blog</a></h3>
+<p>The official blog of the Go project, featuring news and in-depth articles by
+the Go team and guests.</p>
--- a/doc/contribute.html
+++ b/doc/contribute.html
@@ -6,12 +6,9 @@

 <p>
 This document explains how to contribute changes to the Go project.
-It assumes you have followed the
-<a href="/doc/install/source">installation instructions</a> and
+It assumes you have installed Go using the
+<a href="/doc/install">installation instructions</a> and
 have <a href="code.html">written and tested your code</a>.
-</p>
-
-<p>
 (Note that the <code>gccgo</code> frontend lives elsewhere;
 see <a href="gccgo_contribute.html">Contributing to gccgo</a>.)
 </p>
@@ -25,7 +22,7 @@ you're working on if you want it to become part of the main repository.

 <p>
 Before undertaking to write something new for the Go project, send
-mail to the <a href="https://groups.google.com/group/golang-nuts">mailing
+mail to the <a href="http://groups.google.com/group/golang-nuts">mailing
 list</a> to discuss what you plan to do.  This gives everyone a
 chance to validate the design, helps prevent duplication of effort,
 and ensures that the idea fits inside the goals for the language
@@ -48,19 +45,25 @@ tree to make sure the changes don't break other packages or programs:
 </p>

 <pre>
-$ cd go/src
-$ ./all.bash
+cd $GOROOT/src
+./all.bash
 </pre>

 <p>
-(To build under Windows use <code>all.bat</code>.)
+The final line printed by <code>make all</code> should be of the form:
 </p>

+<pre>
+<i>N</i> known bugs; 0 unexpected bugs
+</pre>
+
 <p>
-After running for a while, the command should print
-"<code>ALL</code> <code>TESTS</code> <code>PASSED</code>".
+The value of <i>N</i> varies over time, but the line must
+say &ldquo;<code>0 unexpected bugs</code>&rdquo; and must not
+add &ldquo;<code>test output differs</code>.&rdquo;
 </p>

+
 <h2 id="Code_review">Code review</h2>

 <p>
@@ -68,230 +71,163 @@ Changes to Go must be reviewed before they are submitted,
 no matter who makes the change.
 (In exceptional cases, such as fixing a build, the review can
 follow shortly after submitting.)
-A custom git command called <code>git-codereview</code>,
-discussed below, helps manage the code review process through a Google-hosted
-<a href="https://go-review.googlesource.com/">instance</a> of the code review
-system called <a href="https://code.google.com/p/gerrit/">Gerrit</a>.
+A Mercurial extension helps manage the code review process.
+The extension is included in the Go source tree but needs
+to be added to your Mercurial configuration.
 </p>

-<h3>Set up authentication for code review</h3>
+<h3>Caveat for Mercurial aficionados</h3>

 <p>
-The Git code hosting server and Gerrit code review server both use a Google
-Account to authenticate. You therefore need a Google Account to proceed.
+<i>Using Mercurial with the code review extension is not the same
+as using standard Mercurial.</i>
+</p>
+
+<p>
+The Go repository is maintained as a single line of reviewed changes;
+we prefer to avoid the complexity of Mercurial's arbitrary change graph.
+The code review extension helps here: its <code>hg submit</code> command
+automatically checks for and warns about the local repository
+being out of date compared to the remote one.
+The <code>hg submit</code> command also verifies other
+properties about the Go repository.
+For example,
+it checks that Go code being checked in is formatted in the standard style,
+as defined by <a href="/cmd/gofmt">gofmt</a>,
+and it checks that the author of the code is properly recorded for
+<a href="#copyright">copyright purposes</a>.
+</p>
+
+<p>
+To help ensure changes are only created by <code>hg submit</code>,
+the code review extension disables the standard <code>hg commit</code>
+command.
+</p>
+
+<h3>Configure the extension</h3>
+
+<p>Edit <code>$GOROOT/.hg/hgrc</code> to add:</p>
+
+<pre>
+[extensions]
+codereview = YOUR_GO_ROOT/lib/codereview/codereview.py
+
+[ui]
+username = Your Name &lt;you@server.dom&gt;
+</pre>
+
+<p>Replace YOUR_GO_ROOT with the value of <code>$GOROOT</code>.
+The Mercurial configuration file format does not allow environment variable substitution.
+The <code>username</code> information will not be used unless
+you are a committer (see below), but Mercurial complains if it is missing.
+</p>
+
+<h3>Log in to the code review site.</h3>
+
+<p>
+The code review server uses a Google Account to authenticate.
 (If you can use the account to
-<a href="https://www.google.com/accounts/Login">sign in at google.com</a>,
-you can use it to sign in to the code review server.)
-The email address you use with the code review system
-will be recorded in the <a href="https://go.googlesource.com/go">change log</a>
+<a href="https://www.google.com/accounts/Login?hl=en&amp;continue=http://www.google.com/">sign in at google.com</a>,
+you can use it to sign in to the code review server.
+The email address you use on the Code Review site
+will be recorded in the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
 and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file.
 You can <a href="https://www.google.com/accounts/NewAccount">create a Google Account</a>
 associated with any address where you receive email.
 </p>

-<p>
-Visit the site <a href="https://go.googlesource.com">go.googlesource.com</a>
-and log in using your Google Account.
-Click on the "Generate Password" link that appears at the top of the page.
-</p>
-
-<p>
-Click the radio button that says "Only <code>go.googlesource.com</code>"
-to use this authentication token only for the Go project.
-</p>
-
-<p>
-Further down the page is a box containing commands to install
-the authentication cookie in file called <code>.gitcookies</code> in your home
-directory.
-Copy the text for the commands into a Unix shell window to execute it.
-That will install the authentication token.
-</p>
-
-<p>
-(If you are on a Windows computer, you should instead follow the instructions
-in the yellow box to run the command.)
-</p>
-
-<h3>Register with Gerrit</h3>
-
-<p>
-Now that you have a Google account and the authentication token,
-you need to register your account with Gerrit, the code review system.
-To do this, visit <a href="https://golang.org/cl">golang.org/cl</a>
-and log in using the same Google Account you used above.
-That is all that is required.
-</p>
-
-<h3>Install the git-codereview command</h3>
-
-<p>
-Now install the <code>git-codereview</code> command by running,
-</p>
-
 <pre>
-go get -u golang.org/x/review/git-codereview
+$ cd $GOROOT
+$ hg code-login
+Email (login for uploading to codereview.appspot.com): rsc@golang.org
+Password for rsc@golang.org:
+
+Saving authentication cookies to /Users/rsc/.codereview_upload_cookies_codereview.appspot.com
 </pre>

-<p>
-Make sure <code>git-codereview</code> is installed in your shell path, so that the
-<code>git</code> command can find it. Check that
+<h3>Configure your account settings.</h3>
+
+<p>Edit your <a href="http://codereview.appspot.com/settings">code review settings</a>.
+Grab a nickname.
+Many people prefer to set the Context option to
+&ldquo;Whole file&rdquo; to see more context when reviewing changes.
 </p>

-<pre>
-$ git codereview help
-</pre>
-
-<p>
-prints help text, not an error.
-</p>
-
-<p>
-Note to Git aficionados: The <code>git-codereview</code> command is not required to
-upload and manage Gerrit code reviews. For those who prefer plain Git, the text
-below gives the Git equivalent of each git-codereview command. If you do use plain
-Git, note that you still need the commit hooks that the git-codereview command
-configures; those hooks add a Gerrit <code>Change-Id</code> line to the commit
-message and check that all Go source files have been formatted with gofmt. Even
-if you intend to use plain Git for daily work, install the hooks in a new Git
-checkout by running <code>git-codereview</code> <code>hooks</code>.
-</p>
-
-<h3>Set up git aliases</h3>
-
-<p>
-The <code>git-codereview</code> command can be run directly from the shell
-by typing, for instance,
-</p>
-
-<pre>
-$ git codereview sync
-</pre>
-
-<p>
-but it is more convenient to set up aliases for <code>git-codereview</code>'s own
-subcommands, so that the above becomes,
-</p>
-
-<pre>
-$ git sync
-</pre>
-
-<p>
-The <code>git-codereview</code> subcommands have been chosen to be distinct from
-Git's own, so it's safe to do so.
-</p>
-
-<p>
-The aliases are optional, but in the rest of this document we will assume
-they are installed.
-To install them, copy this text into your Git configuration file
-(usually <code>.gitconfig</code> in your home directory):
-</p>
-
-<pre>
-[alias]
-	change = codereview change
-	gofmt = codereview gofmt
-	mail = codereview mail
-	pending = codereview pending
-	submit = codereview submit
-	sync = codereview sync
-</pre>
-
-<h3>Understanding the git-codereview command</h3>
-
-<p>After installing the <code>git-codereview</code> command, you can run</p>
-
-<pre>
-$ git codereview help
-</pre>
-
-<p>
-to learn more about its commands.
-You can also read the <a href="https://godoc.org/golang.org/x/review/git-codereview">command documentation</a>.
-</p>
-
-<h3>Switch to the master branch</h3>
-
-<p>
-Most Go installations use a release branch, but new changes should
-only be made based on the master branch.
-(They may be applied later to a release branch as part of the release process,
-but most contributors won't do this themselves.)
-Before making a change, make sure you start on the master branch:
-</p>
-
-<pre>
-$ git checkout master
-$ git sync
-</pre>
-
-<p>
-(In Git terms, <code>git</code> <code>sync</code> runs
-<code>git</code> <code>pull</code> <code>-r</code>.)
+<p>Once you have chosen a nickname in the settings page, others
+can use that nickname as a shorthand for naming reviewers and the CC list.
+For example, <code>rsc</code> is an alias for <code>rsc@golang.org</code>.
 </p>

 <h3>Make a change</h3>

 <p>
 The entire checked-out tree is writable.
-Once you have edited files, you must tell Git that they have been modified.
-You must also tell Git about any files that are added, removed, or renamed files.
-These operations are done with the usual Git commands,
-<code>git</code> <code>add</code>,
-<code>git</code> <code>rm</code>,
-and
-<code>git</code> <code>mv</code>.
+If you need to edit files, just edit them: Mercurial will figure out which ones changed.
+You do need to inform Mercurial of added, removed, copied, or renamed files,
+by running
+<code>hg add</code>,
+<code>hg rm</code>,
+<code>hg cp</code>,
+or
+<code>hg mv</code>.
 </p>

-<p>
-If you wish to checkpoint your work, or are ready to send the code out for review, run</p>
+<p>When you are ready to send a change out for review, run</p>

 <pre>
-$ git change <i>&lt;branch&gt;</i>
+$ hg change
 </pre>

-<p>
-from any directory in your Go repository to commit the changes so far.
-The name <i>&lt;branch&gt;</i> is an arbitrary one you choose to identify the
-local branch containing your changes.
-</p>
-
-<p>
-(In Git terms, <code>git</code> <code>change</code> <code>&lt;branch&gt;</code>
-runs <code>git</code> <code>checkout</code> <code>-b</code> <code>branch</code>,
-then <code>git</code> <code>branch</code> <code>--set-upstream-to</code> <code>origin/master</code>,
-then <code>git</code> <code>commit</code>.)
-</p>
-
-<p>
-Git will open a change description file in your editor.
-(It uses the editor named by the <code>$EDITOR</code> environment variable,
-<code>vi</code> by default.)
+<p>from any directory in your Go repository.
+Mercurial will open a change description file in your editor.
+(It uses the editor named by the <code>$EDITOR</code> environment variable, <code>vi</code> by default.)
 The file will look like:
 </p>

 <pre>
+# Change list.
+# Lines beginning with # are ignored.
+# Multi-line values should be indented.

-# Please enter the commit message for your changes. Lines starting
-# with '#' will be ignored, and an empty message aborts the commit.
-# On branch foo
-# Changes not staged for commit:
-#	modified:   editedfile.go
-#
+Reviewer:
+CC:
+
+Description:
+	&lt;enter description here&gt;
+
+Files:
+	src/pkg/math/sin.go
+	src/pkg/math/tan.go
+	src/pkg/regexp/regexp.go
 </pre>

 <p>
-At the beginning of this file is a blank line; replace it
-with a thorough description of your change.
+The <code>Reviewer</code> line lists the reviewers assigned
+to this change, and the <code>CC</code> line lists people to
+notify about the change.
+These can be code review nicknames or arbitrary email addresses.
+Unless explicitly told otherwise, such as in the discussion leading
+up to sending in the change list, leave the reviewer field blank.
+This means that the
+<a href="http://groups.google.com/group/golang-dev">golang-dev@googlegroups.com</a>
+mailing list will be used as the reviewer.
+</p>
+
+<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, prefixed by the primary affected package,
-and is used as the subject for code review mail.
-The rest of the
-description elaborates and should provide context for the
-change and explain what it does.
-If there is a helpful reference, mention it here.
+and is used as the subject for code review mail; the rest of the
+description elaborates.
+</p>
+
+<p>
+The <code>Files</code> section lists all the modified files
+in your client.
+It is best to keep unrelated changes in different change lists.
+In this example, we can include just the changes to package <code>math</code>
+by deleting the line mentioning <code>regexp.go</code>.
 </p>

 <p>
@@ -299,330 +235,264 @@ After editing, the template might now read:
 </p>

 <pre>
-math: improved Sin, Cos and Tan precision for very large arguments
+# Change list.
+# Lines beginning with # are ignored.
+# Multi-line values should be indented.

-The existing implementation has poor numerical properties for
-large arguments, so use the McGillicutty algorithm to improve
-accuracy above 1e10.
+Reviewer: golang-dev@googlegroups.com
+CC: math-nuts@swtch.com

-The algorithm is described at http://wikipedia.org/wiki/McGillicutty_Algorithm
+Description:
+	math: improved Sin, Cos and Tan precision for very large arguments.

-Fixes #159
+	See Bimmler and Shaney, ``Extreme sinusoids,'' J. Math 3(14).
+	Fixes issue 159.

-# Please enter the commit message for your changes. Lines starting
-# with '#' will be ignored, and an empty message aborts the commit.
-# On branch foo
-# Changes not staged for commit:
-#	modified:   editedfile.go
-#
+Files:
+	src/pkg/math/sin.go
+	src/pkg/math/tan.go
 </pre>

 <p>
-The commented section of the file lists all the modified files in your client.
-It is best to keep unrelated changes in different change lists,
-so if you see a file listed that should not be included, abort
-the command and move that file to a different branch.
-</p>
-
-<p>
-The special notation "Fixes #159" associates the change with issue 159 in the
-<a href="https://golang.org/issue/159">Go issue tracker</a>.
+The special sentence &ldquo;Fixes issue 159.&rdquo; associates
+the change with issue 159 in the <a href="http://code.google.com/p/go/issues/list">Go issue tracker</a>.
 When this change is eventually submitted, the issue
 tracker will automatically mark the issue as fixed.
-(There are several such conventions, described in detail in the
-<a href="https://help.github.com/articles/closing-issues-via-commit-messages/">GitHub Issue Tracker documentation</a>.)
 </p>

 <p>
-Once you have finished writing the commit message,
-save the file and exit the editor.
-</p>
-
-<p>
-If you wish to do more editing, re-stage your changes using
-<code>git</code> <code>add</code>, and then run
-</p>
-
-<pre>
-$ git change
-</pre>
-
-<p>
-to update the change description and incorporate the staged changes.  The
-change description contains a <code>Change-Id</code> line near the bottom,
-added by a Git commit hook during the initial
-<code>git</code> <code>change</code>.
-That line is used by Gerrit to match successive uploads of the same change.
-Do not edit or delete it.
-</p>
-
-<p>
-(In Git terms, <code>git</code> <code>change</code> with no branch name
-runs <code>git</code> <code>commit</code> <code>--amend</code>.)
-</p>
-
-<h3>Mail the change for review</h3>
-
-<p>
-Once the change is ready, mail it out for review:
-</p>
-
-<pre>
-$ git mail
-</pre>
-
-<p>
-You can specify a reviewer or CC interested parties
-using the <code>-r</code> or <code>-cc</code> options.
-Both accept a comma-separated list of email addresses:
-</p>
-
-<pre>
-$ git mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
-</pre>
-
-<p>
-Unless explicitly told otherwise, such as in the discussion leading
-up to sending in the change list, it's better not to specify a reviewer.
-All changes are automatically CC'ed to the
-<a href="https://groups.google.com/group/golang-codereviews">golang-codereviews@googlegroups.com</a>
-mailing list.
-</p>
-
-<p>
-(In Git terms, <code>git</code> <code>mail</code> pushes the local committed
-changes to Gerrit using <code>git</code> <code>push</code> <code>origin</code>
-<code>HEAD:refs/for/master</code>.)
-</p>
-
-<p>
-If your change relates to an open issue, please add a comment to the issue
-announcing your proposed fix, including a link to your CL.
-</p>
+Save the file and exit the editor.</p>

 <p>
 The code review server assigns your change an issue number and URL,
-which <code>git</code> <code>mail</code> will print, something like:
+which <code>hg change</code> will print, something like:
 </p>

 <pre>
-remote: New Changes:
-remote:   https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments
+CL created: http://codereview.appspot.com/99999
 </pre>

-<h3>Reviewing code</h3>
-
 <p>
-Running <code>git</code> <code>mail</code> will send an email to you and the
-reviewers asking them to visit the issue's URL and make comments on the change.
-When done, the reviewer adds comments through the Gerrit user interface
-and clicks "Reply" to send comments back.
-You will receive a mail notification when this happens.
-You must reply through the web interface.
-(Unlike with the old Rietveld review system, replying by mail has no effect.)
-</p>
-
-<h3>Revise and upload</h3>
-
-<p>
-You must respond to review comments through the web interface.
-(Unlike with the old Rietveld review system, responding by mail has no effect.)
+If you need to re-edit the change description,
+run <code>hg change 99999</code>.
 </p>

 <p>
-When you have revised the code and are ready for another round of review,
-stage those changes and use <code>git</code> <code>change</code> to update the
-commit.
-To send the update change list for another round of review,
-run <code>git</code> <code>mail</code> again.
+You can see a list of your pending changes by running <code>hg pending</code> (<code>hg p</code> for short).
 </p>

-<p>
-The reviewer can comment on the new copy, and the process repeats.
-The reviewer approves the change by giving it a positive score
-(+1 or +2) and replying <code>LGTM</code>: looks good to me.
-</p>
-
-<p>
-You can see a list of your pending changes by running <code>git</code>
-<code>pending</code>, and switch between change branches with <code>git</code>
-<code>change</code> <code><i>&lt;branch&gt;</i></code>.
-</p>

 <h3>Synchronize your client</h3>

-<p>
-While you were working, others might have submitted changes to the repository.
-To update your local branch, run
-</p>
+<p>While you were working, others might have submitted changes
+to the repository.  To update your client, run</p>

 <pre>
-$ git sync
+$ hg sync
 </pre>

+<p>(For Mercurial fans, <code>hg sync</code> runs <code>hg pull -u</code>
+but then also synchronizes the local change list state against the new data.)</p>
+
 <p>
-(In git terms, <code>git</code> <code>sync</code> runs
-<code>git</code> <code>pull</code> <code>-r</code>.)
+If files you were editing have changed, Mercurial does its best to merge the
+remote changes into your local changes.  It may leave some files to merge by hand.
 </p>

 <p>
-If files you were editing have changed, Git does its best to merge the
-remote changes into your local changes.
-It may leave some files to merge by hand.
-</p>
-
-<p>
-For example, suppose you have edited <code>sin.go</code> but
+For example, suppose you have edited <code>flag_test.go</code> but
 someone else has committed an independent change.
-When you run <code>git</code> <code>sync</code>,
-you will get the (scary-looking) output:
+When you run <code>hg sync</code>, you will get the (scary-looking) output
+(emphasis added):

 <pre>
-$ git sync
-Failed to merge in the changes.
-Patch failed at 0023 math: improved Sin, Cos and Tan precision for very large arguments
-The copy of the patch that failed is found in:
-   /home/you/repo/.git/rebase-apply/patch
-
-When you have resolved this problem, run "git rebase --continue".
-If you prefer to skip this patch, run "git rebase --skip" instead.
-To check out the original branch and stop rebasing, run "git rebase --abort".
+$ hg sync
+adding changesets
+adding manifests
+adding file changes
+added 1 changeset with 2 changes to 2 files
+getting src/pkg/flag/flag.go
+couldn't find merge tool hgmerge
+merging src/pkg/flag/flag_test.go
+warning: conflicts during merge.
+<i>merging src/pkg/flag/flag_test.go failed!</i>
+1 file updated, 0 files merged, 0 files removed, 1 file unresolved
+use 'hg resolve' to retry unresolved file merges
+$
 </pre>

 <p>
-If this happens, run
-</p>
-
-<pre>
-$ git status
-</pre>
-
-<p>
-to see which files failed to merge.
-The output will look something like this:
-</p>
-
-<pre>
-rebase in progress; onto a24c3eb
-You are currently rebasing branch 'mcgillicutty' on 'a24c3eb'.
-  (fix conflicts and then run "git rebase --continue")
-  (use "git rebase --skip" to skip this patch)
-  (use "git rebase --abort" to check out the original branch)
-
-Unmerged paths:
-  (use "git reset HEAD &lt;file&gt;..." to unstage)
-  (use "git add &lt;file&gt;..." to mark resolution)
-
-	<i>both modified:   sin.go</i>
-</pre>
-
-<p>
-The only important part in that transcript is the italicized "both modified"
-line: Git failed to merge your changes with the conflicting change.
-When this happens, Git leaves both sets of edits in the file,
-with conflicts marked by <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> and
+The only important part in that transcript is the italicized line:
+Mercurial failed to merge your changes with the independent change.
+When this happens, Mercurial leaves both edits in the file,
+marked by <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> and
 <code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code>.
-It is now your job to edit the file to combine them.
-Continuing the example, searching for those strings in <code>sin.go</code>
+it is now your job to edit the file to combine them.
+Continuing the example, searching for those strings in <code>flag_test.go</code>
 might turn up:
 </p>

 <pre>
-	arg = scale(arg)
-&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
-	if arg > 1e9 {
+	VisitAll(visitor);
+&lt;&lt;&lt;&lt;&lt;&lt;&lt; local
+	if len(m) != 7 {
 =======
-	if arg > 1e10 {
-&gt;&gt;&gt;&gt;&gt;&gt;&gt; mcgillicutty
-		largeReduce(arg)
+	if len(m) != 8 {
+&gt;&gt;&gt;&gt;&gt;&gt;&gt; other
+		t.Error("VisitAll misses some flags");
 </pre>

 <p>
-Git doesn't show it, but suppose the original text that both edits
-started with was 1e8; you changed it to 1e10 and the other change to 1e9,
-so the correct answer might now be 1e10.  First, edit the section
+Mercurial doesn't show it, but suppose the original text that both edits
+started with was 6; you added 1 and the other change added 2,
+so the correct answer might now be 9.  First, edit the section
 to remove the markers and leave the correct code:
 </p>

 <pre>
-	arg = scale(arg)
-	if arg > 1e10 {
-		largeReduce(arg)
+	VisitAll(visitor);
+	if len(m) != 9 {
+		t.Error("VisitAll misses some flags");
 </pre>

 <p>
-Then tell Git that the conflict is resolved by running
+Then ask Mercurial to mark the conflict as resolved:
 </p>

 <pre>
-$ git add sin.go
+$ hg resolve -m flag_test.go
 </pre>

 <p>
 If you had been editing the file, say for debugging, but do not
 care to preserve your changes, you can run
-<code>git</code> <code>reset</code> <code>HEAD</code> <code>sin.go</code>
-to abandon your changes.
-Then run <code>git</code> <code>rebase</code> <code>--continue</code> to
-restore the change commit.
+<code>hg revert flag_test.go</code> to abandon your
+changes, but you may still need to run
+<code>hg resolve -m</code> to mark the conflict resolved.
 </p>

-<h3>Reviewing code by others</h3>
+<h3>Mail the change for review</h3>

-<p>
-You can import a change proposed by someone else into your local Git repository.
-On the Gerrit review page, click the "Download ▼" link in the upper right
-corner, copy the "Checkout" command and run it from your local Git repo.
-It should look something like this:
+<p>To send out a change for review, run <code>hg mail</code> using the change list number
+assigned during <code>hg change</code>:</p>
+
+<pre>
+$ hg mail 99999
+</pre>
+
+<p>You can add to the <code>Reviewer:</code> and <code>CC:</code> lines
+using the <code>-r</code> or <code>--cc</code> options.
+In the above example, we could have left the <code>Reviewer</code> and <code>CC</code>
+lines blank and then run:
 </p>

 <pre>
-$ git fetch https://go.googlesource.com/review refs/changes/21/1221/1 && git checkout FETCH_HEAD
+$ hg mail -r golang-dev@googlegroups.com --cc math-nuts@swtch.com 99999
 </pre>

+<p>to achieve the same effect.</p>
+
+<p>Note that <code>-r</code> and <code>--cc</code> cannot be spelled <code>--r</code> or <code>-cc</code>.</p>
+
+
+<h3>Reviewing code</h3>
+
 <p>
-To revert, change back to the branch you were working in.
+Running <code>hg mail</code> will send an email to you and the reviewers
+asking them to visit the issue's URL and make comments on the change.
+When done, the reviewer clicks &ldquo;Publish and Mail comments&rdquo;
+to send comments back.
+</p>
+
+
+<h3>Revise and upload</h3>
+
+<p>You will probably revise your code in response to the reviewer comments.
+When you have revised the code and are ready for another round of review, run
+</p>
+
+<pre>
+$ hg mail 99999
+</pre>
+
+<p>again to upload the latest copy and send mail asking the reviewers to please take another look
+(<code>PTAL</code>).
+You might also visit the code review web page and reply to the comments,
+letting the reviewer know that you've addressed them or explain why you
+haven't.  When you're done replying, click &ldquo;Publish and Mail comments&rdquo;
+to send the line-by-line replies and any other comments.
+</p>
+<p>
+The reviewer can comment on the new copy, and the process repeats.
+The reviewer approves the change by replying with a mail that says
+<code>LGTM</code>: looks good to me.
 </p>

 <h3>Submit the change after the review</h3>

 <p>
-After the code has been <code>LGTM</code>'ed, an approver may
-submit it to the master branch using the Gerrit UI.
-There is a "Submit" button on the web page for the change
-that appears once the change is approved (marked +2).
+After the code has been <code>LGTM</code>'ed, it is time to submit
+it to the Mercurial repository.
+If you are a committer, you can run:
 </p>

+<pre>
+$ hg submit 99999
+</pre>
+
 <p>
 This checks the change into the repository.
 The change description will include a link to the code review,
 and the code review will be updated with a link to the change
 in the repository.
-Since the method used to integrate the changes is "Cherry Pick",
-the commit hashes in the repository will be changed by
-the submit operation.
 </p>

-<h3>More information</h3>
-
 <p>
-In addition to the information here, the Go community maintains a <a href="https://golang.org/wiki/CodeReview">CodeReview</a> wiki page.
-Feel free to contribute to this page as you learn the review process.
+If your local copy of the repository is out of date,
+<code>hg submit</code>
+will refuse the change:
 </p>

-<h2 id="copyright">Copyright</h2>
+<pre>
+$ hg submit 99999
+local repository out of date; must sync before submit
+</pre>
+
+<p>
+If you are not a committer, you cannot submit the change directly.
+Instead, a committer, usually the reviewer who said <code>LGTM</code>,
+will run:
+</p>
+
+<pre>
+$ hg clpatch 99999
+$ hg submit 99999
+</pre>
+
+<p>The <code>clpatch</code> command imports your change 99999 into
+the committer's local Mercurial client, at which point the committer
+can check or test the code more.
+(Anyone can run <code>clpatch</code> to try a change that
+has been uploaded to the code review server.)
+The <code>submit</code> command submits the code.  You will be listed as the
+author, but the change message will also indicate who the committer was.
+Your local client will notice that the change has been submitted
+when you next run <code>hg sync</code>.
+</p>
+
+
+<h3 id="copyright">Copyright</h3>

 <p>Files in the Go repository don't list author names,
 both to avoid clutter and to avoid having to keep the lists up to date.
-Instead, your name will appear in the
-<a href="https://golang.org/change">change log</a>
+Instead, your name will appear in the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
 and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
 and perhaps the <a href="/AUTHORS"><code>AUTHORS</code></a> file.
 </p>

 <p>The <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
 defines who the Go contributors&mdash;the people&mdash;are;
-the <a href="/AUTHORS"><code>AUTHORS</code></a> file defines
+the <a href="/AUTHORS"><code>AUTHORS</code></a> file, which defines
 who &ldquo;The Go Authors&rdquo;&mdash;the copyright holders&mdash;are.
 The Go developers at Google will update these files when submitting
 your first change.
@@ -630,15 +500,13 @@ In order for them to do that, you need to have completed one of the
 contributor license agreements:
 <ul>
 <li>
-If you are the copyright holder, you will need to agree to the
-<a href="https://developers.google.com/open-source/cla/individual">individual
+If you are the copyright holder, you will need to agree to
+the <a href="http://code.google.com/legal/individual-cla-v1.0.html">individual
 contributor license agreement</a>, which can be completed online.
 </li>
 <li>
 If your organization is the copyright holder, the organization
-will need to agree to the
-<a href="https://developers.google.com/open-source/cla/corporate">corporate
-contributor license agreement</a>.
+will need to agree to the <a href="http://code.google.com/legal/corporate-cla-v1.0.html">corporate contributor license agreement</a>.
 (If the copyright holder for your code has already completed the
 agreement in connection with another Google open source project,
 it does not need to be completed again.)
@@ -652,12 +520,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 2015 The Go Authors. All rights reserved.
+// Copyright 2012 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>
-
-<p>
-Files in the repository are copyright the year they are added. It is not
-necessary to update the copyright year on files that you change.
-</p>
--- a/doc/debugging_with_gdb.html
+++ b/doc/debugging_with_gdb.html
@@ -9,35 +9,18 @@ Besides this overview you might want to consult the
 <a href="http://sourceware.org/gdb/current/onlinedocs/gdb/">GDB manual</a>.
 </i></p>

-<p>
-GDB does not understand Go programs well.
-The stack management, threading, and runtime contain aspects that differ
-enough from the execution model GDB expects that they can confuse
-the debugger, even when the program is compiled with gccgo.
-As a consequence, although GDB can be useful in some situations, it is
-not a reliable debugger for Go programs, particularly heavily concurrent ones.
-Moreover, it is not a priority for the Go project to address these issues, which
-are difficult.
-In short, the instructions below should be taken only as a guide to how
-to use GDB when it works, not as a guarantee of success.
-</p>
-
-<p>
-In time, a more Go-centric debugging architecture may be required.
-</p>
-
 <h2 id="Introduction">Introduction</h2>

 <p>
 When you compile and link your Go programs with the <code>gc</code> toolchain
-on Linux, Mac OS X, FreeBSD or NetBSD, the resulting binaries contain DWARFv3
+on Linux, Mac OS X or FreeBSD, the resulting binaries contain DWARFv3
 debugging information that recent versions (&gt;7.1) of the GDB debugger can
 use to inspect a live process or a core dump.
 </p>

 <p>
-Pass the <code>'-w'</code> flag to the linker to omit the debug information
-(for example, <code>go build -ldflags "-w" prog.go</code>).
+Pass the <code>'-s'</code> flag to the linker to omit the debug information
+(for example, <code>go build -ldflags "-s" prog.go</code>).
 </p>

 <p>
@@ -53,7 +36,8 @@ debugged.

 <ul>
 <li>
-Show file and line number for code, set breakpoints and disassemble:
+Show file and line number for code 
+, set breakpoints and disassemble:
 <pre>(gdb) <b>list</b>
 (gdb) <b>list <i>line</i></b>
 (gdb) <b>list <i>file.go</i>:<i>line</i></b>
@@ -120,7 +104,7 @@ For example:

 <p>
 If you'd like to see how this works, or want to extend it, take a look at <a
-href="/src/runtime/runtime-gdb.py">src/runtime/runtime-gdb.py</a> in
+href="/src/pkg/runtime/runtime-gdb.py">src/pkg/runtime/runtime-gdb.py</a> in
 the Go source distribution. It depends on some special magic types
 (<code>hash&lt;T,U&gt;</code>) and variables (<code>runtime.m</code> and
 <code>runtime.g</code>) that the linker
@@ -153,7 +137,7 @@ the form <code>pkg.(*MyType).Meth</code>.
 <p>
 In this tutorial we will inspect the binary of the
 <a href="/pkg/regexp/">regexp</a> package's unit tests. To build the binary,
-change to <code>$GOROOT/src/regexp</code> and run <code>go test -c</code>.
+change to <code>$GOROOT/src/pkg/regexp</code> and run <code>go test -c</code>.
 This should produce an executable file named <code>regexp.test</code>.
 </p>

@@ -172,7 +156,7 @@ License GPLv  3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.htm
 Type "show copying" and "show warranty" for licensing/warranty details.
 This GDB was configured as "x86_64-linux".

-Reading symbols from  /home/user/go/src/regexp/regexp.test...
+Reading symbols from  /home/user/go/src/pkg/regexp/regexp.test...
 done.
 Loading Go Runtime support.
 (gdb) 
@@ -180,7 +164,7 @@ Loading Go Runtime support.

 <p>
 The message <code>"Loading Go Runtime support"</code> means that GDB loaded the
-extension from <code>$GOROOT/src/runtime/runtime-gdb.py</code>.
+extension from <code>$GOROOT/src/pkg/runtime/runtime-gdb.py</code>.
 </p>

 <p>
@@ -196,10 +180,10 @@ $ <b>gdb regexp.test -d $GOROOT</b>
 If for some reason GDB still can't find that directory or that script, you can load
 it by hand by telling gdb (assuming you have the go sources in
 <code>~/go/</code>):
-</p>
+<p>

 <pre>
-(gdb) <b>source ~/go/src/runtime/runtime-gdb.py</b>
+(gdb) <b>source ~/go/src/pkg/runtime/runtime-gdb.py</b>
 Loading Go Runtime support.
 </pre>

@@ -259,7 +243,7 @@ Set a breakpoint at the <code>TestFind</code> function:

 <pre>
 (gdb) <b>b 'regexp.TestFind'</b>
-Breakpoint 1 at 0x424908: file /home/user/go/src/regexp/find_test.go, line 148.
+Breakpoint 1 at 0x424908: file /home/user/go/src/pkg/regexp/find_test.go, line 148.
 </pre>

 <p>
@@ -268,9 +252,9 @@ Run the program:

 <pre>
 (gdb) <b>run</b>
-Starting program: /home/user/go/src/regexp/regexp.test
+Starting program: /home/user/go/src/pkg/regexp/regexp.test

-Breakpoint 1, regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
+Breakpoint 1, regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/pkg/regexp/find_test.go:148
 148	func TestFind(t *testing.T) {
 </pre>

@@ -297,9 +281,9 @@ Look at the stack trace for where we’ve paused the program:

 <pre>
 (gdb) <b>bt</b>  <i># backtrace</i>
-#0  regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
-#1  0x000000000042f60b in testing.tRunner (t=0xf8404a89c0, test=0x573720) at /home/user/go/src/testing/testing.go:156
-#2  0x000000000040df64 in runtime.initdone () at /home/user/go/src/runtime/proc.c:242
+#0  regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/pkg/regexp/find_test.go:148
+#1  0x000000000042f60b in testing.tRunner (t=0xf8404a89c0, test=0x573720) at /home/user/go/src/pkg/testing/testing.go:156
+#2  0x000000000040df64 in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:242
 #3  0x000000f8404a89c0 in ?? ()
 #4  0x0000000000573720 in ?? ()
 #5  0x0000000000000000 in ?? ()
@@ -311,18 +295,18 @@ The other goroutine, number 1, is stuck in <code>runtime.gosched</code>, blocked

 <pre>
 (gdb) <b>goroutine 1 bt</b>
-#0  0x000000000040facb in runtime.gosched () at /home/user/go/src/runtime/proc.c:873
+#0  0x000000000040facb in runtime.gosched () at /home/user/go/src/pkg/runtime/proc.c:873
 #1  0x00000000004031c9 in runtime.chanrecv (c=void, ep=void, selected=void, received=void)
- at  /home/user/go/src/runtime/chan.c:342
-#2  0x0000000000403299 in runtime.chanrecv1 (t=void, c=void) at/home/user/go/src/runtime/chan.c:423
+ at  /home/user/go/src/pkg/runtime/chan.c:342
+#2  0x0000000000403299 in runtime.chanrecv1 (t=void, c=void) at/home/user/go/src/pkg/runtime/chan.c:423
 #3  0x000000000043075b in testing.RunTests (matchString={void (struct string, struct string, bool *, error *)}
- 0x7ffff7f9ef60, tests=  []testing.InternalTest = {...}) at /home/user/go/src/testing/testing.go:201
+ 0x7ffff7f9ef60, tests=  []testing.InternalTest = {...}) at /home/user/go/src/pkg/testing/testing.go:201
 #4  0x00000000004302b1 in testing.Main (matchString={void (struct string, struct string, bool *, error *)} 
 0x7ffff7f9ef80, tests= []testing.InternalTest = {...}, benchmarks= []testing.InternalBenchmark = {...})
-at /home/user/go/src/testing/testing.go:168
-#5  0x0000000000400dc1 in main.main () at /home/user/go/src/regexp/_testmain.go:98
-#6  0x00000000004022e7 in runtime.mainstart () at /home/user/go/src/runtime/amd64/asm.s:78
-#7  0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
+at /home/user/go/src/pkg/testing/testing.go:168
+#5  0x0000000000400dc1 in main.main () at /home/user/go/src/pkg/regexp/_testmain.go:98
+#6  0x00000000004022e7 in runtime.mainstart () at /home/user/go/src/pkg/runtime/amd64/asm.s:78
+#7  0x000000000040ea6f in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:243
 #8  0x0000000000000000 in ?? ()
 </pre>

@@ -333,7 +317,7 @@ The stack frame shows we’re currently executing the <code>regexp.TestFind</cod
 <pre>
 (gdb) <b>info frame</b>
 Stack level 0, frame at 0x7ffff7f9ff88:
- rip = 0x425530 in regexp.TestFind (/home/user/go/src/regexp/find_test.go:148); 
+ rip = 0x425530 in regexp.TestFind (/home/user/go/src/pkg/regexp/find_test.go:148); 
    saved rip 0x430233
 called by frame at 0x7ffff7f9ffa8
 source language minimal.
@@ -410,7 +394,7 @@ We can step into the <code>String</code>function call with <code>"s"</code>:

 <pre>
 (gdb) <b>s</b>
-regexp.(*Regexp).String (re=0xf84068d070, noname=void) at /home/user/go/src/regexp/regexp.go:97
+regexp.(*Regexp).String (re=0xf84068d070, noname=void) at /home/user/go/src/pkg/regexp/regexp.go:97
 97      func (re *Regexp) String() string {
 </pre>

@@ -421,12 +405,12 @@ Get a stack trace to see where we are:
 <pre>
 (gdb) <b>bt</b>
 #0  regexp.(*Regexp).String (re=0xf84068d070, noname=void)
-    at /home/user/go/src/regexp/regexp.go:97
+    at /home/user/go/src/pkg/regexp/regexp.go:97
 #1  0x0000000000425615 in regexp.TestFind (t=0xf840688b60)
-    at /home/user/go/src/regexp/find_test.go:151
+    at /home/user/go/src/pkg/regexp/find_test.go:151
 #2  0x0000000000430233 in testing.tRunner (t=0xf840688b60, test=0x5747b8)
-    at /home/user/go/src/testing/testing.go:156
-#3  0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
+    at /home/user/go/src/pkg/testing/testing.go:156
+#3  0x000000000040ea6f in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:243
 ....
 </pre>

--- a/doc/devel/release.html
+++ b/doc/devel/release.html
@@ -3,103 +3,19 @@
 }-->

 <p>This page summarizes the changes between official stable releases of Go.
-The <a href="//golang.org/change">change log</a> has the full details.</p>
+Between releases we issue less stable
+<a href="http://blog.golang.org/2011/03/go-becomes-more-stable.html">weekly snapshots</a>.
+The <a href="weekly.html">weekly snapshot history</a> contains more detail,
+and the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
+has full details.</p>

 <p>To update to a specific release, use:</p>

 <pre>
-git pull
-git checkout <i>release-branch</i>
+hg pull
+hg update <i>tag</i>
 </pre>

-<h2 id="go1.4">go1.4 (released 2014/12/10)</h2>
-
-<p>
-Go 1.4 is a major release of Go.
-Read the <a href="/doc/go1.4">Go 1.4 Release Notes</a> for more information.
-</p>
-
-<h3 id="go1.4.minor">Minor revisions</h3>
-
-<p>
-go1.4.1 (released 2015/01/15) includes bug fixes to the linker and the <code>log</code>, <code>syscall</code>, and <code>runtime</code> packages.
-See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.4.1">Go 1.4.1 milestone on our issue tracker</a> for details.
-</p>
-
-<p>
-go1.4.2 (released 2015/02/17) includes bug fixes to the <code>go</code> command, the compiler and linker, and the <code>runtime</code>, <code>syscall</code>, <code>reflect</code>, and <code>math/big</code> packages.
-See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.4.2">Go 1.4.2 milestone on our issue tracker</a> for details.
-</p>
-
-<h2 id="go1.3">go1.3 (released 2014/06/18)</h2>
-
-<p>
-Go 1.3 is a major release of Go.
-Read the <a href="/doc/go1.3">Go 1.3 Release Notes</a> for more information.
-</p>
-
-<h3 id="go1.3.minor">Minor revisions</h3>
-
-<p>
-go1.3.1 (released 2014/08/13) includes bug fixes to the compiler and the <code>runtime</code>, <code>net</code>, and <code>crypto/rsa</code> packages.
-See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=073fc578434bf3e1e22749b559d273c8da728ebb">change history</a> for details.
-</p>
-
-<p>
-go1.3.2 (released 2014/09/25) includes bug fixes to cgo and the crypto/tls packages.
-See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=go1.3.2">change history</a> for details.
-</p>
-
-<p>
-go1.3.3 (released 2014/09/30) includes further bug fixes to cgo, the runtime package, and the nacl port. 
-See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=go1.3.3">change history</a> for details.
-</p>
-
-<h2 id="go1.2">go1.2 (released 2013/12/01)</h2>
-
-<p>
-Go 1.2 is a major release of Go.
-Read the <a href="/doc/go1.2">Go 1.2 Release Notes</a> for more information.
-</p>
-
-<h3 id="go1.2.minor">Minor revisions</h3>
-
-<p>
-go1.2.1 (released 2014/03/02) includes bug fixes to the <code>runtime</code>, <code>net</code>, and <code>database/sql</code> packages.
-See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31">change history</a> for details.
-</p>
-
-<p>
-go1.2.2 (released 2014/05/05) includes a
-<a href="//code.google.com/p/go/source/detail?r=bda3619e7a2c&repo=tools">security fix</a>
-that affects the tour binary included in the binary distributions (thanks to Guillaume T).
-</p>
-
-<h2 id="go1.1">go1.1 (released 2013/05/13)</h2>
-
-<p>
-Go 1.1 is a major release of Go.
-Read the <a href="/doc/go1.1">Go 1.1 Release Notes</a> for more information.
-</p>
-
-<h3 id="go1.1.minor">Minor revisions</h3>
-
-<p>
-go1.1.1 (released 2013/06/13) includes several compiler and runtime bug fixes.
-See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=43c4a41d24382a56a90e924800c681e435d9e399">change history</a> for details.
-</p>
-
-<p>
-go1.1.2 (released 2013/08/13) includes fixes to the <code>gc</code> compiler
-and <code>cgo</code>, and the <code>bufio</code>, <code>runtime</code>,
-<code>syscall</code>, and <code>time</code> packages.
-See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=a6a9792f94acd4ff686b2bc57383d163608b91cf">change history</a> for details.
-If you use package syscall's <code>Getrlimit</code> and <code>Setrlimit</code>
-functions under Linux on the ARM or 386 architectures, please note change
-<a href="//golang.org/change/55ac276af5a7">55ac276af5a7</a>
-that fixes <a href="//golang.org/issue/5949">issue 5949</a>.
-</p>
-
 <h2 id="go1">go1 (released 2012/03/28)</h2>

 <p>
@@ -123,17 +39,17 @@ The go1 release corresponds to

 <p>
 go1.0.1 (released 2012/04/25) was issued to
-<a href="//golang.org/change/a890477d3dfb">fix</a> an
-<a href="//golang.org/issue/3545">escape analysis bug</a>
-that can lead to memory corruption.
+<a href="https://code.google.com/p/go/source/detail?r=a890477d3dfb">fix</a> an
+<a href="https://code.google.com/p/go/issues/detail?id=3545">escape analysis
+bug</a> that can lead to memory corruption.
 It also includes several minor code and documentation fixes.
 </p>

 <p>
 go1.0.2 (released 2012/06/13) was issued to fix two bugs in the implementation
 of maps using struct or array keys: 
-<a href="//golang.org/issue/3695">issue 3695</a> and
-<a href="//golang.org/issue/3573">issue 3573</a>.
+<a href="http://code.google.com/p/go/issues/detail?id=3695">issue 3695</a> and
+<a href="http://code.google.com/p/go/issues/detail?id=3573">issue 3573</a>.
 It also includes many minor code and documentation fixes.
 </p>

@@ -142,7 +58,7 @@ go1.0.3 (released 2012/09/21) includes minor code and documentation fixes.
 </p>

 <p>
-See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1">go1 release branch history</a> for the complete list of changes.
+See the <a href="http://code.google.com/p/go/source/list?name=release-branch.go1">go1 release branch history</a> for the complete list of changes.
 </p>

 <h2 id="r60">r60 (released 2011/09/07)</h2>
@@ -154,7 +70,7 @@ This section highlights the most significant changes in this release.
 For a more detailed summary, see the
 <a href="weekly.html#2011-08-17">weekly release notes</a>.
 For complete information, see the
-<a href="//code.google.com/p/go/source/list?r=release-branch.r60">Mercurial change list</a>.
+<a href="http://code.google.com/p/go/source/list?r=release-branch.r60">Mercurial change list</a>.
 </p>

 <h3 id="r60.lang">Language</h3>
@@ -224,26 +140,26 @@ more accessible.

 <p>
 r60.1 includes a 
-<a href="//golang.org/change/1824581bf62d">linker
+<a href="http://code.google.com/p/go/source/detail?r=1824581bf62d">linker
 fix</a>, a pair of
-<a href="//golang.org/change/9ef4429c2c64">goplay</a>
-<a href="//golang.org/change/d42ed8c3098e">fixes</a>,
+<a href="http://code.google.com/p/go/source/detail?r=9ef4429c2c64">goplay</a>
+<a href="http://code.google.com/p/go/source/detail?r=d42ed8c3098e">fixes</a>,
 and a <code>json</code> package
-<a href="//golang.org/change/d5e97874fe84">fix</a> and
+<a href="http://code.google.com/p/go/source/detail?r=d5e97874fe84">fix</a> and
 a new
-<a href="//golang.org/change/4f0e6269213f">struct tag
+<a href="http://code.google.com/p/go/source/detail?r=4f0e6269213f">struct tag
 option</a>.
 </p>

 <p>
 r60.2
-<a href="//golang.org/change/ff19536042ac">fixes</a>
+<a href="http://code.google.com/p/go/source/detail?r=ff19536042ac">fixes</a>
 a memory leak involving maps.
 </p>

 <p>
 r60.3 fixes a
-<a href="//golang.org/change/01fa62f5e4e5">reflect bug</a>.
+<a href="http://code.google.com/p/go/source/detail?r=01fa62f5e4e5">reflect bug</a>.
 </p>

 <h2 id="r59">r59 (released 2011/08/01)</h2>
@@ -255,7 +171,7 @@ This section highlights the most significant changes in this release.
 For a more detailed summary, see the
 <a href="weekly.html#2011-07-07">weekly release notes</a>.
 For complete information, see the
-<a href="//code.google.com/p/go/source/list?r=release-branch.r59">Mercurial change list</a>.
+<a href="http://code.google.com/p/go/source/list?r=release-branch.r59">Mercurial change list</a>.
 </p>

 <h3 id="r59.lang">Language</h3>
@@ -265,7 +181,7 @@ This release includes a language change that restricts the use of
 <code>goto</code>.  In essence, a <code>goto</code> statement outside a block
 cannot jump to a label inside that block. Your code may require changes if it
 uses <code>goto</code>.
-See <a href="//golang.org/change/dc6d3cf9279d">this
+See <a href="http://code.google.com/p/go/source/detail?r=dc6d3cf9279d">this
 changeset</a> for how the new rule affected the Go tree.
 </p>

@@ -363,13 +279,13 @@ This section highlights the most significant changes in this release.
 For a more detailed summary, see the
 <a href="weekly.html#2011-06-09">weekly release notes</a>.
 For complete information, see the
-<a href="//code.google.com/p/go/source/list?r=release-branch.r58">Mercurial change list</a>.
+<a href="http://code.google.com/p/go/source/list?r=release-branch.r58">Mercurial change list</a>.
 </p>

 <h3 id="r58.lang">Language</h3>

 <p>
-This release fixes a <a href="//golang.org/change/b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
+This release fixes a <a href="http://code.google.com/p/go/source/detail?r=b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
 </p>

 <h3 id="r58.pkg">Packages</h3>
@@ -428,8 +344,8 @@ the Go tree (and avoid writing Makefiles).
 <h3 id="r58.minor">Minor revisions</h3>

 <p>r58.1 adds 
-<a href="//golang.org/change/293c25943586">build</a> and
-<a href="//golang.org/change/bf17e96b6582">runtime</a>
+<a href="http://code.google.com/p/go/source/detail?r=293c25943586">build</a> and
+<a href="http://code.google.com/p/go/source/detail?r=bf17e96b6582">runtime</a>
 changes to make Go run on OS X 10.7 Lion.
 </p>

@@ -443,7 +359,7 @@ This section highlights the most significant changes in this release.
 For a more detailed summary, see the
 <a href="weekly.html#2011-04-27">weekly release notes</a>.
 For complete information, see the
-<a href="//code.google.com/p/go/source/list?r=release-branch.r57">Mercurial change list</a>.
+<a href="http://code.google.com/p/go/source/list?r=release-branch.r57">Mercurial change list</a>.
 </p>

 <p>The new <a href="/cmd/gofix">gofix</a> tool finds Go programs that use old APIs and rewrites them to use
@@ -454,7 +370,7 @@ future changes to the libraries.
 Gofix can’t
 handle all situations perfectly, so read and test the changes it makes before
 committing them.
-See <a href="//blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
+See <a href="http://blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
 information.</p>

 <h3 id="r57.lang">Language</h3>
@@ -500,7 +416,7 @@ For clients, there are new
 <a href="/pkg/http/#Client">Client</a> and <a href="/pkg/http/#Transport">Transport</a>
 abstractions that give more control over HTTP details such as headers sent
 and redirections followed.  These abstractions make it easy to implement
-custom clients that add functionality such as <a href="//code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
+custom clients that add functionality such as <a href="http://code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
 For servers, <a href="/pkg/http/#ResponseWriter">ResponseWriter</a>
 has dropped its non-essential methods.
 The Hijack and Flush methods are no longer required;
@@ -544,7 +460,7 @@ implements all the possible value methods.
 Instead of a type switch on a Value <code>v</code>, switch on <code>v.Kind()</code>.
 Typeof and NewValue are now called <a href="/pkg/reflect/#Type.TypeOf">TypeOf</a> and <a href="/pkg/reflect/#Value.ValueOf">ValueOf</a>
 To create a writable Value, use <code>New(t).Elem()</code> instead of <code>Zero(t)</code>.
-See <a href="//golang.org/change/843855f3c026">the change description</a>
+See <a href="http://code.google.com/p/go/source/detail?r=843855f3c026">the change description</a>
 for the full details.
 The new API allows a more efficient implementation of Value
 that avoids many of the allocations required by the previous API.
@@ -580,8 +496,8 @@ For other uses, see the <a href="/pkg/runtime/pprof/">runtime/pprof</a> document

 <h3 id="r57.minor">Minor revisions</h3>

-<p>r57.1 fixes a <a href="//golang.org/change/ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
-<p>r57.2 fixes a <a href="//golang.org/change/063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>
+<p>r57.1 fixes a <a href="http://code.google.com/p/go/source/detail?r=ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
+<p>r57.2 fixes a <a href="http://code.google.com/p/go/source/detail?r=063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>

 <h2 id="r56">r56 (released 2011/03/16)</h2>

--- a/doc/devel/weekly.html
+++ b/doc/devel/weekly.html
@@ -3,9 +3,18 @@
 }-->

 <p>This page summarizes the changes between tagged weekly snapshots of Go.
-Such snapshots are no longer created. This page remains as a historical reference only.</p>
+For full details, see the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>.</p>

-<p>For recent information, see the <a href="//golang.org/change">change log</a> and <a href="//groups.google.com/group/golang-dev/">development mailing list</a>.</p>
+<p>Weekly snapshots occur often and may not be stable.
+If stability of API and code is more important than having the
+latest features, use the <a href="release.html">official releases</a> instead.</p>
+
+<p>To update to a specific snapshot, use:</p>
+
+<pre>
+hg pull
+hg update weekly.<i>YYYY-MM-DD</i>
+</pre>

 <h2 id="2012-03-27">2012-03-27 (<a href="release.html#go1">Go 1</a>)</h2>

@@ -2035,7 +2044,7 @@ Other changes:
 * spec: define order of multiple assignment.
 * syscall/windows: dll function load and calling changes (thanks Alex Brainman).
 * syscall: add #ifdefs to fix the manual corrections in ztypes_linux_arm.go (thanks Dave Cheney),
-	adjust Mount to accommodate stricter FS implementations.
+	adjust Mount to accomodate stricter FS implementations.
 * testing: fix time reported for failing tests.
 * utf8: add Valid and ValidString.
 * websocket: tweak hybi ReadHandshake to support Firefox (thanks Luca Greco).
@@ -4362,7 +4371,7 @@ 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 foreseeable future,
+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
--- a/doc/docs.html
+++ b/doc/docs.html
@@ -33,22 +33,20 @@ libraries.

 <img class="gopher" src="/doc/gopher/doc.png"/>

-<h3 id="go_tour"><a href="//tour.golang.org/">A Tour of Go</a></h3>
+<h3 id="go_tour"><a href="http://tour.golang.org/">A Tour of Go</a></h3>
 <p>
 An interactive introduction to Go in three sections.
 The first section covers basic syntax and data structures; the second discusses
 methods and interfaces; and the third introduces Go's concurrency primitives.
 Each section concludes with a few exercises so you can practice what you've
-learned. You can <a href="//tour.golang.org/">take the tour online</a> or
-<a href="//code.google.com/p/go-tour/">install it locally</a>.
+learned. You can <a href="http://tour.golang.org/">take the tour online</a> or
+<a href="http://code.google.com/p/go-tour/">install it locally</a>.
 </p>

 <h3 id="code"><a href="code.html">How to write Go code</a></h3>
 <p>
-Also available as a
-<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this doc
-explains how to use the <a href="/cmd/go/">go command</a> to fetch, build, and
-install packages, commands, and run tests.
+How to use the <a href="/cmd/go/">go command</a> to fetch, build, and install
+packages, commands, and run tests.
 </p>

 <h3 id="effective_go"><a href="effective_go.html">Effective Go</a></h3>
@@ -58,52 +56,39 @@ A must read for any new Go programmer. It augments the tour and
 the language specification, both of which should be read first.
 </p>

-<h3 id="faq"><a href="/doc/faq">Frequently Asked Questions (FAQ)</a></h3>
+<h3 id="ref"><a href="/ref/">Go References</a></h3>
+<p>Language specification, memory model, and detailed documentation for the commands and packages.</p>
+
+<h3 id="appengine"><a href="https://developers.google.com/appengine/docs/go/gettingstarted/">Getting Started with Go on App Engine</a></h3>
+<p>
+How to develop and deploy a simple Go project with
+<a href="https://developers.google.com/appengine/">Google App Engine</a>.
+</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="wiki"><a href="/wiki">The Go Wiki</a></h3>
+<h3 id="wiki"><a href="http://code.google.com/p/go-wiki/wiki">Go Language Community Wiki</a></h3>
 <p>A wiki maintained by the Go community.</p>

-<h4 id="learn_more">More</h4>
+<h2 id="go1">Go version 1</h2>
+
+<h3 id="go1notes"><a href="/doc/go1.html">Go 1 Release Notes</a></h3>
 <p>
-See the <a href="/wiki/Learn">Learn</a> page at the <a href="/wiki">Wiki</a>
-for more Go learning resources.
+A guide for updating your code to work with Go 1.
 </p>

-
-<h2 id="references">References</h2>
-
-<h3 id="pkg"><a href="/pkg/">Package Documentation</a></h3>
+<h3 id="go1compat"><a href="/doc/go1compat.html">Go 1 and the Future of Go Programs</a></h3>
 <p>
-The documentation for the Go standard library.
+What Go 1 defines and the backwards-compatibility guarantees one can expect as
+Go 1 matures.
 </p>

-<h3 id="cmd"><a href="/doc/cmd">Command Documentation</a></h3>
-<p>
-The documentation for the Go tools.
-</p>
+<h2 id="articles">Go Articles</h2>

-<h3 id="spec"><a href="/ref/spec">Language Specification</a></h3>
-<p>
-The official Go Language specification.
-</p>
-
-<h3 id="go_mem"><a href="/ref/mem">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>
-
-<h3 id="release"><a href="/doc/devel/release.html">Release History</a></h3>
-<p>A summary of the changes between Go releases.</p>
-
-
-<h2 id="articles">Articles</h2>
-
-<h3 id="blog"><a href="//blog.golang.org/">The Go Blog</a></h3>
+<h3 id="blog"><a href="http://blog.golang.org/">The Go Blog</a></h3>
 <p>The official blog of the Go project, featuring news and in-depth articles by
 the Go team and guests.</p>

@@ -120,48 +105,43 @@ Guided tours of Go programs.

 <h4>Language</h4>
 <ul>
-<li><a href="/blog/json-rpc-tale-of-interfaces">JSON-RPC: a tale of interfaces</a></li>
-<li><a href="/blog/gos-declaration-syntax">Go's Declaration Syntax</a></li>
-<li><a href="/blog/defer-panic-and-recover">Defer, Panic, and Recover</a></li>
-<li><a href="/blog/go-concurrency-patterns-timing-out-and">Go Concurrency Patterns: Timing out, moving on</a></li>
-<li><a href="/blog/go-slices-usage-and-internals">Go Slices: usage and internals</a></li>
-<li><a href="/blog/gif-decoder-exercise-in-go-interfaces">A GIF decoder: an exercise in Go interfaces</a></li>
-<li><a href="/blog/error-handling-and-go">Error Handling and Go</a></li>
-<li><a href="/blog/organizing-go-code">Organizing Go code</a></li>
+<li><a href="/doc/articles/json_rpc_tale_of_interfaces.html">JSON-RPC: a tale of interfaces</a></li>
+<li><a href="/doc/articles/gos_declaration_syntax.html">Go's Declaration Syntax</a></li>
+<li><a href="/doc/articles/defer_panic_recover.html">Defer, Panic, and Recover</a></li>
+<li><a href="/doc/articles/concurrency_patterns.html">Go Concurrency Patterns: Timing out, moving on</a></li>
+<li><a href="/doc/articles/slices_usage_and_internals.html">Go Slices: usage and internals</a></li>
+<li><a href="http://blog.golang.org/2011/05/gif-decoder-exercise-in-go-interfaces.html">A GIF decoder: an exercise in Go interfaces</a></li>
+<li><a href="/doc/articles/error_handling.html">Error Handling and Go</a></li>
 </ul>

 <h4>Packages</h4>
 <ul>
-<li><a href="/blog/json-and-go">JSON and Go</a> - using the <a href="/pkg/encoding/json/">json</a> package.</li>
-<li><a href="/blog/gobs-of-data">Gobs of data</a> - the design and use of the <a href="/pkg/encoding/gob/">gob</a> package.</li>
-<li><a href="/blog/laws-of-reflection">The Laws of Reflection</a> - the fundamentals of the <a href="/pkg/reflect/">reflect</a> package.</li>
-<li><a href="/blog/go-image-package">The Go image package</a> - the fundamentals of the <a href="/pkg/image/">image</a> package.</li>
-<li><a href="/blog/go-imagedraw-package">The Go image/draw package</a> - the fundamentals of the <a href="/pkg/image/draw/">image/draw</a> package.</li>
+<li><a href="/doc/articles/json_and_go.html">JSON and Go</a> - using the <a href="/pkg/encoding/json/">json</a> package.</li>
+<li><a href="/doc/articles/gobs_of_data.html">Gobs of data</a> - the design and use of the <a href="/pkg/encoding/gob/">gob</a> package.</li>
+<li><a href="/doc/articles/laws_of_reflection.html">The Laws of Reflection</a> - the fundamentals of the <a href="/pkg/reflect/">reflect</a> package.</li>
+<li><a href="/doc/articles/image_package.html">The Go image package</a> - the fundamentals of the <a href="/pkg/image/">image</a> package.</li>
+<li><a href="/doc/articles/image_draw.html">The Go image/draw package</a> - the fundamentals of the <a href="/pkg/image/draw/">image/draw</a> package.</li>
 </ul>

 <h4>Tools</h4>
 <ul>
 <li><a href="/doc/articles/go_command.html">About the Go command</a> - why we wrote it, what it is, what it's not, and how to use it.</li>
-<li><a href="/blog/c-go-cgo">C? Go? Cgo!</a> - linking against C code with <a href="/cmd/cgo/">cgo</a>.</li>
+<li><a href="/doc/articles/c_go_cgo.html">C? Go? Cgo!</a> - linking against C code with <a href="/cmd/cgo/">cgo</a>.</li>
 <li><a href="/doc/gdb">Debugging Go Code with GDB</a></li>
-<li><a href="/blog/godoc-documenting-go-code">Godoc: documenting Go code</a> - writing good documentation for <a href="/cmd/godoc/">godoc</a>.</li>
-<li><a href="/blog/profiling-go-programs">Profiling Go Programs</a></li>
-<li><a href="/doc/articles/race_detector.html">Data Race Detector</a> - a manual for the data race detector.</li>
-<li><a href="/blog/race-detector">Introducing the Go Race Detector</a> - an introduction to the race detector.</li>
-<li><a href="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.</li>
+<li><a href="/doc/articles/godoc_documenting_go_code.html">Godoc: documenting Go code</a> - writing good documentation for <a href="/cmd/godoc/">godoc</a>.</li>
+<li><a href="http://blog.golang.org/2011/06/profiling-go-programs.html">Profiling Go Programs</a></li>
 </ul>

-<h4 id="articles_more">More</h4>
-<p>
-See the <a href="/wiki/Articles">Articles page</a> at the
-<a href="/wiki">Wiki</a> for more Go articles.
-</p>
-
-
 <h2 id="talks">Talks</h2>

 <img class="gopher" src="/doc/gopher/talks.png"/>

+<p>
+The talks marked with a red asterisk (<font color="red">*</font>) were written
+before Go 1 and contain some examples that are no longer correct, but they are
+still of value.
+</p>
+
 <h3 id="video_tour_of_go"><a href="http://research.swtch.com/gotour">A Video Tour of Go</a></h3>
 <p>
 Three things that make Go fast, fun, and productive:
@@ -169,31 +149,63 @@ interfaces, reflection, and concurrency. Builds a toy web crawler to
 demonstrate these.
 </p>

-<h3 id="go_code_that_grows"><a href="//vimeo.com/53221560">Code that grows with grace</a></h3>
-<p>
-One of Go's key design goals is code adaptability; that it should be easy to take a simple design and build upon it in a clean and natural way. In this talk Andrew Gerrand describes a simple "chat roulette" server that matches pairs of incoming TCP connections, and then use Go's concurrency mechanisms, interfaces, and standard library to extend it with a web interface and other features. While the function of the program changes dramatically, Go's flexibility preserves the original design as it grows.
-</p>
-
-<h3 id="go_concurrency_patterns"><a href="//www.youtube.com/watch?v=f6kdp27TYZs">Go Concurrency Patterns</a></h3>
+<h3 id="go_concurrency_patterns"><a href="http://www.youtube.com/watch?v=f6kdp27TYZs">Go Concurrency Patterns</a></h3>
 <p>
 Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code.
 </p>

-<h3 id="advanced_go_concurrency_patterns"><a href="//www.youtube.com/watch?v=QDDwwePbDtw">Advanced Go Concurrency Patterns</a></h3>
+<h3 id="meet_the_go_team"><a href="http://www.youtube.com/watch?v=sln-gJaURzk">Meet the Go team</a></h3>
 <p>
-This talk expands on the <i>Go Concurrency Patterns</i> talk to dive deeper into Go's concurrency primitives.
+A panel discussion with David Symonds, Robert Griesemer, Rob Pike, Ken Thompson, Andrew Gerrand, and Brad Fitzpatrick.
+</p>
+
+<h3 id="writing_web_apps"><a href="http://www.youtube.com/watch?v=-i0hat7pdpk">Writing Web Apps in Go</a><font color="red">*</font></h3>
+<p>
+A talk by Rob Pike and Andrew Gerrand presented at Google I/O 2011.
+It walks through the construction and deployment of a simple web application
+and unveils the <a href="http://blog.golang.org/2011/05/go-and-google-app-engine.html">Go runtime for App Engine</a>.
+See the <a href="http://talks.golang.org/2011/Writing_Web_Apps_in_Go.pdf">presentation slides</a>.
+</p>
+
+<h3 id="go_programming"><a href="http://www.youtube.com/watch?v=jgVhBThJdXc">Go Programming</a><font color="red">*</font></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>

 <h4 id="talks_more">More</h4>
 <p>
-See the <a href="/talks">Go Talks site</a> and <a href="/wiki/GoTalks">wiki page</a> for more Go talks.
+See the <a href="http://code.google.com/p/go-wiki/wiki/GoTalks">GoTalks
+page</a> at the <a href="http://code.google.com/p/go-wiki/wiki">Go Wiki</a> for
+more Go talks.
 </p>

-
 <h2 id="nonenglish">Non-English Documentation</h2>

 <p>
-See the <a href="/wiki/NonEnglish">NonEnglish</a> page
-at the <a href="/wiki">Wiki</a> for localized
+See the <a href="http://code.google.com/p/go-wiki/wiki/NonEnglish">NonEnglish</a> page
+at the <a href="http://code.google.com/p/go-wiki/wiki">Go Wiki</a> for localized
 documentation.
 </p>
+
+<h2 id="community">The Go Community</h2>
+
+<img class="gopher" src="/doc/gopher/project.png"/>
+
+<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="projects"><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="plus"><a href="https://plus.google.com/101406623878176903605/posts">The Go Programming Language at Google+</a></h3>
+<p>The Go project's Google+ page.</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>
--- a/doc/effective_go.html
+++ b/doc/effective_go.html
--- a/doc/gccgo_contribute.html
+++ b/doc/gccgo_contribute.html
@@ -10,10 +10,6 @@ For information on contributing to parts of Go other than gccgo,
 see <a href="/doc/contribute.html">Contributing to the Go project</a>.  For
 information on building gccgo for yourself,
 see <a href="/doc/gccgo_install.html">Setting up and using gccgo</a>.
-For more of the gritty details on the process of doing development
-with the gccgo frontend,
-see <a href="https://code.google.com/p/gofrontend/source/browse/HACKING">the
-file HACKING</a> in the gofrontend repository.
 </p>

 <h2>Legal Prerequisites</h2>
@@ -30,7 +26,7 @@ contribution rules</a>.

 <p>
 The master sources for the gccgo frontend may be found at
-<a href="//code.google.com/p/gofrontend">http://code.google.com/p/gofrontend</a>.
+<a href="http://code.google.com/p/gofrontend">http://code.google.com/p/gofrontend</a>.
 The master sources are not buildable by themselves, but only in
 conjunction with GCC (in the future, other compilers may be
 supported).  Changes made to the gccgo frontend are also applied to
@@ -40,7 +36,7 @@ is mirrored to the <code>gcc/go/gofrontend</code> directory in the GCC
 repository, and the <code>gofrontend</code> <code>libgo</code>
 directory is mirrored to the GCC <code>libgo</code> directory.  In
 addition, the <code>test</code> directory
-from <a href="//go.googlesource.com/go">the main Go repository</a>
+from <a href="http://code.google.com/p/go">the main Go repository</a>
 is mirrored to the <code>gcc/testsuite/go.test/test</code> directory
 in the GCC repository.
 </p>
@@ -65,7 +61,7 @@ from <code>gcc/go/gofrontend</code> to <code>gcc/go</code>.

 <p>
 The run-time library for gccgo is mostly the same as the library
-in <a href="//go.googlesource.com/go">the main Go repository</a>.
+in <a href="http://code.google.com/p/go">the main Go repository</a>.
 The library code in the Go repository is periodically merged into
 the <code>libgo/go</code> directory of the <code>gofrontend</code> and
 then the GCC repositories, using the shell
@@ -73,7 +69,7 @@ script <code>libgo/merge.sh</code>.  Accordingly, most library changes
 should be made in the main Go repository.  The files outside
 of <code>libgo/go</code> are gccgo-specific; that said, some of the
 files in <code>libgo/runtime</code> are based on files
-in <code>src/runtime</code> in the main Go repository.
+in <code>src/pkg/runtime</code> in the main Go repository.
 </p>

 <h2>Testing</h2>
@@ -88,7 +84,7 @@ To run the gccgo test suite, run <code>make check-go</code> in your
 build directory.  This will run various tests
 under <code>gcc/testsuite/go.*</code> and will also run
 the <code>libgo</code> testsuite.  This copy of the tests from the
-main Go repository is run using the DejaGNU script found
+main Go repository is run using the DejaGNU script found in
 in <code>gcc/testsuite/go.test/go-test.exp</code>.
 </p>

@@ -104,9 +100,7 @@ or <code>gcc/testsuite/go.dg</code> directories in the GCC repository.

 <p>
 Changes to the Go frontend should follow the same process as for the
-main Go repository, only for the <code>gofrontend</code> project and
-the <code>gofrontend-dev@googlegroups.com</code> mailing list 
-rather than the <code>go</code> project and the
-<code>golang-dev@googlegroups.com</code> mailing list.  Those changes
-will then be merged into the GCC sources.
+main Go repository, only for the <code>gofrontend</code> project
+rather than the <code>go</code> project.  Those changes will then be
+merged into the GCC sources.
 </p>
--- a/doc/gccgo_install.html
+++ b/doc/gccgo_install.html
@@ -32,18 +32,10 @@ will include Go support.
 </p>

 <p>
-The GCC 4.7.1 release and all later 4.7 releases include a complete
-<a href="/doc/go1.html">Go 1</a> compiler and libraries.
-</p>
-
-<p>
-Due to timing, the GCC 4.8.0 and 4.8.1 releases are close to but not
-identical to Go 1.1.  The GCC 4.8.2 release includes a complete Go
-1.1.2 implementation.
-</p>
-
-<p>
-The GCC 4.9 releases include a complete Go 1.2 implementation.
+The GCC 4.7.0 release includes Go support that is very close to
+<a href="/doc/go1.html">Go 1</a>.  Due to release timing it will not
+include the last few changes to the Go 1 libraries.  The GCC 4.7.1
+release should include a complete Go 1 compiler and libraries.
 </p>

 <h2 id="Source_code">Source code</h2>
@@ -133,8 +125,6 @@ described on
 the <a href="http://gcc.gnu.org/install/prerequisites.html">gcc web
 site</a>.  It is important to install all the prerequisites before
 running the gcc <code>configure</code> script.
-The prerequisite libraries can be conveniently downloaded using the
-script <code>contrib/download_prerequisites</code> in the GCC sources.

 <h3 id="Build_commands">Build commands</h3>

@@ -157,11 +147,11 @@ make install
 <h3 id="Ubuntu">A note on Ubuntu</h3>

 <p>
-Current versions of Ubuntu and versions of GCC before 4.8 disagree on
+Current versions of Ubuntu and current versions of gcc disagree on
 where system libraries and header files are found.  This is not a
-gccgo issue.  When building older versions of GCC, setting these
-environment variables while configuring and building gccgo may fix the
-problem.
+gccgo issue, and we hope this will be resolved soon.  Until it is,
+setting these environment variables while configuring and building
+gccgo may fix the problem.
 </p>

 <pre>
@@ -295,9 +285,9 @@ first one that it finds.

 <ul>
 <li><code><var>FILE</var>.gox</code>
+<li><code><var>FILE</var>.o</code>
 <li><code>lib<var>FILE</var>.so</code>
 <li><code>lib<var>FILE</var>.a</code>
-<li><code><var>FILE</var>.o</code>
 </ul>

 <p>
@@ -319,7 +309,7 @@ gccgo.  Both options take directories to search. The
 </p>

 <p>
-The gccgo compiler does not currently (2013-06-20) record
+The gccgo compiler does not currently (2012-03-20) record
 the file name of imported packages in the object file. You must
 arrange for the imported data to be linked into the program.
 </p>
@@ -395,23 +385,23 @@ struct __go_slice {
 </pre>

 <p>
-The type of a Go function is a pointer to a struct (this is
-<b style="color: red;">subject to change</b>).  The first field in the
-struct points to the code of the function, which will be equivalent to
-a pointer to a C function whose parameter types are equivalent, with
-an additional trailing parameter.  The trailing parameter is the
-closure, and the argument to pass is a pointer to the Go function
-struct.
-
-When a Go function returns more than one value, the C function returns
-a struct.  For example, these functions are roughly equivalent:
+The type of a Go function with no receiver is equivalent to a C function
+whose parameter types are equivalent.  When a Go function returns more
+than one value, the C function returns a struct.  For example, these
+functions have equivalent types:
 </p>

 <pre>
 func GoFunction(int) (int, float64)
-struct { int i; float64 f; } CFunction(int, void*)
+struct { int i; float64 f; } CFunction(int)
 </pre>

+<p>
+A pointer to a Go function is equivalent to a pointer to a C function
+when the functions have equivalent types (this is
+<b style="color: red;">subject to change</b>).
+</p>
+
 <p>
 Go <code>interface</code>, <code>channel</code>, and <code>map</code>
 types have no corresponding C type (<code>interface</code> is a
@@ -467,14 +457,6 @@ i := c_open(&amp;name[0], syscall.O_RDONLY, 0);
 <code>os.Open</code> function instead).
 </p>

-<p>
-Note that if the C function can block, such as in a call
-to <code>read</code>, calling the C function may block the Go program.
-Unless you have a clear understanding of what you are doing, all calls
-between C and Go should be implemented through cgo or SWIG, as for
-the <code>gc</code> compiler.
-</p>
-
 <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
@@ -526,4 +508,4 @@ 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.org/wiki/index.php/GCCGoRTEMS"><code>RTEMS</code> Wiki page</a>.
+<a href="http://www.rtems.com/wiki/index.php/GCCGoRTEMS"><code>RTEMS</code> Wiki page</a>.
--- a/doc/go1.1.html
+++ b/doc/go1.1.html
--- a/doc/go1.2.html
+++ b/doc/go1.2.html
@@ -1,979 +0,0 @@
-<!--{
-	"Title": "Go 1.2 Release Notes",
-	"Path":  "/doc/go1.2",
-	"Template": true
-}-->
-
-<h2 id="introduction">Introduction to Go 1.2</h2>
-
-<p>
-Since the release of <a href="/doc/go1.1.html">Go version 1.1</a> in April, 2013,
-the release schedule has been shortened to make the release process more efficient.
-This release, Go version 1.2 or Go 1.2 for short, arrives roughly six months after 1.1,
-while 1.1 took over a year to appear after 1.0.
-Because of the shorter time scale, 1.2 is a smaller delta than the step from 1.0 to 1.1,
-but it still has some significant developments, including
-a better scheduler and one new language feature.
-Of course, Go 1.2 keeps the <a href="/doc/go1compat.html">promise
-of compatibility</a>.
-The overwhelming majority of programs built with Go 1.1 (or 1.0 for that matter)
-will run without any changes whatsoever when moved to 1.2,
-although the introduction of one restriction
-to a corner of the language may expose already-incorrect code
-(see the discussion of the <a href="#use_of_nil">use of nil</a>).
-</p>
-
-<h2 id="language">Changes to the language</h2>
-
-<p>
-In the interest of firming up the specification, one corner case has been clarified,
-with consequences for programs.
-There is also one new language feature.
-</p>
-
-<h3 id="use_of_nil">Use of nil</h3>
-
-<p>
-The language now specifies that, for safety reasons,
-certain uses of nil pointers are guaranteed to trigger a run-time panic.
-For instance, in Go 1.0, given code like
-</p>
-
-<pre>
-type T struct {
-    X [1<<24]byte
-    Field int32
-}
-
-func main() {
-    var x *T
-    ...
-}
-</pre>
-
-<p>
-the <code>nil</code> pointer <code>x</code> could be used to access memory incorrectly:
-the expression <code>x.Field</code> could access memory at address <code>1<<24</code>.
-To prevent such unsafe behavior, in Go 1.2 the compilers now guarantee that any indirection through
-a nil pointer, such as illustrated here but also in nil pointers to arrays, nil interface values,
-nil slices, and so on, will either panic or return a correct, safe non-nil value.
-In short, any expression that explicitly or implicitly requires evaluation of a nil address is an error.
-The implementation may inject extra tests into the compiled program to enforce this behavior.
-</p>
-
-<p>
-Further details are in the
-<a href="//golang.org/s/go12nil">design document</a>.
-</p>
-
-<p>
-<em>Updating</em>:
-Most code that depended on the old behavior is erroneous and will fail when run.
-Such programs will need to be updated by hand.
-</p>
-
-<h3 id="three_index">Three-index slices</h3>
-
-<p>
-Go 1.2 adds the ability to specify the capacity as well as the length when using a slicing operation
-on an existing array or slice.
-A slicing operation creates a new slice by describing a contiguous section of an already-created array or slice:
-</p>
-
-<pre>
-var array [10]int
-slice := array[2:4]
-</pre>
-
-<p>
-The capacity of the slice is the maximum number of elements that the slice may hold, even after reslicing;
-it reflects the size of the underlying array.
-In this example, the capacity of the <code>slice</code> variable is 8.
-</p>
-
-<p>
-Go 1.2 adds new syntax to allow a slicing operation to specify the capacity as well as the length.
-A second
-colon introduces the capacity value, which must be less than or equal to the capacity of the
-source slice or array, adjusted for the origin. For instance,
-</p>
-
-<pre>
-slice = array[2:4:7]
-</pre>
-
-<p>
-sets the slice to have the same length as in the earlier example but its capacity is now only 5 elements (7-2).
-It is impossible to use this new slice value to access the last three elements of the original array.
-</p>
-
-<p>
-In this three-index notation, a missing first index (<code>[:i:j]</code>) defaults to zero but the other
-two indices must always be specified explicitly.
-It is possible that future releases of Go may introduce default values for these indices.
-</p>
-
-<p>
-Further details are in the
-<a href="//golang.org/s/go12slice">design document</a>.
-</p>
-
-<p>
-<em>Updating</em>:
-This is a backwards-compatible change that affects no existing programs.
-</p>
-
-<h2 id="impl">Changes to the implementations and tools</h2>
-
-<h3 id="preemption">Pre-emption in the scheduler</h3>
-
-<p>
-In prior releases, a goroutine that was looping forever could starve out other
-goroutines on the same thread, a serious problem when GOMAXPROCS
-provided only one user thread.
-In Go 1.2, this is partially addressed: The scheduler is invoked occasionally
-upon entry to a function.
-This means that any loop that includes a (non-inlined) function call can
-be pre-empted, allowing other goroutines to run on the same thread.
-</p>
-
-<h3 id="thread_limit">Limit on the number of threads</h3>
-
-<p>
-Go 1.2 introduces a configurable limit (default 10,000) to the total number of threads
-a single program may have in its address space, to avoid resource starvation
-issues in some environments.
-Note that goroutines are multiplexed onto threads so this limit does not directly
-limit the number of goroutines, only the number that may be simultaneously blocked
-in a system call.
-In practice, the limit is hard to reach.
-</p>
-
-<p>
-The new <a href="/pkg/runtime/debug/#SetMaxThreads"><code>SetMaxThreads</code></a> function in the
-<a href="/pkg/runtime/debug/"><code>runtime/debug</code></a> package controls the thread count limit.
-</p>
-
-<p>
-<em>Updating</em>:
-Few functions will be affected by the limit, but if a program dies because it hits the
-limit, it could be modified to call <code>SetMaxThreads</code> to set a higher count.
-Even better would be to refactor the program to need fewer threads, reducing consumption
-of kernel resources.
-</p>
-
-<h3 id="stack_size">Stack size</h3>
-
-<p>
-In Go 1.2, the minimum size of the stack when a goroutine is created has been lifted from 4KB to 8KB.
-Many programs were suffering performance problems with the old size, which had a tendency
-to introduce expensive stack-segment switching in performance-critical sections.
-The new number was determined by empirical testing.
-</p>
-
-<p>
-At the other end, the new function <a href="/pkg/runtime/debug/#SetMaxStack"><code>SetMaxStack</code></a>
-in the <a href="/pkg/runtime/debug"><code>runtime/debug</code></a> package controls
-the <em>maximum</em> size of a single goroutine's stack.
-The default is 1GB on 64-bit systems and 250MB on 32-bit systems.
-Before Go 1.2, it was too easy for a runaway recursion to consume all the memory on a machine.
-</p>
-
-<p>
-<em>Updating</em>:
-The increased minimum stack size may cause programs with many goroutines to use
-more memory. There is no workaround, but plans for future releases
-include new stack management technology that should address the problem better.
-</p>
-
-<h3 id="cgo_and_cpp">Cgo and C++</h3>
-
-<p>
-The <a href="/cmd/cgo/"><code>cgo</code></a> command will now invoke the C++
-compiler to build any pieces of the linked-to library that are written in C++;
-<a href="/cmd/cgo/">the documentation</a> has more detail.
-</p>
-
-<h3 id="go_tools_godoc">Godoc and vet moved to the go.tools subrepository</h3>
-
-<p>
-Both binaries are still included with the distribution, but the source code for the
-godoc and vet commands has moved to the
-<a href="//code.google.com/p/go.tools">go.tools</a> subrepository.
-</p>
-
-<p>
-Also, the core of the godoc program has been split into a
-<a href="https://code.google.com/p/go/source/browse/?repo=tools#hg%2Fgodoc">library</a>,
-while the command itself is in a separate
-<a href="https://code.google.com/p/go/source/browse/?repo=tools#hg%2Fcmd%2Fgodoc">directory</a>.
-The move allows the code to be updated easily and the separation into a library and command
-makes it easier to construct custom binaries for local sites and different deployment methods.
-</p>
-
-<p>
-<em>Updating</em>:
-Since godoc and vet are not part of the library,
-no client Go code depends on the their source and no updating is required.
-</p>
-
-<p>
-The binary distributions available from <a href="//golang.org">golang.org</a>
-include these binaries, so users of these distributions are unaffected.
-</p>
-
-<p>
-When building from source, users must use "go get" to install godoc and vet.
-(The binaries will continue to be installed in their usual locations, not
-<code>$GOPATH/bin</code>.)
-</p>
-
-<pre>
-$ go get code.google.com/p/go.tools/cmd/godoc
-$ go get code.google.com/p/go.tools/cmd/vet
-</pre>
-
-<h3 id="gccgo">Status of gccgo</h3>
-
-<p>
-We expect the future GCC 4.9 release to include gccgo with full
-support for Go 1.2.
-In the current (4.8.2) release of GCC, gccgo implements Go 1.1.2.
-</p>
-
-<h3 id="gc_changes">Changes to the gc compiler and linker</h3>
-
-<p>
-Go 1.2 has several semantic changes to the workings of the gc compiler suite.
-Most users will be unaffected by them.
-</p>
-
-<p>
-The <a href="/cmd/cgo/"><code>cgo</code></a> command now
-works when C++ is included in the library being linked against.
-See the <a href="/cmd/cgo/"><code>cgo</code></a> documentation
-for details.
-</p>
-
-<p>
-The gc compiler displayed a vestigial detail of its origins when
-a program had no <code>package</code> clause: it assumed
-the file was in package <code>main</code>.
-The past has been erased, and a missing <code>package</code> clause
-is now an error.
-</p>
-
-<p>
-On the ARM, the toolchain supports "external linking", which
-is a step towards being able to build shared libraries with the gc
-tool chain and to provide dynamic linking support for environments
-in which that is necessary.
-</p>
-
-<p>
-In the runtime for the ARM, with <code>5a</code>, it used to be possible to refer
-to the runtime-internal <code>m</code> (machine) and <code>g</code>
-(goroutine) variables using <code>R9</code> and <code>R10</code> directly.
-It is now necessary to refer to them by their proper names.
-</p>
-
-<p>
-Also on the ARM, the <code>5l</code> linker (sic) now defines the
-<code>MOVBS</code> and <code>MOVHS</code> instructions
-as synonyms of <code>MOVB</code> and <code>MOVH</code>,
-to make clearer the separation between signed and unsigned
-sub-word moves; the unsigned versions already existed with a
-<code>U</code> suffix.
-</p>
-
-<h3 id="cover">Test coverage</h3>
-
-<p>
-One major new feature of <a href="/pkg/go/"><code>go test</code></a> is
-that it can now compute and, with help from a new, separately installed
-"go tool cover" program, display test coverage results.
-</p>
-
-<p>
-The cover tool is part of the
-<a href="https://code.google.com/p/go/source/checkout?repo=tools"><code>go.tools</code></a>
-subrepository.
-It can be installed by running
-</p>
-
-<pre>
-$ go get code.google.com/p/go.tools/cmd/cover
-</pre>
-
-<p>
-The cover tool does two things.
-First, when "go test" is given the <code>-cover</code> flag, it is run automatically 
-to rewrite the source for the package and insert instrumentation statements.
-The test is then compiled and run as usual, and basic coverage statistics are reported:
-</p>
-
-<pre>
-$ go test -cover fmt
-ok  	fmt	0.060s	coverage: 91.4% of statements
-$
-</pre>
-
-<p>
-Second, for more detailed reports, different flags to "go test" can create a coverage profile file,
-which the cover program, invoked with "go tool cover", can then analyze.
-</p>
-
-<p>
-Details on how to generate and analyze coverage statistics can be found by running the commands
-</p>
-
-<pre>
-$ go help testflag
-$ go tool cover -help
-</pre>
-
-<h3 id="go_doc">The go doc command is deleted</h3>
-
-<p>
-The "go doc" command is deleted.
-Note that the <a href="/cmd/godoc/"><code>godoc</code></a> tool itself is not deleted,
-just the wrapping of it by the <a href="/cmd/go/"><code>go</code></a> command.
-All it did was show the documents for a package by package path,
-which godoc itself already does with more flexibility.
-It has therefore been deleted to reduce the number of documentation tools and,
-as part of the restructuring of godoc, encourage better options in future.
-</p>
-
-<p>
-<em>Updating</em>: For those who still need the precise functionality of running
-</p>
-
-<pre>
-$ go doc
-</pre>
-
-<p>
-in a directory, the behavior is identical to running
-</p>
-
-<pre>
-$ godoc .
-</pre>
-
-<h3 id="gocmd">Changes to the go command</h3>
-
-<p>
-The <a href="/cmd/go/"><code>go get</code></a> command
-now has a <code>-t</code> flag that causes it to download the dependencies
-of the tests run by the package, not just those of the package itself.
-By default, as before, dependencies of the tests are not downloaded.
-</p>
-
-<h2 id="performance">Performance</h2>
-
-<p>
-There are a number of significant performance improvements in the standard library; here are a few of them.
-</p>
-
-<ul> 
-
-<li>
-The <a href="/pkg/compress/bzip2/"><code>compress/bzip2</code></a>
-decompresses about 30% faster.
-</li>
-
-<li>
-The <a href="/pkg/crypto/des/"><code>crypto/des</code></a> package
-is about five times faster.
-</li>
-
-<li>
-The <a href="/pkg/encoding/json/"><code>encoding/json</code></a> package
-encodes about 30% faster.
-</li>
-
-<li>
-Networking performance on Windows and BSD systems is about 30% faster through the use
-of an integrated network poller in the runtime, similar to what was done for Linux and OS X
-in Go 1.1.
-</li>
-
-</ul>
-
-<h2 id="library">Changes to the standard library</h2>
-
-
-<h3 id="archive_tar_zip">The archive/tar and archive/zip packages</h3>
-
-<p>
-The
-<a href="/pkg/archive/tar/"><code>archive/tar</code></a>
-and
-<a href="/pkg/archive/zip/"><code>archive/zip</code></a>
-packages have had a change to their semantics that may break existing programs.
-The issue is that they both provided an implementation of the
-<a href="/pkg/os/#FileInfo"><code>os.FileInfo</code></a>
-interface that was not compliant with the specification for that interface.
-In particular, their <code>Name</code> method returned the full
-path name of the entry, but the interface specification requires that
-the method return only the base name (final path element).
-</p>
-
-<p>
-<em>Updating</em>: Since this behavior was newly implemented and
-a bit obscure, it is possible that no code depends on the broken behavior.
-If there are programs that do depend on it, they will need to be identified
-and fixed manually.
-</p>
-
-<h3 id="encoding">The new encoding package</h3>
-
-<p>
-There is a new package, <a href="/pkg/encoding/"><code>encoding</code></a>,
-that defines a set of standard encoding interfaces that may be used to
-build custom marshalers and unmarshalers for packages such as
-<a href="/pkg/encoding/xml/"><code>encoding/xml</code></a>,
-<a href="/pkg/encoding/json/"><code>encoding/json</code></a>,
-and
-<a href="/pkg/encoding/binary/"><code>encoding/binary</code></a>.
-These new interfaces have been used to tidy up some implementations in
-the standard library.
-</p>
-
-<p>
-The new interfaces are called
-<a href="/pkg/encoding/#BinaryMarshaler"><code>BinaryMarshaler</code></a>,
-<a href="/pkg/encoding/#BinaryUnmarshaler"><code>BinaryUnmarshaler</code></a>,
-<a href="/pkg/encoding/#TextMarshaler"><code>TextMarshaler</code></a>,
-and
-<a href="/pkg/encoding/#TextUnmarshaler"><code>TextUnmarshaler</code></a>.
-Full details are in the <a href="/pkg/encoding/">documentation</a> for the package
-and a separate <a href="//golang.org/s/go12encoding">design document</a>.
-</p>
-
-<h3 id="fmt_indexed_arguments">The fmt package</h3>
-
-<p>
-The <a href="/pkg/fmt/"><code>fmt</code></a> package's formatted print
-routines such as <a href="/pkg/fmt/#Printf"><code>Printf</code></a>
-now allow the data items to be printed to be accessed in arbitrary order
-by using an indexing operation in the formatting specifications.
-Wherever an argument is to be fetched from the argument list for formatting,
-either as the value to be formatted or as a width or specification integer,
-a new optional indexing notation <code>[</code><em>n</em><code>]</code>
-fetches argument <em>n</em> instead.
-The value of <em>n</em> is 1-indexed.
-After such an indexing operating, the next argument to be fetched by normal
-processing will be <em>n</em>+1.
-</p>
-
-<p>
-For example, the normal <code>Printf</code> call
-</p>
-
-<pre>
-fmt.Sprintf("%c %c %c\n", 'a', 'b', 'c')
-</pre>
-
-<p>
-would create the string <code>"a b c"</code>, but with indexing operations like this,
-</p>
-
-<pre>
-fmt.Sprintf("%[3]c %[1]c %c\n", 'a', 'b', 'c')
-</pre>
-
-<p>
-the result is "<code>"c a b"</code>. The <code>[3]</code> index accesses the third formatting
-argument, which is <code>'c'</code>, <code>[1]</code> accesses the first, <code>'a'</code>,
-and then the next fetch accesses the argument following that one, <code>'b'</code>.
-</p>
-
-<p>
-The motivation for this feature is programmable format statements to access
-the arguments in different order for localization, but it has other uses:
-</p>
-
-<pre>
-log.Printf("trace: value %v of type %[1]T\n", expensiveFunction(a.b[c]))
-</pre>
-
-<p>
-<em>Updating</em>: The change to the syntax of format specifications
-is strictly backwards compatible, so it affects no working programs.
-</p>
-
-<h3 id="text_template">The text/template and html/template packages</h3>
-
-<p>
-The
-<a href="/pkg/text/template/"><code>text/template</code></a> package
-has a couple of changes in Go 1.2, both of which are also mirrored in the
-<a href="/pkg/html/template/"><code>html/template</code></a> package.
-</p>
-
-<p>
-First, there are new default functions for comparing basic types.
-The functions are listed in this table, which shows their names and
-the associated familiar comparison operator.
-</p>
-
-<table cellpadding="0" summary="Template comparison functions">
-<tr>
-<th width="50"></th><th width="100">Name</th> <th width="50">Operator</th>
-</tr>
-<tr>
-<td></td><td><code>eq</code></td> <td><code>==</code></td>
-</tr>
-<tr>
-<td></td><td><code>ne</code></td> <td><code>!=</code></td>
-</tr>
-<tr>
-<td></td><td><code>lt</code></td> <td><code>&lt;</code></td>
-</tr>
-<tr>
-<td></td><td><code>le</code></td> <td><code>&lt;=</code></td>
-</tr>
-<tr>
-<td></td><td><code>gt</code></td> <td><code>&gt;</code></td>
-</tr>
-<tr>
-<td></td><td><code>ge</code></td> <td><code>&gt;=</code></td>
-</tr>
-</table>
-
-<p>
-These functions behave slightly differently from the corresponding Go operators.
-First, they operate only on basic types (<code>bool</code>, <code>int</code>,
-<code>float64</code>, <code>string</code>, etc.).
-(Go allows comparison of arrays and structs as well, under some circumstances.)
-Second, values can be compared as long as they are the same sort of value:
-any signed integer value can be compared to any other signed integer value for example. (Go
-does not permit comparing an <code>int8</code> and an <code>int16</code>).
-Finally, the <code>eq</code> function (only) allows comparison of the first
-argument with one or more following arguments. The template in this example,
-</p>
-
-<pre>
-{{"{{"}}if eq .A 1 2 3 {{"}}"}} equal {{"{{"}}else{{"}}"}} not equal {{"{{"}}end{{"}}"}}
-</pre>
-
-<p>
-reports "equal" if <code>.A</code> is equal to <em>any</em> of 1, 2, or 3.
-</p>
-
-<p>
-The second change is that a small addition to the grammar makes "if else if" chains easier to write.
-Instead of writing,
-</p>
-
-<pre>
-{{"{{"}}if eq .A 1{{"}}"}} X {{"{{"}}else{{"}}"}} {{"{{"}}if eq .A 2{{"}}"}} Y {{"{{"}}end{{"}}"}} {{"{{"}}end{{"}}"}} 
-</pre>
-
-<p>
-one can fold the second "if" into the "else" and have only one "end", like this:
-</p>
-
-<pre>
-{{"{{"}}if eq .A 1{{"}}"}} X {{"{{"}}else if eq .A 2{{"}}"}} Y {{"{{"}}end{{"}}"}}
-</pre>
-
-<p>
-The two forms are identical in effect; the difference is just in the syntax.
-</p>
-
-<p>
-<em>Updating</em>: Neither the "else if" change nor the comparison functions
-affect existing programs. Those that
-already define functions called <code>eq</code> and so on through a function
-map are unaffected because the associated function map will override the new
-default function definitions.
-</p>
-
-<h3 id="new_packages">New packages</h3>
-
-<p>
-There are two new packages.
-</p>
-
-<ul>
-<li>
-The <a href="/pkg/encoding/"><code>encoding</code></a> package is
-<a href="#encoding">described above</a>.
-</li>
-<li>
-The <a href="/pkg/image/color/palette/"><code>image/color/palette</code></a> package
-provides standard color palettes.
-</li>
-</ul>
-
-<h3 id="minor_library_changes">Minor changes to the library</h3>
-
-<p>
-The following list summarizes a number of minor changes to the library, mostly additions.
-See the relevant package documentation for more information about each change.
-</p>
-
-<ul>
-
-<li>
-The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package
-adds the
-<a href="/pkg/archive/zip/#File.DataOffset"><code>DataOffset</code></a> accessor
-to return the offset of a file's (possibly compressed) data within the archive.
-</li>
-
-<li>
-The <a href="/pkg/bufio/"><code>bufio</code></a> package
-adds <a href="/pkg/bufio/#Reader.Reset"><code>Reset</code></a>
-methods to <a href="/pkg/bufio/#Reader"><code>Reader</code></a> and
-<a href="/pkg/bufio/#Writer"><code>Writer</code></a>.
-These methods allow the <a href="/pkg/io/#Reader"><code>Readers</code></a>
-and <a href="/pkg/io/#Writer"><code>Writers</code></a>
-to be re-used on new input and output readers and writers, saving
-allocation overhead. 
-</li>
-
-<li>
-The <a href="/pkg/compress/bzip2/"><code>compress/bzip2</code></a>
-can now decompress concatenated archives.
-</li>
-
-<li>
-The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>
-package adds a <a href="/pkg/compress/flate/#Writer.Reset"><code>Reset</code></a> 
-method on the <a href="/pkg/compress/flate/#Writer"><code>Writer</code></a>,
-to make it possible to reduce allocation when, for instance, constructing an
-archive to hold multiple compressed files.
-</li>
-
-<li>
-The <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a> package's
-<a href="/pkg/compress/gzip/#Writer"><code>Writer</code></a> type adds a
-<a href="/pkg/compress/gzip/#Writer.Reset"><code>Reset</code></a>
-so it may be reused.
-</li>
-
-<li>
-The <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a> package's
-<a href="/pkg/compress/zlib/#Writer"><code>Writer</code></a> type adds a
-<a href="/pkg/compress/zlib/#Writer.Reset"><code>Reset</code></a>
-so it may be reused.
-</li>
-
-<li>
-The <a href="/pkg/container/heap/"><code>container/heap</code></a> package
-adds a <a href="/pkg/container/heap/#Fix"><code>Fix</code></a>
-method to provide a more efficient way to update an item's position in the heap.
-</li>
-
-<li>
-The <a href="/pkg/container/list/"><code>container/list</code></a> package
-adds the <a href="/pkg/container/list/#List.MoveBefore"><code>MoveBefore</code></a>
-and
-<a href="/pkg/container/list/#List.MoveAfter"><code>MoveAfter</code></a>
-methods, which implement the obvious rearrangement.
-</li>
-
-<li>
-The <a href="/pkg/crypto/cipher/"><code>crypto/cipher</code></a> package
-adds the a new GCM mode (Galois Counter Mode), which is almost always
-used with AES encryption.
-</li>
-
-<li>
-The 
-<a href="/pkg/crypto/md5/"><code>crypto/md5</code></a> package
-adds a new <a href="/pkg/crypto/md5/#Sum"><code>Sum</code></a> function
-to simplify hashing without sacrificing performance.
-</li>
-
-<li>
-Similarly, the 
-<a href="/pkg/crypto/md5/"><code>crypto/sha1</code></a> package
-adds a new <a href="/pkg/crypto/sha1/#Sum"><code>Sum</code></a> function.
-</li>
-
-<li>
-Also, the
-<a href="/pkg/crypto/sha256/"><code>crypto/sha256</code></a> package
-adds <a href="/pkg/crypto/sha256/#Sum256"><code>Sum256</code></a>
-and <a href="/pkg/crypto/sha256/#Sum224"><code>Sum224</code></a> functions.
-</li>
-
-<li>
-Finally, the <a href="/pkg/crypto/sha512/"><code>crypto/sha512</code></a> package
-adds <a href="/pkg/crypto/sha512/#Sum512"><code>Sum512</code></a> and
-<a href="/pkg/crypto/sha512/#Sum384"><code>Sum384</code></a> functions.
-</li>
-
-<li>
-The <a href="/pkg/crypto/x509/"><code>crypto/x509</code></a> package
-adds support for reading and writing arbitrary extensions.
-</li>
-
-<li>
-The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package adds
-support for TLS 1.1, 1.2 and AES-GCM.
-</li>
-
-<li>
-The <a href="/pkg/database/sql/"><code>database/sql</code></a> package adds a
-<a href="/pkg/database/sql/#DB.SetMaxOpenConns"><code>SetMaxOpenConns</code></a>
-method on <a href="/pkg/database/sql/#DB"><code>DB</code></a> to limit the
-number of open connections to the database.
-</li>
-
-<li>
-The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package
-now always allows trailing commas on fields.
-</li>
-
-<li>
-The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package
-now treats channel and function fields of structures as if they were unexported,
-even if they are not. That is, it ignores them completely. Previously they would
-trigger an error, which could cause unexpected compatibility problems if an
-embedded structure added such a field.
-The package also now supports the generic <code>BinaryMarshaler</code> and
-<code>BinaryUnmarshaler</code> interfaces of the
-<a href="/pkg/encoding/"><code>encoding</code></a> package
-described above.
-</li>
-
-<li>
-The <a href="/pkg/encoding/json/"><code>encoding/json</code></a> package
-now will always escape ampersands as "\u0026" when printing strings.
-It will now accept but correct invalid UTF-8 in
-<a href="/pkg/encoding/json/#Marshal"><code>Marshal</code></a>
-(such input was previously rejected).
-Finally, it now supports the generic encoding interfaces of the
-<a href="/pkg/encoding/"><code>encoding</code></a> package
-described above.
-</li>
-
-<li>
-The <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a> package
-now allows attributes stored in pointers to be marshaled.
-It also supports the generic encoding interfaces of the
-<a href="/pkg/encoding/"><code>encoding</code></a> package
-described above through the new
-<a href="/pkg/encoding/xml/#Marshaler"><code>Marshaler</code></a>,
-<a href="/pkg/encoding/xml/#Unmarshaler"><code>Unmarshaler</code></a>,
-and related
-<a href="/pkg/encoding/xml/#MarshalerAttr"><code>MarshalerAttr</code></a> and
-<a href="/pkg/encoding/xml/#UnmarshalerAttr"><code>UnmarshalerAttr</code></a>
-interfaces.
-The package also adds a
-<a href="/pkg/encoding/xml/#Encoder.Flush"><code>Flush</code></a> method
-to the
-<a href="/pkg/encoding/xml/#Encoder"><code>Encoder</code></a>
-type for use by custom encoders. See the documentation for
-<a href="/pkg/encoding/xml/#Encoder.EncodeToken"><code>EncodeToken</code></a>
-to see how to use it.
-</li>
-
-<li>
-The <a href="/pkg/flag/"><code>flag</code></a> package now
-has a <a href="/pkg/flag/#Getter"><code>Getter</code></a> interface
-to allow the value of a flag to be retrieved. Due to the
-Go 1 compatibility guidelines, this method cannot be added to the existing
-<a href="/pkg/flag/#Value"><code>Value</code></a>
-interface, but all the existing standard flag types implement it.
-The package also now exports the <a href="/pkg/flag/#CommandLine"><code>CommandLine</code></a>
-flag set, which holds the flags from the command line.
-</li>
-
-<li>
-The <a href="/pkg/go/ast/"><code>go/ast</code></a> package's
-<a href="/pkg/go/ast/#SliceExpr"><code>SliceExpr</code></a> struct
-has a new boolean field, <code>Slice3</code>, which is set to true
-when representing a slice expression with three indices (two colons).
-The default is false, representing the usual two-index form.
-</li>
-
-<li>
-The <a href="/pkg/go/build/"><code>go/build</code></a> package adds
-the <code>AllTags</code> field
-to the <a href="/pkg/go/build/#Package"><code>Package</code></a> type,
-to make it easier to process build tags.
-</li>
-
-<li>
-The <a href="/pkg/image/draw/"><code>image/draw</code></a> package now
-exports an interface, <a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>,
-that wraps the standard <a href="/pkg/image/draw/#Draw"><code>Draw</code></a> method.
-The Porter-Duff operators now implement this interface, in effect binding an operation to
-the draw operator rather than providing it explicitly.
-Given a paletted image as its destination, the new
-<a href="/pkg/image/draw/#FloydSteinberg"><code>FloydSteinberg</code></a>
-implementation of the
-<a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>
-interface will use the Floyd-Steinberg error diffusion algorithm to draw the image.
-To create palettes suitable for such processing, the new
-<a href="/pkg/image/draw/#Quantizer"><code>Quantizer</code></a> interface
-represents implementations of quantization algorithms that choose a palette
-given a full-color image.
-There are no implementations of this interface in the library.
-</li>
-
-<li>
-The <a href="/pkg/image/gif/"><code>image/gif</code></a> package
-can now create GIF files using the new
-<a href="/pkg/image/gif/#Encode"><code>Encode</code></a>
-and <a href="/pkg/image/gif/#EncodeAll"><code>EncodeAll</code></a>
-functions.
-Their options argument allows specification of an image
-<a href="/pkg/image/draw/#Quantizer"><code>Quantizer</code></a> to use;
-if it is <code>nil</code>, the generated GIF will use the 
-<a href="/pkg/image/color/palette/#Plan9"><code>Plan9</code></a>
-color map (palette) defined in the new
-<a href="/pkg/image/color/palette/"><code>image/color/palette</code></a> package.
-The options also specify a
-<a href="/pkg/image/draw/#Drawer"><code>Drawer</code></a>
-to use to create the output image;
-if it is <code>nil</code>, Floyd-Steinberg error diffusion is used.
-</li>
-
-<li>
-The <a href="/pkg/io/#Copy"><code>Copy</code></a> method of the
-<a href="/pkg/io/"><code>io</code></a> package now prioritizes its
-arguments differently.
-If one argument implements <a href="/pkg/io/#WriterTo"><code>WriterTo</code></a>
-and the other implements <a href="/pkg/io/#ReaderFrom"><code>ReaderFrom</code></a>,
-<a href="/pkg/io/#Copy"><code>Copy</code></a> will now invoke
-<a href="/pkg/io/#WriterTo"><code>WriterTo</code></a> to do the work,
-so that less intermediate buffering is required in general.
-</li>
-
-<li>
-The <a href="/pkg/net/"><code>net</code></a> package requires cgo by default
-because the host operating system must in general mediate network call setup.
-On some systems, though, it is possible to use the network without cgo, and useful
-to do so, for instance to avoid dynamic linking.
-The new build tag <code>netgo</code> (off by default) allows the construction of a
-<code>net</code> package in pure Go on those systems where it is possible.
-</li>
-
-<li>
-The <a href="/pkg/net/"><code>net</code></a> package adds a new field
-<code>DualStack</code> to the <a href="/pkg/net/#Dialer"><code>Dialer</code></a>
-struct for TCP connection setup using a dual IP stack as described in
-<a href="http://tools.ietf.org/html/rfc6555">RFC 6555</a>.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package will no longer
-transmit cookies that are incorrect according to
-<a href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>.
-It just logs an error and sends nothing.
-Also,
-the <a href="/pkg/net/http/"><code>net/http</code></a> package's
-<a href="/pkg/net/http/#ReadResponse"><code>ReadResponse</code></a>
-function now permits the <code>*Request</code> parameter to be <code>nil</code>,
-whereupon it assumes a GET request.
-Finally, an HTTP server will now serve HEAD
-requests transparently, without the need for special casing in handler code.
-While serving a HEAD request, writes to a 
-<a href="/pkg/net/http/#Handler"><code>Handler</code></a>'s
-<a href="/pkg/net/http/#ResponseWriter"><code>ResponseWriter</code></a>
-are absorbed by the
-<a href="/pkg/net/http/#Server"><code>Server</code></a>
-and the client receives an empty body as required by the HTTP specification.
-</li>
-
-<li>
-The <a href="/pkg/os/exec/"><code>os/exec</code></a> package's 
-<a href="/pkg/os/exec/#Cmd.StdinPipe"><code>Cmd.StdinPipe</code></a> method 
-returns an <code>io.WriteCloser</code>, but has changed its concrete
-implementation from <code>*os.File</code> to an unexported type that embeds
-<code>*os.File</code>, and it is now safe to close the returned value.
-Before Go 1.2, there was an unavoidable race that this change fixes.
-Code that needs access to the methods of <code>*os.File</code> can use an
-interface type assertion, such as <code>wc.(interface{ Sync() error })</code>.
-</li>
-
-<li>
-The <a href="/pkg/runtime/"><code>runtime</code></a> package relaxes
-the constraints on finalizer functions in
-<a href="/pkg/runtime/#SetFinalizer"><code>SetFinalizer</code></a>: the
-actual argument can now be any type that is assignable to the formal type of
-the function, as is the case for any normal function call in Go.
-</li>
-
-<li>
-The <a href="/pkg/sort/"><code>sort</code></a> package has a new
-<a href="/pkg/sort/#Stable"><code>Stable</code></a> function that implements
-stable sorting. It is less efficient than the normal sort algorithm, however.
-</li>
-
-<li>
-The <a href="/pkg/strings/"><code>strings</code></a> package adds
-an <a href="/pkg/strings/#IndexByte"><code>IndexByte</code></a>
-function for consistency with the <a href="/pkg/bytes/"><code>bytes</code></a> package.
-</li>
-
-<li>
-The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package
-adds a new set of swap functions that atomically exchange the argument with the
-value stored in the pointer, returning the old value.
-The functions are
-<a href="/pkg/sync/atomic/#SwapInt32"><code>SwapInt32</code></a>,
-<a href="/pkg/sync/atomic/#SwapInt64"><code>SwapInt64</code></a>,
-<a href="/pkg/sync/atomic/#SwapUint32"><code>SwapUint32</code></a>,
-<a href="/pkg/sync/atomic/#SwapUint64"><code>SwapUint64</code></a>,
-<a href="/pkg/sync/atomic/#SwapUintptr"><code>SwapUintptr</code></a>,
-and
-<a href="/pkg/sync/atomic/#SwapPointer"><code>SwapPointer</code></a>,
-which swaps an <code>unsafe.Pointer</code>.
-</li>
-
-<li>
-The <a href="/pkg/syscall/"><code>syscall</code></a> package now implements
-<a href="/pkg/syscall/#Sendfile"><code>Sendfile</code></a> for Darwin.
-</li>
-
-<li>
-The <a href="/pkg/testing/"><code>testing</code></a> package
-now exports the <a href="/pkg/testing/#TB"><code>TB</code></a> interface.
-It records the methods in common with the
-<a href="/pkg/testing/#T"><code>T</code></a>
-and
-<a href="/pkg/testing/#B"><code>B</code></a> types,
-to make it easier to share code between tests and benchmarks.
-Also, the
-<a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a>
-function now quantizes the return value to an integer (although it
-still has type <code>float64</code>), to round off any error caused by
-initialization and make the result more repeatable. 
-</li>
-
-<li>
-The <a href="/pkg/text/template/"><code>text/template</code></a> package
-now automatically dereferences pointer values when evaluating the arguments
-to "escape" functions such as "html", to bring the behavior of such functions
-in agreement with that of other printing functions such as "printf".
-</li>
-
-<li>
-In the <a href="/pkg/time/"><code>time</code></a> package, the
-<a href="/pkg/time/#Parse"><code>Parse</code></a> function
-and
-<a href="/pkg/time/#Time.Format"><code>Format</code></a>
-method
-now handle time zone offsets with seconds, such as in the historical
-date "1871-01-01T05:33:02+00:34:08".
-Also, pattern matching in the formats for those routines is stricter: a non-lowercase letter
-must now follow the standard words such as "Jan" and "Mon".
-</li>
-
-<li>
-The <a href="/pkg/unicode/"><code>unicode</code></a> package
-adds <a href="/pkg/unicode/#In"><code>In</code></a>,
-a nicer-to-use but equivalent version of the original
-<a href="/pkg/unicode/#IsOneOf"><code>IsOneOf</code></a>,
-to see whether a character is a member of a Unicode category.
-</li>
-
-</ul>
--- a/doc/go1.3.html
+++ b/doc/go1.3.html
@@ -1,608 +0,0 @@
-<!--{
-	"Title": "Go 1.3 Release Notes",
-	"Path":  "/doc/go1.3",
-	"Template": true
-}-->
-
-<h2 id="introduction">Introduction to Go 1.3</h2>
-
-<p>
-The latest Go release, version 1.3, arrives six months after 1.2,
-and contains no language changes.
-It focuses primarily on implementation work, providing 
-precise garbage collection,
-a major refactoring of the compiler tool chain that results in
-faster builds, especially for large projects,
-significant performance improvements across the board,
-and support for DragonFly BSD, Solaris, Plan 9 and Google's Native Client architecture (NaCl).
-It also has an important refinement to the memory model regarding synchronization.
-As always, Go 1.3 keeps the <a href="/doc/go1compat.html">promise
-of compatibility</a>,
-and almost everything 
-will continue to compile and run without change when moved to 1.3.
-</p>
-
-<h2 id="os">Changes to the supported operating systems and architectures</h2>
-
-<h3 id="win2000">Removal of support for Windows 2000</h3>
-
-<p>
-Microsoft stopped supporting Windows 2000 in 2010.
-Since it has <a href="https://codereview.appspot.com/74790043">implementation difficulties</a>
-regarding exception handling (signals in Unix terminology),
-as of Go 1.3 it is not supported by Go either.
-</p>
-
-<h3 id="dragonfly">Support for DragonFly BSD</h3>
-
-<p>
-Go 1.3 now includes experimental support for DragonFly BSD on the <code>amd64</code> (64-bit x86) and <code>386</code> (32-bit x86) architectures.
-It uses DragonFly BSD 3.6 or above.
-</p>
-
-<h3 id="freebsd">Support for FreeBSD</h3>
-
-<p>
-It was not announced at the time, but since the release of Go 1.2, support for Go on FreeBSD
-requires FreeBSD 8 or above.
-</p>
-
-<p>
-As of Go 1.3, support for Go on FreeBSD requires that the kernel be compiled with the
-<code>COMPAT_FREEBSD32</code> flag configured.
-</p>
-
-<p>
-In concert with the switch to EABI syscalls for ARM platforms, Go 1.3 will run only on FreeBSD 10.
-The x86 platforms, 386 and amd64, are unaffected.
-</p>
-
-<h3 id="nacl">Support for Native Client</h3>
-
-<p>
-Support for the Native Client virtual machine architecture has returned to Go with the 1.3 release.
-It runs on the 32-bit Intel architectures (<code>GOARCH=386</code>) and also on 64-bit Intel, but using
-32-bit pointers (<code>GOARCH=amd64p32</code>).
-There is not yet support for Native Client on ARM.
-Note that this is Native Client (NaCl), not Portable Native Client (PNaCl).
-Details about Native Client are <a href="https://developers.google.com/native-client/dev/">here</a>;
-how to set up the Go version is described <a href="//golang.org/wiki/NativeClient">here</a>.
-</p>
-
-<h3 id="netbsd">Support for NetBSD</h3>
-
-<p>
-As of Go 1.3, support for Go on NetBSD requires NetBSD 6.0 or above.
-</p>
-
-<h3 id="openbsd">Support for OpenBSD</h3>
-
-<p>
-As of Go 1.3, support for Go on OpenBSD requires OpenBSD 5.5 or above.
-</p>
-
-<h3 id="plan9">Support for Plan 9</h3>
-
-<p>
-Go 1.3 now includes experimental support for Plan 9 on the <code>386</code> (32-bit x86) architecture.
-It requires the <code>Tsemacquire</code> syscall, which has been in Plan 9 since June, 2012.
-</p>
-
-<h3 id="solaris">Support for Solaris</h3>
-
-<p>
-Go 1.3 now includes experimental support for Solaris on the <code>amd64</code> (64-bit x86) architecture.
-It requires illumos, Solaris 11 or above.
-</p>
-
-<h2 id="memory">Changes to the memory model</h2>
-
-<p>
-The Go 1.3 memory model <a href="https://codereview.appspot.com/75130045">adds a new rule</a>
-concerning sending and receiving on buffered channels,
-to make explicit that a buffered channel can be used as a simple
-semaphore, using a send into the
-channel to acquire and a receive from the channel to release.
-This is not a language change, just a clarification about an expected property of communication.
-</p>
-
-<h2 id="impl">Changes to the implementations and tools</h2>
-
-<h3 id="stacks">Stack</h3>
-
-<p>
-Go 1.3 has changed the implementation of goroutine stacks away from the old,
-"segmented" model to a contiguous model.
-When a goroutine needs more stack
-than is available, its stack is transferred to a larger single block of memory.
-The overhead of this transfer operation amortizes well and eliminates the old "hot spot"
-problem when a calculation repeatedly steps across a segment boundary.
-Details including performance numbers are in this
-<a href="//golang.org/s/contigstacks">design document</a>.
-</p>
-
-<h3 id="garbage_collector">Changes to the garbage collector</h3>
-
-<p>
-For a while now, the garbage collector has been <em>precise</em> when examining
-values in the heap; the Go 1.3 release adds equivalent precision to values on the stack.
-This means that a non-pointer Go value such as an integer will never be mistaken for a
-pointer and prevent unused memory from being reclaimed.
-</p>
-
-<p>
-Starting with Go 1.3, the runtime assumes that values with pointer type
-contain pointers and other values do not.
-This assumption is fundamental to the precise behavior of both stack expansion
-and garbage collection.
-Programs that use <a href="/pkg/unsafe/">package unsafe</a>
-to store integers in pointer-typed values are illegal and will crash if the runtime detects the behavior.
-Programs that use <a href="/pkg/unsafe/">package unsafe</a> to store pointers
-in integer-typed values are also illegal but more difficult to diagnose during execution.
-Because the pointers are hidden from the runtime, a stack expansion or garbage collection
-may reclaim the memory they point at, creating
-<a href="//en.wikipedia.org/wiki/Dangling_pointer">dangling pointers</a>.
-</p>
-
-<p>
-<em>Updating</em>: Code that uses <code>unsafe.Pointer</code> to convert
-an integer-typed value held in memory into a pointer is illegal and must be rewritten.
-Such code can be identified by <code>go vet</code>.
-</p>
-
-<h3 id="map">Map iteration</h3>
-
-<p>
-Iterations over small maps no longer happen in a consistent order.
-Go 1 defines that &ldquo;<a href="//golang.org/ref/spec#For_statements">The iteration order over maps
-is not specified and is not guaranteed to be the same from one iteration to the next.</a>&rdquo;
-To keep code from depending on map iteration order,
-Go 1.0 started each map iteration at a random index in the map.
-A new map implementation introduced in Go 1.1 neglected to randomize
-iteration for maps with eight or fewer entries, although the iteration order
-can still vary from system to system.
-This has allowed people to write Go 1.1 and Go 1.2 programs that
-depend on small map iteration order and therefore only work reliably on certain systems.
-Go 1.3 reintroduces random iteration for small maps in order to flush out these bugs.
-</p>
-
-<p>
-<em>Updating</em>: If code assumes a fixed iteration order for small maps,
-it will break and must be rewritten not to make that assumption.
-Because only small maps are affected, the problem arises most often in tests.
-</p>
-
-<h3 id="liblink">The linker</h3>
-
-<p>
-As part of the general <a href="//golang.org/s/go13linker">overhaul</a> to
-the Go linker, the compilers and linkers have been refactored.
-The linker is still a C program, but now the instruction selection phase that
-was part of the linker has been moved to the compiler through the creation of a new
-library called <code>liblink</code>.
-By doing instruction selection only once, when the package is first compiled,
-this can speed up compilation of large projects significantly.
-</p>
-
-<p>
-<em>Updating</em>: Although this is a major internal change, it should have no
-effect on programs.
-</p>
-
-<h3 id="gccgo">Status of gccgo</h3>
-
-<p>
-GCC release 4.9 will contain the Go 1.2 (not 1.3) version of gccgo.
-The release schedules for the GCC and Go projects do not coincide,
-which means that 1.3 will be available in the development branch but
-that the next GCC release, 4.10, will likely have the Go 1.4 version of gccgo.
-</p>
-
-<h3 id="gocmd">Changes to the go command</h3>
-
-<p>
-The <a href="/cmd/go/"><code>cmd/go</code></a> command has several new
-features.
-The <a href="/cmd/go/"><code>go run</code></a> and
-<a href="/cmd/go/"><code>go test</code></a> subcommands
-support a new <code>-exec</code> option to specify an alternate
-way to run the resulting binary.
-Its immediate purpose is to support NaCl.
-</p>
-
-<p>
-The test coverage support of the <a href="/cmd/go/"><code>go test</code></a>
-subcommand now automatically sets the coverage mode to <code>-atomic</code>
-when the race detector is enabled, to eliminate false reports about unsafe
-access to coverage counters.
-</p>
-
-<p>
-The <a href="/cmd/go/"><code>go test</code></a> subcommand
-now always builds the package, even if it has no test files.
-Previously, it would do nothing if no test files were present.
-</p>
-
-<p>
-The <a href="/cmd/go/"><code>go build</code></a> subcommand
-supports a new <code>-i</code> option to install dependencies
-of the specified target, but not the target itself.
-</p>
-
-<p>
-Cross compiling with <a href="/cmd/cgo/"><code>cgo</code></a> enabled
-is now supported.
-The CC_FOR_TARGET and CXX_FOR_TARGET environment
-variables are used when running all.bash to specify the cross compilers
-for C and C++ code, respectively.
-</p>
-
-<p>
-Finally, the go command now supports packages that import Objective-C
-files (suffixed <code>.m</code>) through cgo.
-</p>
-
-<h3 id="cgo">Changes to cgo</h3>
-
-<p>
-The <a href="/cmd/cgo/"><code>cmd/cgo</code></a> command,
-which processes <code>import "C"</code> declarations in Go packages,
-has corrected a serious bug that may cause some packages to stop compiling.
-Previously, all pointers to incomplete struct types translated to the Go type <code>*[0]byte</code>,
-with the effect that the Go compiler could not diagnose passing one kind of struct pointer
-to a function expecting another.
-Go 1.3 corrects this mistake by translating each different
-incomplete struct to a different named type.
-</p>
-
-<p>
-Given the C declaration <code>typedef struct S T</code> for an incomplete <code>struct S</code>,
-some Go code used this bug to refer to the types <code>C.struct_S</code> and <code>C.T</code> interchangeably.
-Cgo now explicitly allows this use, even for completed struct types.
-However, some Go code also used this bug to pass (for example) a <code>*C.FILE</code>
-from one package to another.
-This is not legal and no longer works: in general Go packages
-should avoid exposing C types and names in their APIs.
-</p>
-
-<p>
-<em>Updating</em>: Code confusing pointers to incomplete types or
-passing them across package boundaries will no longer compile
-and must be rewritten.
-If the conversion is correct and must be preserved,
-use an explicit conversion via <a href="/pkg/unsafe/#Pointer"><code>unsafe.Pointer</code></a>.
-</p>
-
-<h3 id="swig">SWIG 3.0 required for programs that use SWIG</h3>
-
-<p>
-For Go programs that use SWIG, SWIG version 3.0 is now required.
-The <a href="/cmd/go"><code>cmd/go</code></a> command will now link the
-SWIG generated object files directly into the binary, rather than
-building and linking with a shared library.
-</p>
-
-<h3 id="gc_flag">Command-line flag parsing</h3>
-
-<p>
-In the gc tool chain, the assemblers now use the
-same command-line flag parsing rules as the Go flag package, a departure
-from the traditional Unix flag parsing.
-This may affect scripts that invoke the tool directly.
-For example,
-<code>go tool 6a -SDfoo</code> must now be written
-<code>go tool 6a -S -D foo</code>.
-(The same change was made to the compilers and linkers in <a href="/doc/go1.1#gc_flag">Go 1.1</a>.)
-</p>
-
-<h3 id="godoc">Changes to godoc</h3>
-<p>
-When invoked with the <code>-analysis</code> flag, 
-<a href="//godoc.org/golang.org/x/tools/cmd/godoc">godoc</a>
-now performs sophisticated <a href="/lib/godoc/analysis/help.html">static
-analysis</a> of the code it indexes.  
-The results of analysis are presented in both the source view and the
-package documentation view, and include the call graph of each package
-and the relationships between 
-definitions and references,
-types and their methods,
-interfaces and their implementations,
-send and receive operations on channels,
-functions and their callers, and
-call sites and their callees.
-</p>
-
-<h3 id="misc">Miscellany</h3>
-
-<p>
-The program <code>misc/benchcmp</code> that compares
-performance across benchmarking runs has been rewritten.
-Once a shell and awk script in the main repository, it is now a Go program in the <code>go.tools</code> repo.
-Documentation is <a href="//godoc.org/golang.org/x/tools/cmd/benchcmp">here</a>.
-</p>
-
-<p>
-For the few of us that build Go distributions, the tool <code>misc/dist</code> has been
-moved and renamed; it now lives in <code>misc/makerelease</code>, still in the main repository.
-</p>
-
-<h2 id="performance">Performance</h2>
-
-<p>
-The performance of Go binaries for this release has improved in many cases due to changes
-in the runtime and garbage collection, plus some changes to libraries.
-Significant instances include:
-</p>
-
-<ul> 
-
-<li>
-The runtime handles defers more efficiently, reducing the memory footprint by about two kilobytes
-per goroutine that calls defer.
-</li>
-
-<li>
-The garbage collector has been sped up, using a concurrent sweep algorithm,
-better parallelization, and larger pages.
-The cumulative effect can be a 50-70% reduction in collector pause time.
-</li>
-
-<li>
-The race detector (see <a href="/doc/articles/race_detector.html">this guide</a>)
-is now about 40% faster.
-</li>
-
-<li>
-The regular expression package <a href="/pkg/regexp/"><code>regexp</code></a>
-is now significantly faster for certain simple expressions due to the implementation of
-a second, one-pass execution engine.
-The choice of which engine to use is automatic;
-the details are hidden from the user.
-</li>
-
-</ul>
-
-<p>
-Also, the runtime now includes in stack dumps how long a goroutine has been blocked,
-which can be useful information when debugging deadlocks or performance issues.
-</p>
-
-<h2 id="library">Changes to the standard library</h2>
-
-<h3 id="new_packages">New packages</h3>
-
-<p>
-A new package <a href="/pkg/debug/plan9obj/"><code>debug/plan9obj</code></a> was added to the standard library.
-It implements access to Plan 9 <a href="http://plan9.bell-labs.com/magic/man2html/6/a.out">a.out</a> object files.
-</p>
-
-<h3 id="major_library_changes">Major changes to the library</h3>
-
-<p>
-A previous bug in <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a>
-made it possible to skip verification in TLS inadvertently.
-In Go 1.3, the bug is fixed: one must specify either ServerName or
-InsecureSkipVerify, and if ServerName is specified it is enforced.
-This may break existing code that incorrectly depended on insecure
-behavior.
-</p>
-
-<p>
-There is an important new type added to the standard library: <a href="/pkg/sync/#Pool"><code>sync.Pool</code></a>.
-It provides an efficient mechanism for implementing certain types of caches whose memory
-can be reclaimed automatically by the system.
-</p>
-
-<p>
-The <a href="/pkg/testing/"><code>testing</code></a> package's benchmarking helper,
-<a href="/pkg/testing/#B"><code>B</code></a>, now has a
-<a href="/pkg/testing/#B.RunParallel"><code>RunParallel</code></a> method
-to make it easier to run benchmarks that exercise multiple CPUs.
-</p>
-
-<p>
-<em>Updating</em>: The crypto/tls fix may break existing code, but such
-code was erroneous and should be updated.
-</p>
-
-<h3 id="minor_library_changes">Minor changes to the library</h3>
-
-<p>
-The following list summarizes a number of minor changes to the library, mostly additions.
-See the relevant package documentation for more information about each change.
-</p>
-
-<ul>
-
-<li> In the <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package,
-a new <a href="/pkg/crypto/tls/#DialWithDialer"><code>DialWithDialer</code></a>
-function lets one establish a TLS connection using an existing dialer, making it easier
-to control dial options such as timeouts.
-The package also now reports the TLS version used by the connection in the
-<a href="/pkg/crypto/tls/#ConnectionState"><code>ConnectionState</code></a>
-struct.
-</li>
-
-<li> The <a href="/pkg/crypto/x509/#CreateCertificate"><code>CreateCertificate</code></a>
-function of the <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
-now supports parsing (and elsewhere, serialization) of PKCS #10 certificate
-signature requests.
-</li>
-
-<li>
-The formatted print functions of the <code>fmt</code> package now define <code>%F</code>
-as a synonym for <code>%f</code> when printing floating-point values.
-</li>
-
-<li>
-The <a href="/pkg/math/big/"><code>math/big</code></a> package's
-<a href="/pkg/math/big/#Int"><code>Int</code></a> and
-<a href="/pkg/math/big/#Rat"><code>Rat</code></a> types
-now implement
-<a href="/pkg/encoding/#TextMarshaler"><code>encoding.TextMarshaler</code></a> and
-<a href="/pkg/encoding/#TextUnmarshaler"><code>encoding.TextUnmarshaler</code></a>.
-</li>
-
-<li>
-The complex power function, <a href="/pkg/math/cmplx/#Pow"><code>Pow</code></a>,
-now specifies the behavior when the first argument is zero.
-It was undefined before.
-The details are in the <a href="/pkg/math/cmplx/#Pow">documentation for the function</a>.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package now exposes the
-properties of a TLS connection used to make a client request in the new
-<a href="/pkg/net/http/#Response"><code>Response.TLS</code></a> field.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package now
-allows setting an optional server error logger
-with <a href="/pkg/net/http/#Server"><code>Server.ErrorLog</code></a>.
-The default is still that all errors go to stderr.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package now
-supports disabling HTTP keep-alive connections on the server
-with <a href="/pkg/net/http/#Server.SetKeepAlivesEnabled"><code>Server.SetKeepAlivesEnabled</code></a>.
-The default continues to be that the server does keep-alive (reuses
-connections for multiple requests) by default.
-Only resource-constrained servers or those in the process of graceful
-shutdown will want to disable them.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package adds an optional
-<a href="/pkg/net/http/#Transport"><code>Transport.TLSHandshakeTimeout</code></a>
-setting to cap the amount of time HTTP client requests will wait for
-TLS handshakes to complete.
-It's now also set by default
-on <a href="/pkg/net/http#DefaultTransport"><code>DefaultTransport</code></a>.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package's
-<a href="/pkg/net/http/#DefaultTransport"><code>DefaultTransport</code></a>,
-used by the HTTP client code, now
-enables <a href="http://en.wikipedia.org/wiki/Keepalive#TCP_keepalive">TCP
-keep-alives</a> by default.
-Other <a href="/pkg/net/http/#Transport"><code>Transport</code></a>
-values with a nil <code>Dial</code> field continue to function the same
-as before: no TCP keep-alives are used.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package
-now enables <a href="http://en.wikipedia.org/wiki/Keepalive#TCP_keepalive">TCP
-keep-alives</a> for incoming server requests when
-<a href="/pkg/net/http/#ListenAndServe"><code>ListenAndServe</code></a>
-or
-<a href="/pkg/net/http/#ListenAndServeTLS"><code>ListenAndServeTLS</code></a>
-are used.
-When a server is started otherwise, TCP keep-alives are not enabled.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package now
-provides an
-optional <a href="/pkg/net/http/#Server"><code>Server.ConnState</code></a>
-callback to hook various phases of a server connection's lifecycle
-(see <a href="/pkg/net/http/#ConnState"><code>ConnState</code></a>).
-This can be used to implement rate limiting or graceful shutdown.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package's HTTP
-client now has an
-optional <a href="/pkg/net/http/#Client"><code>Client.Timeout</code></a>
-field to specify an end-to-end timeout on requests made using the
-client.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package's
-<a href="/pkg/net/http/#Request.ParseMultipartForm"><code>Request.ParseMultipartForm</code></a>
-method will now return an error if the body's <code>Content-Type</code>
-is not <code>mutipart/form-data</code>.
-Prior to Go 1.3 it would silently fail and return <code>nil</code>.
-Code that relies on the previous behavior should be updated.
-</li>
-
-<li> In the <a href="/pkg/net/"><code>net</code></a> package,
-the <a href="/pkg/net/#Dialer"><code>Dialer</code></a> struct now
-has a <code>KeepAlive</code> option to specify a keep-alive period for the connection.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package's 
-<a href="/pkg/net/http/#Transport"><code>Transport</code></a>
-now closes <a href="/pkg/net/http/#Request"><code>Request.Body</code></a>
-consistently, even on error.
-</li>
-
-<li>
-The <a href="/pkg/os/exec/"><code>os/exec</code></a> package now implements
-what the documentation has always said with regard to relative paths for the binary.
-In particular, it only calls <a href="/pkg/os/exec/#LookPath"><code>LookPath</code></a>
-when the binary's file name contains no path separators.
-</li>
-
-<li>
-The <a href="/pkg/reflect/#Value.SetMapIndex"><code>SetMapIndex</code></a>
-function in the <a href="/pkg/reflect/"><code>reflect</code></a> package
-no longer panics when deleting from a <code>nil</code> map.
-</li>
-
-<li>
-If the main goroutine calls 
-<a href="/pkg/runtime/#Goexit"><code>runtime.Goexit</code></a>
-and all other goroutines finish execution, the program now always crashes,
-reporting a detected deadlock.
-Earlier versions of Go handled this situation inconsistently: most instances
-were reported as deadlocks, but some trivial cases exited cleanly instead.
-</li>
-
-<li>
-The runtime/debug package now has a new function
-<a href="/pkg/runtime/debug/#WriteHeapDump"><code>debug.WriteHeapDump</code></a>
-that writes out a description of the heap.
-</li>
-
-<li>
-The <a href="/pkg/strconv/#CanBackquote"><code>CanBackquote</code></a>
-function in the <a href="/pkg/strconv/"><code>strconv</code></a> package
-now considers the <code>DEL</code> character, <code>U+007F</code>, to be
-non-printing.
-</li>
-
-<li>
-The <a href="/pkg/syscall/"><code>syscall</code></a> package now provides
-<a href="/pkg/syscall/#SendmsgN"><code>SendmsgN</code></a>
-as an alternate version of
-<a href="/pkg/syscall/#Sendmsg"><code>Sendmsg</code></a>
-that returns the number of bytes written.
-</li>
-
-<li>
-On Windows, the <a href="/pkg/syscall/"><code>syscall</code></a> package now
-supports the cdecl calling convention through the addition of a new function
-<a href="/pkg/syscall/#NewCallbackCDecl"><code>NewCallbackCDecl</code></a>
-alongside the existing function
-<a href="/pkg/syscall/#NewCallback"><code>NewCallback</code></a>.
-</li>
-
-<li>
-The <a href="/pkg/testing/"><code>testing</code></a> package now
-diagnoses tests that call <code>panic(nil)</code>, which are almost always erroneous.
-Also, tests now write profiles (if invoked with profiling flags) even on failure.
-</li>
-
-<li>
-The <a href="/pkg/unicode/"><code>unicode</code></a> package and associated
-support throughout the system has been upgraded from
-Unicode 6.2.0 to <a href="http://www.unicode.org/versions/Unicode6.3.0/">Unicode 6.3.0</a>.
-</li>
-
-</ul>
--- a/doc/go1.4.html
+++ b/doc/go1.4.html
@@ -1,896 +0,0 @@
-<!--{
-	"Title": "Go 1.4 Release Notes",
-	"Path":  "/doc/go1.4",
-	"Template": true
-}-->
-
-<h2 id="introduction">Introduction to Go 1.4</h2>
-
-<p>
-The latest Go release, version 1.4, arrives as scheduled six months after 1.3.
-</p>
-
-<p>
-It contains only one tiny language change,
-in the form of a backwards-compatible simple variant of <code>for</code>-<code>range</code> loop,
-and a possibly breaking change to the compiler involving methods on pointers-to-pointers.
-</p>
-
-<p>
-The release focuses primarily on implementation work, improving the garbage collector
-and preparing the ground for a fully concurrent collector to be rolled out in the
-next few releases.
-Stacks are now contiguous, reallocated when necessary rather than linking on new
-"segments";
-this release therefore eliminates the notorious "hot stack split" problem.
-There are some new tools available including support in the <code>go</code> command
-for build-time source code generation.
-The release also adds support for ARM processors on Android and Native Client (NaCl)
-and for AMD64 on Plan 9.
-</p>
-
-<p>
-As always, Go 1.4 keeps the <a href="/doc/go1compat.html">promise
-of compatibility</a>,
-and almost everything 
-will continue to compile and run without change when moved to 1.4.
-</p>
-
-<h2 id="language">Changes to the language</h2>
-
-<h3 id="forrange">For-range loops</h3>
-<p>
-Up until Go 1.3, <code>for</code>-<code>range</code> loop had two forms
-</p>
-
-<pre>
-for i, v := range x {
-	...
-}
-</pre>
-
-<p>
-and
-</p>
-
-<pre>
-for i := range x {
-	...
-}
-</pre>
-
-<p>
-If one was not interested in the loop values, only the iteration itself, it was still
-necessary to mention a variable (probably the <a href="/ref/spec#Blank_identifier">blank identifier</a>, as in
-<code>for</code> <code>_</code> <code>=</code> <code>range</code> <code>x</code>), because
-the form
-</p>
-
-<pre>
-for range x {
-	...
-}
-</pre>
-
-<p>
-was not syntactically permitted.
-</p>
-
-<p>
-This situation seemed awkward, so as of Go 1.4 the variable-free form is now legal.
-The pattern arises rarely but the code can be cleaner when it does.
-</p>
-
-<p>
-<em>Updating</em>: The change is strictly backwards compatible to existing Go
-programs, but tools that analyze Go parse trees may need to be modified to accept
-this new form as the
-<code>Key</code> field of <a href="/pkg/go/ast/#RangeStmt"><code>RangeStmt</code></a>
-may now be <code>nil</code>.
-</p>
-
-<h3 id="methodonpointertopointer">Method calls on **T</h3>
-
-<p>
-Given these declarations,
-</p>
-
-<pre>
-type T int
-func (T) M() {}
-var x **T
-</pre>
-
-<p>
-both <code>gc</code> and <code>gccgo</code> accepted the method call
-</p>
-
-<pre>
-x.M()
-</pre>
-
-<p>
-which is a double dereference of the pointer-to-pointer <code>x</code>.
-The Go specification allows a single dereference to be inserted automatically,
-but not two, so this call is erroneous according to the language definition.
-It has therefore been disallowed in Go 1.4, which is a breaking change,
-although very few programs will be affected.
-</p>
-
-<p>
-<em>Updating</em>: Code that depends on the old, erroneous behavior will no longer
-compile but is easy to fix by adding an explicit dereference.
-</p>
-
-<h2 id="os">Changes to the supported operating systems and architectures</h2>
-
-<h3 id="android">Android</h3>
-
-<p>
-Go 1.4 can build binaries for ARM processors running the Android operating system.
-It can also build a <code>.so</code> library that can be loaded by an Android application
-using the supporting packages in the <a href="https://golang.org/x/mobile">mobile</a> subrepository.
-A brief description of the plans for this experimental port are available
-<a href="https://golang.org/s/go14android">here</a>.
-</p>
-
-<h3 id="naclarm">NaCl on ARM</h3>
-
-<p>
-The previous release introduced Native Client (NaCl) support for the 32-bit x86
-(<code>GOARCH=386</code>)
-and 64-bit x86 using 32-bit pointers (GOARCH=amd64p32).
-The 1.4 release adds NaCl support for ARM (GOARCH=arm).
-</p>
-
-<h3 id="plan9amd64">Plan9 on AMD64</h3>
-
-<p>
-This release adds support for the Plan 9 operating system on AMD64 processors,
-provided the kernel supports the <code>nsec</code> system call and uses 4K pages.
-</p>
-
-<h2 id="compatibility">Changes to the compatibility guidelines</h2>
-
-<p>
-The <a href="/pkg/unsafe/"><code>unsafe</code></a> package allows one
-to defeat Go's type system by exploiting internal details of the implementation
-or machine representation of data.
-It was never explicitly specified what use of <code>unsafe</code> meant
-with respect to compatibility as specified in the
-<a href="go1compat.html">Go compatibility guidelines</a>.
-The answer, of course, is that we can make no promise of compatibility
-for code that does unsafe things.
-</p>
-
-<p>
-We have clarified this situation in the documentation included in the release.
-The <a href="go1compat.html">Go compatibility guidelines</a> and the
-docs for the <a href="/pkg/unsafe/"><code>unsafe</code></a> package
-are now explicit that unsafe code is not guaranteed to remain compatible.
-</p>
-  
-<p>
-<em>Updating</em>: Nothing technical has changed; this is just a clarification
-of the documentation.
-</p>
-
-
-<h2 id="impl">Changes to the implementations and tools</h2>
-
-<h3 id="runtime">Changes to the runtime</h3>
-
-<p>
-Prior to Go 1.4, the runtime (garbage collector, concurrency support, interface management,
-maps, slices, strings, ...) was mostly written in C, with some assembler support.
-In 1.4, much of the code has been translated to Go so that the garbage collector can scan
-the stacks of programs in the runtime and get accurate information about what variables
-are active.
-This change was large but should have no semantic effect on programs.
-</p>
-
-<p>
-This rewrite allows the garbage collector in 1.4 to be fully precise,
-meaning that it is aware of the location of all active pointers in the program.
-This means the heap will be smaller as there will be no false positives keeping non-pointers alive.
-Other related changes also reduce the heap size, which is smaller by 10%-30% overall
-relative to the previous release.
-</p>
-
-<p>
-A consequence is that stacks are no longer segmented, eliminating the "hot split" problem.
-When a stack limit is reached, a new, larger stack is allocated, all active frames for
-the goroutine are copied there, and any pointers into the stack are updated.
-Performance can be noticeably better in some cases and is always more predictable.
-Details are available in <a href="https://golang.org/s/contigstacks">the design document</a>.
-</p>
-
-<p>
-The use of contiguous stacks means that stacks can start smaller without triggering performance issues,
-so the default starting size for a goroutine's stack in 1.4 has been reduced from 8192 bytes to 2048 bytes.
-</p>
-
-<p>
-As preparation for the concurrent garbage collector scheduled for the 1.5 release,
-writes to pointer values in the heap are now done by a function call,
-called a write barrier, rather than directly from the function updating the value.
-In this next release, this will permit the garbage collector to mediate writes to the heap while it is running.
-This change has no semantic effect on programs in 1.4, but was
-included in the release to test the compiler and the resulting performance.
-</p>
-
-<p>
-The implementation of interface values has been modified.
-In earlier releases, the interface contained a word that was either a pointer or a one-word
-scalar value, depending on the type of the concrete object stored.
-This implementation was problematical for the garbage collector,
-so as of 1.4 interface values always hold a pointer.
-In running programs, most interface values were pointers anyway,
-so the effect is minimal, but programs that store integers (for example) in
-interfaces will see more allocations.
-</p>
-
-<p>
-As of Go 1.3, the runtime crashes if it finds a memory word that should contain
-a valid pointer but instead contains an obviously invalid pointer (for example, the value 3).
-Programs that store integers in pointer values may run afoul of this check and crash.
-In Go 1.4, setting the <a href="/pkg/runtime/"><code>GODEBUG</code></a> variable
-<code>invalidptr=0</code> disables
-the crash as a workaround, but we cannot guarantee that future releases will be
-able to avoid the crash; the correct fix is to rewrite code not to alias integers and pointers.
-</p>
-
-<h3 id="asm">Assembly</h3>
-
-<p>
-The language accepted by the assemblers <code>cmd/5a</code>, <code>cmd/6a</code>
-and <code>cmd/8a</code> has had several changes,
-mostly to make it easier to deliver type information to the runtime.
-</p>
-
-<p>
-First, the <code>textflag.h</code> file that defines flags for <code>TEXT</code> directives
-has been copied from the linker source directory to a standard location so it can be
-included with the simple directive
-</p>
-
-<pre>
-#include "textflag.h"
-</pre>
-
-<p>
-The more important changes are in how assembler source can define the necessary
-type information.
-For most programs it will suffice to move data
-definitions (<code>DATA</code> and <code>GLOBL</code> directives)
-out of assembly into Go files
-and to write a Go declaration for each assembly function.
-The <a href="/doc/asm#runtime">assembly document</a> describes what to do.
-</p>
-
-<p>
-<em>Updating</em>:
-Assembly files that include <code>textflag.h</code> from its old
-location will still work, but should be updated.
-For the type information, most assembly routines will need no change,
-but all should be examined.
-Assembly source files that define data,
-functions with non-empty stack frames, or functions that return pointers
-need particular attention.
-A description of the necessary (but simple) changes
-is in the <a href="/doc/asm#runtime">assembly document</a>.
-</p>
-
-<p>
-More information about these changes is in the <a href="/doc/asm">assembly document</a>.
-</p>
-
-<h3 id="gccgo">Status of gccgo</h3>
-
-<p>
-The release schedules for the GCC and Go projects do not coincide.
-GCC release 4.9 contains the Go 1.2 version of gccgo.
-The next release, GCC 5, will likely have the Go 1.4 version of gccgo.
-</p>
-
-<h3 id="internalpackages">Internal packages</h3>
-
-<p>
-Go's package system makes it easy to structure programs into components with clean boundaries,
-but there are only two forms of access: local (unexported) and global (exported).
-Sometimes one wishes to have components that are not exported,
-for instance to avoid acquiring clients of interfaces to code that is part of a public repository
-but not intended for use outside the program to which it belongs.
-</p>
-
-<p>
-The Go language does not have the power to enforce this distinction, but as of Go 1.4 the
-<a href="/cmd/go/"><code>go</code></a> command introduces
-a mechanism to define "internal" packages that may not be imported by packages outside
-the source subtree in which they reside.
-</p>
-
-<p>
-To create such a package, place it in a directory named <code>internal</code> or in a subdirectory of a directory
-named internal.
-When the <code>go</code> command sees an import of a package with <code>internal</code> in its path,
-it verifies that the package doing the import
-is within the tree rooted at the parent of the <code>internal</code> directory.
-For example, a package <code>.../a/b/c/internal/d/e/f</code>
-can be imported only by code in the directory tree rooted at <code>.../a/b/c</code>.
-It cannot be imported by code in <code>.../a/b/g</code> or in any other repository.
-</p>
-
-<p>
-For Go 1.4, the internal package mechanism is enforced for the main Go repository;
-from 1.5 and onward it will be enforced for any repository.
-</p>
-
-<p>
-Full details of the mechanism are in
-<a href="https://golang.org/s/go14internal">the design document</a>.
-</p>
-
-<h3 id="canonicalimports">Canonical import paths</h3>
-
-<p>
-Code often lives in repositories hosted by public services such as <code>github.com</code>,
-meaning that the import paths for packages begin with the name of the hosting service,
-<code>github.com/rsc/pdf</code> for example.
-One can use
-<a href="/cmd/go/#hdr-Remote_import_paths">an existing mechanism</a>
-to provide a "custom" or "vanity" import path such as
-<code>rsc.io/pdf</code>, but
-that creates two valid import paths for the package.
-That is a problem: one may inadvertently import the package through the two
-distinct paths in a single program, which is wasteful;
-miss an update to a package because the path being used is not recognized to be
-out of date;
-or break clients using the old path by moving the package to a different hosting service.
-</p>
-
-<p>
-Go 1.4 introduces an annotation for package clauses in Go source that identify a canonical
-import path for the package.
-If an import is attempted using a path that is not canonical,
-the <a href="/cmd/go/"><code>go</code></a> command
-will refuse to compile the importing package.
-</p>
-
-<p>
-The syntax is simple: put an identifying comment on the package line.
-For our example, the package clause would read:
-</p>
-
-<pre>
-package pdf // import "rsc.io/pdf"
-</pre>
-
-<p>
-With this in place,
-the <code>go</code> command will
-refuse to compile a package that imports <code>github.com/rsc/pdf</code>, 
-ensuring that the code can be moved without breaking users.
-</p>
-
-<p>
-The check is at build time, not download time, so if <code>go</code> <code>get</code>
-fails because of this check, the mis-imported package has been copied to the local machine
-and should be removed manually.
-</p>
-
-<p>
-To complement this new feature, a check has been added at update time to verify
-that the local package's remote repository matches that of its custom import.
-The <code>go</code> <code>get</code> <code>-u</code> command will fail to
-update a package if its remote repository has changed since it was first
-downloaded.
-The new <code>-f</code> flag overrides this check.
-</p>
-
-<p>
-Further information is in
-<a href="https://golang.org/s/go14customimport">the design document</a>.
-</p>
-
-<h3 id="subrepo">Import paths for the subrepositories</h3>
-
-<p>
-The Go project subrepositories (<code>code.google.com/p/go.tools</code> and so on)
-are now available under custom import paths replacing <code>code.google.com/p/go.</code> with <code>golang.org/x/</code>,
-as in <code>golang.org/x/tools</code>.
-We will add canonical import comments to the code around June 1, 2015,
-at which point Go 1.4 and later will stop accepting the old <code>code.google.com</code> paths.
-</p>
-
-<p>
-<em>Updating</em>: All code that imports from subrepositories should change
-to use the new <code>golang.org</code> paths.
-Go 1.0 and later can resolve and import the new paths, so updating will not break
-compatibility with older releases.
-Code that has not updated will stop compiling with Go 1.4 around June 1, 2015.
-</p>
-
-<h3 id="gogenerate">The go generate subcommand</h3>
-
-<p>
-The <a href="/cmd/go/"><code>go</code></a> command has a new subcommand,
-<a href="/cmd/go/#hdr-Generate_Go_files_by_processing_source"><code>go generate</code></a>,
-to automate the running of tools to generate source code before compilation.
-For example, it can be used to run the <a href="/cmd/yacc"><code>yacc</code></a>
-compiler-compiler on a <code>.y</code> file to produce the Go source file implementing the grammar,
-or to automate the generation of <code>String</code> methods for typed constants using the new
-<a href="http://godoc.org/golang.org/x/tools/cmd/stringer">stringer</a>
-tool in the <code>golang.org/x/tools</code> subrepository.
-</p>
-
-<p>
-For more information, see the 
-<a href="https://golang.org/s/go1.4-generate">design document</a>.
-</p>
-
-<h3 id="filenames">Change to file name handling</h3>
-
-<p>
-Build constraints, also known as build tags, control compilation by including or excluding files
-(see the documentation <a href="/pkg/go/build/"><code>/go/build</code></a>).
-Compilation can also be controlled by the name of the file itself by "tagging" the file with
-a suffix (before the <code>.go</code> or <code>.s</code> extension) with an underscore
-and the name of the architecture or operating system.
-For instance, the file <code>gopher_arm.go</code> will only be compiled if the target
-processor is an ARM.
-</p>
-
-<p>
-Before Go 1.4, a file called just <code>arm.go</code> was similarly tagged, but this behavior
-can break sources when new architectures are added, causing files to suddenly become tagged.
-In 1.4, therefore, a file will be tagged in this manner only if the tag (architecture or operating
-system name) is preceded by an underscore.
-</p>
-
-<p>
-<em>Updating</em>: Packages that depend on the old behavior will no longer compile correctly.
-Files with names like <code>windows.go</code> or <code>amd64.go</code> should either
-have explicit build tags added to the source or be renamed to something like
-<code>os_windows.go</code> or <code>support_amd64.go</code>.
-</p>
-
-<h3 id="gocmd">Other changes to the go command</h3>
-
-<p>
-There were a number of minor changes to the
-<a href="/cmd/go/"><code>cmd/go</code></a>
-command worth noting.
-</p>
-
-<ul>
-
-<li>
-Unless <a href="/cmd/cgo/"><code>cgo</code></a> is being used to build the package,
-the <code>go</code> command now refuses to compile C source files,
-since the relevant C compilers
-(<a href="/cmd/6c/"><code>6c</code></a> etc.)
-are intended to be removed from the installation in some future release.
-(They are used today only to build part of the runtime.)
-It is difficult to use them correctly in any case, so any extant uses are likely incorrect,
-so we have disabled them.
-</li>
-
-<li>
-The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
-subcommand has a new flag, <code>-o</code>, to set the name of the resulting binary,
-corresponding to the same flag in other subcommands.
-The non-functional <code>-file</code> flag has been removed.
-</li>
-
-<li>
-The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
-subcommand will compile and link all <code>*_test.go</code> files in the package,
-even when there are no <code>Test</code> functions in them. 
-It previously ignored such files.
-</li>
-
-<li>
-The behavior of the
-<a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>build</code></a>
-subcommand's
-<code>-a</code> flag has been changed for non-development installations.
-For installations running a released distribution, the <code>-a</code> flag will no longer
-rebuild the standard library and commands, to avoid overwriting the installation's files.
-</li>
-
-</ul>
-
-<h3 id="pkg">Changes to package source layout</h3>
-
-<p>
-In the main Go source repository, the source code for the packages was kept in
-the directory <code>src/pkg</code>, which made sense but differed from
-other repositories, including the Go subrepositories.
-In Go 1.4, the<code> pkg</code> level of the source tree is now gone, so for example
-the <a href="/pkg/fmt/"><code>fmt</code></a> package's source, once kept in
-directory <code>src/pkg/fmt</code>, now lives one level higher in <code>src/fmt</code>.
-</p>
-
-<p>
-<em>Updating</em>: Tools like <code>godoc</code> that discover source code
-need to know about the new location. All tools and services maintained by the Go team
-have been updated.
-</p>
-
-
-<h3 id="swig">SWIG</h3>
-
-<p>
-Due to runtime changes in this release, Go 1.4 requires SWIG 3.0.3.
-</p>
-
-<h3 id="misc">Miscellany</h3>
-
-<p>
-The standard repository's top-level <code>misc</code> directory used to contain
-Go support for editors and IDEs: plugins, initialization scripts and so on.
-Maintaining these was becoming time-consuming
-and needed external help because many of the editors listed were not used by
-members of the core team.
-It also required us to make decisions about which plugin was best for a given
-editor, even for editors we do not use.
-</p>
-
-<p>
-The Go community at large is much better suited to managing this information.
-In Go 1.4, therefore, this support has been removed from the repository.
-Instead, there is a curated, informative list of what's available on
-a <a href="//golang.org/wiki/IDEsAndTextEditorPlugins">wiki page</a>.
-</p>
-
-<h2 id="performance">Performance</h2>
-
-<p>
-Most programs will run about the same speed or slightly faster in 1.4 than in 1.3;
-some will be slightly slower.
-There are many changes, making it hard to be precise about what to expect.
-</p>
-
-<p>
-As mentioned above, much of the runtime was translated to Go from C,
-which led to some reduction in heap sizes.
-It also improved performance slightly because the Go compiler is better
-at optimization, due to things like inlining, than the C compiler used to build
-the runtime.
-</p>
-
-<p>
-The garbage collector was sped up, leading to measurable improvements for
-garbage-heavy programs.
-On the other hand, the new write barriers slow things down again, typically
-by about the same amount but, depending on their behavior, some programs
-may be somewhat slower or faster.
-</p>
-
-<p>
-Library changes that affect performance are documented below.
-</p>
-
-<h2 id="library">Changes to the standard library</h2>
-
-<h3 id="new_packages">New packages</h3>
-
-<p>
-There are no new packages in this release.
-</p>
-
-<h3 id="major_library_changes">Major changes to the library</h3>
-
-<h4 id="scanner">bufio.Scanner</h4>
-
-<p>
-The <a href="/pkg/bufio/#Scanner"><code>Scanner</code></a> type in the
-<a href="/pkg/bufio/"><code>bufio</code></a> package
-has had a bug fixed that may require changes to custom
-<a href="/pkg/bufio/#SplitFunc"><code>split functions</code></a>. 
-The bug made it impossible to generate an empty token at EOF; the fix
-changes the end conditions seen by the split function.
-Previously, scanning stopped at EOF if there was no more data.
-As of 1.4, the split function will be called once at EOF after input is exhausted,
-so the split function can generate a final empty token
-as the documentation already promised.
-</p>
-
-<p>
-<em>Updating</em>: Custom split functions may need to be modified to
-handle empty tokens at EOF as desired.
-</p>
-
-<h4 id="syscall">syscall</h4>
-
-<p>
-The <a href="/pkg/syscall/"><code>syscall</code></a> package is now frozen except
-for changes needed to maintain the core repository.
-In particular, it will no longer be extended to support new or different system calls
-that are not used by the core.
-The reasons are described at length in <a href="https://golang.org/s/go1.4-syscall">a
-separate document</a>.
-</p>
-
-<p>
-A new subrepository, <a href="https://golang.org/x/sys">golang.org/x/sys</a>,
-has been created to serve as the location for new developments to support system
-calls on all kernels.
-It has a nicer structure, with three packages that each hold the implementation of
-system calls for one of
-<a href="http://godoc.org/golang.org/x/sys/unix">Unix</a>,
-<a href="http://godoc.org/golang.org/x/sys/windows">Windows</a> and
-<a href="http://godoc.org/golang.org/x/sys/plan9">Plan 9</a>.
-These packages will be curated more generously, accepting all reasonable changes
-that reflect kernel interfaces in those operating systems.
-See the documentation and the article mentioned above for more information.
-</p>
-
-<p>
-<em>Updating</em>: Existing programs are not affected as the <code>syscall</code>
-package is largely unchanged from the 1.3 release.
-Future development that requires system calls not in the <code>syscall</code> package
-should build on <code>golang.org/x/sys</code> instead.
-</p>
-
-<h3 id="minor_library_changes">Minor changes to the library</h3>
-
-<p>
-The following list summarizes a number of minor changes to the library, mostly additions.
-See the relevant package documentation for more information about each change.
-</p>
-
-<ul>
-
-<li>
-The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package's
-<a href="/pkg/archive/zip/#Writer"><code>Writer</code></a> now supports a
-<a href="/pkg/archive/zip/#Writer.Flush"><code>Flush</code></a> method.
-</li>
-
-<li>
-The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>,
-<a href="/pkg/compress/gzip/"><code>compress/gzip</code></a>,
-and <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a>
-packages now support a <code>Reset</code> method
-for the decompressors, allowing them to reuse buffers and improve performance.
-The <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a> package also has a
-<a href="/pkg/compress/gzip/#Reader.Multistream"><code>Multistream</code></a> method to control support
-for multistream files.
-</li>
-
-<li>
-The <a href="/pkg/crypto/"><code>crypto</code></a> package now has a
-<a href="/pkg/crypto/#Signer"><code>Signer</code></a> interface, implemented by the
-<code>PrivateKey</code> types in
-<a href="/pkg/crypto/ecdsa"><code>crypto/ecdsa</code></a> and
-<a href="/pkg/crypto/rsa"><code>crypto/rsa</code></a>.
-</li>
-
-<li>
-The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
-now supports ALPN as defined in <a href="http://tools.ietf.org/html/rfc7301">RFC 7301</a>.
-</li>
-
-<li>
-The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
-now supports programmatic selection of server certificates
-through the new <a href="/pkg/crypto/tls/#Config.CertificateForName"><code>CertificateForName</code></a> function
-of the <a href="/pkg/crypo/tls/#Config"><code>Config</code></a> struct.
-</li>
-
-<li>
-Also in the crypto/tls package, the server now supports 
-<a href="https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00">TLS_FALLBACK_SCSV</a>
-to help clients detect fallback attacks.
-(The Go client does not support fallback at all, so it is not vulnerable to
-those attacks.)
-</li>
-
-<li>
-The <a href="/pkg/database/sql/"><code>database/sql</code></a> package can now list all registered
-<a href="/pkg/database/sql/#Drivers"><code>Drivers</code></a>.
-</li>
-
-<li>
-The <a href="/pkg/debug/dwarf/"><code>debug/dwarf</code></a> package now supports
-<a href="/pkg/debug/dwarf/#UnspecifiedType"><code>UnspecifiedType</code></a>s.
-</li>
-
-<li>
-In the <a href="/pkg/encoding/asn1/"><code>encoding/asn1</code></a> package,
-optional elements with a default value will now only be omitted if they have that value.
-</li>
-
-<li>
-The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package no longer
-quotes empty strings but does quote the end-of-data marker <code>\.</code> (backslash dot).
-This is permitted by the definition of CSV and allows it to work better with Postgres.
-</li>
-
-<li>
-The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package has been rewritten to eliminate
-the use of unsafe operations, allowing it to be used in environments that do not permit use of the
-<a href="/pkg/unsafe/"><code>unsafe</code></a> package.
-For typical uses it will be 10-30% slower, but the delta is dependent on the type of the data and
-in some cases, especially involving arrays, it can be faster.
-There is no functional change.
-</li>
-
-<li>
-The <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a> package's
-<a href="/pkg/encoding/xml/#Decoder"><code>Decoder</code></a> can now report its input offset.
-</li>
-
-<li>
-In the <a href="/pkg/fmt/"><code>fmt</code></a> package,
-formatting of pointers to maps has changed to be consistent with that of pointers
-to structs, arrays, and so on.
-For instance, <code>&amp;map[string]int{"one":</code> <code>1}</code> now prints by default as
-<code>&amp;map[one:</code> <code>1]</code> rather than as a hexadecimal pointer value.
-</li>
-
-<li>
-The <a href="/pkg/image/"><code>image</code></a> package's
-<a href="/pkg/image/#Image"><code>Image</code></a>
-implementations like
-<a href="/pkg/image/#RGBA"><code>RGBA</code></a> and
-<a href="/pkg/image/#Gray"><code>Gray</code></a> have specialized
-<a href="/pkg/image/#RGBA.RGBAAt"><code>RGBAAt</code></a> and
-<a href="/pkg/image/#Gray.GrayAt"><code>GrayAt</code></a> methods alongside the general
-<a href="/pkg/image/#Image.At"><code>At</code></a> method.
-</li>
-
-<li>
-The <a href="/pkg/image/png/"><code>image/png</code></a> package now has an
-<a href="/pkg/image/png/#Encoder"><code>Encoder</code></a>
-type to control the compression level used for encoding.
-</li>
-
-<li>
-The <a href="/pkg/math/"><code>math</code></a> package now has a
-<a href="/pkg/math/#Nextafter32"><code>Nextafter32</code><a/> function.
-</li>
-
-<li>
-The <a href="/pkg/net/http/"><code>net/http</code></a> package's
-<a href="/pkg/net/http/#Request"><code>Request</code></a> type
-has a new <a href="/pkg/net/http/#Request.BasicAuth"><code>BasicAuth</code></a> method
-that returns the username and password from authenticated requests using the
-HTTP Basic Authentication
-Scheme.
-</li>
-
-<li>The <a href="/pkg/net/http/"><code>net/http</code></a> package's
-<a href="/pkg/net/http/#Request"><code>Transport</code></a> type
-has a new <a href="/pkg/net/http/#Transport.DialTLS"><code>DialTLS</code></a> hook
-that allows customizing the behavior of outbound TLS connections.
-</li>
-
-<li>
-The <a href="/pkg/net/http/httputil/"><code>net/http/httputil</code></a> package's
-<a href="/pkg/net/http/httputil/#ReverseProxy"><code>ReverseProxy</code></a> type
-has a new field,
-<a href="/pkg/net/http/#ReverseProxy.ErrorLog"><code>ErrorLog</code></a>, that
-provides user control of logging.
-</li>
-
-<li>
-The <a href="/pkg/os/"><code>os</code></a> package
-now implements symbolic links on the Windows operating system
-through the <a href="/pkg/os/#Symlink"><code>Symlink</code></a> function.
-Other operating systems already have this functionality.
-There is also a new <a href="/pkg/os/#Unsetenv"><code>Unsetenv</code></a> function.
-</li>
-
-<li>
-The <a href="/pkg/reflect/"><code>reflect</code></a> package's
-<a href="/pkg/reflect/#Type"><code>Type</code></a> interface
-has a new method, <a href="/pkg/reflect/#type.Comparable"><code>Comparable</code></a>,
-that reports whether the type implements general comparisons.
-</li>
-
-<li>
-Also in the <a href="/pkg/reflect/"><code>reflect</code></a> package, the
-<a href="/pkg/reflect/#Value"><code>Value</code></a> interface is now three instead of four words
-because of changes to the implementation of interfaces in the runtime.
-This saves memory but has no semantic effect.
-</li>
-
-<li>
-The <a href="/pkg/runtime/"><code>runtime</code></a> package
-now implements monotonic clocks on Windows,
-as it already did for the other systems.
-</li>
-
-<li>
-The <a href="/pkg/runtime/"><code>runtime</code></a> package's
-<a href="/pkg/runtime/#MemStats.Mallocs"><code>Mallocs</code></a> counter
-now counts very small allocations that were missed in Go 1.3.
-This may break tests using <a href="/pkg/runtime/#ReadMemStats"><code>ReadMemStats</code></a>
-or <a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a>
-due to the more accurate answer.
-</li>
-
-<li>
-In the <a href="/pkg/runtime/"><code>runtime</code></a> package,
-an array <a href="/pkg/runtime/#MemStats.PauseEnd"><code>PauseEnd</code></a>
-has been added to the
-<a href="/pkg/runtime/#MemStats"><code>MemStats</code></a>
-and <a href="/pkg/runtime/#GCStats"><code>GCStats</code></a> structs.
-This array is a circular buffer of times when garbage collection pauses ended.
-The corresponding pause durations are already recorded in
-<a href="/pkg/runtime/#MemStats.PauseNs"><code>PauseNs</code></a>
-</li>
-
-<li>
-The <a href="/pkg/runtime/race/"><code>runtime/race</code></a> package
-now supports FreeBSD, which means the
-<a href="/pkg/cmd/go/"><code>go</code></a> command's <code>-race</code>
-flag now works on FreeBSD.
-</li>
-
-<li>
-The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package
-has a new type, <a href="/pkg/sync/atomic/#Value"><code>Value</code></a>.
-<code>Value</code> provides an efficient mechanism for atomic loads and
-stores of values of arbitrary type.
-</li>
-
-<li>
-In the <a href="/pkg/syscall/"><code>syscall</code></a> package's
-implementation on Linux, the
-<a href="/pkg/syscall/#Setuid"><code>Setuid</code></a>
-and <a href="/pkg/syscall/#Setgid"><code>Setgid</code></a> have been disabled
-because those system calls operate on the calling thread, not the whole process, which is
-different from other platforms and not the expected result.
-</li>
-
-<li>
-The <a href="/pkg/testing/"><code>testing</code></a> package
-has a new facility to provide more control over running a set of tests.
-If the test code contains a function
-<pre>
-func TestMain(m *<a href="/pkg/testing/#M"><code>testing.M</code></a>) 
-</pre>
-
-that function will be called instead of running the tests directly.
-The <code>M</code> struct contains methods to access and run the tests.
-</li>
-
-<li>
-Also in the <a href="/pkg/testing/"><code>testing</code></a> package,
-a new <a href="/pkg/testing/#Coverage"><code>Coverage</code></a>
-function reports the current test coverage fraction,
-enabling individual tests to report how much they are contributing to the
-overall coverage.
-</li>
-
-<li>
-The <a href="/pkg/text/scanner/"><code>text/scanner</code></a> package's
-<a href="/pkg/text/scanner/#Scanner"><code>Scanner</code></a> type
-has a new function,
-<a href="/pkg/text/scanner/#Scanner.IsIdentRune"><code>IsIdentRune</code></a>,
-allowing one to control the definition of an identifier when scanning.
-</li>
-
-<li>
-The <a href="/pkg/text/template/"><code>text/template</code></a> package's boolean
-functions <code>eq</code>, <code>lt</code>, and so on have been generalized to allow comparison
-of signed and unsigned integers, simplifying their use in practice.
-(Previously one could only compare values of the same signedness.)
-All negative values compare less than all unsigned values.
-</li>
-
-<li>
-The <code>time</code> package now uses the standard symbol for the micro prefix,
-the micro symbol (U+00B5 'µ'), to print microsecond durations.
-<a href="/pkg/time/#ParseDuration"><code>ParseDuration</code></a> still accepts <code>us</code>
-but the package no longer prints microseconds as <code>us</code>.
-<br>
-<em>Updating</em>: Code that depends on the output format of durations
-but does not use ParseDuration will need to be updated.
-</li>
-
-</ul>
--- a/doc/go1.5.txt
+++ b/doc/go1.5.txt
@@ -1,55 +0,0 @@
-Overall:
-
-build: Go 1.4 required to build (https://golang.org/cl/2470, https://golang.org/cl/2993)
-
-New Ports:
-Darwin/ARM, a.k.a iOS. (https://golang.org/cl/2118, 2119, 3273, 2121, 2122, ..., 2127)
-
-API additions and behavior changes:
-
-bufio: add Reader.Discard (https://golang.org/cl/2260)
-crypto/cipher: clarify what will happen if len(src) != len(dst) for the Stream interface. (https://golang.org/cl/1754)
-crypto/elliptic: add Name field to CurveParams struct (https://golang.org/cl/2133)
-crypto/tls: change default minimum version to TLS 1.0. (https://golang.org/cl/1791)
-encoding/base64: add unpadded encodings (https://golang.org/cl/1511)
-log: add SetOutput functions (https://golang.org/cl/2686, https://golang.org/cl/3023)
-net/http: support for setting trailers from a server Handler (https://golang.org/cl/2157)
-net/http/cgi: fix REMOTE_ADDR, REMOTE_HOST, add REMOTE_PORT (https://golang.org/cl/4933)
-net/smtp: add TLSConnectionState accessor (https://golang.org/cl/2151)
-os/signal: add Ignore and Reset (https://golang.org/cl/3580)
-runtime, syscall: use SYSCALL instruction on FreeBSD (Go 1.5 now requires FreeBSD 8-STABLE+) (https://golang.org/cl/3020)
-strings: add Compare(x, y string) int, for symmetry with bytes.Compare (https://golang.org/cl/2828)
-testing/quick: support generation of arrays (https://golang.org/cl/3865)
-
-Tools:
-
-cmd/go: std wildcard now excludes commands in main repo (https://golang.org/cl/5550)
-cmd/vet: better validation of struct tags (https://golang.org/cl/2685)
-cmd/ld: no longer record build timestamp in Windows PE file header (https://golang.org/cl/3740)
-
-Performance:
-
-cmd/gc: optimize memclr of slices and arrays (https://golang.org/cl/2520)
-sort: number of Sort performance optimizations (https://golang.org/cl/2100, https://golang.org/cl/2614, ...)
-strconv: optimize decimal to string conversion (https://golang.org/cl/2105)
-math/big: faster assembly kernels for amd64 and 386 (https://golang.org/cl/2503, https://golang.org/cl/2560)
-math/big: faster "pure Go" kernels for platforms w/o assembly kernels (https://golang.org/cl/2480)
-
-Assembler:
-
-ARM assembly syntax has had some features removed.
-
-	- mentioning SP or PC as a hardware register
-		These are always pseudo-registers except that in some contexts
-		they're not, and it's confusing because the context should not affect
-		which register you mean. Change the references to the hardware
-		registers to be explicit: R13 for SP, R15 for PC.
-	- constant creation using assignment
-		The files say a=b when they could instead say #define a b.
-		There is no reason to have both mechanisms.
-	- R(0) to refer to R0.
-		Some macros use this to a great extent. Again, it's easy just to
-		use a #define to rename a register.
-	
-Also expression evaluation now uses uint64s instead of signed integers and the
-precedence of operators is now Go-like rather than C-like.
--- a/doc/go1.html
+++ b/doc/go1.html
@@ -1,6 +1,5 @@
 <!--{
 	"Title": "Go 1 Release Notes",
-	"Path":  "/doc/go1",
 	"Template": true
 }-->

@@ -486,7 +485,7 @@ into subdirectories. For instance, <code>utf8</code> and
 <code>utf16</code> now occupy subdirectories of <code>unicode</code>.
 Also, <a href="#subrepo">some packages</a> have moved into
 subrepositories of
-<a href="//code.google.com/p/go"><code>code.google.com/p/go</code></a>
+<a href="http://code.google.com/p/go"><code>code.google.com/p/go</code></a>
 while <a href="#deleted">others</a> have been deleted outright.
 </p>

@@ -565,7 +564,7 @@ by hand.
 <p>
 Because they are not standardized, the packages under the <code>exp</code> directory will not be available in the
 standard Go 1 release distributions, although they will be available in source code form
-in <a href="//code.google.com/p/go/">the repository</a> for
+in <a href="http://code.google.com/p/go/">the repository</a> for
 developers who wish to use them.
 </p>

@@ -619,6 +618,8 @@ The packages in their new locations are:

 <ul>
 <li><code>old/netchan</code></li>
+<li><code>old/regexp</code></li>
+<li><code>old/template</code></li>
 </ul>

 <p>
@@ -638,8 +639,6 @@ Go 1 deletes several packages outright:
 <li><code>container/vector</code></li>
 <li><code>exp/datafmt</code></li>
 <li><code>go/typechecker</code></li>
-<li><code>old/regexp</code></li>
-<li><code>old/template</code></li>
 <li><code>try</code></li>
 </ul>

@@ -651,7 +650,7 @@ and also the command <code>gotry</code>.
 <em>Updating</em>:
 Code that uses <code>container/vector</code> should be updated to use
 slices directly.  See
-<a href="//code.google.com/p/go-wiki/wiki/SliceTricks">the Go
+<a href="http://code.google.com/p/go-wiki/wiki/SliceTricks">the Go
 Language Community Wiki</a> for some suggestions.
 Code that uses the other packages (there should be almost zero) will need to be rethought.
 </p>
@@ -660,7 +659,7 @@ Code that uses the other packages (there should be almost zero) will need to be

 <p>
 Go 1 has moved a number of packages into other repositories, usually sub-repositories of
-<a href="//code.google.com/p/go/">the main Go repository</a>.
+<a href="http://code.google.com/p/go/">the main Go repository</a>.
 This table lists the old and new import paths:

 <table class="codetable" frame="border" summary="Sub-repositories">
@@ -999,9 +998,9 @@ Running <code>go</code> <code>fix</code> will perform the needed changes.
 <p>
 In Go 1, the
 <a href="/pkg/crypto/x509/#CreateCertificate"><code>CreateCertificate</code></a>
-function and
-<a href="/pkg/crypto/x509/#Certificate.CreateCRL"><code>CreateCRL</code></a>
-method in <code>crypto/x509</code> have been altered to take an
+and
+<a href="/pkg/crypto/x509/#CreateCRL"><code>CreateCRL</code></a>
+functions in <code>crypto/x509</code> have been altered to take an
 <code>interface{}</code> where they previously took a <code>*rsa.PublicKey</code>
 or <code>*rsa.PrivateKey</code>. This will allow other public key algorithms
 to be implemented in the future.
@@ -1184,7 +1183,7 @@ if set to <a href="/pkg/go/doc/#AllDecls"><code>AllDecls</code></a>, all declara
 (not just exported ones) are considered.
 The function <code>NewFileDoc</code> was removed, and the function
 <code>CommentText</code> has become the method
-<a href="/pkg/go/ast/#CommentGroup.Text"><code>Text</code></a> of
+<a href="/pkg/go/ast/#Text"><code>Text</code></a> of
 <a href="/pkg/go/ast/#CommentGroup"><code>ast.CommentGroup</code></a>.
 </p>

@@ -1498,7 +1497,7 @@ to test common error properties, plus a few new error values
 with more Go-like names, such as
 <a href="/pkg/os/#ErrPermission"><code>ErrPermission</code></a>
 and
-<a href="/pkg/os/#ErrNotExist"><code>ErrNotExist</code></a>.
+<a href="/pkg/os/#ErrNoEnv"><code>ErrNoEnv</code></a>.
 </p>

 <p>
@@ -1677,7 +1676,7 @@ instead of a <code>Visitor</code> interface value.
 The <code>WalkFunc</code> function will be called even for files or directories that could not be opened;
 in such cases the error argument will describe the failure.
 If a directory's contents are to be skipped,
-the function should return the value <a href="/pkg/path/filepath/#pkg-variables"><code>filepath.SkipDir</code></a>
+the function should return the value <a href="/pkg/path/filepath/#variables"><code>filepath.SkipDir</code></a>
 </p>

 {{code "/doc/progs/go1.go" `/STARTWALK/` `/ENDWALK/`}}
@@ -1695,7 +1694,7 @@ The compiler will catch code using the old interface.
 The <a href="/pkg/regexp/"><code>regexp</code></a> package has been rewritten.
 It has the same interface but the specification of the regular expressions
 it supports has changed from the old "egrep" form to that of
-<a href="//code.google.com/p/re2/">RE2</a>.
+<a href="http://code.google.com/p/re2/">RE2</a>.
 </p>

 <p>
@@ -1866,7 +1865,7 @@ made easier with the new structure of the packages.
 The imports will be updated by fix tool.
 Single-template uses will be otherwise be largely unaffected.
 Code that uses multiple templates in concert will need to be updated by hand.
-The <a href="/pkg/text/template/#pkg-examples">examples</a> in
+The <a href="/pkg/text/template/#examples">examples</a> in
 the documentation for <code>text/template</code> can provide guidance.
 </p>

@@ -1912,7 +1911,7 @@ package <a href="/pkg/reflect/"><code>reflect</code></a>.
 <em>Updating</em>:
 Code using these functions must be rewritten to use
 package <a href="/pkg/reflect/"><code>reflect</code></a>.
-The changes to <a href="//golang.org/change/2646dc956207">encoding/gob</a> and the <a href="//code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
+The changes to <a href="http://code.google.com/p/go/source/detail?r=2646dc956207">encoding/gob</a> and the <a href="http://code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
 may be helpful as examples.
 </p>

@@ -2035,4 +2034,4 @@ They are available for many combinations of architecture and operating system
 Installation details are described on the
 <a href="/doc/install">Getting Started</a> page, while
 the distributions themselves are listed on the
-<a href="https://golang.org/dl/">downloads page</a>.
+<a href="http://code.google.com/p/go/downloads/list">downloads page</a>.
--- a/doc/go1compat.html
+++ b/doc/go1compat.html
@@ -1,6 +1,5 @@
 <!--{
-	"Title": "Go 1 and the Future of Go Programs",
-	"Path":  "/doc/go1compat"
+	"Title": "Go 1 and the Future of Go Programs"
 }-->

 <h2 id="introduction">Introduction</h2>
@@ -83,16 +82,16 @@ break if the bug is fixed. We reserve the right to fix such bugs.
 <li>
 Struct literals. For the addition of features in later point
 releases, it may be necessary to add fields to exported structs in
-the API. Code that uses unkeyed struct literals (such as pkg.T{3,
+the API. Code that uses untagged struct literals (such as pkg.T{3,
 "x"}) to create values of these types would fail to compile after
-such a change. However, code that uses keyed literals (pkg.T{A:
+such a change. However, code that uses tagged literals (pkg.T{A:
 3, B: "x"}) will continue to compile after such a change. We will
-update such data structures in a way that allows keyed struct
-literals to remain compatible, although unkeyed literals may fail
+update such data structures in a way that allows tagged struct
+literals to remain compatible, although untagged literals may fail
 to compile. (There are also more intricate cases involving nested
 data structures or interfaces, but they have the same resolution.)
 We therefore recommend that composite literals whose type is defined
-in a separate package should use the keyed notation.
+in a separate package should use the tagged notation.
 </li>

 <li>
@@ -104,14 +103,6 @@ outside of tests, and using it may cause a program to fail
 to compile in future releases.
 </li>

-<li>
-Use of package <code>unsafe</code>. Packages that import
-<a href="/pkg/unsafe/"><code>unsafe</code></a>
-may depend on internal properties of the Go implementation.
-We reserve the right to make changes to the implementation
-that may break such programs.
-</li>
-
 </ul>

 <p>
@@ -153,28 +144,13 @@ developed software based on Go 1.

 <p>
 Code in sub-repositories of the main go tree, such as
-<a href="//golang.org/x/net">golang.org/x/net</a>,
+<a href="http://code.google.com/p/go.net">code.google.com/p/go.net</a>,
 may be developed under
 looser compatibility requirements. However, the sub-repositories
 will be tagged as appropriate to identify versions that are compatible
 with the Go 1 point releases.
 </p>

-<h2 id="operating_systems">Operating systems</h2>
-
-<p>
-It is impossible to guarantee long-term compatibility with operating
-system interfaces, which are changed by outside parties.
-The <a href="/pkg/syscall/"><code>syscall</code></a> package
-is therefore outside the purview of the guarantees made here.
-As of Go version 1.4, the <code>syscall</code> package is frozen.
-Any evolution of the system call interface must be supported elsewhere,
-such as in the
-<a href="//golang.org/x/sys">go.sys</a> subrepository.
-For details and background, see
-<a href="//golang.org/s/go1.4-syscall">this document</a>.
-</p>
-
 <h2 id="tools">Tools</h2>

 <p>
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -1,6 +1,5 @@
 <!--{
-	"Title": "Frequently Asked Questions (FAQ)",
-	"Path": "/doc/faq"
+	"Title": "FAQ"
 }-->

 <h2 id="Origins">Origins</h2>
@@ -55,18 +54,13 @@ By its design, Go proposes an approach for the construction of system
 software on multicore machines.
 </ul>

-<p>
-A much more expansive answer to this question is available in the article,
-<a href="//talks.golang.org/2012/splash.article">Go at Google:
-Language Design in the Service of Software Engineering</a>.
-
 <h3 id="What_is_the_status_of_the_project">
 What is the status of the project?</h3>

 <p>
 Go became a public open source project on November 10, 2009.
 After a couple of years of very active design and development, stability was called for and
-Go 1 was <a href="//blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
+Go 1 was <a href="http://blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
 on March 28, 2012.
 Go 1, which includes a <a href="/ref/spec">language specification</a>,
 <a href="/pkg/">standard libraries</a>,
@@ -162,12 +156,6 @@ and so on.  These cannot be addressed well by libraries or tools; a new
 language was called for.
 </p>

-<p>
-The article <a href="//talks.golang.org/2012/splash.article">Go at Google</a>
-discusses the background and motivation behind the design of the Go language,
-as well as providing more detail about many of the answers presented in this FAQ.
-</p>
-
 <h3 id="ancestors">
 What are Go's ancestors?</h3>
 <p>
@@ -219,21 +207,14 @@ easier to understand what happens when things combine.
 <h3 id="Is_Google_using_go_internally"> Is Google using Go internally?</h3>

 <p>
-Yes. There are now several Go programs deployed in
+Yes. There are now several Go programs deployed in 
 production inside Google.  A public example is the server behind
-<a href="//golang.org">golang.org</a>.
+<a href="http://golang.org">http://golang.org</a>.
 It's just the <a href="/cmd/godoc"><code>godoc</code></a>
 document server running in a production configuration on
 <a href="https://developers.google.com/appengine/">Google App Engine</a>.
 </p>

-<p>
-Other examples include the <a href="//github.com/youtube/vitess/">Vitess</a>
-system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>,
-which delivers Chrome binaries and other large installables such as <code>apt-get</code>
-packages.
-</p>
-
 <h3 id="Do_Go_programs_link_with_Cpp_programs">
 Do Go programs link with C/C++ programs?</h3>

@@ -242,14 +223,14 @@ There are two Go compiler implementations, <code>gc</code>
 (the <code>6g</code> program and friends) 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.
+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>

 <p>
-The <a href="/cmd/cgo/">cgo</a> program provides the mechanism for a
-&ldquo;foreign function interface&rdquo; to allow safe calling of
+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.
 </p>

@@ -260,7 +241,7 @@ Does Go support Google's protocol buffers?</h3>
 <p>
 A separate open source project provides the necessary compiler plugin and library.
 It is available at
-<a href="//github.com/golang/protobuf">github.com/golang/protobuf/</a>
+<a href="http://code.google.com/p/goprotobuf/">http://code.google.com/p/goprotobuf/</a>
 </p>


@@ -270,9 +251,9 @@ Can I translate the Go home page into another language?</h3>
 <p>
 Absolutely. We encourage developers to make Go Language sites in their own languages.
 However, if you choose to add the Google logo or branding to your site
-(it does not appear on <a href="//golang.org/">golang.org</a>),
+(it does not appear on <a href="http://golang.org/">golang.org</a>),
 you will need to abide by the guidelines at
-<a href="//www.google.com/permissions/guidelines.html">www.google.com/permissions/guidelines.html</a>
+<a href="http://www.google.com/permissions/guidelines.html">http://www.google.com/permissions/guidelines.html</a>
 </p>

 <h2 id="Design">Design</h2>
@@ -412,8 +393,6 @@ 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.
-Experience with several earlier languages has shown that the CSP model
-fits well into a procedural language framework.
 </p>

 <h3 id="goroutines">
@@ -426,20 +405,18 @@ 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: they have little
-overhead beyond the memory for the stack, which is just a few kilobytes.
+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, which is just a few kilobytes.
 </p>

 <p>
-To make the stacks small, Go's run-time uses resizable, bounded stacks.  A newly
+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 grows (and shrinks) the memory for storing
-the stack automatically, allowing many goroutines to live in a modest
-amount of memory.
-The CPU overhead averages about three cheap instructions per function call.
+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
+address space.  If goroutines were just threads, system resources would
 run out at a much smaller number.
 </p>

@@ -448,7 +425,7 @@ 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 goroutines, and in those cases where it did, the map was
+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,
@@ -461,34 +438,6 @@ as when hosting an untrusted program, the implementation could interlock
 map access.
 </p>

-<h3 id="language_changes">
-Will you accept my language change?</h3>
-
-<p>
-People often suggest improvements to the language—the
-<a href="//groups.google.com/group/golang-nuts">mailing list</a>
-contains a rich history of such discussions—but very few of these changes have
-been accepted.
-</p>
-
-<p>
-Although Go is an open source project, the language and libraries are protected
-by a <a href="/doc/go1compat.html">compatibility promise</a> that prevents
-changes that break existing programs.
-If your proposal violates the Go 1 specification we cannot even entertain the
-idea, regardless of its merit.
-A future major release of Go may be incompatible with Go 1, but we're not ready
-to start talking about what that might be.
-</p>
-
-<p>
-Even if your proposal is compatible with the Go 1 spec, it might
-not be in the spirit of Go's design goals.
-The article <i><a href="//talks.golang.org/2012/splash.article">Go
-at Google: Language Design in the Service of Software Engineering</a></i>
-explains Go's origins and the motivation behind its design.
-</p>
-
 <h2 id="types">Types</h2>

 <h3 id="Is_Go_an_object-oriented_language">
@@ -647,7 +596,7 @@ func (b Bar) Foo() {}
 </pre>

 <p>
-Most code doesn't make use of such constraints, since they limit the utility of
+Most code doesn't make use of such constraints, since they limit the utility of 
 the interface idea. Sometimes, though, they're necessary to resolve ambiguities
 among similar interfaces.
 </p>
@@ -708,7 +657,7 @@ A related example goes the other way:

 <pre>
 type Opener interface {
-   Open() Reader
+   Open(name) Reader
 }

 func (t T3) Open() *os.File
@@ -889,11 +838,6 @@ type is generic; if you care about how many bits an integer holds, Go
 encourages you to be explicit.
 </p>

-<p>
-A blog post, title <a href="http://blog.golang.org/constants">Constants</a>,
-explores this topic in more detail.
-</p>
-
 <h3 id="builtin_maps">
 Why are maps built in?</h3>
 <p>
@@ -929,11 +873,11 @@ 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.  Changing these
-types to act as references to the associated, shared data structures resolved
-these issues. This change added some regrettable complexity to the
-language but had a large effect on usability: Go became a more
-productive, comfortable language when it was introduced.
+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>
@@ -945,9 +889,9 @@ How are libraries documented?</h3>
 There is a program, <code>godoc</code>, written in Go, that extracts
 package documentation from the source code. It can be used on the
 command line or on the web. An instance is running at
-<a href="/pkg/">golang.org/pkg/</a>.
+<a href="http://golang.org/pkg/">http://golang.org/pkg/</a>.
 In fact, <code>godoc</code> implements the full site at
-<a href="/">golang.org/</a>.
+<a href="http://golang.org/">http://golang.org/</a>.
 </p>

 <h3 id="Is_there_a_Go_programming_style_guide">
@@ -964,19 +908,11 @@ compendium of do's and don'ts that allows interpretation.
 All the Go code in the repository has been run through <code>gofmt</code>.
 </p>

-<p>
-The document titled
-<a href="//golang.org/s/comments">Go Code Review Comments</a>
-is a collection of very short essays about details of Go idiom that are often
-missed by programmers.
-It is a handy reference for people doing code reviews for Go projects.
-</p>
-
 <h3 id="How_do_I_submit_patches_to_the_Go_libraries">
 How do I submit patches to the Go libraries?</h3>

 <p>
-The library sources are in the <code>src</code> directory of the repository.
+The library sources are in <code>go/src/pkg</code>.
 If you want to make a significant change, please discuss on the mailing list before embarking.
 </p>

@@ -986,67 +922,30 @@ See the document
 for more information about how to proceed.
 </p>

-<h3 id="git_https">
-Why does "go get" use HTTPS when cloning a repository?</h3>
+<h3 id="Why_does_the_project_use_Mercurial_and_not_git">
+Why does the project use Mercurial and not git?</h3>

 <p>
-Companies often permit outgoing traffic only on the standard TCP ports 80 (HTTP)
-and 443 (HTTPS), blocking outgoing traffic on other ports, including TCP port 9418 
-(git) and TCP port 22 (SSH).
-When using HTTPS instead of HTTP, <code>git</code> enforces certificate validation by
-default, providing protection against man-in-the-middle, eavesdropping and tampering attacks.
-The <code>go get</code> command therefore uses HTTPS for safety.
+The Go project, hosted by Google Code at
+<a href="http://code.google.com/p/go">code.google.com/p/go</a>,
+uses Mercurial as its version control system.
+When the project launched,
+Google Code supported only Subversion and Mercurial.
+Mercurial was a better choice because of its plugin mechanism
+that allowed us to create the "codereview" plugin to connect
+the project to the excellent code review tools at 
+<a href="http://codereview.appspot.com">codereview.appspot.com</a>.
 </p>

 <p>
-If you use <code>git</code> and prefer to push changes through SSH using your existing key 
-it's easy to work around this. For GitHub, try one of these solutions:
-</p>
-<ul>
-<li>Manually clone the repository in the expected package directory:
-<pre>
-$ cd $GOPATH/src/github.com/username
-$ git clone git@github.com:username/package.git
-</pre>
-</li>
-<li>Force <code>git push</code> to use the <code>SSH</code> protocol by appending
-these two lines to <code>~/.gitconfig</code>:
-<pre>
-[url "git@github.com:"]
-	pushInsteadOf = https://github.com/
-</pre>
-</li>
-</ul>
-
-<h3 id="get_version">
-How should I manage package versions using "go get"?</h3>
-
-<p>
-"Go get" does not have any explicit concept of package versions.
-Versioning is a source of significant complexity, especially in large code bases,
-and we are unaware of any approach that works well at scale in a large enough
-variety of situations to be appropriate to force on all Go users.
-What "go get" and the larger Go toolchain do provide is isolation of
-packages with different import paths.
-For example, the standard library's <code>html/template</code> and <code>text/template</code>
-coexist even though both are "package template".
-This observation leads to some advice for package authors and package users.
-</p>
-
-<p>
-Packages intended for public use should try to maintain backwards compatibility as they evolve.
-The <a href="/doc/go1compat.html">Go 1 compatibility guidelines</a> are a good reference here:
-don't remove exported names, encourage tagged composite literals, and so on.
-If different functionality is required, add a new name instead of changing an old one.
-If a complete break is required, create a new package with a new import path.</p>
-
-<p>
-If you're using an externally supplied package and worry that it might change in
-unexpected ways, the simplest solution is to copy it to your local repository.
-(This is the approach Google takes internally.)
-Store the copy under a new import path that identifies it as a local copy.
-For example, you might copy "original.com/pkg" to "you.com/external/original.com/pkg".
-Keith Rarick's <a href="https://github.com/kr/goven">goven</a> is one tool to help automate this process.
+Programmers who work
+with the Go project's source rather than release downloads sometimes
+ask for the project to switch to git.
+That would be possible, but it would be a lot of work and
+would also require reimplementing the codereview plugin.
+Given that Mercurial works today, with code review support,
+combined with the Go project's mostly linear, non-branching use of
+version control, a switch to git doesn't seem worthwhile.
 </p>

 <h2 id="Pointers">Pointers and Allocation</h2>
@@ -1071,58 +970,7 @@ 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="pointer_to_interface">
-When should I use a pointer to an interface?</h3>
-
-<p>
-Almost never. Pointers to interface values arise only in rare, tricky situations involving
-disguising an interface value's type for delayed evaluation.
-</p>
-
-<p>
-It is however a common mistake to pass a pointer to an interface value
-to a function expecting an interface. The compiler will complain about this
-error but the situation can still be confusing, because sometimes a
-<a href="#different_method_sets">pointer
-is necessary to satisfy an interface</a>.
-The insight is that although a pointer to a concrete type can satisfy
-an interface, with one exception <em>a pointer to an interface can never satisfy an interface</em>.
-</p>
-
-<p>
-Consider the variable declaration,
-</p>
-
-<pre>
-var w io.Writer
-</pre>
-
-<p>
-The printing function <code>fmt.Fprintf</code> takes as its first argument
-a value that satisfies <code>io.Writer</code>—something that implements
-the canonical <code>Write</code> method. Thus we can write
-</p>
-
-<pre>
-fmt.Fprintf(w, "hello, world\n")
-</pre>
-
-<p>
-If however we pass the address of <code>w</code>, the program will not compile.
-</p>
-
-<pre>
-fmt.Fprintf(&amp;w, "hello, world\n") // Compile-time error.
-</pre>
-
-<p>
-The one exception is that any value, even a pointer to an interface, can be assigned to
-a variable of empty interface type (<code>interface{}</code>).
-Even so, it's almost certainly a mistake if the value is a pointer to an interface;
-the result can be confusing.
+makes a copy of the pointer, but again not the data it points to. 
 </p>

 <h3 id="methods_on_values_or_pointers">
@@ -1148,7 +996,7 @@ There are several considerations.
 First, and most important, does the method need to modify the
 receiver?
 If it does, the receiver <em>must</em> be a pointer.
-(Slices and maps act as references, so their story is a little
+(Slices and maps are reference types, so their story is a little
 more subtle, but for instance to change the length of a slice
 in a method the receiver must still be a pointer.)
 In the examples above, if <code>pointerMethod</code> modifies
@@ -1199,16 +1047,14 @@ of Effective Go</a> for more details.
 </p>

 <h3 id="q_int_sizes">
-What is the size of an <code>int</code> on a 64 bit machine?</h3>
+Why is <code>int</code> 32 bits on 64 bit machines?</h3>

 <p>
 The sizes of <code>int</code> and <code>uint</code> are implementation-specific
 but the same as each other on a given platform.
-For portability, code that relies on a particular
+The 64 bit Go compilers (both gc and gccgo) use a 32 bit representation for
+<code>int</code>.  Code that relies on a particular
 size of value should use an explicitly sized type, like <code>int64</code>.
-Prior to Go 1.1, the 64-bit Go compilers (both gc and gccgo) used
-a 32-bit representation for <code>int</code>. As of Go 1.1 they use
-a 64-bit representation.
 On the other hand, floating-point scalars and complex
 numbers are always sized: <code>float32</code>, <code>complex64</code>,
 etc., because programmers should be aware of precision when using
@@ -1216,6 +1062,12 @@ floating-point numbers.
 The default size of a floating-point constant is <code>float64</code>.
 </p>

+<p>
+At the moment, all implementations use 32-bit ints, an essentially arbitrary decision.
+However, we expect that <code>int</code> will be increased to 64 bits on 64-bit
+architectures in a future release of Go.
+</p>
+
 <h3 id="stack_or_heap">
 How do I know whether a variable is allocated on the heap or the stack?</h3>

@@ -1244,22 +1096,6 @@ analysis</em> recognizes some cases when such variables will not
 live past the return from the function and can reside on the stack.
 </p>

-<h3 id="Why_does_my_Go_process_use_so_much_virtual_memory">
-Why does my Go process use so much virtual memory?</h3>
-
-<p>
-The Go memory allocator reserves a large region of virtual memory as an arena
-for allocations. This virtual memory is local to the specific Go process; the
-reservation does not deprive other processes of memory.
-</p>
-
-<p>
-To find the amount of actual memory allocated to a Go process, use the Unix
-<code>top</code> command and consult the <code>RES</code> (Linux) or
-<code>RSIZE</code> (Mac OS X) columns.
-<!-- TODO(adg): find out how this works on Windows -->
-</p>
-
 <h2 id="Concurrency">Concurrency</h2>

 <h3 id="What_operations_are_atomic_What_about_mutexes">
@@ -1283,7 +1119,7 @@ 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="//blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
+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">
@@ -1293,15 +1129,12 @@ Why doesn't my multi-goroutine program use multiple CPUs?</h3>
 You must set the <code>GOMAXPROCS</code> shell environment variable
 or use the similarly-named <a href="/pkg/runtime/#GOMAXPROCS"><code>function</code></a>
 of the runtime package to allow the
-run-time support to utilize more than one OS thread.
+run-time support to utilize more than one OS thread. 
 </p>

 <p>
 Programs that perform parallel computation should benefit from an increase in
 <code>GOMAXPROCS</code>.
-However, be aware that
-<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
-is not parallelism</a>.
 </p>

 <h3 id="Why_GOMAXPROCS">
@@ -1309,7 +1142,7 @@ Why does using <code>GOMAXPROCS</code> &gt; 1 sometimes make my program
 slower?</h3>

 <p>
-It depends on the nature of your program.
+It depends on the nature of your program. 
 Problems that are intrinsically sequential cannot be sped up by adding
 more goroutines.
 Concurrency only becomes parallelism when the problem is
@@ -1330,16 +1163,11 @@ to speed it up.
 </p>

 <p>
-Go's goroutine scheduler is not as good as it needs to be. In the future, it
+Go's goroutine scheduler is not as good as it needs to be. In future, it
 should recognize such cases and optimize its use of OS threads. For now,
 <code>GOMAXPROCS</code> should be set on a per-application basis.
 </p>

-<p>
-For more detail on this topic see the talk entitled,
-<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
-is not Parallelism</a>.
-
 <h2 id="Functions_methods">Functions and Methods</h2>

 <h3 id="different_method_sets">
@@ -1403,20 +1231,18 @@ func main() {

    // wait for all goroutines to complete before exiting
    for _ = range values {
-        &lt;-done
+        &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
+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 iteration of the loop uses the same instance of the variable <code>v</code>, so
-each closure shares that single variable. When the closure runs, it prints the
+each closure shares that single variable. When the closure runs, it prints the 
 value of <code>v</code> at the time <code>fmt.Println</code> is executed,
-but <code>v</code> may have been modified since the goroutine was launched.
-To help detect this and other problems before they happen, run
-<a href="/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>.
+but <code>v</code> may have been modified since the goroutine was launched. 
 </p>

 <p>
@@ -1435,7 +1261,7 @@ One way is to pass the variable as an argument to the closure:
 </pre>

 <p>
-In this example, the value of <code>v</code> is passed as an argument to the
+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>
@@ -1512,7 +1338,7 @@ builds a test binary, and runs it.

 <p>See the <a href="/doc/code.html">How to Write Go Code</a> document,
 the <a href="/pkg/testing/"><code>testing</code></a> package
-and the <a href="/cmd/go/#hdr-Test_packages"><code>go test</code></a> subcommand for more details.
+and the <a href="/cmd/go/#Test_packages"><code>go test</code></a> subcommand for more details.
 </p>

 <h3 id="testing_framework">
@@ -1550,7 +1376,7 @@ table-driven, iterating over a list of inputs and outputs defined
 in a data structure (Go has excellent support for data structure literals).
 The work to write a good test and good error messages will then be amortized over many
 test cases. The standard Go library is full of illustrative examples, such as in
-<a href="/src/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
+<a href="/src/pkg/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
 </p>


@@ -1560,7 +1386,7 @@ test cases. The standard Go library is full of illustrative examples, such as in
 What compiler technology is used to build the compilers?</h3>

 <p>
-<code>Gccgo</code> has a front end written in C++, with a recursive descent parser coupled to the
+<code>Gccgo</code> has a C++ front-end with a recursive descent parser coupled to the
 standard GCC back end. <code>Gc</code> is written in C using
 <code>yacc</code>/<code>bison</code> for the parser.
 Although it's a new program, it fits in the Plan 9 C compiler suite
@@ -1569,46 +1395,33 @@ and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries.
 </p>

 <p>
-We considered using LLVM for <code>gc</code> but we felt it was too large and
-slow to meet our performance goals.
-</p>
-
-<p>
-We also considered writing <code>gc</code>, the original Go compiler, in Go itself but
+We considered writing <code>gc</code>, the original Go compiler, in Go itself but
 elected not to do so because of the difficulties of bootstrapping and
 especially of open source distribution&mdash;you'd need a Go compiler to
 set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to
-consider writing a compiler in Go.
-A plan to do that by machine translation of the existing compiler is under development.
-<a href="http://golang.org/s/go13compiler">A separate document</a>
-explains the reason for this approach.
+consider writing a compiler in Go, which might well happen. (Go would be a
+fine language in which to implement a compiler; a native lexer and
+parser are already available in the <a href="/pkg/go/"><code>go</code></a> package.)
 </p>

 <p>
-That plan aside,
-Go is a
-fine language in which to implement a self-hosting compiler: a native lexer and
-parser are already available in the <a href="/pkg/go/"><code>go</code></a> package
-and a separate type checking
-<a href="http://godoc.org/golang.org/x/tools/go/types">package</a>
-has also been written.
+We also considered using LLVM for <code>gc</code> but we felt it was too large and
+slow to meet our performance goals.
 </p>

 <h3 id="How_is_the_run_time_support_implemented">
 How is the run-time support implemented?</h3>

 <p>
-Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
-tiny bit of assembler) although much of it has been translated to Go since then
-and one day all of it might be (except for the assembler bits).
-<code>Gccgo</code>'s run-time support uses <code>glibc</code>.
-<code>Gc</code> uses a custom C library to keep the footprint under
+Again due to bootstrapping issues, the run-time code is mostly in C (with a
+tiny bit of assembler) although Go is capable of implementing most of
+it now. <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
+<code>Gc</code> uses a custom library to keep the footprint under
 control; it is
 compiled with a version of the Plan 9 C compiler that supports
-resizable stacks for goroutines.
-The <code>gccgo</code> compiler implements these on Linux only,
-using a technique called segmented stacks,
-supported by recent modifications to the gold linker.
+segmented stacks for goroutines.
+The <code>gccgo</code> compiler implements segmented
+stacks on Linux only, supported by recent modifications to the gold linker.
 </p>

 <h3 id="Why_is_my_trivial_program_such_a_large_binary">
@@ -1626,8 +1439,8 @@ A simple C "hello, world" program compiled and linked statically using gcc
 on Linux is around 750 kB,
 including an implementation of <code>printf</code>.
 An equivalent Go program using <code>fmt.Printf</code>
-is around 1.9 MB, but
-that includes more powerful run-time support and type information.
+is around 1.2 MB, but
+that includes more powerful run-time support.
 </p>

 <h3 id="unused_variables_and_imports">
@@ -1635,19 +1448,16 @@ Can I stop these complaints about my unused variable/import?</h3>

 <p>
 The presence of an unused variable may indicate a bug, while
-unused imports just slow down compilation,
-an effect that can become substantial as a program accumulates
-code and programmers over time.
-For these reasons, Go refuses to compile programs with unused
-variables or imports,
-trading short-term convenience for long-term build speed and
-program clarity.
+unused imports just slow down compilation.
+Accumulate enough unused imports in your code tree and
+things can get very slow.
+For these reasons, Go allows neither.
 </p>

 <p>
-Still, when developing code, it's common to create these situations
+When developing code, it's common to create these situations
 temporarily and it can be annoying to have to edit them out before the
-program will compile.
+program will compile.  
 </p>

 <p>
@@ -1687,14 +1497,6 @@ func main() {
 }
 </pre>

-<p>
-Nowadays, most Go programmers use a tool,
-<a href="http://godoc.org/golang.org/x/tools/cmd/goimports">goimports</a>,
-which automatically rewrites a Go source file to have the correct imports,
-eliminating the unused imports issue in practice.
-This program is easily connected to most editors to run automatically when a Go source file is written.
-</p>
-
 <h2 id="Performance">Performance</h2>

 <h3 id="Why_does_Go_perform_badly_on_benchmark_x">
@@ -1702,13 +1504,13 @@ Why does Go perform badly on benchmark X?</h3>

 <p>
 One of Go's design goals is to approach the performance of C for comparable
-programs, yet on some benchmarks it does quite poorly, including several
-in <a href="/test/bench/shootout/">test/bench/shootout</a>. The slowest depend on libraries
-for which versions of comparable performance are not available in Go.
+programs, yet on some benchmarks it does quite poorly, including several 
+in <a href="/test/bench/shootout/">test/bench/shootout</a>. The slowest depend on libraries 
+for which versions of comparable performance are not available in Go. 
 For instance, <a href="/test/bench/shootout/pidigits.go">pidigits.go</a>
 depends on a multi-precision math package, and the C
 versions, unlike Go's, use <a href="http://gmplib.org/">GMP</a> (which is
-written in optimized assembler).
+written in optimized assembler). 
 Benchmarks that depend on regular expressions
 (<a href="/test/bench/shootout/regex-dna.go">regex-dna.go</a>, for instance) are
 essentially comparing Go's native <a href="/pkg/regexp">regexp package</a> to
@@ -1727,7 +1529,7 @@ indicate.
 <p>
 Still, there is room for improvement. The compilers are good but could be
 better, many libraries need major performance work, and the garbage collector
-isn't fast enough yet. (Even if it were, taking care not to generate unnecessary
+isn't fast enough yet. (Even if it were, taking care not to generate unnecessary 
 garbage can have a huge effect.)
 </p>

@@ -1736,7 +1538,7 @@ In any case, Go can often be very competitive.
 There has been significant improvement in the performance of many programs
 as the language and tools have developed.
 See the blog post about
-<a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
+<a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling
 Go programs</a> for an informative example.

 <h2 id="change_from_c">Changes from C</h2>
@@ -1895,7 +1697,7 @@ considerable control over memory layout and allocation, much more than
 is typical in garbage-collected languages. A careful programmer can reduce
 the garbage collection overhead dramatically by using the language well;
 see the article about
-<a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
+<a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling
 Go programs</a> for a worked example, including a demonstration of Go's
 profiling tools.
 </p>
--- a/doc/go_mem.html
+++ b/doc/go_mem.html
@@ -1,6 +1,6 @@
 <!--{
 	"Title": "The Go Memory Model",
-	"Subtitle": "Version of May 31, 2014",
+	"Subtitle": "Version of March 6, 2012",
 	"Path": "/ref/mem"
 }-->

@@ -21,29 +21,6 @@ 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>Advice</h2>
-
-<p>
-Programs that modify data being simultaneously accessed by multiple goroutines
-must serialize such access.
-</p>
-
-<p>
-To serialize access, protect the data with channel operations or other synchronization primitives
-such as those in the <a href="/pkg/sync/"><code>sync</code></a>
-and <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> packages.
-</p>
-
-<p>
-If you must read the rest of this document to understand the behavior of your program,
-you are being too clever.
-</p>
-
-<p>
-Don't be clever.
-</p>
-
 <h2>Happens Before</h2>

 <p>
@@ -297,41 +274,6 @@ then the program would not be guaranteed to print
 crash, or do something else.)
 </p>

-<p class="rule">
-The <i>k</i>th receive on a channel with capacity <i>C</i> happens before the <i>k</i>+<i>C</i>th send from that channel completes.
-</p>
-
-<p>
-This rule generalizes the previous rule to buffered channels.
-It allows a counting semaphore to be modeled by a buffered channel:
-the number of items in the channel corresponds to the number of active uses,
-the capacity of the channel corresponds to the maximum number of simultaneous uses,
-sending an item acquires the semaphore, and receiving an item releases
-the semaphore.
-This is a common idiom for limiting concurrency.
-</p>
-
-<p>
-This program starts a goroutine for every entry in the work list, but the
-goroutines coordinate using the <code>limit</code> channel to ensure
-that at most three are running work functions at a time.
-</p>
-
-<pre>
-var limit = make(chan int, 3)
-
-func main() {
-	for _, w := range work {
-		go func() {
-			limit <- 1
-			w()
-			<-limit
-		}()
-	}
-	select{}
-}
-</pre>
-
 <h3>Locks</h3>

 <p>
@@ -419,7 +361,7 @@ func twoprint() {

 <p>
 calling <code>twoprint</code> causes <code>"hello, world"</code> to be printed twice.
-The first call to <code>doprint</code> runs <code>setup</code> once.
+The first call to <code>twoprint</code> runs <code>setup</code> once.
 </p>

 <h2>Incorrect synchronization</h2>
--- a/doc/go_spec.html
+++ b/doc/go_spec.html
--- a/doc/godocs.js
+++ b/doc/godocs.js
@@ -0,0 +1,213 @@
+// Except as noted, this content is licensed under Creative Commons
+// Attribution 3.0
+
+/* A little code to ease navigation of these documents.
+ *
+ * On window load we:
+ *  + Generate a table of contents (godocs_generateTOC)
+ *  + Add links up to the top of the doc from each section (godocs_addTopLinks)
+ */
+
+/* We want to do some stuff on page load (after the HTML is rendered).
+   So listen for that:
+ */
+function bindEvent(el, e, fn) {
+  if (el.addEventListener){
+    el.addEventListener(e, fn, false);
+  } else if (el.attachEvent){
+    el.attachEvent('on'+e, fn);
+  }
+}
+
+function godocs_bindSearchEvents() {
+  var search = document.getElementById('search');
+  if (!search) {
+    // no search box (index disabled)
+    return;
+  }
+  function clearInactive() {
+    if (search.className == "inactive") {
+      search.value = "";
+      search.className = "";
+    }
+  }
+  function restoreInactive() {
+    if (search.value !== "") {
+      return;
+    }
+    if (search.type != "search") {
+      search.value = search.getAttribute("placeholder");
+    }
+    search.className = "inactive";
+  }
+  restoreInactive();
+  bindEvent(search, 'focus', clearInactive);
+  bindEvent(search, 'blur', restoreInactive);
+}
+
+/* Returns the "This sweet header" from <h2>This <i>sweet</i> header</h2>.
+ * Takes a node, returns a string.
+ */
+function godocs_nodeToText(node) {
+  var TEXT_NODE = 3; // Defined in Mozilla but not MSIE :(
+
+  var text = '';
+  for (var j = 0; j != node.childNodes.length; j++) {
+    var child = node.childNodes[j];
+    if (child.nodeType == TEXT_NODE) {
+      if (child.nodeValue != '[Top]') { //ok, that's a hack, but it works.
+        text = text + child.nodeValue;
+      }
+    } else {
+      text = text + godocs_nodeToText(child);
+    }
+  }
+  return text;
+}
+
+/* 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.
+ */
+function godocs_generateTOC() {
+  if (document.getElementById('manual-nav')) { return; }
+  var navbar = document.getElementById('nav');
+  if (!navbar) { return; }
+
+  var toc_items = [];
+
+  var i;
+  var seenNav = false;
+  for (i = 0; i < navbar.parentNode.childNodes.length; i++) {
+    var node = navbar.parentNode.childNodes[i];
+    if (!seenNav) { 
+      if (node.id == 'nav') {
+        seenNav = true;
+      }
+      continue;
+    }
+    if ((node.tagName != 'h2') && (node.tagName != 'H2') &&
+        (node.tagName != 'h3') && (node.tagName != 'H3')) {
+      continue;
+    }
+    if (!node.id) {
+      node.id = 'tmp_' + i;
+    }
+    var text = godocs_nodeToText(node);
+    if (!text) { continue; }
+
+    var textNode = document.createTextNode(text);
+
+    var link = document.createElement('a');
+    link.href = '#' + node.id;
+    link.appendChild(textNode);
+
+    // Then create the item itself
+    var item;
+    if ((node.tagName == 'h2') || (node.tagName == 'H2')) {
+      item = document.createElement('dt');
+    } else { // h3
+      item = document.createElement('dd');
+    }
+
+    item.appendChild(link);
+    toc_items.push(item);
+  }
+
+  if (toc_items.length <= 1) { return; }
+
+  var dl1 = document.createElement('dl');
+  var dl2 = document.createElement('dl');
+
+  var split_index = (toc_items.length / 2) + 1;
+  if (split_index < 8) {
+    split_index = toc_items.length;
+  }
+
+  for (i = 0; i < split_index; i++) {
+    dl1.appendChild(toc_items[i]);
+  }
+  for (/* keep using i */; i < toc_items.length; i++) {
+    dl2.appendChild(toc_items[i]);
+  }
+
+  var tocTable = document.createElement('table');
+  navbar.appendChild(tocTable);
+  tocTable.className = 'unruled';
+  var tocBody = document.createElement('tbody');
+  tocTable.appendChild(tocBody);
+
+  var tocRow = document.createElement('tr');
+  tocBody.appendChild(tocRow);
+
+  // 1st column
+  var tocCell = document.createElement('td');
+  tocCell.className = 'first';
+  tocRow.appendChild(tocCell);
+  tocCell.appendChild(dl1);
+
+  // 2nd column
+  tocCell = document.createElement('td');
+  tocRow.appendChild(tocCell);
+  tocCell.appendChild(dl2);
+}
+
+function getElementsByClassName(base, clazz) {
+  if (base.getElementsByClassName) {
+    return base.getElementsByClassName(clazz);
+  }
+  var elements = base.getElementsByTagName('*'), foundElements = [];
+  for (var n in elements) {
+    if (clazz == elements[n].className) {
+      foundElements.push(elements[n]);
+    }
+  }
+  return foundElements;
+}
+
+function godocs_bindToggle(el) {
+  var button = getElementsByClassName(el, "toggleButton");
+  var callback = function() {
+    if (el.className == "toggle") {
+      el.className = "toggleVisible";
+    } else {
+      el.className = "toggle";
+    }
+  };
+  for (var i = 0; i < button.length; i++) {
+    bindEvent(button[i], "click", callback);
+  }
+}
+function godocs_bindToggles(className) {
+  var els = getElementsByClassName(document, className);
+  for (var i = 0; i < els.length; i++) {
+    godocs_bindToggle(els[i]);
+  }
+}
+function godocs_bindToggleLink(l, prefix) {
+  bindEvent(l, "click", function() {
+    var i = l.href.indexOf("#"+prefix);
+    if (i < 0) {
+      return;
+    }
+    var id = prefix + l.href.slice(i+1+prefix.length);
+    var eg = document.getElementById(id);
+    eg.className = "toggleVisible";
+  });
+}
+function godocs_bindToggleLinks(className, prefix) {
+  var links = getElementsByClassName(document, className);
+  for (i = 0; i < links.length; i++) {
+    godocs_bindToggleLink(links[i], prefix);
+  }
+}
+
+function godocs_onload() {
+  godocs_bindSearchEvents();
+  godocs_generateTOC();
+  godocs_bindToggles("toggle");
+  godocs_bindToggles("toggleVisible");
+  godocs_bindToggleLinks("exampleLink", "example_");
+  godocs_bindToggleLinks("overviewLink", "");
+}
+
+bindEvent(window, 'load', godocs_onload);
--- a/doc/gopher/README
+++ b/doc/gopher/README
@@ -1,3 +0,0 @@
-The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/)
-The design is licensed under the Creative Commons 3.0 Attributions license.
-Read this article for more details: http://blog.golang.org/gopher
--- a/doc/gopher/biplane.jpg
+++ b/doc/gopher/biplane.jpg
--- a/Show More
+++ b/Show More