Manual changes to the following files:
src/pkg/Makefile
src/pkg/exp/vector/Makefile (now: src/pkg/container/vector/Makefile)
R=rsc, r
CC=golang-dev
https://golang.org/cl/181041
- use an interface {Get()}
- implement Get for maps, slices
- for slices, retrieves the address of the end of the array, which will give the
same value for every slice of the same array.
R=rsc
CC=golang-dev
https://golang.org/cl/179129
(Thanks to ken and rsc for pointing this out)
rsc:
ken pointed out that there's a race in the new
one-lock-per-channel code. the issue is that
if one goroutine has gone to sleep doing
select {
case <-c1:
case <-c2:
}
and then two more goroutines try to send
on c1 and c2 simultaneously, the way that
the code makes sure only one wins is the
selgen field manipulation in dequeue:
// if sgp is stale, ignore it
if(sgp->selgen != sgp->g->selgen) {
//prints("INVALID PSEUDOG POINTER\n");
freesg(c, sgp);
goto loop;
}
// invalidate any others
sgp->g->selgen++;
but because the global lock is gone both
goroutines will be fiddling with sgp->g->selgen
at the same time.
This results in a 7% slowdown in the single threaded case for a
ping-pong microbenchmark.
Since the cas predominantly succeeds, adding a simple check first
didn't make any difference.
R=rsc
CC=golang-dev
https://golang.org/cl/180068
Allows stand-alone types (e.g. []int as patterns) and doesn't require
a semicolon at the end (which are now mandatory terminators).
- Fix a matcher bug.
R=rsc
CC=golang-dev
https://golang.org/cl/179088
This is not a complete JPEG implementation (e.g. it does not handle
progressive JPEGs or restart markers), but I was able to take a photo
with my phone, and view the resultant JPEG in pure Go.
The decoder is simple, but slow. The Huffman decoder in particular
should be easily improvable, but optimization is left to future
changelists. Being able to inline functions in the inner loop should
also help performance.
The output is not pixel-for-pixel identical to libjpeg, although
identical behavior isn't necessarily a goal, since JPEG is a lossy
codec. There are at least two reasons for the discrepancy.
First, the inverse DCT algorithm used is the same as Plan9's
src/cmd/jpg, which has different rounding errors from libjpeg's
default IDCT implementation. Note that libjpeg actually has three
different IDCT implementations: one floating point, and two fixed
point. Out of those four, Plan9's seemed the simplest to understand,
partly because it has no #ifdef's or C macros.
Second, for 4:2:2 or 4:2:0 chroma sampling, this implementation does
nearest neighbor upsampling, compared to libjpeg's triangle filter
(e.g. see h2v1_fancy_upsample in jdsample.c).
The difference from the first reason is typically zero, but sometimes
1 (out of 256) in YCbCr space, or double that in RGB space. The
difference from the second reason can be as large as 8/256 in YCbCr
space, in regions of steep chroma gradients. Informal eyeballing
suggests that the net difference is typically imperceptible, though.
R=r
CC=golang-dev, rsc
https://golang.org/cl/164056
into consts in the resulting Go source. Previously known as issue 161047,
which I deleted accidentally. Fixes issue 207.
R=rsc
https://golang.org/cl/166059
