Activity
Yesterday
dmitshur commented on godoc.org: is down, serving 500 internal server errors3h
Another update. We've restored the redis backend, and so godoc.org should be operating okay now. I'll watch it some more to make sure it continues to be stable.dmitshur commented on godoc.org: is down, serving 500 internal server errors5h
The measures I applied in https://github.com/golang/go/issues/36642#issuecomment-576051792 worked for a few hours, but by now the redis backend that godoc.org uses has become completely unresponsive,…dmitshur commented on github.com/golang/gddo: Importing github.com/paranoidguy/databunker/src6h
See https://github.com/golang/go/issues/36642.dmitshur commented on godoc.org: serving a very high frequency of 500 internal server errors9h
I've taken some measures to address the problem, and the 500s are no longer happening at very high frequency as of 4:45 PM EST (12 minutes ago).
I'll remove the Soon label since this is mitigated.…dmitshur commented on github.com/golang/gddo: Internal server error when viewing packages10h
Let's use https://github.com/golang/go/issues/36642 as the canonical issue to track this.dmitshur commented on godoc.org: is down10h
I can confirm, there is an excessively high frequency of 500 Internal Server Error responses.
I'll look into whether there's something I can do now.
Until this issue is resolved, consider using…dmitshur opened a change github.com/indieweb/indieauth: improve consistency of terminology and wording11h
This change is made of 4 logical and well-described commits (if this were Gerrit, I'd send a stack of 4 CLs) with the general theme of following up on #13 and improving consistency. Please see the co…dmitshur created branch in github.com/dmitshur/indieauth11h
terminology-consistencydmitshur forked in github.com/indieweb/indieauth11h
dmitshur reviewed +2 on golang.org/x/mobile/gl: enable to use buffer objects for TexSubImage2D by nil1d
(2 comments)
LGTM with minor nit comments on the commit message. Thank you.
s/to use/use of/
Also add “data” after nil at the end.
s/to use/use of/ here too.Last Week
dmitshur commented on golang.org/x/mobile/gl: enable to use buffer objects for TexSubImage2D1d
(1 comment)
I noticed this TODO comment and realized we can delete it now, because this CL implements that TODO.
However, then I noticed that there's the same TODO comment in TexImage2D above...
A…dmitshur commented on golang.org/x/mobile/gl: enable to use buffer objects for TexSubImage2D1d
(6 comments)
go vet says the same thing here:
./gl.go:903:10: possible misuse of unsafe.Pointer
(It's out of scope for this CL, I'm just pointing it out for reference.)
I'm not sure how safe …dmitshur commented on net: document that OpError.Err field must be non-nil1d
Fixed by [CL 187677](https://golang.org/cl/187677).dmitshur commented on golang.org/x/tools/internal/lsp/cmd: tests failing on darwin on all versions of Go1d
Thanks Rebecca!dmitshur commented on github.com/indieweb/indieauth: Improve validation rules for the verification response 'me'2d
The original issue talks only about differences in the URL path. Another case to consider is URLs that differ only by the query. E.g.:
`https://example.com/users?id=100` -> `https://example.com/us…dmitshur merged a change golang.org/x/build/kubernetes/gke: skip 4 tests on builders2d
dmitshur commented on golang.org/x/build/kubernetes/gke: skip 4 tests on builders2d
> I feel like we should have a big comment for that. Someone new to this test file could reasonably assume that it runs in CI (or succeeds in CI) otherwise.
Sorry, I don't understand this. Can you c…dmitshur commented on golang.org/x/build/kubernetes/gke: skip 4 tests on builders2d
> Does this mean that these tests aren't run anywhere?
They won't be run on builders, but they can still be run manually.
> If so, should we instead delete them?
We discussed that option in issue …dmitshur opened a change golang.org/x/build/kubernetes/gke: skip 4 tests on builders2d
dmitshur commented on golang.org/x/tools/go/packages: race detected during execution of various tests2d
Thanks for the update @stamblerre.
I'll retitle this to be about the remaining races in `go/packages` then, and update this issue if something new comes up.dmitshur merged a change golang.org/x/build/dashboard: remove darwin-amd64-10_8 builder type2d
dmitshur opened a change golang.org/x/build/dashboard: remove darwin-amd64-10_8 builder type2d
dmitshur opened an issue golang.org/x/build/cmd/coordinator: some linux-amd64 trybot builds getting stuck at the end2d
There are two trybot invocations that were started on January 6th, 2020:
- https://go-review.googlesource.com/c/go/+/213497/1#message-639b9bcf1a7ccbacf081510b4569799cc252057a
- https://go-review.…dmitshur commented on : dev.boringcrypto branch behind the main releases (1.13.4b4 vs 1.13.6)3d
/cc @FiloSottile @katiehockmandmitshur commented on golang.org/x/mobile/gl: request: enable to pass nil to TexSubImage2D for buffer objects3d
I agree with that rationale for preferring changing type to `interface{}` and accepting `[]byte` or `int`, instead of using `uintptr`. Let's do that. We should document the two types it accepts and w…dmitshur opened an issue golang.org/x/tools/go/packages: race detected during execution of various tests3d
From https://build.golang.org/?repo=golang.org%2fx%2ftools, there are a number of instances where the freebsd-amd64-race builder reported a failure. Many of them failed due to data races:
<details…dmitshur commented on golang.org/x/tools: freebsd-amd64-race builder is failing consistently3d
The freebsd-amd64-race builder no longer failing consistently on x/tools. However, there are still occasional failures. Need to see if they are connected to limited memory, and if so, consider going …dmitshur opened an issue golang.org/x/tools/internal/lsp/cmd: tests failing on darwin on all versions of Go3d
From https://build.golang.org/?repo=golang.org%2fx%2ftools, all darwin builders have recently started to fail on all supported versions of Go. It seems to have started with [CL 214419](https://golang…dmitshur commented on cmd/go: go mod download -json with exit code 1 sometimes prints JSON and sometimes doesn't3d
I wanted to follow up here with an update. After reading the relevant source code very closely:
https://github.com/golang/go/blob/d2de9bd59c068c1bfcb4293de4286196dacf2e43/src/cmd/go/internal/modcm…dmitshur commented on github.com/indieweb/indieauth: Improve validation rules for the verification response 'me'4d
> And yeah the whole reason I proposed this change is because as it stands, IndieAuth is only suitable for one-user-per-domain situations, but there's definitely interest in getting IndieAuth support…dmitshur commented on github.com/indieweb/indieauth: Improve validation rules for the verification response 'me'4d
In your suggestion to only allow augmentations to the path, it's worth considering that the following user profile canonicalization may be worth supporting:
- `https://example.com/alice/` -> `http…dmitshur commented on github.com/indieweb/indieauth: Ambiguity in handling redirections4d
I also found it hard to be confident how to interpret the current wording in a situation involving both permanent and temporary redirects.
My best interpretation has been to understand that if the…dmitshur commented on cmd/go: panics listing ./... in GOROOT/src4d
I tried on `linux/amd64` wit the updated instructions and it didn't reproduce there for me:
```
$ go version
go version go1.13.6 linux/amd64
$ cd $(go env GOROOT)/src; go list ./...
archive/ta…dmitshur commented on cmd/go: panics listing ./... in GOROOT/src4d
> > Does this issue reproduce with the latest release?
>
> Yes, 1.13.4.
I can't reproduce this on `go1.13.6 darwin/amd64`.
Other than your OS being Linux, perhaps there's something different …dmitshur opened an issue golang.org/x/tools/go/internal/gcimporter: test fails on openbsd-386-64 builder on release-branch.go1.125d
From [build.golang.org](https://build.golang.org), the tests for this package fail on `openbsd-386-64` builder:
```
haserrors/haserrors.go:2:22: cannot convert "" (untyped string constant) to unt…dmitshur opened an issue golang.org/x/build/cmd/coordinator: reject unsupported builder types in slowbot requests5d
[CL 212101](https://go-review.googlesource.com/c/go/+/212101/4#message-0693a88a5e7c4056612617e13d5e6756eee7b6a4) has a comment from Dec 19 2019 that included `darwin-amd64-10_8` in a slowbot request.…dmitshur commented on golang.org/x/build: freebsd-amd64-10_3 trybot took over 20 minutes5d
This may or may not be a separate issue, but many linux trybots have been taking upwards of 20, 30, up to 1.5 hours to complete recently. E.g., from https://go-review.googlesource.com/c/tools/+/21471…dmitshur commented on golang.org/x/tools: freebsd-amd64-race builder is failing consistently5d
[CL 214433](https://golang.org/cl/214433) was deployed this morning, and the freebsd-amd64-race builder has been passing on x/tools since then:
<img src="https://user-images.githubusercontent.com/…dmitshur merged a change golang.org/x/build/dashboard: upsize freebsd-amd64-race builder to 7.2 GB RAM5d
dmitshur commented on golang.org/x/build/dashboard: upsize freebsd-amd64-race builder to 7.2 GB RAM5d
I've deployed this change this morning to look for unexpected problems. https in buildletURLTmpl did not cause a breakage, and the freebsd-amd64-race builder has passed on x/tools with the increased …dmitshur commented on golang.org/x/build: should not be testing x/mobile on freebsd/386 on Go 1.125d
The relevant components are redeployed by now. This is the new current state for posterity:
![image](https://user-images.githubusercontent.com/1924134/72376216-98f2ad00-36db-11ea-9a9e-eec84d978a87…dmitshur commented on golang.org/x/build/app/appengine: deploying with clean working tree affects the deploy because certain files are in .gitignore but not .gcloudignore5d
I've remembered something that should be taken into account if we consider removing/reducing .gitignore files.
Some of the env directories have scripts that use said directories for "caching" some…dmitshur commented on golang.org/x/build/app/appengine: deploying with dirty working tree affects the deploy5d
I ran into this today too. I could't deploy `x/build/app/appengine` because it was failing to build due to a "MemoryError":
<details><br>
```
dmitshur@dev-dmitshur:~/go/src/golang.org/x/build$…dmitshur opened an issue golang.org/x/build/app/appengine: deploying with clean working tree affects the deploy because certain files are in .gitignore but not .gcloudignore5d
In x/build right now:
```
build $ find . -name '.gitignore' | wc -l
16
build $ find . -name '.gcloudignore'
./app/appengine/.gcloudignore
./.gcloudignore
```
Not all the files that …dmitshur merged a change golang.org/dl/internal/genv: find directory to write output with module mode in mind6d
dmitshur commented on cmd/go: generate shouldn't require a complete valid package6d
> Moreover, that seems like the clear tiebreaker, too: when `go generate` invokes a tool, it should set `GOPACKAGE` based on the file containing *that specific* `go:generate` comment.
What should ha…dmitshur commented on golang.org/dl/internal/genv: find directory to write output with module mode in mind6d
(1 comment)
Thanks for the suggestion.
I feel repoRoot() doesn't make it clear enough that this function wouldn't work for any repo root, that it must be root of the golang.org/dl module (and/or re…dmitshur commented on golang.org/x/build/dashboard: upsize freebsd-amd64-race builder to 7.2 GB RAM6d
(1 comment)
I think this is a good opportunity to try making that change now. The TODO comment is from 3 years ago when FreeBSD 11 builders were added in CL 37498, and I didn't see a good reason to …dmitshur opened a change golang.org/x/build/dashboard: upsize freebsd-amd64-race builder to 7.2 GB RAM6d
dmitshur starred in mvdan.cc/dockexec6d
dmitshur commented on golang.org/x/mobile/gl: request: enable to pass nil to TexSubImage2D for buffer objects6d
@hajimehoshi Thanks for working on this.
> To satisfy all `glTexSubImage2D` features, we might need a new function to pass `uintptr` instead. To my case, just 0 (nil) is enough, so I'm fine with p…dmitshur closed an issue golang.org/x/tools/internal/lsp: frequent out-of-memory errors on windows-amd64-race builder6d
dmitshur commented on golang.org/x/tools/internal/lsp: frequent out-of-memory errors on windows-amd64-race builder6d
> FWIW, it looks like `freebsd-amd64-race` is doing fine on `n1-highcpu-4`, so it may be worth some time for the `x/tools` folks to figure out why Windows isn't managing. (Are some tests being unexpe…dmitshur commented on golang.org/x/tools: build failing on windows-amd64-longtest6d
This issue is resolved now, based on the current state of the `windows-amd64-longtest` column on https://build.golang.org/?repo=golang.org%2fx%2ftools:
<details><br>
<img src=https://user-image…dmitshur closed an issue golang.org/x/tools: build failing on windows-amd64-longtest6d
dmitshur commented on golang.org/dl/internal/genv: find directory to write output with module mode in mind6d
(1 comment)
Thanks, I was aware this is the current behavior when the user invokes genv outside of any module (aka the GOMOD=os.DevNull case), and I considered doing this.
I thought that it would n…dmitshur commented on golang.org/dl/internal/genv: find directory to write output with module mode in mind6d
I considered refactoring golangOrgDlRoot to be more general and just returning information about the main module:
// mainModule determines the module path and root directory of the main module
// …Earlier
dmitshur commented on golang.org/dl/internal/genv: find directory to write output with module mode in mind1w
(1 comment)
The go command invocation does not use -e flag, so if there are any errors loading module, the go command would exit with a non-zero exit code.
There is code above that checks 'go list …dmitshur opened a change golang.org/dl/internal/genv: find directory to write output with module mode in mind1w
dmitshur merged a change golang.org/x/build/dashboard: include default builds policy in freebsd-386-* builders1w
dmitshur merged a change golang.org/x/build/dashboard: remove explicit support for release-branch.go1.111w
dmitshur opened a change golang.org/x/build/dashboard: include default builds policy in freebsd-386-* builders1w
dmitshur opened an issue golang.org/x/mobile/cmd/gobind: TestGobind failing on Go 1.121w
Sample build link is https://build.golang.org/log/46ff9239d847eedc57081fb7d1580a4b01de…dmitshur reviewed +2 on cmd/go/internal/modload: [release-branch.go1.12] remove erroneous test case1w
(1 comment)
Thanks.
Please let me know you need a release manager to submit this (in case you can't yourself).
I think this can be updated to "Fixes", but if you prefer to keep it as "Updates" and…dmitshur reviewed +1 on cmd/go/internal/modload: fix an erroneous comment about the test repo1w
Thank you for fixing this comment. This change makes sense and looks good to me, but I'll let one of cmd/go owners look it over before it's submitted.dmitshur opened an issue golang.org/x/build: document that it's a special internal repo, doesn't provide same level of stability as other golang.org/x repos1w
The x/build repo is described in its README as:
> This subrepository holds the source for various packages and tools that support Go's build system and the development of the Go programming langua…dmitshur commented on doc: update the minimum supported macOS version to 10.111w
I've reviewed our https://golang.org/dl/ and https://golang.org/doc/install pages, and I believe we should not submit this change until Go 1.14 comes out and Go 1.12 is no longer supported.
On https…dmitshur reviewed +2 on golang.org/x/website/content/static/doc: remove mention of modules from gopath_code.html1w
(1 comment)
Thank you.
I think it'd be worth mentioning the rationale for this change, i.e., that this is a follow up to CL 199417.
(Otherwise, someone in the future may find it harder to understa…dmitshur commented on golang.org/x/website/content/static/doc: rewrite code.html for go modules1w
(1 comment)
This bullet point was not there in the original code.html document (e.g., see CL 199058). Based on the comment history on this CL, it looks like it may have been copied from code.html to…dmitshur opened an issue cmd/go/internal/modload: e0cf3de987e6 no longer is the latest commit on the master branch1w
Both on `master` and `release-branch.go1.13`, there is a comment in query_test.go:
https://github.com/golang/go/blob/56d6b87972c9852570fe017ac5fa153314c21992/src/cmd/go/internal/modload/query_test…dmitshur reviewed +2 on golang.org/x/website/content/static: update description of "How to Write Go Code"1w
(1 comment)
Nit: It may look nicer to move this one word from the next sentence to the next line.dmitshur commented on golang.org/x/website/content/static: add gopath_code.html file and regenerate1w
> I wonder if we should have a test that crawls the site and fails if any links like this are broken?
Based on how I imagine such a test would work, I'm not sure if it's viable and worth implementin…dmitshur merged a change CONTRIBUTORS: first round of updates for Go 1.141w
dmitshur merged a change golang.org/x/website/content/static: add gopath_code.html file and regenerate1w
dmitshur merged a change golang.org/x/website/content/static: add gopath_code.html file and regenerate1w
dmitshur commented on golang.org/x/build: freebsd-amd64-10_3 trybot took over 20 minutes1w
This was its build log:
<details><br>
```
builder: freebsd-amd64-10_3
rev: 83d7ec855bf73948effea263cb4ee3b2d2474c92
buildlet: http://10.240.0.155 GCE VM: buildlet-freebsd-10-3-rne51…dmitshur opened an issue golang.org/x/build: freebsd-amd64-10_3 trybot took over 20 minutes1w
From https://go-review.googlesource.com/c/go/+/214079/1#message-7f31aa619ce56c7e7101472dd62cdc6402837b34, a CL on `release-branch.go1.12` branch, the `freebsd-amd64-10_3` builder took 23~ minutes. Al…dmitshur reviewed +2 on doc: [release-branch.go1.12] document Go 1.12.151w
dmitshur reviewed +2 on golang.org/x/website/content/static/doc: document Go 1.12.151w
dmitshur reviewed -2 on golang.org/x/tools/cmd/bundle: use caller's module version via go/packages1w
(1 comment)
-2 to prevent accidental submission. See my inline comment and please let me know if I'm missing something.
> we only use this tool in module mode anyway.
I don't think that's currentl…dmitshur reviewed +2 on github.com/google/go-github/v28: Bump major version to v29 (take 2)1w
LGTM. I tested this change and don't see any issues.dmitshur commented on github.com/google/go-github/v28: Revert "Bump major version to v29"1w
> (I deleted the `v29.0.0` if that makes any difference.)
That version has already been [indexed](https://index.golang.org/index?since=2020-01-08T22:03:01.935587Z) and [added](https://sum.golang.o…dmitshur opened a change golang.org/x/website/content/static: add gopath_code.html file and regenerate1w
dmitshur commented on github.com/google/go-github/v28: Revert "Bump major version to v29"1w
No problem @gmlewis, thank you for taking care of this.
I believe the issue in PR #1344 was that it did not update the [recently added](https://github.com/google/go-github/pull/1285) `example/topi…dmitshur commented on golang.org/x/tools/cmd/bundle: use caller's module version via go/packages1w
(2 comments)
If you want, add:
Updates golang/go#24661
Is it viable and a good idea to test both module mode and GOPATH mode?dmitshur opened a change CONTRIBUTORS: first round of updates for Go 1.141w
dmitshur commented on golang.org/x/tools/go/packages: test timeout on freebsd-amd64-race builder1w
This may be related to #36444.dmitshur opened an issue golang.org/x/tools: freebsd-amd64-race builder is failing consistently1w
The linux-amd64-race builder is currently configured with 15 GB RAM (via the n1-standard-4 machine type). [CL 213557](https://golang.org/cl/213557) has recently increased the RAM for windows-amd64-ra…dmitshur commented on golang.org/x/tools: build failing on windows-amd64-longtest1w
The aforementioned change has had an effect. Both windows-amd64-longtest and -race have been [passing on x/tools](https://build.golang.org/?repo=golang.org%2fx%2ftools) since the builder change was d…dmitshur reviewed +2 on cmd/go: fix test broken by incorrect comments1w
dmitshur commented on golang.org/x/tools/go/ast/astutil: DeleteImport() causes SEGV1w
Thanks for reporting.
This may be another edge case that isn't handled by [CL 44372](https://golang.org/cl/44372) nor [CL 92250045](https://golang.org/cl/92250045).
Also /cc @fatih since he's a…dmitshur commented on runtime: thread sanitizer failing on ppc64le1w
Sorry for the delay in getting back to you @laboger. I wanted to update you that we're not able to give out gomote access at this time, unfortunately. We're still working on fixing that, but it will …dmitshur reviewed +2 on golang.org/x/oauth2/README: fix a typo, update README to point people at endpoints1w
(1 comment)
Use https.dmitshur merged a change golang.org/x/build/dashboard: upsize windows-amd64-{longtest,race} builders to 14.4 GB RAM1w
dmitshur commented on golang.org/x/build/dashboard: upsize windows-amd64-{longtest,race} builders to 14.4 GB RAM1w
I wrote some more detailed motivation for this at https://golang.org/issue/35186#issuecomment-571438725.dmitshur commented on golang.org/x/tools: build failing on windows-amd64-longtest1w
I've spun up a bunch of VMs/laptops with Windows 7/10 ([WindowsBuild](https://golang.org/wiki/WindowsBuild) was very helpful), some with 8 GB RAM and one with 16 GB.
### 8 GB
On 8 GB configurat…dmitshur opened a change golang.org/x/build/dashboard: upsize windows-amd64-{longtest,race} builders to 14.4 GB RAM1w
dmitshur merged a change golang.org/x/talks/README: clarify deploy instructions1w
dmitshur commented on golang.org/x/build/devapp/owners: add wasm, oauth2 owners, quiet log spam in test1w
Sorry, log.Writer() was added only in 1.13.dmitshur opened an issue golang.org/x/tools/go/loader: data race reported while running TestCycles1w
From https://build.golang.org/log/1667c1c432e0389a87b0b5433d895b42eccd7716, which is a `linux-amd64-race` test run of golang/tools@774c71fcf11405d0a5ce0aba75dc113822d62178 using Go tip (1.14-ish):
…