Manually repair/update z* files for netbsd - this allows Go to
compile again on 386.
R=golang-dev, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6194064
Also set maxContractLen automatically.
Note that the table size is much bigger than it needs to be.
Optimization is best done, though, when the language specific
tables are added.
R=r
CC=golang-dev
https://golang.org/cl/6167044
go help remote used to reference "go help importpath", which has
changed to "go help packages".
Fixes#3598.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6201065
Tested manually.
Fixes#3554.
Before:
$ cd $GOROOT/src/pkg
$ go list io
io
$ go list io/...
io
io/ioutil
$ cd $GOROOT/src/pkg/io
$ go list .
io
$ go list ./...
io/ioutil
After:
$ cd $GOROOT/src/pkg
$ go list io
io
$ go list io/...
io
io/ioutil
$ cd $GOROOT/src/pkg/io
$ go list .
io
$ go list ./...
io
io/ioutil
$ go list ././...
io
io/ioutil
$ go list ././.././io/...
io
io/ioutil
$ go list ../image
image
$ go list ../image/...
image
image/color
image/draw
image/gif
image/jpeg
image/png
$ go list ../.../template
html/template
text/template
$ cd $GOROOT/src/pkg
$ go list ./io
io
$ go list ./io/...
io
io/ioutil
$ go list ./.../pprof
net/http/pprof
runtime/pprof
$ go list ./compress
can't load package: package compress: no Go source files in /home/nigeltao/go/src/pkg/compress
$ go list ./compress/...
compress/bzip2
compress/flate
compress/gzip
compress/lzw
compress/zlib
$ cd $GOROOT/src/pkg/code.google.com
$ go list ./p/leveldb-go/...
code.google.com/p/leveldb-go/leveldb
code.google.com/p/leveldb-go/leveldb/crc
code.google.com/p/leveldb-go/leveldb/db
code.google.com/p/leveldb-go/leveldb/memdb
code.google.com/p/leveldb-go/leveldb/memfs
code.google.com/p/leveldb-go/leveldb/record
code.google.com/p/leveldb-go/leveldb/table
code.google.com/p/leveldb-go/manualtest/filelock
$ go list ./p/.../truetype
code.google.com/p/freetype-go/example/truetype
code.google.com/p/freetype-go/freetype/truetype
$ go list ./p/.../example
warning: "./p/.../example" matched no packages
$ go list ./p/.../example/...
code.google.com/p/freetype-go/example/freetype
code.google.com/p/freetype-go/example/gamma
code.google.com/p/freetype-go/example/raster
code.google.com/p/freetype-go/example/round
code.google.com/p/freetype-go/example/truetype
code.google.com/p/x-go-binding/example/imgview
code.google.com/p/x-go-binding/example/xgb
R=rsc
CC=golang-dev
https://golang.org/cl/6194056
These files change from exactly 10003 bytes long to 100003: a digit,
a '.', 100k digits, and a '\n'.
The magic constants in compress/flate/deflate_test.go change since
deflateInflateStringTests checks that the compressed form of e.txt
is not 'too large'. I'm not exactly sure how these numbers were
originally calculated (they were introduced in codereview 5554066
"make lazy matching work"); perhaps krasin@golang.org can comment.
My change was to increase the first one (no compression) to a tight
bound, and multiply all the others by 10.
Benchcmp numbers for compress/flate and compress/lzw below. LZW's
window size of 4096 is less than 10k, so shows no significant change.
Flate's window size is 32768, between 10k and 100k, and so the .*1e5
and .*1e6 benchmarks show a dramatic drop, since the compressed forms
are no longer a trivial forward copy of 10k digits repeated over and
over, but should now be more representative of real world usage.
compress/flate:
benchmark old MB/s new MB/s speedup
BenchmarkDecodeDigitsSpeed1e4 16.58 16.52 1.00x
BenchmarkDecodeDigitsSpeed1e5 68.09 18.10 0.27x
BenchmarkDecodeDigitsSpeed1e6 124.63 18.35 0.15x
BenchmarkDecodeDigitsDefault1e4 17.21 17.12 0.99x
BenchmarkDecodeDigitsDefault1e5 118.28 19.19 0.16x
BenchmarkDecodeDigitsDefault1e6 295.62 20.52 0.07x
BenchmarkDecodeDigitsCompress1e4 17.22 17.17 1.00x
BenchmarkDecodeDigitsCompress1e5 118.19 19.21 0.16x
BenchmarkDecodeDigitsCompress1e6 295.59 20.55 0.07x
BenchmarkEncodeDigitsSpeed1e4 8.18 8.19 1.00x
BenchmarkEncodeDigitsSpeed1e5 43.22 12.84 0.30x
BenchmarkEncodeDigitsSpeed1e6 80.76 13.48 0.17x
BenchmarkEncodeDigitsDefault1e4 6.29 6.19 0.98x
BenchmarkEncodeDigitsDefault1e5 31.63 3.60 0.11x
BenchmarkEncodeDigitsDefault1e6 52.97 3.24 0.06x
BenchmarkEncodeDigitsCompress1e4 6.20 6.19 1.00x
BenchmarkEncodeDigitsCompress1e5 31.59 3.59 0.11x
BenchmarkEncodeDigitsCompress1e6 53.18 3.25 0.06x
compress/lzw:
benchmark old MB/s new MB/s speedup
BenchmarkDecoder1e4 21.99 22.09 1.00x
BenchmarkDecoder1e5 22.77 22.71 1.00x
BenchmarkDecoder1e6 22.90 22.90 1.00x
BenchmarkEncoder1e4 21.04 21.19 1.01x
BenchmarkEncoder1e5 22.06 22.06 1.00x
BenchmarkEncoder1e6 22.16 22.28 1.01x
R=rsc
CC=golang-dev, krasin
https://golang.org/cl/6207043
I'm not sure where the BOM came from, originally.
http://www.gutenberg.org/files/74/74.txt doesn't have it, although
a fresh download of that URL gives me "\r\n"s instead of plain "\n"s,
and the extra line "Character set encoding: ASCII". Maybe Project
Gutenberg has changed their server configuration since we added that
file to the Go repo.
Anyway, this change is just manually excising the BOM from the start
of the file, leaving pure ASCII.
R=r, bradfitz
CC=golang-dev, krasin, rsc
https://golang.org/cl/6197061
This adds restoring the window position so that the buffer doesn't jump around after the erase/copy.
R=sameer
CC=golang-dev
https://golang.org/cl/5981055
dictates a CJK rune is only part of a certain specified range if it
is explicitly defined in the Unicode Codepoint Database.
Fixed the code and some of the tests accordingly.
R=r
CC=golang-dev
https://golang.org/cl/6160044
This is a follow-up to CL 5978051.
Use kernel cas64 helper if we can, fallback to LDREXD/STREXD if
we are on ARMv6 or higher, and to lock-emulated cas64 if on ARMv5.
A future CL will fix {Add,Load,Store}{Int,Uint}64 and issue 3331.
R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6034048
Decode AT_RANDOM, AT_HWCAP, and AT_PLATFORM.
This CL only make use of AT_RANDOM, but future CLs will make use of the others.
R=dave, rsc
CC=golang-dev
https://golang.org/cl/5978051
Some newer Linux distributions (Ubuntu ARM at least) use a new multiarch
directory organization, where dynamic linker is no longer in the hardcoded
path in our linker.
For example, Ubuntu 12.04 ARM hardfloat places its dynamic linker at
/lib/arm-linux-gnueabihf/ld-linux.so.3
Ref: http://lackof.org/taggart/hacking/multiarch/
Also, to support Debian GNU/kFreeBSD as a FreeBSD variant, we need this capability, so it's part of issue 3533.
This CL add a new pragma (#pragma dynlinker "path") to cc.
R=iant, rsc
CC=golang-dev
https://golang.org/cl/6086043
1. In CL 5989057, I made a mistake in the last minute change.
"MOVW.W R4, -4(SP)" should really be "MOVW.W R4, -4(R13)",
as 5l will rewrite offset for SP.
2. misc/cgo/test/issue1560.go tests for parallel sleep of 1s,
but on ARM, the deadline is frequently missed, so change sleep
time to 2s on ARM.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6202043
This adds proper note handling for Plan 9,
and fixes the issue of properly killing go procs.
Without this change, the first go proc that dies
(using runtime·exit()) would kill all the running
go procs. Proper signal handling is needed.
R=golang-dev, ality, rminnich, rsc
CC=golang-dev, john, mirtchovski
https://golang.org/cl/5617048
Instead use a new type, "Note", whose underlying
type is just a string. This change allows us to
remove the exported os.Plan9Note type.
R=bradfitz, seed, rsc
CC=golang-dev
https://golang.org/cl/6015046
Part 1 of CL 5601044 (cgo: Linux/ARM support)
Limitation: doesn't support thumb library yet.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/5991065
crypto.Hash.New() changed to panicking when the hash function isn't
linked in, but crypto/x509 still expects it to return nil.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6175047
This makes it possible to inline the prefetch of upcoming
memory addresses during garbage collection, instead of
needing to flush registers, make a function call, and
reload registers. On garbage collection-heavy workloads,
this results in a 5% speedup.
Fixes#3493.
R=dvyukov, ken, r, dave
CC=golang-dev
https://golang.org/cl/5990066
The first bug was that tertiary ignorables had the same colElem as
implicit colElems, yielding unexpected results. The current encoding
ensures that a non-implicit colElem is never 0. This fix uncovered
another bug of the trie that indexed incorrectly into the null block.
This was caused by an unfinished optimization that would avoid the
need to max out the most-significant bits of continuation bytes.
This bug was also present in the trie used in exp/norm and has been
fixed there as well. The appearence of the bug was rare, as the lower
blocks happened to be nearly nil.
R=r
CC=golang-dev
https://golang.org/cl/6127070
