- 25 Jan, 2012 20 commits
-
-
Brad Fitzpatrick authored
The real fix for Issue 2616 is in https://golang.org/cl/5532057, to be submitted following this CL, without the test there which doesn't work reliably. This one seems to. R=rsc CC=golang-dev https://golang.org/cl/5569063
-
Russ Cox authored
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/5569064
-
Russ Cox authored
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/5576044
-
Robert Griesemer authored
R=rsc, r CC=golang-dev https://golang.org/cl/5564055
-
Russ Cox authored
Python and Mercurial are a matched pair. R=adg CC=golang-dev https://golang.org/cl/5570065
-
Russ Cox authored
R=golang-dev, adg CC=golang-dev https://golang.org/cl/5564054
-
Robert Griesemer authored
Added a cache to compensate for extra call overhead. go test -bench=Print marginally faster (in the noise). R=r CC=golang-dev https://golang.org/cl/5574061
-
Robert Griesemer authored
No changes when applying gofmt to src, misc. Fixes #2597. R=r CC=golang-dev https://golang.org/cl/5564056
-
Robert Griesemer authored
R=rsc CC=golang-dev https://golang.org/cl/5575055
-
Robert Griesemer authored
The implementation is divided into 4 phases: 1) export filtering of an incoming AST if necessary (exports.go) 2) reading of a possibly filtered AST (reader.go: type reader) 3) method set computation (reader.go) 4) sorting and creation of final documentation (reader.go) In contrast to the old implementation, the presentation data (Names, Docs, Decls, etc.) are created immediately upon reading the respective AST node. Also, all types are collected (embedded or not) in a uniform way. Once the entire AST has been processed, all methods and types have been collected and the method sets for each type can be computed (phase 3). To produce the final documentation, the method sets and value maps are sorted. There are no API changes. Passes the existing test suite unchanged. R=rsc, rogpeppe CC=golang-dev https://golang.org/cl/5554044
-
Robert Griesemer authored
R=adg, iant CC=golang-dev https://golang.org/cl/5573062
-
Fazlul Shahriar authored
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5563046
-
David Symonds authored
R=rsc CC=golang-dev https://golang.org/cl/5574060
-
Joel Sing authored
Reimplement the test based on code from adg@golang.org. The previous version has a race since the file is closed via defer rather than in the go routine. This meant that the file could be closed before the go routine has actually received io.EOF. It then receives EBADF and continues to do zero-byte writes to the pipe. This addresses an issue seen on FreeBSD and OpenBSD, where the test passes but exits with a SIGPIPE, resulting in a failure. R=golang-dev, adg CC=golang-dev https://golang.org/cl/5554083
-
Rob Pike authored
R=golang-dev, gri, bradfitz, adg CC=golang-dev https://golang.org/cl/5571060
-
Andrew Gerrand authored
Without this change it's possible to launch godoc, immediately GET /, and see a directory listing instead of root.html R=gri CC=golang-dev https://golang.org/cl/5575054
-
Robert Griesemer authored
R=r, bradfitz CC=golang-dev https://golang.org/cl/5574059
-
Andrew Balholm authored
Fixes #2755 R=dsymonds, rsc CC=golang-dev https://golang.org/cl/5571052
-
Rob Pike authored
R=golang-dev, adg CC=golang-dev https://golang.org/cl/5570060
-
Robert Griesemer authored
R=r, bradfitz CC=golang-dev https://golang.org/cl/5574058
-
- 24 Jan, 2012 19 commits
-
-
Nigel Tao authored
work in progress, and we are not ready to freeze its API for Go 1. Package html still exists, containing just two functions: EscapeString and UnescapeString. Both the packages at exp/html and html are "package html". The former is a superset of the latter. At some point in the future, the exp/html code will move back into html, once we have finalized the parser API. R=rsc, dsymonds CC=golang-dev https://golang.org/cl/5571059
-
Gustavo Niemeyer authored
Marshaler has a number of open areas that need further thought (e.g. it doesn't handle attributes, it's supposed to handle tag names internally but has no information to do so, etc). We're removing it now and will bring it back with an interface that covers these aspects, after Go 1. Related to issue 2771, but doesn't fix it. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5574057
-
Andrew Gerrand authored
R=golang-dev, bradfitz, rsc, r, gri, r CC=golang-dev https://golang.org/cl/5543047
-
Gustavo Niemeyer authored
That was supposed to be in the original CL, but missed the files. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5570052
-
Andrew Gerrand authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/5564050
-
Brad Fitzpatrick authored
Fixes #2628 R=golang-dev, gri CC=golang-dev https://golang.org/cl/5571058
-
Brad Fitzpatrick authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/5570056
-
Shenghou Ma authored
In order to allow buildscript.sh to generate buildscripts for all $GOOS/$GOARCH combinations, we have to generate dummy files for cmd/go. Fixes #2586. R=rsc, golang-dev CC=golang-dev https://golang.org/cl/5557050
-
Brad Fitzpatrick authored
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5574056
-
Olivier Duperray authored
Fixes #2759. R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5570053
-
Brad Fitzpatrick authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/5575049
-
Russ Cox authored
R=golang-dev, bradfitz CC=golang-dev https://golang.org/cl/5569054
-
Ivan Krasin authored
R=rsc, imkrasin CC=golang-dev https://golang.org/cl/5569048
-
Brad Fitzpatrick authored
Also, add an explicit error type when the right hand side is an unexported function. R=golang-dev, gri, rogpeppe, agl, rsc CC=golang-dev https://golang.org/cl/5564048
-
Luuk van Dijk authored
Fixes #2700. R=rsc CC=golang-dev https://golang.org/cl/5574046
-
Gustavo Niemeyer authored
Includes gofix module. The only case not covered should be xml.Unmarshal, since it remains with a similar interface, and would require introspecting the type of its first argument better. Fixes #2626. R=golang-dev, rsc, gustavo CC=golang-dev https://golang.org/cl/5574053
-
Robert Griesemer authored
CL 5572043 removed the last uses of this field. The information is readily available from Type.Decl. R=rsc, golang-dev CC=golang-dev https://golang.org/cl/5570049
-
Rob Pike authored
R=nigeltao, christoph, rsc, r, tux21b CC=golang-dev https://golang.org/cl/5573048
-
Robert Griesemer authored
Also: remove an unused template variable declaration. R=adg CC=golang-dev https://golang.org/cl/5572043
-
- 23 Jan, 2012 1 commit
-
-
David G. Andersen authored
The bitLen function currently shifts out blocks of 8 bits at a time. This change replaces this sorta-linear algorithm with a log(N) one (shift out 16 bits, then 8, then 4, then 2, then 1). I left the start of it linear at 16 bits at a time so that the function continues to work with 32 or 64 bit values without any funkiness. The algorithm is similar to several of the nlz ("number of leading zeros") algorithms from "Hacker's Delight" or the "bit twiddling hacks" pages. Doesn't make a big difference to the existing benchmarks, but I'm using the code in a different context that calls bitLen much more often, so it seemed worthwhile making the existing codebase faster so that it's a better building block. Microbenchmark results on a 64-bit Macbook Pro using 6g from weekly.2012-01-20: benchmark old ns/op new ns/op delta big.BenchmarkBitLen0 4 6 +50.12% big.BenchmarkBitLen1 4 6 +33.91% big.BenchmarkBitLen2 6 6 +3.05% big.BenchmarkBitLen3 7 6 -19.05% big.BenchmarkBitLen4 9 6 -30.19% big.BenchmarkBitLen5 11 6 -42.23% big.BenchmarkBitLen8 16 6 -61.78% big.BenchmarkBitLen9 5 6 +18.29% big.BenchmarkBitLen16 18 7 -60.99% big.BenchmarkBitLen17 7 6 -4.64% big.BenchmarkBitLen31 19 7 -62.49% On an ARM machine (with the previous weekly): benchmark old ns/op new ns/op delta big.BenchmarkBitLen0 37 50 +36.56% big.BenchmarkBitLen1 59 51 -13.69% big.BenchmarkBitLen2 74 59 -20.40% big.BenchmarkBitLen3 92 60 -34.89% big.BenchmarkBitLen4 110 59 -46.09% big.BenchmarkBitLen5 127 60 -52.68% big.BenchmarkBitLen8 181 59 -67.24% big.BenchmarkBitLen9 78 60 -23.05% big.BenchmarkBitLen16 199 69 -65.13% big.BenchmarkBitLen17 91 70 -23.17% big.BenchmarkBitLen31 210 95 -54.43% R=golang-dev, dave, edsrzf, gri CC=golang-dev https://golang.org/cl/5570044
-