This is a core API change.
1) gofix misc src
2) Manual adjustments to the following files under src/pkg:
gob/decode.go
rpc/client.go
os/error.go
io/io.go
bufio/bufio.go
http/request.go
websocket/client.go
as well as:
src/cmd/gofix/testdata/*.go.in (reverted)
test/fixedbugs/bug243.go
3) Implemented gofix patch (oserrorstring.go) and test case (oserrorstring_test.go)
Compiles and runs all tests.
R=r, rsc, gri
CC=golang-dev
https://golang.org/cl/4607052
Currently, when an importer closes the connection, the exporter gives an
error message 'netchan export: error decoding client header:EOF'. This
change causes the exporter to look for an EOF during the parse of the
header, and silences the log message in that case.
R=r
CC=golang-dev, rog
https://golang.org/cl/4132044
This aligns the naming scheme with the testing package and
also lets govet work on more logging calls.
R=rsc
CC=golang-dev
https://golang.org/cl/4001048
This was broken after the last update (2011-01-20).
However, I'm not sure if the changed example is a
sensible use of import(), so I'd appreciate comments.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4067043
When data is received for a channel, but that channel
is not ready to receive it, the central run() loop
is currently blocked, but this can lead to deadlock
and interference between independent channels.
This CL adds an explicit buffer size to netchan
channels (an API change) - the sender will not
send values until the buffer is non empty.
The protocol changes to send ids rather than channel names
because acks can still be sent after a channel is hung up,
we we need an identifier that can be ignored.
R=r, rsc
CC=golang-dev
https://golang.org/cl/2447042
I have written a tool to verify Printf calls, and although it's not
ready to be reviewed yet it's already uncovered a spate of problems
in the repository. I'm sending this CL to break the changes into
pieces; as the tool improves it will find more, I'm sure.
R=rsc
CC=golang-dev
https://golang.org/cl/3427043
There's no need to hold the client mutex when calling encode, since encode itself
uses a mutex to make the writes atomic. However, we need to keep
the messages ordered, so add a mutex for that purpose alone.
Fixes#1244.
R=rsc
CC=golang-dev
https://golang.org/cl/2833041
New logging interface simplifies and generalizes.
1) Loggers now have only one output.
2) log.Stdout, Stderr, Crash and friends are gone.
Logging is now always to standard error by default.
3) log.Panic* replaces log.Crash*.
4) Exiting and panicking are not part of the logger's state; instead
the functions Exit* and Panic* simply call Exit or panic after
printing.
5) There is now one 'standard logger'. Instead of calling Stderr,
use Print etc. There are now triples, by analogy with fmt:
Print, Println, Printf
What was log.Stderr is now best represented by log.Println,
since there are now separate Print and Println functions
(and methods).
6) New functions SetOutput, SetFlags, and SetPrefix allow global
editing of the standard logger's properties. This is new
functionality. For instance, one can call
log.SetFlags(log.Lshortfile|log.Ltime|log.Lmicroseconds)
to get all logging output to show file name, line number, and
time stamp.
In short, for most purposes
log.Stderr -> log.Println or log.Print
log.Stderrf -> log.Printf
log.Crash -> log.Panicln or log.Panic
log.Crashf -> log.Panicf
log.Exit -> log.Exitln or log.Exit
log.Exitf -> log.Exitf (no change)
This has a slight breakage: since loggers now write only to one
output, existing calls to log.New() need to delete the second argument.
Also, custom loggers with exit or panic properties will need to be
reworked.
All package code updated to new interface.
The test has been reworked somewhat.
The old interface will be removed after the new release.
For now, its elements are marked 'deprecated' in their comments.
Fixes#1184.
R=rsc
CC=golang-dev
https://golang.org/cl/2419042
Also add exporter.Drain() to wait for completion.
This makes it possible for an Exporter to fire off a message
and wait (by calling Drain) for the message to be received,
even if a client has yet to call to retrieve it.
Once this design is settled, I'll do the same for import send.
Testing strategies welcome. I have some working stand-alone
tests.
R=rsc
CC=golang-dev
https://golang.org/cl/2137041
It's unlikely to affect any extant code, but I wanted to make this API change
before digging in for a rewrite.
R=rsc
CC=golang-dev
https://golang.org/cl/2112041
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
limitations:
poor error handling
teardown not done
exporter must send, importer must receive
testing is rudimentary at best
R=rsc
CC=golang-dev
https://golang.org/cl/186234
