Activity
Yesterday
dmitshur commented on github.com/indieweb/indieauth: Improve validation rules for the verification response 'me'3h
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 builders8h
dmitshur commented on golang.org/x/build/kubernetes/gke: skip 4 tests on builders9h
> 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 builders11h
> 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 builders11h
dmitshur commented on golang.org/x/tools/go/packages: race detected during execution of various tests12h
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 type12h
dmitshur opened a change golang.org/x/build/dashboard: remove darwin-amd64-10_8 builder type13h
dmitshur opened an issue golang.org/x/build/cmd/coordinator: some linux-amd64 trybot builds getting stuck at the end14h
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.…This Week
dmitshur commented on : dev.boringcrypto branch behind the main releases (1.13.4b4 vs 1.13.6)1d
/cc @FiloSottile @katiehockmandmitshur commented on golang.org/x/mobile/gl: request: enable to pass nil to TexSubImage2D for buffer objects1d
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 tests1d
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 consistently1d
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 Go1d
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't1d
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'2d
> 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'2d
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 redirections2d
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/src2d
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/src2d
> > 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.123d
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 requests3d
[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 minutes3d
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 consistently3d
[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 RAM3d
dmitshur commented on golang.org/x/build/dashboard: upsize freebsd-amd64-race builder to 7.2 GB RAM3d
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.123d
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 .gcloudignore3d
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 deploy3d
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 .gcloudignore3d
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 mind4d
dmitshur commented on cmd/go: generate shouldn't require a complete valid package4d
> 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 mind4d
(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 RAM4d
(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 RAM4d
dmitshur starred in mvdan.cc/dockexec4d
dmitshur commented on golang.org/x/mobile/gl: request: enable to pass nil to TexSubImage2D for buffer objects4d
@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 builder4d
dmitshur commented on golang.org/x/tools/internal/lsp: frequent out-of-memory errors on windows-amd64-race builder4d
> 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-longtest4d
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-longtest4d
dmitshur commented on golang.org/dl/internal/genv: find directory to write output with module mode in mind4d
(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 mind4d
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
// …Last Week
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):
…dmitshur commented on golang.org/x/build/devapp/owners: add wasm, oauth2 owners, quiet log spam in test1w
(1 comment)
I'd also suggest optionally moving this helper entry to be below var entries, the main table of owners, because it's lower level/less important. (Both places are okay.)dmitshur commented on golang.org/x/build/devapp/owners: add wasm, oauth2 owners, quiet log spam in test1w
(1 comment)
Oh, I see you can't easily swap their order because the deferred closure uses &logBuf. Bummer.
Maybe just add orig := log.Writer() on top and use that inside the closure.dmitshur reviewed +2 on golang.org/x/build/devapp/owners: add wasm, oauth2 owners, quiet log spam in test1w
(1 comment)
Pass the original log output instead of hardcoding os.Stderr:
defer func(orig io.Writer) {
...
log.SetOutput(orig)
}(log.Writer())
And move the log.SetOutput(&l…Earlier
dmitshur starred in github.com/veggiedefender/torrent-client1w
dmitshur starred in github.com/brendoncarroll/webfs1w
dmitshur commented on github.com/shurcooL/githubv4: QQ on generating proper struct1w
Slightly off topic, I want to point out you could simplify that query by using the [`nodes`](https://developer.github.com/v4/object/searchresultitemconnection/#nodes) field directly (since the only f…dmitshur commented on golang.org/x/mobile/gl: enable to use buffer objects for TexSubImage2D1w
(1 comment)
After comparing the documentation for the two functions, it seems this doesn't apply exactly the same for TexSubImage2D. I left a comment on the issue, let's discuss there.dmitshur commented on golang.org/x/mobile/gl: request: enable to pass nil to TexSubImage2D for buffer objects1w
@hajimehoshi In https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glTexImage2D.xhtml, it states very clearly that:
> data may be a null pointer. In this case, texture memory is allocated…dmitshur commented on github.com/shurcooL/githubv4: QQ on generating proper struct1w
Hi @atmosx,
Thanks for providing the exact GraphQL query and the Go code you tried, it made investigating this very easy.
The problem is here:
```diff
-Repo []struct {
+Repo struct {
```
It is be…dmitshur commented on github.com/shurcooL/graphql: better error message or different behavior when expecting slice of structs, but have single struct1w
A related problem happened in shurcooL/githubv4#55.
The problem was that the query was `Repo []struct { ... }` but should've been `Repo struct { ... }`. The error was "struct field for "name" doesn'…dmitshur merged a change runtime: [release-branch.go1.12] monitor for suspend/resume to kick timeouts2w
dmitshur closed an issue runtime: revert Windows change to boot-time timers [1.13 backport]2w