Age | Commit message (Collapse) | Author |
|
««« CL 4457049 / d222384d1bad
doc: release.r57
R=golang-dev, r, adg, r2
CC=golang-dev
https://golang.org/cl/4457049
»»»
R=golang-dev
TBR=r
CC=golang-dev
https://golang.org/cl/4431087
|
|
««« CL 4437089 / b2670a39da7c
Make.cmd: create TARGDIR if necessary
Fixes #1771.
R=adg, rsc1
CC=golang-dev
https://golang.org/cl/4437089
»»»
R=adg
CC=golang-dev
https://golang.org/cl/4454054
|
|
««« CL 4444087 / 9abf81a9df90
reflect: allow unexported key in Value.MapIndex
Fixes #1748.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4444087
»»»
R=r, r2
CC=golang-dev
https://golang.org/cl/4433099
|
|
««« CL 4433088 / 099dd59d3976
jpeg: speed up RGBA encoding ~%50
Avoids image.At(), color.RGBA(), opposing 8 bit shifts,
and min function calls in a loop. Not as pretty as before,
but the pure version is still there to revert back to
later if/when the compiler gets better.
before (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 64781360 ns/op 18.97 MB/s
after (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 42044300 ns/op 29.23 MB/s
(benchmarked on an HP z600; 16 core Xeon E5520 @ 2.27Ghz)
R=r, r2, nigeltao
CC=golang-dev
https://golang.org/cl/4433088
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4431086
|
|
««« CL 4435081 / 48c0b02c6e7f
doc/install: specify clone -u instead of -r
R=rsc
CC=golang-dev
https://golang.org/cl/4435081
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4436080
|
|
««« CL 4438090 / 29f6e2e230a3
image: fix build
accidentally deleted one method
TBR=rsc
R=rsc
CC=golang-dev
https://golang.org/cl/4438090
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4445084
|
|
decoding PNG.
««« CL 4428080 / 2098f7682f2d
image: add type-specific Set methods and use them when decoding PNG.
This speeds up PNG decode about 20% by avoiding per-pixel interface conversions.
R=nigeltao, rsc
CC=golang-dev
https://golang.org/cl/4428080
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4426078
|
|
««« CL 4430075 / ca45c67d28cf
http/pprof: fix POST reading bug
R=bradfitz
CC=golang-dev
https://golang.org/cl/4430075
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4454053
|
|
««« CL 4445079 / f8cc81f985e5
5a, 6a, 8a, cc: remove old environment variables
Uses of $INCLUDE and $NPROC are left over from Plan 9.
Remove them to avoid causing confusion.
R=golang-dev, r2
CC=golang-dev
https://golang.org/cl/4445079
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4438096
|
|
««« CL 4436072 / e280d98747be
runtime, sync/atomic: fix arm cas
Works around bug in kernel implementation on old ARM5 kernels.
Bug was fixed on 26 Nov 2007 (between 2.6.23 and 2.6.24) but
old kernels persist.
Fixes #1750.
R=dfc, golang-dev
CC=golang-dev
https://golang.org/cl/4436072
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4452064
|
|
««« CL 4432077 / 66eb68cbd5c2
png: speed up opaque RGBA encoding
With Linux/8g on a 2006 Mac Mini (1.66 GHz Intel Core Duo,
2KB L1, 2MB L2, 2G main memory), GOMAXPROCS unset:
start:
png.BenchmarkEncodePaletted 50 44772820 ns/op
png.BenchmarkEncodeRGBOpaque 10 208395900 ns/op
png.BenchmarkEncodeRGBA 5 331088000 ns/op
remove interface method calls:
png.BenchmarkEncodePaletted 50 44722880 ns/op
png.BenchmarkEncodeRGBOpaque 10 139042600 ns/op
png.BenchmarkEncodeRGBA 5 334033600 ns/op
flate inline min/max():
png.BenchmarkEncodePaletted 50 40631180 ns/op
png.BenchmarkEncodeRGBOpaque 10 124894900 ns/op
png.BenchmarkEncodeRGBA 5 312099000 ns/op
after adler change:
png.BenchmarkEncodePaletted 50 40181760 ns/op
png.BenchmarkEncodeRGBOpaque 20 121781950 ns/op
png.BenchmarkEncodeRGBA 5 313890800 ns/op
In comparison to 121 ms on this 2006 machine, on my
Core2 Duo 2.66 GHz laptop, the final BenchmarkEncodeRGBOpaque
runs in 27 ms. (these are all for 640x480 images)
R=nigeltao, rsc, r
CC=golang-dev
https://golang.org/cl/4432077
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4430076
|
|
««« CL 4432085 / 370c77323b75
http: rename ErrBodyReadAferClose to ErrBodyReadAfterClose
R=bradfitz, dsymonds
CC=golang-dev
https://golang.org/cl/4432085
»»»
TBR=adg
CC=golang-dev
https://golang.org/cl/4425086
|
|
change
««« CL 4432083 / 698b5ea9c782
mime/multipart: fix regression from previous ReadSlice change
The previous change to make multipart use ReadSlice out of
paranoia broke multipart to not deal with large lines in
the bodies.
We should only be paranoid about long lines in the header
sections.
Fixes http://code.google.com/p/camlistore/issues/detail?id=4
R=adg
CC=golang-dev
https://golang.org/cl/4432083
»»»
R=adg
CC=golang-dev
https://golang.org/cl/4452062
|
|
««« CL 4433094 / e30213b07276
http: new error for reading a body after it's been closed
R=adg
CC=golang-dev
https://golang.org/cl/4433094
»»»
R=adg
CC=golang-dev
https://golang.org/cl/4433098
|
|
««« CL 4445074 / 304d7d2b1d6c
image: png & jpeg encoding benchmarks
No code changes in this CL.
R=r
CC=golang-dev
https://golang.org/cl/4445074
»»»
R=adg
CC=golang-dev
https://golang.org/cl/4453056
|
|
««« CL 4431075 / acee6ec98e9a
xml: fix reflect error
Fixes #1749.
R=bradfitz
CC=golang-dev
https://golang.org/cl/4431075
»»»
R=adg
CC=golang-dev
https://golang.org/cl/4457048
|
|
|
|
R=rsc
CC=golang-dev
https://golang.org/cl/4437077
|
|
R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4431068
|
|
before & after:
adler32.BenchmarkGolden 100000 14747 ns/op
adler32.BenchmarkGolden 200000 8761 ns/op
Found by profiling PNG encoding.
R=rsc, bradfitzwork, eds
CC=golang-dev
https://golang.org/cl/4441073
|
|
This time for sure.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4437078
|
|
Previously, whether declaring a type which copied the structure of a type it was referenced in via a pointer field would work depended on whether you declared it before or after the type it copied, e.g. type T2 T1; type T1 struct { F *T2 } would work, however type T1 struct { F *T2 }; type T2 T1 wouldn't.
Fixes #667.
R=rsc
CC=golang-dev
https://golang.org/cl/4313064
|
|
The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).
That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls. Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.
The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp. In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number. Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory. On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number. Scanblock would not scan anything, possibly
causing in-use blocks to be freed.
In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.
Fixes #1620.
Fixes #1746.
R=iant, r
CC=golang-dev
https://golang.org/cl/4437075
|
|
Fixes #1397.
R=iant
CC=golang-dev
https://golang.org/cl/4444064
|
|
runtime: memory allocated by OS not in usable range
runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
throw: out of memory
runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
runtime.throw(0x1fffd, 0x101)
runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
runtime.mal(0x100004, 0x20bc4)
runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
runtime.new(0x100004, 0x8fe84000, 0x20bc4)
main.main+0x29 /Users/rsc/x.go:11
main.main()
runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
runtime.mainstart()
runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
runtime.goexit()
----- goroutine created by -----
_rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80
R=iant, r
CC=golang-dev
https://golang.org/cl/4444073
|
|
R=brad_danga_com, rsc, dfc, r, dchest, bradfitz
CC=golang-dev
https://golang.org/cl/4439075
|
|
This one didn't come up in previous greps.
R=adg
CC=golang-dev
https://golang.org/cl/4430071
|
|
This also removes an unnecessary allocation in
http/transfer.go
R=r, rsc1, r2, adg
CC=golang-dev
https://golang.org/cl/4426066
|
|
R=rsc
CC=golang-dev
https://golang.org/cl/4432076
|
|
Fixes #1725
R=rsc
CC=golang-dev
https://golang.org/cl/4442086
|
|
R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4438077
|
|
Add local URI path support, which isn't as fringe
as I originally thought. (it's supported by Apache)
Send an implicit 302 status on redirects (not 200).
Fixes #1597
R=rsc, r
CC=golang-dev
https://golang.org/cl/4442089
|
|
In a GOROOT path a backslash is a path separator
not an escape character. For example, `C:\go`.
Fixes gotest error:
version.go:3: unknown escape sequence: g
R=rsc
CC=golang-dev
https://golang.org/cl/4437076
|
|
R=golang-dev, bradfitzgo, bradfitzwork, nigeltao, rog
CC=golang-dev
https://golang.org/cl/4271078
|
|
Fixes #1742.
I hope.
Also this picks up an update to go_tutorial.html that should already have happened.
R=brainman, rsc, peterGo
CC=golang-dev
https://golang.org/cl/4452050
|
|
R=dsymonds
CC=golang-dev
https://golang.org/cl/4436060
|
|
Fixes #1531.
R=adg
CC=golang-dev
https://golang.org/cl/4442088
|
|
For example, with GOPATH set like so
GOPATH=/home/adg/gocode
And after creating some subdirectories
mkdir /home/adg/gocode/{bin,pkg,src}
I can use goinstall to install the github.com/nf/goto web server,
which depends on the github.com/nf/stat package, with
goinstall github.com/nf/goto
This downloads and installs all dependencies (that aren't already
installed) like so
/home/adg/gocode/bin/goto
/home/adg/gocode/pkg/darwin_amd64/github.com/nf/stat.a
/home/adg/gocode/src/github.com/nf/goto/...
/home/adg/gocode/src/github.com/nf/stat/...
R=rsc, niemeyer
CC=golang-dev
https://golang.org/cl/4438043
|
|
R=rsc, dfc
CC=golang-dev
https://golang.org/cl/4452047
|
|
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4442085
|
|
pointer.
Can make the API nicer in some cases.
R=rsc, rog, r2
CC=golang-dev
https://golang.org/cl/4428064
|
|
No bugs found yet, though.
R=rsc, bradfitzwork
CC=golang-dev
https://golang.org/cl/4436058
|
|
I ran the new verification code against a large number of certificates
with a huge (>1000) number of intermediates.
I had previously convinced myself that a cycle in the certificate
graph implied a cycle in the hash graph (and thus, a contradiction).
This is bogus because the signatures don't cover each other.
Secondly, I managed to drive the verification into a time explosion
with a fully connected graph of certificates. The code would try to
walk the factorial number of paths.
This change switches the CertPool to dealing with indexes of
certificates rather than pointers: this makes equality easy. (I didn't
want to compare pointers because a reasonable gc could move objects
around over time.)
Secondly, verification now memorizes the chains from a given
certificate. This is dynamic programming for the lazy, but there's a
solid reason behind it: dynamic programming would ignore the Issuer
hints that we can exploit by walking up the chain rather than down.
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4439070
|
|
R=rsc, bradfitzgo
CC=golang-dev
https://golang.org/cl/4433070
|
|
Used to fault trying to access l->list->next
when l->list == nil after MCentral_AllocList.
Now prints
runtime: out of memory: no room in arena for 65536-byte allocation (536870912 in use)
throw: out of memory
followed by stack trace.
Fixes #1650.
R=r, dfc
CC=golang-dev
https://golang.org/cl/4446062
|
|
R=bradfitzgo, rsc, peterGo
CC=golang-dev
https://golang.org/cl/4441051
|
|
This change will allow to generate valid executable,
even if rsc disables dwarf generation, as it happend
at revision 9a64273f9d68.
R=rsc
CC=golang-dev, lvd, vcc
https://golang.org/cl/4425066
|
|
Work on issue 155
R=rsc, bradfitzwork
CC=golang-dev
https://golang.org/cl/4435071
|
|
Also, 6g was passing uninitialized
Node &n2 to regalloc, causing non-deterministic
register collisions (but only when both left and
right hand side of comparison had function calls).
Fixes #1728.
R=ken2
CC=golang-dev
https://golang.org/cl/4425070
|
|
It's no longer used.
R=adg
CC=golang-dev
https://golang.org/cl/4426061
|