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

At the moment, gc and gccgo report compile-
time errors for certain constant indexes that
are out of bounds. The spec however requests
a run-time panic for out-of-bounds indexes
(http://tip.golang.org/ref/spec#Indexes).

Document the status quo.

Fixes #4231.

R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/6699048

Fixes #4104.

R=golang-dev, dave, minux.ma
CC=golang-dev
https://golang.org/cl/6639051

A 4-bit window is convenient because 4 divides both 32 and 64,
therefore we never have a window spanning words of the exponent.
Additionaly, the benefit of a 5-bit window is only 2.6% at 1024-bits
and 3.3% at 2048-bits.

This code is still not constant time, however.

benchmark                        old ns/op    new ns/op    delta
BenchmarkRSA2048Decrypt           17108590     11180370  -34.65%
Benchmark3PrimeRSA2048Decrypt     13003720      7680390  -40.94%

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

only supports ARMv6K and newer ARM cores.

R=rsc, dave
CC=golang-dev
https://golang.org/cl/6601064

Define the properties of the arguments better. In particular,
explain that the path is (sort of) relative to the argument to
Walk.

Fixes #4119.

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

Fixes #3590.

R=bradfitz, mikioh.mikioh, iant, bsiegert
CC=golang-dev
https://golang.org/cl/6684054

- always return 1 for y <= 0
- document that the sign of m is ignored
- protect against div-0 panics by treating
  m == 0 the same way as m == nil
- added extra tests

Fixes #4239.

R=agl, remyoudompheng, agl
CC=golang-dev
https://golang.org/cl/6724046

The RFC doesn't actually have an opinion on whether this is a fatal or
warning level alert, but common practice suggests that it should be a
warning.

This involves rebasing most of the tests.

Fixes #3413.

R=golang-dev, shanemhansen, rsc
CC=golang-dev
https://golang.org/cl/6654050

Also: handle assignments to the blank identifier.

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

Fixes #4243.

R=golang-dev, iant
CC=golang-dev, sebastien.paolacci
https://golang.org/cl/6682050

R=adg, bsiegert
CC=golang-dev
https://golang.org/cl/6660047

R=adg
CC=golang-dev
https://golang.org/cl/6650053

so that keyboard navigation events are sent to div#page.

        Fixes #4233.

R=adg
CC=golang-dev
https://golang.org/cl/6652048

This patch is enough to fix compilation of
exp/types tests but only passes a stripped down
version of the appripriate torture test.

Update #4207.

R=dave, nigeltao, rsc, golang-dev
CC=golang-dev
https://golang.org/cl/6621061

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

R=golang-dev, adg, dave, rsc, minux.ma, dvyukov
CC=golang-dev
https://golang.org/cl/6648043

Proposed new text to make matters clearer. The existing text was
unclear about the state of result parameters when panicking.

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

R=0xe2.0x9a.0x9b, minux.ma, iant, dave
CC=golang-dev
https://golang.org/cl/6654052

This is a straight copy/paste, and the deletion of a TODO. There are
no other changes.

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

To be clear, this supports decoding the bytes on the wire into an
in-memory image. There is no API change: jpeg.Decode will still not
return until the entire image is decoded.

The code is obviously more complicated, and costs around 10% in
performance on baseline JPEGs. The processSOS code could be cleaned up a
bit, and maybe some of that loss can be reclaimed, but I'll leave that
for follow-up CLs, to keep the diff for this one as small as possible.

Before:
BenchmarkDecode	    1000	   2855637 ns/op	  21.64 MB/s
After:
BenchmarkDecodeBaseline	     500	   3178960 ns/op	  19.44 MB/s
BenchmarkDecodeProgressive	     500	   4082640 ns/op	  15.14 MB/s

Fixes #3976.

The test data was generated by:
# Create intermediate files; cjpeg on Ubuntu 10.04 can't read PNG.
convert video-001.png video-001.bmp
convert video-005.gray.png video-005.gray.pgm
# Create new test files.
cjpeg -quality 100 -sample 1x1,1x1,1x1 -progressive video-001.bmp > video-001.progressive.jpeg
cjpeg -quality 50 -sample 2x2,1x1,1x1 video-001.bmp > video-001.q50.420.jpeg
cjpeg -quality 50 -sample 2x1,1x1,1x1 video-001.bmp > video-001.q50.422.jpeg
cjpeg -quality 50 -sample 1x1,1x1,1x1 video-001.bmp > video-001.q50.444.jpeg
cjpeg -quality 50 -sample 2x2,1x1,1x1 -progressive video-001.bmp > video-001.q50.420.progressive.jpeg
cjpeg -quality 50 -sample 2x1,1x1,1x1 -progressive video-001.bmp > video-001.q50.422.progressive.jpeg
cjpeg -quality 50 -sample 1x1,1x1,1x1 -progressive video-001.bmp > video-001.q50.444.progressive.jpeg
cjpeg -quality 50 video-005.gray.pgm > video-005.gray.q50.jpeg
cjpeg -quality 50 -progressive video-005.gray.pgm > video-005.gray.q50.progressive.jpeg
# Delete intermediate files.
rm video-001.bmp video-005.gray.pgm

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

Fixes #3374.

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

caller of ioutil.TempFile() can use f.Name() to get "pathname"
of the temporary file, instead of just the "name" of the file.

Also remove an out-of-date comment about random number state.

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

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6663044

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

        It has been moved to go.talks/2010/ExpressivenessOfGo-2010.pdf
        URL: http://talks.golang.org/2010/ExpressivenessOfGo-2010.pdf

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

R=rsc, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/6657048

Valgrind Massif result when linking godoc:
On amd64:
                    old          new         -/+
mem_heap_B       185844612    175358047    -5.7%
mem_heap_extra_B    773404       773137    -0.0%

On 386/ARM:
                    old          new         -/+
mem_heap_B       141775701    131289941    -7.4%
mem_heap_extra_B    737011       736955    -0.0%

R=golang-dev, r, dave
CC=golang-dev
https://golang.org/cl/6655045

Also, to aid debugging cmd/dist, make make.bat support --dist-tool flag.

Fixes #3100.

R=alex.brainman
CC=golang-dev
https://golang.org/cl/6637061

Better explanation of width for floating-point values.
Explain that scanning does not handle %#q etc.

Fixes #4202.
Fixes #4206.

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

Fixes #4031.

R=golang-dev, bradfitz, remyoudompheng, r, dave
CC=golang-dev
https://golang.org/cl/6632046

Fixes #4236.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6658051

R=golang-dev, dsymonds, r
CC=golang-dev
https://golang.org/cl/6615078

Minor performance impact running sequentially:

benchmark                      old ns/op    new ns/op    delta
BenchmarkString10Base2               389          391   +0.51%
BenchmarkString100Base2             1530         1534   +0.26%
BenchmarkString1000Base2           11789        11787   -0.02%
BenchmarkString10000Base2         111443       112030   +0.53%
BenchmarkString100000Base2       1017483      1015347   -0.21%
BenchmarkString10Base8               339          344   +1.47%
BenchmarkString100Base8              753          756   +0.40%
BenchmarkString1000Base8            4618         4641   +0.50%
BenchmarkString10000Base8          43217        43534   +0.73%
BenchmarkString100000Base8        397518       400602   +0.78%
BenchmarkString10Base10              630          630   +0.00%
BenchmarkString100Base10            1975         1960   -0.76%
BenchmarkString1000Base10          10179        10174   -0.05%
BenchmarkString10000Base10         44527        44416   -0.25%
BenchmarkString100000Base10     14404694     14425308   +0.14%
BenchmarkString10Base16              283          288   +1.77%
BenchmarkString100Base16             597          598   +0.17%
BenchmarkString1000Base16           3189         3186   -0.09%
BenchmarkString10000Base16         29403        29364   -0.13%
BenchmarkString100000Base16       265657       265587   -0.03%

Note that due to other improvements (faster assembly routines,
better code generation by compiler), these benchmarks now run
up to 37% faster than they used to at the last time measured (1/9/2012).

Minor performance impact for StringPiParallel running in parallel:

Current CL but with Lock/Unlock commented out (removed):

BenchmarkStringPiParallel	    5000	    343581 ns/op
BenchmarkStringPiParallel-2	   10000	    184511 ns/op
BenchmarkStringPiParallel-3	   10000	    129768 ns/op
BenchmarkStringPiParallel-4	   10000	    102326 ns/op

Current CL:

BenchmarkStringPiParallel	    5000	    345169 ns/op
BenchmarkStringPiParallel-2	   10000	    185827 ns/op
BenchmarkStringPiParallel-3	   10000	    131168 ns/op
BenchmarkStringPiParallel-4	   10000	    102353 ns/op

Fixes #4218.

R=dvyukov, michael.jones, dave
CC=golang-dev
https://golang.org/cl/6643053

I was an idiot and was thinking that a small base didn't matter
because the exponentiation would quickly make the number the same size
as the modulus. But, of course, the small base continues to make
multiplications unrealistically cheap throughout the computation.

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

Fixes #4220.

R=dvyukov, bradfitz
CC=golang-dev
https://golang.org/cl/6638053

Update #4191.

Fixes unreported race failure at
http://build.golang.org/log/61e43a328fb220801d3d5c88cd91916cfc5dc43c

R=dvyukov, bradfitz
CC=golang-dev
https://golang.org/cl/6640057

It was suggested that it's too easy to use crypto/hmac insecurely and
I think that has some merit. This change adds a Equal function to
make it obvious that MAC values should be compared in constant time.

R=rsc, max
CC=golang-dev
https://golang.org/cl/6632044

0. windows uses all.bat instead of ./all.bash
1. correct expected all.bash output
2. mention you need to use an application specific password
if you're using 2-step verification
3. note you can edit files included in CL by 'hg change NNNN'
or 'hg file'

R=golang-dev, adg, r
CC=golang-dev
https://golang.org/cl/6615060

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