Not a bug per-se, the issue is that the fmt.Sprintf method inside the
ByteSize.String() method ends up calling itself to generate the String
representation of the ByteSize value. Infinite loops are bad.
Updated as per review comments
R=r
CC=golang-dev
https://golang.org/cl/1974046
Two tests start a goroutine which runs exportSend, and then
the tests run importReceive. exportSend creates an export
channel. importReceive asks to receive values on that
channel. Because exportSend runs in a separate goroutine,
it's possible for the export client to receive the request for
values on the channel, from importReceive, before the
goroutine actually creates the export channel. That causes an
error: "export: no such channel: exportedSend". This patch
avoids the race by creating the export channel before starting
the goroutine.
There does not seem to be a similar race condition in the
tests which send data in the other direction.
R=r
CC=golang-dev
https://golang.org/cl/2026045
End the charade (farce?) that we are using upload.py unaltered.
Cut all the unused stuff.
Indent using tabs to match the rest of the file.
Next: rewrite MercurialVCS to use mercurial package,
to avoid overhead of forking off a new hg command
multiple times for every file. And parallelize upload.
R=gri
CC=golang-dev
https://golang.org/cl/2009046
- refine/define Scope, Object, and Type structures
(note: scope.go has the addition of types, the rest is only re-organized
for better readability)
- implemented top-level of type checker:
resolve global type declarations (deal with double decls, cycles, etc.)
- temporary hooks for checking of const/var declarations, function/method bodies
- test harness for fine-grained testing (exact error locations)
with initial set of tests
This is a subset of the code for easier review.
R=rsc
CC=golang-dev
https://golang.org/cl/1967049
Based on the observation that a great number of the types that
are copied or compared in interfaces, maps, and channels are
word-sized, this uses specialized copy and equality functions
for them that use a word instead of 4 or 8 bytes. Seems to yield
0-6% improvements in performance in the benchmarks I've run.
For example, with the regexp benchmarks:
Before:
regexp.BenchmarkLiteral 500000 3.26 µs/op
regexp.BenchmarkNotLiteral 100000 13.67 µs/op
regexp.BenchmarkMatchClass 100000 18.72 µs/op
regexp.BenchmarkMatchClass_InRange 100000 20.04 µs/op
regexp.BenchmarkReplaceAll 100000 27.85 µs/op
After:
regexp.BenchmarkLiteral 500000 3.11 µs/op
regexp.BenchmarkNotLiteral 200000 13.29 µs/op
regexp.BenchmarkMatchClass 100000 17.65 µs/op
regexp.BenchmarkMatchClass_InRange 100000 18.49 µs/op
regexp.BenchmarkReplaceAll 100000 26.34 µs/op
R=rsc
CC=golang-dev
https://golang.org/cl/1967047
This way, if you later want to check things in,
you can (with appropriate authorization).
Using plain http leads to the cryptic error
abort: HTTP Method Not Allowed.
R=r
CC=golang-dev
https://golang.org/cl/1983050
Commands written in Go depend on Go packages, so they
cannot be built by src/cmd/make.bash. They have been
built by src/make.bash after all the packages are done, but
we want to be able to use cgo (written in Go) during the build
of package net. To make this possible, build the commands
from src/pkg/Makefile instead of src/make.bash, so that they
are included in the package dependency analysis.
R=r
CC=golang-dev
https://golang.org/cl/1972046
$ hg p
codereview disabled: cannot open /Users/rsc/g/go/src/pkg/goplan9.googlecode.com/hg/lib/codereview/codereview.cfg
$
R=dsymonds, r
CC=golang-dev
https://golang.org/cl/1998046
Due to header key normalization/typo, the server never responds with
the protocol header in place. This breaks all (draft76) applications
that are using the protocol-header.
R=ukai, rsc
CC=golang-dev
https://golang.org/cl/1969046
