This is a replacement for pending CL 2219042. It only contains
the raw suffixarray functionality with two methods:
- New create a new index from some data
- Lookup lookup occurences of a bytes slice in the data
Any other functionality (dealing with multiple data sets and
the corresponding position lists) is generic and doesn't have
to be part of this package.
Known performance bug: This implementation works fine for data sets
up to several megabytes as long as it doesn't contain very long
contiguous sequences of equal bytes. For instance, index creation for
all .go files under GOROOT (250KLOCs, approx. 9MB) takes ~50s on
2.66 GHz Intel Xeon as long as test/fixedbugs/257.go is excluded.
With that file, index creation times takes several days. 257.go contains
a string of 1M smiley faces.
There are more sophisticated suffixarray creation algorithms which
can handle very long common prefixes. The implementation can be
updated w/o the need to change the interface.
R=rsc, r, PeterGo
CC=golang-dev
https://golang.org/cl/2265041
Add windows NOTEST list to pkg make file.
5a make file. the change removes a space
character that was included when appending
an extension to TARG.
R=brainman, rsc
CC=golang-dev
https://golang.org/cl/2140046
- 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
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
Generic text-based network protcol library for SMTP-like protocols.
HTTP and NNTP should be changed to use this package,
and I expect that SMTP and POP3 will be able to use it too.
R=cemeyer, nigeltao_golang, r
CC=golang-dev, petar-m
https://golang.org/cl/889041
Somewhat of a work-in-progress (in that MIME is a large spec), but this is
functional and enough for discussion and/or code review.
In addition to the unit tests, I've tested with curl and Chrome with
a variety of test files, making sure the digests of files are unaltered
when read via a multipart Part.
R=rsc, adg, dsymonds1, agl1
CC=golang-dev
https://golang.org/cl/1681049
- go/ast: removed StringList (not needed anymore)
- go/ast: changed import path and field list tag to a single string
- updated all dependencies
R=rsc
CC=golang-dev
https://golang.org/cl/217056
Emphasis on minimal interface and fast scanning.
Recognizes all Go literals by default. Easily
configurable to recognize different whitespace
characters and tokens.
Provides detailed position information for each
token.
R=rsc, r
CC=golang-dev
https://golang.org/cl/181160
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
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
