Phrases like "returns whether or not the image is opaque" could be
describing what the function does (it always returns, regardless of
the opacity) or what it returns (a boolean indicating the opacity).
Even when the "or not" is missing, the phrasing is bizarre.
Go with "reports whether", which is still clunky but at least makes
it clear we're talking about the return value.
These were edited by hand. A few were cleaned up in other ways.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/11699043
This must have been from when "error" was a good variable
name for an "os.Error". But we use "err" these days.
R=golang-dev, dsymonds, r
CC=golang-dev
https://golang.org/cl/9132045
When using subexpressions ($1) as replacements, when they either don't exist or values weren't found causes a panic.
This patch ensures that the match location isn't -1, to prevent out of bounds errors.
Fixes#3816.
R=franciscossouza, rsc
CC=golang-dev
https://golang.org/cl/6931049
Ran 'double.pl' on the pkg tree to identify doubled words.
One change to an error string return in x509; the rest are in comments.
Thanks to Matt Jibson for the idea.
R=golang-dev, bsiegert
CC=golang-dev
https://golang.org/cl/6344089
ReadRune. (If you have a Reader but not a RuneReader, use bufio.)
The matching code is a few percent slower but significantly cleaner.
R=rsc
CC=golang-dev
https://golang.org/cl/4125046
Minor cleanup:
- removed a duplicate test case
- added a function to remove repeated code
- for consistency, replaced "return nil" with a panic at an
unreachable point
Fixes#1428.
R=golang-dev, r, rsc
CC=golang-dev
https://golang.org/cl/4057042
After a prefix match, the old code advanced the length of the
prefix. This is incorrect since the full match might begin
in the middle of the prefix. (Consider "aaaab+" matching
"aaaaaab").
Fixes#1373
R=rsc
CC=golang-dev
https://golang.org/cl/3795044
The bug was that for an anchored pattern such as ^x, the prefix
scan ignored the anchor, and could scan the whole file if there was
no x present. The fix is to do prefix matching after the anchor;
the cost miniscule; the speedups huge.
R=rsc, gri
CC=golang-dev
https://golang.org/cl/3837042
The former is a boolean function to test whether a string
contains a regular expression metacharacter; the second
returns the string used to compile the regexp.
R=gri, rsc
CC=golang-dev
https://golang.org/cl/3728041
The code used interfaces in a pretty, pedagogical way but not efficiently.
Remove unnecessary interface code for significant speedups.
Before:
regexp.BenchmarkLiteral 1000000 2629 ns/op
regexp.BenchmarkNotLiteral 100000 18131 ns/op
regexp.BenchmarkMatchClass 100000 26647 ns/op
regexp.BenchmarkMatchClass_InRange 100000 27092 ns/op
regexp.BenchmarkReplaceAll 100000 27014 ns/op
After:
regexp.BenchmarkLiteral 1000000 2077 ns/op
regexp.BenchmarkNotLiteral 100000 13738 ns/op
regexp.BenchmarkMatchClass 100000 20418 ns/op
regexp.BenchmarkMatchClass_InRange 100000 20999 ns/op
regexp.BenchmarkReplaceAll 100000 21825 ns/op
There's likely more to do without major surgery, but this is a simple, significant step.
R=rsc
CC=golang-dev
https://golang.org/cl/3572042
Changed all uses of bytes.Add (aside from those testing bytes.Add) to append(a, b...).
Also ran "gofmt -s" and made use of copy([]byte, string) in the fasta benchmark.
R=golang-dev, r, r2
CC=golang-dev
https://golang.org/cl/3302042
The previous set was spotty, incomplete, and confusing.
This CL proposes a regular, clean set with clearer names.
It's also complete. Many existing methods will be deprecated,
but not in this CL. Ditto for the tests.
R=rsc, gri
CC=golang-dev, rog
https://golang.org/cl/1946041
charclass to avoid unnecessarily iterating over ranges.
Also, use the fact that IntVector is an []int to avoid method calls.
On my machine, this brings us from ~27500 ns/op to ~17500 ns/op in the benchmark I've added (it is also faster in the case where a range check
doesn't help, added a benchmark for this too.)
I'd also like to propose that "[]", and "[^]" be disallowed. They aren't useful as far as I can tell, they aren't widely supported, and they make reasoning about character classes a bit more complicated.
R=r
CC=golang-dev
https://golang.org/cl/1495041