That way I don't have to constantly edit deploy.go (and fix it before
committing a CL) when debugging for GCE.
Change-Id: Ie4f75443e4356c5ce1a59931f3cb9e34344350be
When baseURL or listen is something like ":3179" or "0.0.0.0:3179", the
resulting server hostname in the client config would be useless.
Therefore, in that case we use req.Host to set the hostname instead.
Fixes issue #641
Change-Id: I33d65776fbac945a411f4328ebbbc5763dec8eb6
The systemd-docker image on Docker Hub uses an out of date version
of the Docker client. We build our own to get the version required
by recent CoreOS releases. See #646.
Change-Id: I0b1dc6c70f44055c8f92be44cf16269df8a63f0e
We redefine a MultipartReader(*http.Request) function to use instead of
req.MultipartReader, so we can get a (bugfixed) multipart Reader from
our vendored mime/multipart, instead of the buggy one from the stdlib's.
Fixes issue #642
Change-Id: I6a205bff915632d4ee77547e6e26bc0af99665e9
At a2119aca7dc82dc5b5cd40b1a2f56e82323da002 in go tip
because we want the bugfix at 821b54921a3cba5d853b531d4b03527c01bfc9b4
We could legitimately vendor as "vendor/mime/multipart" and shadow the
stdlib's but we do it in future for clarity.
Issue #642
Change-Id: Ifddbd4c9120936b8acc2f6ae31a97b1831b99f34
We can now use DialTLS when we need a custom TLS setup, i.e. with
android, or when using self-signed certificates, or when totally
skipping certificates verification.
This allows us to get rid of the scheme rewriting hack, which simplifies
things, in particular because we have less tricky URL/host parsing to
do.
For the sake of tests and not affecting "real" code, I introduced the
fake_android build tag, so the tests can use custom functions to
simulate testing whether we're on android.
Fixes#566
Change-Id: I72ac2bb69ad2365e98dd6ca2e7016ce9c2d7c57e
Instead of the old ./misc/pre-commit.githook
Also fix devcam hook pre-commit so we don't show the override message in
that case.
Change-Id: I390016765056b9c4d3331d12bef8f2581e5621df
I just wanted to update the Google Cloud Logging code (still in review
at: https://code-review.googlesource.com/#/c/2650/) but that required
updating tons of things. For instance, gocloud now always depends on
grpc, which depends on http2, which we already had in third_party, so
that now moves into vendor.
I was unable to run the tests because of some error. The error message
was useless.
But "go run make.go" compiles everything at least.
We don't rewrite import paths anymore, because we use the new vendor
mechanism that comes with Go 1.5.
Also remove misc/pre-commit.githook because of the above, and because
the rest is covered by devcam hook.
Change-Id: Iafb32e19b21d1df44b9625a5f58bf898e6b51fa8
Update our Go image to use Go1.5.
Also, with Go1.5, we can compile static binaries (with CGO_ENABLED=0 and
--tags=netgo) without having to first rebuild Go itself from source with
CGO_ENABLED=0.
Finally, with Go1.5, we can now cross-compile straight outta the (linux)
binary tarball (without having to first build the necessary runtime in
src).
For both these above reasons, we don't need to use the Go -src tarball,
and we don't need to have a dedicated Go docker image for each GOOS we
cross-compile too.
Yay, progress!
Change-Id: Ibafb542a4771b151638e796ad3df78e0c8f1a4bf
Later, we should look into using it for more cases. First, to see if we
can phase "halving in place" out, and also to see the gains with other
image types (non YCbCr).
Change-Id: I4b95e2039407f1a91e04cb502674819f17680e02
While investigating issue #635 I remembered that golang.org/x/image/draw
might offer some interesting features. It indeed happens to have some
rescaling routines that seem to work better in the YCbCr case than our
custom code, which is illustrated by these benchmarks:
% go test -v -bench Benchmark.*YCrCb.* -run Bench* -benchmem
% ./pkg/images/resize/
PASS
BenchmarkResizeYCrCb-4 20 79213653 ns/op
9437475 B/op 5 allocs/op
BenchmarkNewResizeYCrCb-4 100 15711294 ns/op
1048668 B/op 2 allocs/op
BenchmarkHalveYCrCb-4 100 17328467 ns/op
128 B/op 1 allocs/op
ok camlistore.org/pkg/images/resize 5.889s
One can see that not only the new resize is faster, and uses less memory
than the old one, but it is also about as fast as "resizing by halving
in place". And this is with the ApproxBiLinear algorithm; some quick
additional tests seemed to indicate that NearestNeighbor was twice as
fast, with about the same memory usage. I chose ApproxBiLinear as it
seemed the most conservative choice for now.
I think it is also worth investigating whether we can be rid of "halving
in place", since it would make for simpler code overall, and since
ApproxBiLinear might be faster in most cases. It would have the nice
side-effect of solving issue #635 too. However, "halving in place" will
always win when it comes to memory usage, so it depends on our
priorities.
Finally, these other new benchmarks show that using the new resize does
not make the #635 mystery much worse (going from ~16% to ~18%), and that
interestingly the results of the old resize and the new resize are
pretty different by themselves.
% go test -v -run TestCompare ./pkg/images/resize/
=== RUN TestCompareOldResizeToHalveInplace
--- FAIL: TestCompareOldResizeToHalveInplace (2.49s)
resize_test.go:377: *image.Gray PSNR 63.7793
resize_test.go:377: *image.Gray16 PSNR 59.9547
resize_test.go:377: *image.NRGBA PSNR 62.8252
resize_test.go:377: *image.NRGBA64 PSNR 62.8252
resize_test.go:377: *image.Paletted PSNR 51.4949
resize_test.go:377: *image.RGBA PSNR 62.8252
resize_test.go:377: *image.RGBA64 PSNR 62.8252
resize_test.go:377: *image.YCbCr PSNR 61.9664
resize_test.go:382: *image.YCbCr not the same 18077 pixels
different 16.35%
resize_test.go:377: *image.YCbCr PSNR 52.4121
resize_test.go:382: *image.YCbCr not the same 18139 pixels
different 16.40%
resize_test.go:377: *image.YCbCr PSNR 51.4972
resize_test.go:382: *image.YCbCr not the same 17932 pixels
different 16.21%
resize_test.go:377: *image.YCbCr PSNR 51.6399
resize_test.go:382: *image.YCbCr not the same 17881 pixels
different 16.17%
resize_test.go:377: *image.YCbCr PSNR 50.7736
resize_test.go:382: *image.YCbCr not the same 17976 pixels
different 16.25%
resize_test.go:377: *image.YCbCr PSNR 52.4536
resize_test.go:382: *image.YCbCr not the same 18180 pixels
different 16.44%
=== RUN TestCompareNewResizeToHalveInplace
--- FAIL: TestCompareNewResizeToHalveInplace (2.27s)
resize_test.go:377: *image.Gray PSNR 63.7793
resize_test.go:377: *image.Gray16 PSNR 59.9547
resize_test.go:377: *image.NRGBA PSNR 62.8252
resize_test.go:377: *image.NRGBA64 PSNR 62.8252
resize_test.go:377: *image.Paletted PSNR 51.4949
resize_test.go:377: *image.RGBA PSNR 62.8252
resize_test.go:377: *image.RGBA64 PSNR 62.8252
resize_test.go:377: *image.YCbCr PSNR 59.5902
resize_test.go:382: *image.YCbCr not the same 20757 pixels
different 18.77%
resize_test.go:377: *image.YCbCr PSNR 52.0962
resize_test.go:382: *image.YCbCr not the same 20811 pixels
different 18.82%
resize_test.go:377: *image.YCbCr PSNR 51.3374
resize_test.go:382: *image.YCbCr not the same 20671 pixels
different 18.69%
resize_test.go:377: *image.YCbCr PSNR 51.3586
resize_test.go:382: *image.YCbCr not the same 20618 pixels
different 18.64%
resize_test.go:377: *image.YCbCr PSNR 57.2346
resize_test.go:382: *image.YCbCr not the same 20705 pixels
different 18.72%
resize_test.go:377: *image.YCbCr PSNR 50.7504
resize_test.go:382: *image.YCbCr not the same 20847 pixels
different 18.85%
=== RUN TestCompareOldResizeToNewResize
--- FAIL: TestCompareOldResizeToNewResize (2.54s)
resize_test.go:377: *image.Gray PSNR +Inf
resize_test.go:377: *image.Gray16 PSNR +Inf
resize_test.go:377: *image.NRGBA PSNR +Inf
resize_test.go:377: *image.NRGBA64 PSNR +Inf
resize_test.go:377: *image.Paletted PSNR +Inf
resize_test.go:377: *image.RGBA PSNR +Inf
resize_test.go:377: *image.RGBA64 PSNR +Inf
resize_test.go:377: *image.YCbCr PSNR 59.1024
resize_test.go:382: *image.YCbCr not the same 16350 pixels
different 14.78%
resize_test.go:377: *image.YCbCr PSNR 62.6523
resize_test.go:377: *image.YCbCr PSNR 62.7010
resize_test.go:377: *image.YCbCr PSNR 59.1396
resize_test.go:382: *image.YCbCr not the same 16225 pixels
different 14.67%
resize_test.go:377: *image.YCbCr PSNR 59.0844
resize_test.go:382: *image.YCbCr not the same 16294 pixels
different 14.73%
resize_test.go:377: *image.YCbCr PSNR 59.0534
resize_test.go:382: *image.YCbCr not the same 16413 pixels
different 14.84%
Change-Id: Ia8c578a53416ec0f1cac1477a1a68acfede84b24
I also wonder if we want to take a more comprehensive approach to
environment variables, perhaps populating a struct at startup that other
code can consult later. But it might be too soon for that kind of thing
in this project.
Change-Id: I65a34622bf906c1256ceb357ba983bc5acd6b887
When uploading a file, we were already checking if the contents and file
blob already existed, and acted smartly accordingly. However, we were
still always creating a new permanode (and camliContent claim) for that
file.
This CL addresses that last point.
Fixes#622
Change-Id: Ifb5c8846e20b6684d25a7749c64b09904e07bb6f
url.Parse in Go 1.5 now fails with the scheme://IPv6:/foo form (trailing
colon). But it still works when the hostname is an actual hostname, or
an IPv4, which seems inconsistent.
This CL therefore not only accepts this new failure (which comes with Go
1.5) but also considers any host with a trailing colon as an invalid URL
and refuses to rewrite it.
There probably are other places in Camlistore where we should the same.
See https://github.com/golang/go/issues/12200
Change-Id: Ib9ea95a71013b5b53f2fd99415015ec916bb4d9d
We won't be rewriting the import paths of our third-parties anymore
since we use the new vendor mechanism that comes with Go 1.5. Hence, no
need to check for those rewrites anymore.
Change-Id: Ib9557b60c077190bfd5a6db95ad582f153aa4a68
Mathieu Lonjaret