Benny Siegert [Fri, 13 May 2011 02:34:48 +0000 (22:34 -0400)]
image/tiff: Reject images with SampleFormat != 1.
The TIFF spec says that a baseline TIFF reader must gracefully terminate
when the image has a SampleFormat tag which it does not support.
For baseline compatibility, only SampleFormat=1 (the default) is needed.
Images with other sample formats (e.g. floating-point color values)
are very rare in practice.
Robert Griesemer [Thu, 12 May 2011 16:15:59 +0000 (09:15 -0700)]
go spec: clarify semantics of range clause
This CL proposes some subtle language changes
in an attempt to clarify the semantics of range
clauses and simplify uses of maps.
- nil maps behave like empty maps; but attempting
to set a value in a nil map causes a run-time panic
- nil channels are never ready for communication;
sending or reading from a nil channel blocks forever
- if there is only one index iteration variable in a
range clause and len(range expression) would be a constant,
the range expression is not evaluated.
(was discrepancy with len/cap before)
- the notion of what is a constant expression len(x)
for (pointer to) arrays x has been generalized and
simplified (can still be syntactically decided)
(before: more restrictive syntactic rule that was not
consistently implemented)
Robert Griesemer [Thu, 12 May 2011 16:01:50 +0000 (09:01 -0700)]
go/printer: more accurate comment for incomplete structs/interfaces
A struct or interface type node is marked incomplete if fields or
methods have been removed through any kind of filtering, not just
because entries are not exported.
The current message was misleading in some cases (for instance:
"godoc -src reflect Implements").
Robert Griesemer [Thu, 12 May 2011 16:01:10 +0000 (09:01 -0700)]
go/doc, godoc: when filtering for godoc, don't remove elements of a declaration
Partially revert CL 4518050. In go/doc.go, instead of calling the go/ast filter
functions, implement the corresponding match functions that do no remove
declaration elements.
Russ Cox [Thu, 12 May 2011 15:21:34 +0000 (11:21 -0400)]
dashboard: fix for branches
In the new world, one builder runs
gobuilder -commit
which uploads information about commits to the dashboard,
which then hands the work out to the builders by hash.
There is no assumption anymore that the commit numbers
are consistent across builders.
New builders will need to be deployed. For now darwin-amd64
is running the new builder to test the code.
The new JSON-based protocol for handing out work via /todo
should be easy to extend if we want to add support for sending
trial CLs to the builders.
This code is already running on godashboard.appspot.com.
R=adg, dave
CC=golang-dev
https://golang.org/cl/4519047
Anthony Martin [Thu, 12 May 2011 03:52:05 +0000 (23:52 -0400)]
ld: fix alignment of rodata section on Plan 9
This was causing a panic in the reflect package
since type.* pointers with their low bits set are
assumed to have certain flags set that disallow
the use of reflection.
Thanks to Pavel and Taru for help tracking down
this bug.
Brad Fitzpatrick [Thu, 12 May 2011 02:33:15 +0000 (22:33 -0400)]
http: fix two Transport gzip+persist crashes
There were a couple issues:
-- HEAD requests were attempting to be ungzipped,
despite having no content. That was fixed in
the previous patch version, but ultimately was
fixed as a result of other refactoring:
-- persist.go's ClientConn "lastbody" field was
remembering the wrong body, since we were
mucking with it later. Instead, ditch
ClientConn's readRes func field and add a new
method passing it in, so we can use a closure
and do all our bodyEOFSignal + gunzip stuff
in one place, simplifying a lot of code and
not requiring messing with ClientConn's innards.
-- closing the gzip reader didn't consume its
contents. if the caller wasn't done reading
all the response body and ClientConn closed it
(thinking it'd move past those bytes in the
TCP stream), it actually wouldn't. so introduce
a new wrapper just for gzip reader to have its
Close method do an ioutil.Discard on its body
first, before the close.
Christian Himpel [Wed, 11 May 2011 20:33:27 +0000 (13:33 -0700)]
http: write cookies according to RFC 6265
RFC 6265 requires that user agents MUST NOT send more than
one Cookie header in a request.
Note, this change also fixes an issue when sending requests
with more than one cookie header line to a php script served
by an apache web server. Apache concatenates the cookies
with ", ", but php tries to split them only at ";". E.g.
two cookies: "a=b, c=d" are seen by php as one cookie "a"
with the value "b, c=d".
Brad Fitzpatrick [Wed, 11 May 2011 19:11:32 +0000 (12:11 -0700)]
http: fix transport bug with zero-length bodies
An optimization in Transport which re-uses TCP
connections early in the case where there is
no response body interacted poorly with
ErrBodyReadAfterClose. Upon recycling the TCP
connection early we would Close the Response.Body
(in case the user forgot to), but in the case
of a zero-lengthed body, the user's handler might
not have run yet.
This CL makes sure the Transport doesn't try
to Close requests when we're about to immediately
re-use the TCP connection.
This also includes additional tests I wrote
while debugging.
Robert Griesemer [Tue, 10 May 2011 18:09:56 +0000 (11:09 -0700)]
go/ast, go/doc, godoc: consider struct fields and interface methods when filtering ASTs
So far, only top-level names where considered when trimming ASTs
using a filter function. For instance, "godoc reflect Implements"
didn't show the "Implements" method of the type Interface because
the local method name was not considered (on the other hand, "top-
level" declared methods associated with types were considered).
With this CL, AST filter functions look also at struct fields
and interface methods.
R=rsc, r
CC=golang-dev
https://golang.org/cl/4518050
Nigel Tao [Tue, 10 May 2011 00:25:32 +0000 (17:25 -0700)]
image/jpeg: speed up decoding by inlining the clip function and
writing the idct result directly to the image buffer instead of
storing it in an intermediate d.blocks field.
Writing to d.blocks was necessary when decoding to an image.RGBA image,
but now that we decode to a ycbcr.YCbCr we can write each component
directly to the image buffer.
Crude "time ./6.out" scores to decode a specific 2592x1944 JPEG 20
times show a 16% speed-up:
BEFORE
user 0m10.410s
user 0m10.400s
user 0m10.480s
user 0m10.480s
user 0m10.460s
AFTER
user 0m9.050s
user 0m9.050s
user 0m9.050s
user 0m9.070s
user 0m9.020s
Robert Griesemer [Mon, 9 May 2011 21:48:05 +0000 (14:48 -0700)]
go/parser: always introduce an ast.Object when declaring an identifier
When traversing parameter lists (e.g. for type checking), we want the
invariant that all identifers have associated objects (even _ idents),
so that we can associate a type with each object.
Alex Brainman [Sun, 8 May 2011 06:32:00 +0000 (16:32 +1000)]
syscall: fix bug in mksyscall_windows.pl
This change fixes generation of "shadow" variables for bool parameters.
Before the change, it was naming all bool variables with the same name of _p0.
Now it calls them _p0, _p1, ... So the code could compile.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4479047
Nigel Tao [Sun, 8 May 2011 01:57:32 +0000 (18:57 -0700)]
compress/lzw: silently drop implied codes that are too large,
instead of returning an error.
For example, http://www.w3.org/Graphics/GIF/spec-gif89a.txt
explicitly says that GIF encoders can use a full table as is,
without needing to send a clear code.
Benny Siegert [Thu, 5 May 2011 03:52:55 +0000 (20:52 -0700)]
image/tiff: implement a decoder.
The current iteration can decode 8-bit images in
grayscale, paletted, RGB, RGBA and NRGBA mode. LZW compression
is implemented but does not work on my test images.
Deflate (i.e. zlib) compression with or without a horizontal
predictor is supported.
Nigel Tao [Wed, 4 May 2011 17:17:53 +0000 (10:17 -0700)]
exp/draw: fast paths for drawing a YCbCr or an NRGBA onto an RGBA.
On my laptop, I had an 800x600 jpeg and an 800x600 png (with
transparency). I timed how long it took to draw each image onto an
equivalently sized, zeroed RGBA image.
Previously, the jpeg took 75ms and the png took 70ms, going through
the medium-fast path, i.e. func drawRGBA in draw.go.
After this CL, the jpeg took 14ms, and the png took 21ms with the
Over operator and 12ms with the Src operator.
It's only a rough estimate basd on one image file, but it should
give an idea of the order of magnitude of improvement.
R=rsc, r
CC=adg, golang-dev
https://golang.org/cl/4468044
Verified the change (on a fast machine) by removing the
existing sleep, in which case the race happens ~50% of the
time with GOMAXPROCS > 1, but recovers gracefully with
retries.
Russ Cox [Tue, 3 May 2011 14:39:11 +0000 (10:39 -0400)]
codereview: add release branch support
Note that if you are working on the upcoming release
branch you have to point your extension path to a
copy of lib/codereview/codereview.py that won't change
as the repository flips between release-branch and default branch.
This warning should only apply to this one branch and only to rsc,
but you never know.
Russ Cox [Mon, 2 May 2011 17:55:51 +0000 (13:55 -0400)]
misc/cgo/test: run tests
The new gotest ignores Test functions outside *_test.go files
(the old shell script allowed them), so replace one clumsy hack
with another.
The root problem is that the package makefiles only know
how to run cgo for source files in the package proper, not
for test files. Making it work for test files is probably more
trouble than it's worth.
Robert Griesemer [Mon, 2 May 2011 16:16:31 +0000 (09:16 -0700)]
go spec: restricted expressions may still be parenthesized
No language change.
- added a few examples with parentheses
- added a corresponding sentence to assignments
(this explicitly permits: (_) = 0, currently allowed by 6g,
gofmt, but marked as an error by gccgo).
Brad Fitzpatrick [Mon, 2 May 2011 14:26:40 +0000 (07:26 -0700)]
jpeg: speed up RGBA encoding ~%50
Avoids image.At(), color.RGBA(), opposing 8 bit shifts,
and min function calls in a loop. Not as pretty as before,
but the pure version is still there to revert back to
later if/when the compiler gets better.
before (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 64781360 ns/op 18.97 MB/s
after (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 42044300 ns/op 29.23 MB/s
(benchmarked on an HP z600; 16 core Xeon E5520 @ 2.27Ghz)
In comparison to 121 ms on this 2006 machine, on my
Core2 Duo 2.66 GHz laptop, the final BenchmarkEncodeRGBOpaque
runs in 27 ms. (these are all for 640x480 images)
R=nigeltao, rsc, r
CC=golang-dev
https://golang.org/cl/4432077