Also add a byte count to the varint benchmarks - this
isn't accurate, of course, but it allows a rough comparison to
the other benchmarks.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5496070
The algorithm is the same as in the double-conversion library
which also implements Florian Loitsch's fast printing algorithm.
It uses extended floats with a 64-bit mantissa, but cannot give
an answer for all cases.
old ns/op new ns/op speedup
BenchmarkAtof64Decimal 332 322 1.0x
BenchmarkAtof64Float 385 373 1.0x
BenchmarkAtof64FloatExp 9777 419 23.3x
BenchmarkAtof64Big 3934 691 5.7x
BenchmarkAtof64RandomBits 34060 899 37.9x
BenchmarkAtof64RandomFloats 1329 680 2.0x
See F. Loitsch, ``Printing Floating-Point Numbers Quickly and
Accurately with Integers'', Proceedings of the ACM, 2010.
R=ality, rsc
CC=golang-dev, remy
https://golang.org/cl/5494068
This is like the ill-fated CL 5493063 except that
I have written a shell script (autogen.sh) instead of
thinking I could possibly write a correct Makefile.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5496075
An old update for API changes in reflect package left several
helper variables that do not have a meaning anymore, and
the type checking of arrays vs slices was broken.
Fixes#2513.
R=ultrotter, rsc
CC=golang-dev, remy
https://golang.org/cl/5488094
The longest numbers we have to represent are the smallest denormals.
Their decimal mantissa is not longer than 5^1100. Taking into
account some extra size for in-place operations, 800 digits are
enough. This saves time used for zero intiialization of extra
bytes.
old ns/op new ns/op delta
strconv_test.BenchmarkAtof64Decimal 521 334 -35.9%
strconv_test.BenchmarkAtof64Float 572 391 -31.6%
strconv_test.BenchmarkAtof64FloatExp 10242 10036 -2.0%
strconv_test.BenchmarkAtof64Big 4229 4029 -4.7%
strconv_test.BenchmarkFormatFloatDecimal 1396 934 -33.1%
strconv_test.BenchmarkFormatFloat 4295 3341 -22.2%
strconv_test.BenchmarkFormatFloatExp 12035 11181 -7.1%
strconv_test.BenchmarkFormatFloatBig 4213 3229 -23.4%
strconv_test.BenchmarkAppendFloatDecimal 1031 600 -41.8%
strconv_test.BenchmarkAppendFloat 3971 3044 -23.3%
strconv_test.BenchmarkAppendFloatExp 11699 11003 -5.9%
strconv_test.BenchmarkAppendFloatBig 3836 2915 -24.0%
R=golang-dev, bradfitz, rsc
CC=golang-dev, remy
https://golang.org/cl/5491064
Not all syscalls are implemented, but many are. On the suggestion
of Joel Sing <jsing@google.com>, the generated files were added
with hg add instead of hg cp, since they are generated on an OS
dependant basis.
R=golang-dev, jsing, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/5491050
We still very much assume it in the code, but with this change in
place we can implement other things later without changing and users
of the package.
Fixes#2319.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/5489073
Add NetBSD to mksignals.sh and generate files.
While we're here, also add netbsd to the +build list where appropriate.
R=golang-dev, jsing
CC=golang-dev
https://golang.org/cl/5492064
That was the last build that was close to working.
I will try that change again next week.
Make is being very subtle today.
At the reverted-to CL, the ARM traceback appears
to be broken. I'll look into that next week too.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5492063
- no empty lines inside empty structs and interfaces
- top-level declarations are separated by a blank line if
a) they are of different kind (e.g. const vs type); or
b) there are documentation comments associated with a
declaration (this is new)
- applied gofmt -w misc src
The actual changes are in go/printer/nodes.go:397-400 (empty structs/interfaces),
and go/printer/printer.go:307-309 (extra line break). The remaining
changes are cleanups w/o changing the existing functionality.
Fixes issue 2570.
R=rsc
CC=golang-dev
https://golang.org/cl/5493057
Why it was not failing anywhere else I don't know,
but the Makefile was definitely wrong. The rules
must not run in parallel.
TBR=r
CC=golang-dev
https://golang.org/cl/5489069
I am looking forward to not supporting two build
systems simultaneously. Make complains about
a circular dependency still, but I don't understand it
and it's probably not worth the time to figure out.
TBR=r
CC=golang-dev
https://golang.org/cl/5496058
Collapse the arch,os-specific directories into the main directory
by renaming xxx/foo.c to foo_xxx.c, and so on.
There are no substantial edits here, except to the Makefile.
The assumption is that the Go tool will #define GOOS_darwin
and GOARCH_amd64 and will make any file named something
like signals_darwin.h available as signals_GOOS.h during the
build. This replaces what used to be done with -I$(GOOS).
There is still work to be done to make runtime build with
standard tools, but this is a big step. After this we will have
to write a script to generate all the generated files so they
can be checked in (instead of generated during the build).
R=r, iant, r, lucio.dere
CC=golang-dev
https://golang.org/cl/5490053
In 'go test' I deleted the leading package. prefix
from all the test names, since it contained no actual
information. Adjust the -test.run argument accordingly.
This will still work with the current gotest too, since
the argument is an unanchored pattern.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5491058
I'm not 100% sure I get all the corner cases right, for end tags, but
I'll let the test suite smoke it out.
Pass tests10.dat, test 1:
<!DOCTYPE html><svg></svg><![CDATA[a]]>
| <!DOCTYPE html>
| <html>
| <head>
| <body>
| <svg svg>
| <!-- [CDATA[a]] -->
Also pass tests through test 5:
<!DOCTYPE html><body><table><svg></svg></table>
R=andybalholm
CC=golang-dev
https://golang.org/cl/5495044
In some rare cases, gofmt would accept more than the maximum
number of empty lines (1) between source code snippets.
The actual change is in printer.go, lines 773-775; the rest
is some minor restructuring.
Applied gofmt -w src misc .
Fixes#2387.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5496047
If a Pipe method is called, return the underlying
reader/writer from session.clientChan, bypassing the
io.Copy and io.Pipe harness.
StdoutPipe and StderrPipe now return an io.Reader not
an io.ReadCloser as SSH cannot signal the close of the
local reader to the remote process.
R=rsc, agl, gustav.paul, cw
CC=golang-dev
https://golang.org/cl/5493047
%g down to two mallocs from four. Also a mild speedup.
fmt_test.BenchmarkSprintfFloat 3016 2703 -10.38%
Fixes#2557.
R=rsc
CC=golang-dev
https://golang.org/cl/5491054
Before/after, best of 3:
json.BenchmarkCodeEncoder 10 183495300 ns/op 10.58 MB/s
->
json.BenchmarkCodeEncoder 10 133025100 ns/op 14.59 MB/s
But don't get too excited about this. These benchmarks, while
stable at any point of time, fluctuate wildly with any line of
code added or removed anywhere in the path due to stack splitting
issues.
It's currently much faster, though, and this is the API that
doesn't allocate so should always be faster in theory.
R=golang-dev, dsymonds, rsc, r, gri
CC=golang-dev
https://golang.org/cl/5411052
It is probably a mistake to have these here at all -
os is supposed to be portable - but this only fixes
the build issue.
R=golang-dev, r, r, iant
CC=golang-dev
https://golang.org/cl/5487073
Pass tests6.dat, test 26:
foo<col>
| <col>
Also pass tests through test 35:
<table><tr><div><td>
R=nigeltao
CC=golang-dev
https://golang.org/cl/5482074
I realize I didn't send the tests in last time. Anyway, I added
a test that knows too much about the package's internal structure,
and I'm not sure whether it's the right thing to do.
Vadik.
R=bradfitz, rsc, go.peter.90
CC=golang-dev
https://golang.org/cl/5450073
This redefinition means that the public signature of html/template
does not refer to text/template.
Fixes#2546.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5487083
We only want to attempt to un-gzip if there's a body (not in
response to a HEAD)
This was accidentally passing before, but revealed to be broken
when c3c6e72d7cc went in.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5477093
The obvious fix is breaking the build in non-obvious ways.
Reverting while waiting for the correct fix, if any is needed.
««« original CL description
net/http: fix bug in error checking
Thanks to josef86@gmail.com for pointing this out.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/5477092
»»»
R=iant
CC=golang-dev
https://golang.org/cl/5488085
The transmitter must encode an interface value if it is to be decoded
into an interface value, but it's a common and confusing error to
encode a concrete value and attempt to decode it into an interface,
particularly *interface{}. This CL attempts to explain things better.
Fixes#2367.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5485072
Testing total space fails for gccgo when not using split
stacks, because then each goroutine has a large stack, and so
the total memory usage is large.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5487068
I was confused by the existence of two portable Hypot
routines in the tree when I cleaned things up, and I made
ARM use the wrong (imprecise) one. Use the right one,
and delete the wrong one.
Fixes arm build.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5485065
breaks build
««« original CL description
http: close connection after printing panic stack trace
In a testing situation, it's possible for a local http
server to panic and the test exit without the stack trace
ever being printed.
Fixes#2480.
R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/5414048
»»»
R=bradfitz
CC=golang-dev
https://golang.org/cl/5482061
In a testing situation, it's possible for a local http
server to panic and the test exit without the stack trace
ever being printed.
Fixes#2480.
R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/5414048
This will be nicer to the automatic tools.
It requires a few more assembly stubs
but fewer Go files.
There are a few instances where it looks like
there are new blobs of code, but they are just
being copied out of deleted files.
There is no new code here.
Suppose you have a portable implementation for Sin
and a 386-specific assembly one. The old way to
do this was to write three files
sin_decl.go
func Sin(x float64) float64 // declaration only
sin_386.s
assembly implementation
sin_port.go
func Sin(x float64) float64 { ... } // pure-Go impl
and then link in either sin_decl.go+sin_386.s or
just sin_port.go. The Makefile actually did the magic
of linking in only the _port.go files for those without
assembly and only the _decl.go files for those with
assembly, or at least some of that magic.
The biggest problem with this, beyond being hard
to explain to the build system, is that once you do
explain it to the build system, godoc knows which
of sin_port.go or sin_decl.go are involved on a given
architecture, and it (correctly) ignores the other.
That means you have to put identical doc comments
in both files.
The new approach, which is more like what we did
in the later packages math/big and sync/atomic,
is to have
sin.go
func Sin(x float64) float64 // decl only
func sin(x float64) float64 {...} // pure-Go impl
sin_386.s
// assembly for Sin (ignores sin)
sin_amd64.s
// assembly for Sin: jmp sin
sin_arm.s
// assembly for Sin: jmp sin
Once we abandon Makefiles we can put all the assembly
stubs in one source file, so the number of files will
actually go down.
Chris asked whether the branches cost anything.
Given that they are branching to pure-Go implementations
that are not typically known for their speed, the single
direct branch is not going to be noticeable. That is,
it's on the slow path.
An alternative would have been to preserve the old
"only write assembly files when there's an implementation"
and still have just one copy of the declaration of Sin
(and thus one doc comment) by doing:
sin.go
func Sin(x float64) float64 { return sin(x) }
sin_decl.go
func sin(x float64) float64 // declaration only
sin_386.s
// assembly for sin
sin_port.go
func sin(x float64) float64 { portable code }
In this version everyone would link in sin.go and
then either sin_decl.go+sin_386.s or sin_port.go.
This has an extra function call on all paths, including
the "fast path" to get to assembly, and it triples the
number of Go files involved compared to what I did
in this CL. On the other hand you don't have to
write assembly stubs. After starting down this path
I decided that the assembly stubs were the easier
approach.
As for generating the assembly stubs on the fly, much
of the goal here is to eliminate magic from the build
process, so that zero-configuration tools like goinstall
or the new go tool can handle this package.
R=golang-dev, r, cw, iant, r
CC=golang-dev
https://golang.org/cl/5488057
Example:
PACKAGE
package utf8
import "unicode/utf8"
Package utf8 implements functions and constants to support text
encoded in UTF-8. This package calls a Unicode character a rune for
brevity.
CONSTANTS
const (
RuneError = unicode.ReplacementChar // the "error" Rune or "replacement character".
RuneSelf = 0x80 // characters below Runeself are represented as themselves in a single byte.
UTFMax = 4 // maximum number of bytes of a UTF-8 encoded Unicode character.
)
Numbers fundamental to the encoding.
FUNCTIONS
func DecodeLastRune(p []byte) (r rune, size int)
DecodeLastRune unpacks the last UTF-8 encoding in p and returns the
rune and its width in bytes.
func DecodeLastRuneInString(s string) (r rune, size int)
DecodeLastRuneInString is like DecodeLastRune but its input is a
string.
func DecodeRune(p []byte) (r rune, size int)
DecodeRune unpacks the first UTF-8 encoding in p and returns the rune
and its width in bytes.
func DecodeRuneInString(s string) (r rune, size int)
DecodeRuneInString is like DecodeRune but its input is a string.
func EncodeRune(p []byte, r rune) int
EncodeRune writes into p (which must be large enough) the UTF-8
encoding of the rune. It returns the number of bytes written.
func FullRune(p []byte) bool
FullRune reports whether the bytes in p begin with a full UTF-8
encoding of a rune. An invalid encoding is considered a full Rune
since it will convert as a width-1 error rune.
func FullRuneInString(s string) bool
FullRuneInString is like FullRune but its input is a string.
func RuneCount(p []byte) int
RuneCount returns the number of runes in p. Erroneous and short
encodings are treated as single runes of width 1 byte.
func RuneCountInString(s string) (n int)
RuneCountInString is like RuneCount but its input is a string.
func RuneLen(r rune) int
RuneLen returns the number of bytes required to encode the rune.
func RuneStart(b byte) bool
RuneStart reports whether the byte could be the first byte of an
encoded rune. Second and subsequent bytes always have the top two
bits set to 10.
func Valid(p []byte) bool
Valid reports whether p consists entirely of valid UTF-8-encoded
runes.
func ValidString(s string) bool
ValidString reports whether s consists entirely of valid UTF-8-encoded
runes.
TYPES
type String struct {
// contains filtered or unexported fields
}
String wraps a regular string with a small structure that provides
more efficient indexing by code point index, as opposed to byte index.
Scanning incrementally forwards or backwards is O(1) per index
operation (although not as fast a range clause going forwards).
Random access is O(N) in the length of the string, but the overhead is
less than always scanning from the beginning. If the string is ASCII,
random access is O(1). Unlike the built-in string type, String has
internal mutable state and is not thread-safe.
func NewString(contents string) *String
NewString returns a new UTF-8 string with the provided contents.
func (s *String) At(i int) rune
At returns the rune with index i in the String. The sequence of runes
is the same as iterating over the contents with a "for range" clause.
func (s *String) Init(contents string) *String
Init initializes an existing String to hold the provided contents.
It returns a pointer to the initialized String.
func (s *String) IsASCII() bool
IsASCII returns a boolean indicating whether the String contains only
ASCII bytes.
func (s *String) RuneCount() int
RuneCount returns the number of runes (Unicode code points) in the
String.
func (s *String) Slice(i, j int) string
Slice returns the string sliced at rune positions [i:j].
func (s *String) String() string
String returns the contents of the String. This method also means the
String is directly printable by fmt.Print.
Fixes#2479.
R=golang-dev, dsymonds, mattn.jp, r, gri, r
CC=golang-dev
https://golang.org/cl/5472051
To allow these types as map keys, we must fill in
equal and hash functions in their algorithm tables.
Structs or arrays that are "just memory", like [2]int,
can and do continue to use the AMEM algorithm.
Structs or arrays that contain special values like
strings or interface values use generated functions
for both equal and hash.
The runtime helper func runtime.equal(t, x, y) bool handles
the general equality case for x == y and calls out to
the equal implementation in the algorithm table.
For short values (<= 4 struct fields or array elements),
the sequence of elementwise comparisons is inlined
instead of calling runtime.equal.
R=ken, mpimenov
CC=golang-dev
https://golang.org/cl/5451105
