R=r
CC=golang-dev
https://golang.org/cl/180118

- use an interface {Get()}
- implement Get for maps, slices
- for slices, retrieves the address of the end of the array, which will give the
	same value for every slice of the same array.

R=rsc
CC=golang-dev
https://golang.org/cl/179129

R=gri
CC=golang-dev
https://golang.org/cl/179128

(Also fix case sensitivity in test for PTR inside fmt_test.go)
Fixes #441.

R=rsc, iant
CC=golang-dev
https://golang.org/cl/180112

R=r
CC=golang-dev
https://golang.org/cl/179120

R=gri
CC=rsc
https://golang.org/cl/178048

R=r, rsc
CC=golang-dev
https://golang.org/cl/179118

Fixes #436.

R=ken2
https://golang.org/cl/180105

R=dho
CC=golang-dev
https://golang.org/cl/180099

gccgo currently fails this test.

R=rsc
CC=golang-dev
https://golang.org/cl/179108

R=ken2
https://golang.org/cl/180092

corrects a common misunderstanding about NewBuffer.

R=rsc
CC=golang-dev
https://golang.org/cl/179106

(Thanks to ken and rsc for pointing this out)

rsc:
	ken pointed out that there's a race in the new
	one-lock-per-channel code.  the issue is that
	if one goroutine has gone to sleep doing

	select {
	case <-c1:
	case <-c2:
	}

	and then two more goroutines try to send
	on c1 and c2 simultaneously, the way that
	the code makes sure only one wins is the
	selgen field manipulation in dequeue:

	       // if sgp is stale, ignore it
	       if(sgp->selgen != sgp->g->selgen) {
		       //prints("INVALID PSEUDOG POINTER\n");
		       freesg(c, sgp);
		       goto loop;
	       }

	       // invalidate any others
	       sgp->g->selgen++;

	but because the global lock is gone both
	goroutines will be fiddling with sgp->g->selgen
	at the same time.

This results in a 7% slowdown in the single threaded case for a
ping-pong microbenchmark.

Since the cas predominantly succeeds, adding a simple check first
didn't make any difference.

R=rsc
CC=golang-dev
https://golang.org/cl/180068

now that the parser doesn't do this test anymore

R=rsc
CC=golang-dev
https://golang.org/cl/179105

added more test cases
some capitalization cleanups

R=rsc
CC=golang-dev
https://golang.org/cl/180085

R=rsc
CC=golang-dev
https://golang.org/cl/179099

R=dho, phf
CC=golang-dev
https://golang.org/cl/180082

Fixes #443.

R=dho
CC=golang-dev
https://golang.org/cl/179095

        them in the stream.

R=rsc
https://golang.org/cl/174052

R=rsc
CC=golang-dev
https://golang.org/cl/179096

R=ken2
CC=dho
https://golang.org/cl/179097

leading tabs into spaces to ensure a good outcome in
most browsers

R=rsc
https://golang.org/cl/165051

Fixes #431.

R=r, rsc
CC=golang-dev
https://golang.org/cl/179079

R=gri
CC=golang-dev
https://golang.org/cl/180081

Fixes #342.

R=rsc
CC=golang-dev
https://golang.org/cl/179062

structs containing bitfields.

Fixes #163.

R=rsc
CC=golang-dev
https://golang.org/cl/180059

source for xproto.go.

R=rsc
CC=golang-dev
https://golang.org/cl/180074

	most signals, so that ordinary programs
	can be killed, for example.

Fixes #434.

R=dsymonds1
CC=golang-dev, hoisie
https://golang.org/cl/180064

R=rsc
CC=golang-dev
https://golang.org/cl/180075

Allows stand-alone types (e.g. []int as patterns) and doesn't require
a semicolon at the end (which are now mandatory terminators).

- Fix a matcher bug.

R=rsc
CC=golang-dev
https://golang.org/cl/179088

This is not a complete JPEG implementation (e.g. it does not handle
progressive JPEGs or restart markers), but I was able to take a photo
with my phone, and view the resultant JPEG in pure Go.

The decoder is simple, but slow. The Huffman decoder in particular
should be easily improvable, but optimization is left to future
changelists. Being able to inline functions in the inner loop should
also help performance.

The output is not pixel-for-pixel identical to libjpeg, although
identical behavior isn't necessarily a goal, since JPEG is a lossy
codec. There are at least two reasons for the discrepancy.

First, the inverse DCT algorithm used is the same as Plan9's
src/cmd/jpg, which has different rounding errors from libjpeg's
default IDCT implementation. Note that libjpeg actually has three
different IDCT implementations: one floating point, and two fixed
point. Out of those four, Plan9's seemed the simplest to understand,
partly because it has no #ifdef's or C macros.

Second, for 4:2:2 or 4:2:0 chroma sampling, this implementation does
nearest neighbor upsampling, compared to libjpeg's triangle filter
(e.g. see h2v1_fancy_upsample in jdsample.c).

The difference from the first reason is typically zero, but sometimes
1 (out of 256) in YCbCr space, or double that in RGB space. The
difference from the second reason can be as large as 8/256 in YCbCr
space, in regions of steep chroma gradients. Informal eyeballing
suggests that the net difference is typically imperceptible, though.

R=r
CC=golang-dev, rsc
https://golang.org/cl/164056

Also adds Development heading on navbar, with Roadmap being
the only current entry.

R=r
CC=golang-dev
https://golang.org/cl/180069

in parser's ParsePkgFile and ParsePackage functions.

R=rsc
CC=golang-dev, rog
https://golang.org/cl/180070

Fixes #389.

R=rsc
CC=golang-dev
https://golang.org/cl/180061

into consts in the resulting Go source.  Previously known as issue 161047,
which I deleted accidentally.  Fixes issue 207.

R=rsc
https://golang.org/cl/166059

R=rsc
https://golang.org/cl/176070

R=rsc, r, phf
CC=golang-dev
https://golang.org/cl/170046

R=rsc
CC=golang-dev
https://golang.org/cl/176064

Fixes #422.

R=r
CC=golang-dev
https://golang.org/cl/180057

Fixes #71.

R=rsc, r
https://golang.org/cl/162056