Activity
Today
dmitshur reviewed +2 on github.com/go-gl/gl: Update the Go version to 1.1217m
dmitshur reviewed +1 on golang.org/x/website/blog: add 2021 Go Developer Survey launch announcement1h
(1 comment)
Minor and optional comment: this link works, but it might be better to link directly to https://go.dev/blog/survey2020-results to skip a redirect.dmitshur reviewed +2 on github.com/go-gl/gl: Update the Go version to 1.121h
Minor suggestion. Maybe it's better to reverse the order so the latest version (1.17) is tested and listed first, and the oldest version 1.12 is at the bottom (since it's least important and soones…Last Week
dmitshur opened a change github.com/golang/freetype: Round scale to nearest 26.6 fixed point.1d
With this change, the computation of the scale factor becomes
identical across the freetype and truetype packages, removing
deviations in the font metrics that are derived from scale.
The roundi…dmitshur created branch in github.com/golang/freetype1d
scale-nearestdmitshur opened an issue github.com/golang/freetype: discrepancy in scale factor conversion between freetype and truetype packages1d
I noticed there's sometimes a tiny discrepancy in font metrics as computed by `freetype.Context` and `truetype.NewFace`.
As a reproducible example, using the Go Mono font of size 86.4 exactly, at …dmitshur commented on github.com/golang/freetype: don't include Luxi fonts in this package1d
Thanks—this is a duplicate of #60.dmitshur closed an issue github.com/golang/freetype: don't include Luxi fonts in this package1d
dmitshur reviewed +2 on github.com/go-gl/glfw/v3.3/glfw: add openbsd support2d
Looks reasonable to me. One minor comment/question.
Is "/usr/X11R6/include" considered a standard include directory on OpenBSD?dmitshur reviewed +2 on golang.org/x/build/internal/gomote/protos: add a skeleton for a gomote api4d
dmitshur merged a change golang.org/x/build/dashboard: remove OpenBSD 6.4 builders4d
dmitshur commented on syscall/js: remove Wrapper type to avoid extreme allocations and improve performance4d
Updated the milestone to Go 1.18 since that's the version this proposal was implemented.
This change is significant enough to warrant being mentioned in the [1.18 release notes](https://tip.golang…dmitshur commented on syscall/js: remove Wrapper interface4d
RELNOTE=yesdmitshur closed a change golang.org/x/build/dashboard: upsize openbsd-386-64 to 16 GB RAM5d
dmitshur commented on golang.org/x/build/dashboard: upsize openbsd-386-64 to 16 GB RAM5d
This is a 32-bit architecture, so increasing machine RAM size beyond 4 GB is unlikely to help. Going with CL 357370 instead.dmitshur commented on golang.org/x/tools/go/internal/gcimporter: frequent failures with SIGSEGV on openbsd-386-64 builder5d
This is a 32-bit architecture, so increasing RAM of the machine to 16 GB probably won't help (thanks @cagedmantis for catching this).
I think the right next step here is #49090.dmitshur opened a change golang.org/x/build/dashboard: remove OpenBSD 6.4 builders5d
OpenBSD 6.4 is not supported by now.
Fixes golang/go#49090.
Fixes golang/go#36563.
Fixes golang/go#38413.
Fixes golang/go#46080.dmitshur closed an issue runtime: apparent TestEnsureDropM deadlock on openbsd-386-62 builder5d
dmitshur commented on runtime: apparent TestEnsureDropM deadlock on openbsd-386-62 builder5d
Indeed, OpenBSD 6.2 is not supported, closing.dmitshur opened an issue golang.org/x/build/dashboard: remove OpenBSD 6.4 builders5d
At this time, OpenBSD 7.0 (released 6 days ago) and 6.9 are the supported releases of OpenBSD per their support policy of maintaining the last 2 releases. OpenBSD 6.4 stopped being supported on Octob…dmitshur commented on cmd/compile: completion of outstanding issues for generics [freeze exception]5d
Thank you for letting us know. We have discussed this on the team and agreed that this exception is okay to make for 1.18, especially since this is a part of overall generics work that is in scope of…dmitshur closed an issue cmd/compile: completion of outstanding issues for generics [freeze exception]5d
dmitshur commented on golang.org/x/build: aix-ppc64 builder has double/unmerged PATH causing wrong 'go' binary to be found5d
@bcmills Based on a recent test failure (e.g., https://build.golang.org/log/3d50d2e41477382548e0b84905d5dff6ea05f2f2) and the test code, to me it looks like the problem may be that the test code trie…dmitshur reviewed +2 on golang.org/x/build/cmd/buildlet: in setPathEnv, override the last PATH entry, not the first5d
(1 comment)
In case there are 2 or more PATH variables in env, only one of them (previously the first, now the last) will be removed.
If the goal of this fix is to allow setPathEnv to operate corre…dmitshur commented on cmd/go: add GOAMD64 environment variable6d
RELNOTE=yesdmitshur commented on github.com/shurcooL/githubv4: Not parsing Node query correctly6d
This line looks off:
```
} `graphql:"node(id: $repoId")`
```
Perhaps it should be:
```
} `graphql:"node(id: $repoId)"`
```dmitshur reviewed +2 on golang.org/x/build/buildlet: correct MinCPUPlatform name6d
Earlier
dmitshur starred in github.com/gotify/server/v21w
dmitshur commented on misc/wasm: Go 1.17.2 causes WASM builds to throw `command line too long` with many environment variables1w
Both command line arguments and environment variables are currently passed to WebAssembly by writing them to linear memory, and [CL 354571](https://golang.org/cl/354571) added a fixed limit of 4096 b…dmitshur commented on misc/wasm: Go 1.17.2 causes WASM builds to throw `command line too long` with many environment variables1w
Also CC @cherrymui.dmitshur reviewed +2 on golang.org/x/build/dashboard: use n2 instances where necessary1w
(4 comments)
Nit: NestedVirt or 'nested virtualization'.
This HostConfig doesn't set MinCPUPlatform, so maybe mention NestedVirt instead (or in addition to).
Same as above.
Maybe this…dmitshur reviewed +2 on golang.org/x/website/cmd/golangorg: redirect /x/ to pkgsite subrepo page1w
dmitshur commented on golang.org/x/tools/go/internal/gcimporter: frequent failures with SIGSEGV on openbsd-386-64 builder1w
I'll give it some time before submitting CL 355669, since the builder machine type changed slightly in CL 354757, so we have more data. (Otherwise we won't know what it was that fixed it.)
> > Thi…dmitshur opened a change golang.org/x/build/dashboard: upsize openbsd-386-64 to 16 GB RAM1w
Stay with 4 vCPU, but increase RAM from 4 to 16 GB. This is to help
this builder run x/tools tests without running into problems caused
by having insufficient memory.
For golang/go#36563.
Updates go…dmitshur commented on golang.org/x/tools/go/internal/gcimporter: frequent failures with SIGSEGV on openbsd-386-64 builder1w
Now that [CL 354757](https://golang.org/cl/354757) is submitted, I'll send a CL for this.dmitshur reviewed +2 on golang.org/x/build/...: migrate from n1 to e2 instances1w
(1 comment)
Some relevant resources for reference:
• https://cloud.google.com/compute/docs/machine-types#machine_types
• https://cloud.google.com/blog/products/compute/google-compute-engine-get…dmitshur commented on golang.org/x/tools/go/internal/gcimporter: frequent failures with SIGSEGV on openbsd-386-64 builder1w
From the original comment:
> I suspect this may be similar to #36444. This builder is currently on n1-highcpu-4, which has only 3.6 GB memory, and that is likely not enough for x/tools tests to pa…dmitshur commented on golang.org/x/tools: document minimum requirements for tests1w
The pattern that seems to establish itself here is that builders that run x/tools tests need approximately 16~ GB RAM. Going with as little as 4 or 8 GB RAM has proven to be insufficient in a number …dmitshur merged a change golang.org/x/build/cmd/releasebot: create GitHub milestones for next release1w
dmitshur commented on golang.org/x/build/cmd/releasebot: create GitHub milestones for next release1w
(2 comments)
FWIW, GitHub API v4 added support for filtering milestones with a query on the title. But v3 doesn’t have that, and the error indeed doesn't report the ID of the conflicting miles…dmitshur merged a change golang.org/x/build/cmd/buildlet: add Makefile target for darwin/arm641w
dmitshur opened a change golang.org/x/build/cmd/buildlet: add Makefile target for darwin/arm641w
This target updates the buildlet binary used by builders that
test the darwin/arm64 port (i.e., darwin-arm64-11_0-toothrot).
Updates golang/go#39782.dmitshur reviewed +2 on golang.org/x/build/cmd/coordinator: drop subrepo GOPATH testing support2w
(1 comment)
Since #34352 isn't resolved yet and the checked out x repo is also being used for running tests in the code below, let's include that in the comment so that it's a more compl…dmitshur reviewed +2 on all: update vendored golang.org/x/tools2w
TRY=longtest (for more thorough coverage by cmd/internal/moddeps.TestAllDependencies test)dmitshur commented on golang.org/x/build/cmd/coordinator: drop subrepo GOPATH testing support2w
(5 comments)
s/run go env GOMOD/find go.mod files/
Running tests in module mode can be done without checking out said files to disk, instead relying on module mirror to fetch the code to be tested.…dmitshur merged a change doc/go1.18: document FreeBSD 11.x will no longer be supported2w
dmitshur commented on doc/go1.18: document FreeBSD 11.x will no longer be supported2w
Thanks.dmitshur reviewed +2 on cmd/pprof: update vendored github.com/google/pprof2w
TRY=longtest (for more thorough coverage by cmd/internal/moddeps.TestAllDependencies test)dmitshur closed an issue golang.org/x/build/cmd/coordinator: some subrepos want to run tests in both module and GOPATH modes2w
dmitshur commented on golang.org/x/build/cmd/coordinator: some subrepos want to run tests in both module and GOPATH modes2w
It turned out we had sufficient coverage so none of the subrepos needed this,
and we got by without ever implementing it. So the decision here is "won't fix".
Closing in favor of #48875.dmitshur commented on golang.org/x/build/cmd/coordinator: drop unused GOPATH subrepo testing path2w
Yes, I think by now it's safe to drop that path.
Issue #30233 was open for a long time to test some x repos in both modes, but we got by without ever implementing it. Given the status of GOPATH mode…dmitshur opened a change golang.org/x/build/cmd/releasebot: create GitHub milestones for next release2w
The current release process relies on humans to create GitHub milestones
for future Go releases. releasebot includes automated checks that detect
when that step is forgotten. CL 294249 included one o…dmitshur commented on cmd/cgo: fails to bootstrap on illumos-amd64 builder with "undefined: ast.IndexListExpr"2w
Thanks very much @jclulow!
The issue affecting `cmd/cgo` and causing a visible failure was fixed via [CL 354695](https://golang.org/cl/354695), which is why this issue is closed now, but updating th…dmitshur reviewed +2 on cmd/dist: run a checkNotStale on the builders before running tests2w
Do you have a sense of how much extra time this adds? Would it be worth blocking landing this on having metrics for average builder completion time, or not worth?
Given each tester.runPending invoca…dmitshur reviewed +2 on golang.org/x/build/Revert "internal/coordinator: start VMs without external IPs"2w
(1 comment)
Please apply the suggested action for revert CL commit messages (https://golang.org/wiki/CommitMessage#reverts):
> Edit the description to add the Gerrit CL number being rolled back …dmitshur reviewed +2 on golang.org/x/build/dashboard: update host-ios-arm64-corellium-ios to match its previous env2w
Since the builder appears to be providing its own functional GOROOT_BOOTSTRAP value, I understand it's also possible to fix the issue by removing its incorrect override in dashboard.go.dmitshur commented on golang.org/x/build: "unexpected stale targets" on darwin builders2w
The buildlet binary for darwin-amd64 has been updated (the rest to follow).
@bcmills Can you check whether it's working as expected in CL 223755?dmitshur reviewed +2 on misc/boring: [dev.boringcrypto] fix Docker Hub references2w
(2 comments)
Another mention of Docker Hub.
Another. (Maybe fine to update later.)dmitshur commented on cmd/go: continue conversion to bug-resistant //go:build constraints2w
For quick reference, the outstanding CLs for this issue that I'm aware of and their status as of this posting:
- [CL 240611](https://golang.org/cl/240611) - includes "For #41184", has +2, outst…dmitshur commented on cmd/cgo: fails to bootstrap on illumos-amd64 builder with "undefined: ast.IndexListExpr"2w
@jclulow is the owner of the `illumos-amd64` builder listed at https://farmer.golang.org/builders, and I understand the only one able to resolve this issue. Please let us know if someone else can he…dmitshur reviewed +2 on golang.org/dl/...: add go1.16.9 and go1.17.22w
Nice work, Go Bot! 😎dmitshur reviewed +2 on golang.org/x/build/...: consistently set PWD to match Dir for subprocesses2w
Thanks. Leaving a +2 but probably better not to submit before the current release is complete (#48843).
> the convenience of using envutil didn't seem worth the maintenance headache of dealin…dmitshur commented on golang.org/x/build: "unexpected stale targets" on darwin builders2w
> I mailed out a CL to fix this, but I think it will require some deployment work to determine whether it fixes the problem.
I think the change in [CL 353549](https://golang.org/cl/353549) most re…dmitshur commented on golang.org/x/build: misc-compile TryBots are too slow again2w
A [comment on Apr 23](https://github.com/golang/go/issues/32632#issuecomment-825932443) mentions a revised target time:
> Our updated target time for TryBot completion time is 10 minutes (see subj…dmitshur closed an issue golang.org/x/build: one ppc64le osuosl builder is configured differently from the rest, causing failures2w
dmitshur commented on golang.org/x/build: one ppc64le osuosl builder is configured differently from the rest, causing failures2w
Closing since I understand this is all resolved, thanks again!dmitshur starred in github.com/Khan/genqlient3w
dmitshur commented on golang.org/x/pkgsite: possible change in how example links work3w
The old golang.org/pkg/ documentation server indeed used anchors for examples that don't exactly match those on pkg.go.dev. When pkg.go.dev was in its early development stages in 2019, since it was a…dmitshur commented on golang.org/x/tools/cmd/godoc: show internal packages when explicitly requested3w
godoc is essentially in maintenance mode by now, and may be headed towards being replaced with a newer tool based on a more actively maintained documentation rendering library (e.g., see issue #48264…dmitshur pushed to
master in github.com/shurcooL/githubv41mo
dmitshur merged a change github.com/shurcooL/githubv4: Regenerate schema for changes by 2021-09-201mo
dmitshur reviewed +2 on github.com/shurcooL/githubv4: Regenerate schema for changes by 2021-09-201mo
Thanks, changes look good.
I think it's okay to go with `string` as the underlying type for the new Base64String scalar for now. It's simpler, and gives the caller explicit control over the base64…dmitshur pushed to
bkeyes/update-schema in github.com/bluekeyes/githubv41mo
dmitshur starred in github.com/bluekeyes/patch2pr1mo
dmitshur starred in github.com/bluekeyes/go-gitdiff1mo
dmitshur commented on github.com/hexops/valast: String method is not viable in environments where executable `go` is unavailable1mo
Heya! 😀 Sorry that it's via an issue report! 😅
> this is definitely unintentional.
Thanks for confirming.
> what may be happening is our usage of gofumpt
From what I can tell, this particul…dmitshur opened an issue github.com/hexops/valast: String method is not viable in environments where executable `go` is unavailable1mo
Consider the following (minified) example program that tries to print a value of type [`font.Metrics`](https://pkg.go.dev/golang.org/x/image/font#Metrics):
```Go
package main
import (
"fmt"
…dmitshur starred in github.com/magcius/noclip.website1mo
dmitshur opened an issue golang.org/x/pkgsite/cmd/pkgsite: templates aren't embedded, causing an error if run from another directory1mo
This issue is likely a subset of #40371.
<details><summary>Environment Details</summary>
### What version of Go are you using (`go version`)?
<pre>
$ go version
go version go1.17.1 darwin/…dmitshur commented on github: consider using GitHub Discussions (currently available in beta)1mo
By now, GitHub Discussions are being tried out in the Go project to a limited degree. See https://github.com/golang/go/discussions/47139.dmitshur starred in github.com/mystor/git-revise1mo
dmitshur commented on golang.org/x/build/cmd/release: darwin/arm64 installer prompts for installing Rosetta 21mo
@ifamakes I've checked the `Distribution` file in go1.17.darwin-arm64.pkg, and it still has `hostArchitectures="arm64"` set, so that hasn't regressed on our side.
Since this issue has been closed fo…dmitshur commented on golang.org/x/pkgsite: add support for type parameters1mo
I understand the scope of this issue is x/pkgsite, and I don't mean to change that.
I'll point out that a similar issue may apply to x/website, though golang.org serves documentation under a signi…dmitshur commented on golang.org/x/build/cmd/gerritbot: running into letsencrypt authorization rate limit1mo
The problem turned out to be a misconfigured use of `autocert` (not enabling `acme.ALPNProto`, and not using `HTTPHandler`), which prevented gerritbot's HTML "hello" page from being served. [CL 34843…dmitshur commented on github.com/shurcooL/githubv4: Do not include unhelpful scalar types.1mo
@davidkarlsen Something like this should work:
```Go
variables := map[string]interface{}{
"somekey": (*githubv4.String)(nil), // or another concrete type instead of String
// ...
}
```dmitshur commented on all: update standard-library dependencies at the start and end of each development cycle1mo
With the 5 CLs above, we're in good shape for early in cycle. Removing that label to revisit this closer to the code freeze.dmitshur starred in github.com/ianlancetaylor/demangle1mo
dmitshur pushed to
master in github.com/shurcooL/httperror1modmitshur pushed to
master in github.com/shurcooL/httperror1modmitshur opened an issue golang.org/x/build/internal/workflow: TestParallelism is flaky1mo
This seems to happen occasionally, suggesting the test is flaky:
```
--- FAIL: TestParallelism (0.15s)
workflow_test.go:122: task sleep #1 : started
workflow_test.go:122: task sleep #2…dmitshur commented on cmd/vet: panic during processing of hash/crc32 package1mo
@timothy-king Correct. Go 1.17 and 1.16 do not have this problem.dmitshur commented on golang.org/x/crypto/curve25519: consider removing dependency on "fmt" if worthwhile1mo
Sounds good. Please include a small test in x/crypto that this package doesn't import `fmt`, so this property doesn't accidentally regress without the benefit of go/build's test.dmitshur opened an issue golang.org/x/crypto/curve25519: consider removing dependency on "fmt" if worthwhile1mo
The `curve25519` package imports `fmt` and uses it 3 times:
```Go
return nil, fmt.Errorf("bad scalar length: %d, expected %d", l, 32)
return nil, fmt.Errorf("bad point length: %d, expected %d", …dmitshur commented on cmd/vet: panic during processing of hash/crc32 package1mo
Bisection shows this problem is introduced in [CL 338529](https://golang.org/cl/338529):
```
$ (cd cmd; go get -d golang.org/x/tools@3fce476f0a782aeb5034d592c189e63be4ba6c9e && go mod tidy && go …dmitshur opened an issue cmd/vet: panic during processing of hash/crc32 package1mo
There is a problem on tip when the vendored x/tools module is updated to its latest master pseudo-version (as part of #36905).
### What did you do?
```
$ git clone https://go.googlesource.com/…dmitshur commented on go/types: incorrect type reported for comma-err C functions (manifests itself in IDEs)1mo
The fix that closed this issue landed into master branch, which is where Go 1.18 development is happening, so moving this issue to the Go1.18 milestone. (The 1.17 backport issue #47854 is in 1.17.1 m…dmitshur commented on cmd/compile: reduced microbenchmark execution speed in 1.171mo
This issue was closed in NeedsInvestigation state without a fix, but if a fix were to be made, it would need to target Go 1.18 first. Since this isn't a [backport issue](https://golang.org/wiki/Minor…dmitshur commented on all: decide and document iOS supported versions1mo
Also CC @changkun, @hajimehoshi.dmitshur commented on golang.org/x/build: adding linux-riscv64-unmatched builder1mo
cmd/coordinator has been redeployed, so the reverse builder should be able to connect. It’s visible at https://farmer.golang.org now:
> host-linux-riscv64-unmatched: 0/0 (1 missing)dmitshur closed an issue golang.org/x/mobile: failed to pull the signing certificate to determine your team ID1mo