Activity
Today
dmitshur commented on golang.org/x/build/internal/task: add task to tweet about Go releases10m
(3 comments)
Yes, we should at least document it. I wanted to also include a code check to catch swapped input, but it wasn't as easy as it should be without an existing Go version parser handy …dmitshur merged a change cmd/link: [release-branch.go1.17] disable weak reference in itab if build with "-linkshared"33m
dmitshur commented on cmd/link: [release-branch.go1.17] disable weak reference in itab if build with "-linkshared"34m
Not restarting TryBots since they passed on Patch Set 1, and the only change in PS 2 is in the commit message.dmitshur commented on cmd/link: -buildmode=pie -linkshared panic at runtime [1.17 backport]35m
Thanks for pointing that out. We can proceed with the backport CL, as only 1.17 needs the fix then.dmitshur commented on debug/macho: [release-branch.go1.16] fail on invalid dynamic symbol table command39m
The failure is unrelated. (In the unlikely case a real failure is masked, it'll be spotted by a post-submit run and release tests.)dmitshur reviewed +2 on debug/macho: [release-branch.go1.17] fail on invalid dynamic symbol table command41m
dmitshur reviewed +2 on debug/macho: [release-branch.go1.16] fail on invalid dynamic symbol table command41m
dmitshur commented on cmd/link: [release-branch.go1.16] increase reserved space for passing env on wasm1h
This change is ready for review.dmitshur opened a change cmd/link: [release-branch.go1.16] increase reserved space for passing env on wasm1h
On wasm, the wasm_exec.js helper passes the command line arguments and
environment variables via a reserved space in the wasm linear memory.
Increase this reserved space from 4096 to 8192 bytes so mo…dmitshur opened a change cmd/link: [release-branch.go1.17] increase reserved space for passing env on wasm1h
On wasm, the wasm_exec.js helper passes the command line arguments and
environment variables via a reserved space in the wasm linear memory.
Increase this reserved space from 4096 to 8192 bytes so mo…dmitshur commented on cmd/link: -buildmode=pie -linkshared panic at runtime [1.17 backport]1h
The backport policy requires both supported releases, Go 1.17 and 1.16 at this time, to be supported equally (see https://golang.org/issue/34536#issuecomment-572188389). So to proceed here we need to…dmitshur merged a change runtime: [release-branch.go1.16] consistently access pollDesc r/w Gs with atomics1h
dmitshur merged a change runtime: [release-branch.go1.17] consistently access pollDesc r/w Gs with atomics1h
Yesterday
dmitshur commented on runtime: TestSegv fails with the latest tip version19h
Does it happen reproducibly for you, or only occasionally?
It didn't reproduce locally on macOS 11.6 darwin/amd64 @ commit 749f6e9eb6d101ef2ea4b7228a966391a80aa89b for me, at least not on the firs…dmitshur commented on debug/macho: invalid dynamic symbol table command can cause panic [1.17 backport]19h
@rolandshoemaker Can you please prepare two backport CL (here, and for #48991) following https://golang.org/wiki/MinorReleases#making-cherry-pick-cls? Thanks.dmitshur commented on golang.org/x/sys/unix: TestSysctlClockinfo failing with "input/output error" on openbsd-arm*-jsing since Aug. 219h
> The easy fix is to regenerate the definitions on a supported release - however, this will obviously mean that it will stop working on 6.8 and earlier (which are no longer supported releases).
Th…dmitshur commented on cmd/compile: 64 bits shifts on arm get wrong results [1.17 backport]19h
Closed by merging 3a03ddf735f0e8eff3f8325a496f28b71d3dbe39 to release-branch.go1.17.dmitshur closed an issue cmd/compile: 64 bits shifts on arm get wrong results [1.17 backport]19h
dmitshur closed an issue cmd/compile: 64 bits shifts on arm get wrong results [1.16 backport]19h
dmitshur commented on cmd/compile: 64 bits shifts on arm get wrong results [1.16 backport]19h
Closed by merging 1a6281d9501763b1457abe99f142f0efe435fe29 to release-branch.go1.16.dmitshur merged a change cmd/compile: [release-branch.go1.16] ensure constant shift amounts are in range for arm19h
dmitshur merged a change cmd/compile: [release-branch.go1.16] ensure constant shift amounts are in range for arm19h
dmitshur commented on cmd/compile: [release-branch.go1.16] ensure constant shift amounts are in range for arm19h
(1 comment)
Was done.dmitshur commented on cmd/compile: [release-branch.go1.17] ensure constant shift amounts are in range for arm19h
Unrelated failure, and chance of a real failure being masked is low enough to proceed (this builder will be run again on post-submit and during release tests).
Was done.dmitshur commented on cmd/compile: [release-branch.go1.17] ensure constant shift amounts are in range for arm19h
Unrelated failure, and chance of a real failure being masked is low enough to proceed (this builder will be run again on post-submit and during release tests).
Was done.dmitshur merged a change cmd/compile: [release-branch.go1.17] ensure constant shift amounts are in range for arm19h
dmitshur commented on cmd/compile: incorrect arm/arm64 simplification rules [1.16 backport]20h
Closed by merging cfe182c67328f852d33ff00c9dc876765f19e546 to release-branch.go1.16.dmitshur closed an issue cmd/compile: incorrect arm/arm64 simplification rules [1.16 backport]20h
dmitshur closed an issue cmd/compile: incorrect arm/arm64 simplification rules [1.17 backport]20h
dmitshur commented on cmd/compile: incorrect arm/arm64 simplification rules [1.17 backport]20h
Closed by merging 644555d34e5154215e4599610d861ec598bfbef2 to release-branch.go1.17.dmitshur merged a change cmd/compile: [release-branch.go1.17] fix simplification rules on arm/arm6420h
dmitshur merged a change cmd/compile: [release-branch.go1.16] fix simplification rules on arm/arm6420h
dmitshur commented on runtime: test failed with the latest tip version20h
What version of macOS are you using? macOS 12 has one known issue #49138.
Is this happening with an older tip commit?dmitshur commented on golang.org/x/website/go.dev: fix go playground on homepage21h
(1 comment)
It seems this is where it fetches the playground example from. If modified to 'https://golang.org/doc/play/', as long as CORS is set up to allow such requests, this may be one wa…dmitshur reviewed +2 on golang.org/x/website/go.dev: fix go playground on homepage21h
If I understand correctly, this copies files that are served and available at https://golang.org/doc/play/ into go.dev, so they're also available at https://go.dev/doc/play/.
This seems fine to …dmitshur commented on golang.org/x/build/internal/task: post tweets via Twitter API23h
(1 comment)
I considered that, but I thought that if we wanted to modify how we use the Twitter API, we'd likely need to test it against the real Twitter API (e.g., using a staging set of creden…dmitshur commented on golang.org/x/build/cmd/releasebot: add modes for making a release tweet programmatically23h
(1 comment)
Sorry but I'm not sure if I understand what the suggestion to "log the tweet at the end of the message" means specifically.
It's true that the input to TweetRelease is f…dmitshur merged a change golang.org/x/build/maintner/cmd/maintserve: update dependencies23h
dmitshur commented on golang.org/x/build/internal/task: add task to tweet about Go releases23h
(1 comment)
I expect this task can be improved to accept release archives as input when we're further along with completing more release automation tasks, and this use of the golang.org/dl/ API …dmitshur commented on golang.org/x/net/http2: client can hang forever if headers' size exceeds connection's buffer size and server hangs past request time [1.16 backport]1d
This is a subset of #49076 and will be resolved by [CL 356988](https://golang.org/cl/356988).dmitshur commented on golang.org/x/net/http2: client can hang forever if headers' size exceeds connection's buffer size and server hangs past request time [1.17 backport]1d
This is a subset of #49077 and will be resolved by [CL 357683](https://golang.org/cl/357683).dmitshur commented on cmd/compile: internal compiler error: can't find source for b12->b4: v31 = MOVBload <bool> v14 v1 : DX [1.17 backport]1d
From reading #49122 I understand that this was a regression in 1.17, so 1.16 doesn't need this backport since it doesn't have the bug (please correct if that's not the case).dmitshur commented on runtime: "morestack on g0" in x/perf/storage/app on windows/arm641d
Friendly ping on this issue as it's currently marked as a release-blocker.
Also CC @bufflig in case you're able to take a look.dmitshur commented on golang.org/x/tools/gopls/internal/regtest/diagnostics: TestQuickFixEmptyFiles failing frequently on small/slow builders1d
CC @golang/release.dmitshur commented on golang.org/x/tools/internal/imports: update stdlib index after every major Go release1d
[CL 344629](https://golang.org/cl/344629) updated the index for 1.17, so moving this to next milestone (with early-in-cycle) so this gets pinged when 1.18 is out.dmitshur closed an issue github.com/esimov/stackblur-go: latest release tag is named "1.0.1" instead of "v1.0.1", and not recognized1d
dmitshur commented on github.com/esimov/stackblur-go: latest release tag is named "1.0.1" instead of "v1.0.1", and not recognized1d
Thank you!
Closing, since this is resolved.dmitshur commented on github.com/golang/freetype: discrepancy in scale factor conversion between freetype and truetype packages1d
Thanks for taking a look.
I haven’t looked at the C FreeType code, so I don’t know which it uses offhand. I wouldn’t mind trying to look later on if it can help.This Week
dmitshur starred in github.com/esimov/stackblur-go1d
dmitshur commented on golang.org/x/build/cmd/releasebot: add modes for making a release tweet programmatically1d
(1 comment)
It may seem odd that a generic "too long" message is printed instead of saying how many characters over the limit it is, or even checking that as a precondition.
The reason for …dmitshur commented on golang.org/x/build/internal/task: add task to tweet about Go releases1d
(1 comment)
This is version "1.0.1", but it appears as a pseduo-version because "v" prefix was missed in the tag name. I filed https://github.com/esimov/stackblur-go/issues/4 about t…dmitshur opened an issue github.com/esimov/stackblur-go: latest release tag is named "1.0.1" instead of "v1.0.1", and not recognized1d
Hello, thanks for offering this excellent Go package!
There are two releases published at https://github.com/esimov/stackblur-go/releases, 1.0.1 and 1.0.0, but the tag for 1.0.1 is missing the "v"…dmitshur opened a change golang.org/x/build/cmd/releasebot: add modes for making a release tweet programmatically1d
This allows exercising (and benefiting from improvements offered by)
the programmatic tweet creation tasks as soon as the next minor release.
The same task will be added and used by relui when possib…dmitshur merged a change golang.org/x/website/blog: add 2021 Go Developer Survey launch announcement2d
dmitshur reviewed +2 on golang.org/x/website/blog: add 2021 Go Developer Survey launch announcement2d
dmitshur reviewed +2 on golang.org/x/tools/go/analysis/passes/httpresponse: fix a testing issue.2d
Thanks for the quick fix!
Minor suggestion from golang.org/wiki/CommitMessage:
> • there is no trailing period [in the commit subject]
s/For/Fixes/
Since it seems this is enough to fix and c…dmitshur merged a change all: update vendored golang.org/x/tools2d
dmitshur commented on golang.org/x/tools/go/analysis/passes/httpresponse: add typeparams test2d
This test passes on tip but not 1.17/1.16—filed issue #49160.
Is 'true ||' an accidental left-over from local development, not meant to be included in the final version of this CL?dmitshur opened an issue golang.org/x/tools/go/analysis/passes/httpresponse: Test fails on "typeparams" test case with 1.17/1.162d
As of [CL 358696](https://golang.org/cl/358696), `Test` passes on tip but fails with Go 1.17 and 1.16 (as detected on build.golang.org, see [log](https://build.golang.org/log/1ccc300775d5dcc1d1f71b92…dmitshur commented on cmd/compile: update the export version for generics2d
Opened #49159 for tracking purposes and sent CL 358620 (a simple fix that may be sufficient).dmitshur commented on all: update vendored golang.org/x/tools2d
TRY=longtestdmitshur opened a change all: update vendored golang.org/x/tools2d
Pull in CL 358034 (and some more changes with passing tests) with:
go get -d golang.org/x/tools@f916b54
go mod tidy
go mod vendor
This teaches x/tools/cmd/bundle and the package loader it uses a…dmitshur commented on cmd/internal/moddeps: TestAllDependencies fails due to bundle not working2d
> Perhaps the x/tools version required in src/cmd/go.mod needs to be updated to include [CL 358034](https://golang.org/cl/358034),
That seems to do the trick. Will send a CL.dmitshur opened an issue go/types: 2d
As of [CL 357049](https://golang.org/cl/357049), `moddeps.TestAllDependencies` fails in non-short mode (as detected on the linux-amd64-longtest builder, see [log](https://build.golang.org/log/3e2831d…dmitshur merged a change syscall: [release-branch.go1.17] do not use handle lists on windows when NoInheritHandles is true2d
dmitshur commented on misc/wasm: Go 1.17.2 causes WASM builds to throw `command line too long` with many environment variables2d
@gopherbot Please open backport tracking issues.
This is a follow-up to the security fix included in Go 1.17.2 and 1.16.9 for issue #48797; without it some programs are unable to run.dmitshur commented on golang.org/x/text/transform: Document Chain buffer limit2d
Thanks for reporting this issue. I'm not sure whether it's possible/preferable for `Chain` to be improved so this internal limit is removed, or maybe just documenting it is the better fix.
CC @mpv…dmitshur commented on golang.org/x/perf/storage: support postgres for db2d
I'm not sure whether it's in scope of `x/perf/storage` package to support environments other than what's needed for Go's own needs at perfdata.golang.org. There isn't an [owner entry](https://dev.gol…dmitshur closed an issue golang.org/x/build: plan9 arm builder failed2d
dmitshur commented on golang.org/x/build: plan9 arm builder failed2d
CC @0intro via [builder owners](https://farmer.golang.org/builders).
There's a similarity to [CL 354752](https://golang.org/cl/354752). CC @bcmills.
It looks like it's been fixed recently (than…dmitshur reviewed +2 on github.com/go-gl/gl: Update the Go version to 1.122d
dmitshur reviewed +1 on golang.org/x/website/blog: add 2021 Go Developer Survey launch announcement3d
(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.123d
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.4d
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/freetype4d
scale-nearestdmitshur opened an issue github.com/golang/freetype: discrepancy in scale factor conversion between freetype and truetype packages4d
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 package4d
Thanks—this is a duplicate of #60.dmitshur closed an issue github.com/golang/freetype: don't include Luxi fonts in this package4d
dmitshur reviewed +2 on github.com/go-gl/glfw/v3.3/glfw: add openbsd support5d
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 api1w
dmitshur merged a change golang.org/x/build/dashboard: remove OpenBSD 6.4 builders1w
dmitshur commented on syscall/js: remove Wrapper type to avoid extreme allocations and improve performance1w
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 interface1w
RELNOTE=yesdmitshur closed a change golang.org/x/build/dashboard: upsize openbsd-386-64 to 16 GB RAM1w
dmitshur commented on golang.org/x/build/dashboard: upsize openbsd-386-64 to 16 GB RAM1w
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 builder1w
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 builders1w
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 builder1w
dmitshur commented on runtime: apparent TestEnsureDropM deadlock on openbsd-386-62 builder1w
Indeed, OpenBSD 6.2 is not supported, closing.dmitshur opened an issue golang.org/x/build/dashboard: remove OpenBSD 6.4 builders1w
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]1w
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]1w
dmitshur commented on golang.org/x/build: aix-ppc64 builder has double/unmerged PATH causing wrong 'go' binary to be found1w
@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 first1w
(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 variable1w
RELNOTE=yesdmitshur commented on github.com/shurcooL/githubv4: Not parsing Node query correctly1w
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 name1w
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.