profile
viewpoint
Dmitri Shuralyov dmitshur Google, Go team NYC https://dmitri.shuralyov.com I pursue insight, then make things simpler and better. I enjoy writing correct, high-quality Go code. Minimalist.

avelino/awesome-go 74360

A curated list of awesome Go frameworks, libraries and software

gopherjs/gopherjs 10834

A compiler from Go to JavaScript for running Go code in a browser

glfw/glfw 8566

A multi-platform library for OpenGL, OpenGL ES, Vulkan, window and input

google/go-github 8085

Go library for accessing the GitHub API

russross/blackfriday 4865

Blackfriday: a markdown processor for Go

dustin/go-humanize 3018

Go Humans! (formatters for units to human friendly sizes)

golang/tour 1417

[mirror] A Tour of Go

google/crfs 1196

CRFS: Container Registry Filesystem

go-interpreter/wagon 897

wagon, a WebAssembly-based Go interpreter, for Go.

gregjones/httpcache 656

A Transport for http.Client that will cache responses according to the HTTP RFC

issue commentgolang/go

cmd/go: varying GOROOT_FINAL invalidates precompiled C dependencies of "net"

Based on analysis in https://github.com/golang/go/issues/50183#issuecomment-1018921215 and following discussion, it sounds like it's determined that cmd/go itself is working as intended for 1.18, and there are no changes planned to it. CL 380503 will improve the behavior of the golang.org/dl/... commands. Is that all that's needed here for 1.18, or is there anything more?

lyderic

comment created time in 12 hours

issue commentgolang/go

cmd/go: varying GOROOT_FINAL invalidates precompiled C dependencies of "net"

If I understand correctly, once the accepted proposal #47257 is implemented, this issue (and others like it) will stop being relevant. So that is the long-term fix for this problem, and we just need a short-term one here.

One possible resolution might be to build the release with -trimpath, so that users could themselves build with -trimpath to avoid staleness. (That change would be up to @golang/release to decide.)

It seems that it's not tenable to release with -trimpath unless that becomes the default in cmd/go as well, since we want to avoid staleness with the most common configuration, which is using defaults. Either way, this isn't relevant post-#47257, and there are better short-term alternatives below.

Another possible resolution is to declare that you need a C compiler in order to build with CGO_ENABLED=1. (That seems eminently reasonable to me, but it would be a change in policy.)

Needing a C compiler to build with CGO_ENABLED=1 seems reasonable to me too, and I don't see how things can work otherwise. This seems inevitable post-#47257, and before then, there are better short-term alternatives below.

A third possible resolution is to declare that if you want to use a precompiled Go distribution without a C compiler, you must either set GOROOT_FINAL explicitly to the path used when building that distribution, or install that precompiled distribution to exactly its preordained GOROOT_FINAL location.

As a more immediate workaround (but IMO clearly a hack), I suppose we could change golang.org/dl/internal/version to explicitly set GOROOT_FINAL itself before invoking the go command. 😅

(@golang/release: how do y'all feel about that?)

This seems like the best option to improve things before #47257 is resolved. Its only downside is it increases complexity in golang.org/dl/internal/version, but oh well.

Now that os.Executable() exists and cmd/go finds itself and infers its GOROOT from that, I wonder if GOROOT_FINAL has outlived its usefulness and can be removed, which would help remove the complexity/issues it adds. If so, this workaround in golang.org/dl/internal/version can eventually go away.

lyderic

comment created time in 12 hours

issue commentgolang/go

x/build/cmd/release: Go installer on macOS 12.2 beta (21D5039d) fails

We've applied the aforementioned change to our release pipeline, so macOS installers that are published alongside upcoming Go releases should not be affected by this problem. We can keep this issue open until the next Go release is out, possibly Go 1.18 Beta 2, to verify.

Thanks for reporting this.

alaroldai

comment created time in a day

Pull request review commentgo-gl/glfw

v3.3/glfw: expose native wayland methods

+// +build linux,wayland freebsd,wayland netbsd,wayland

Now that the new file has openbsd,wayland added, it seems native_linbsd_x11.go should also be updated so its build constraint is openbsd,!wayland.

rajveermalviya

comment created time in 2 days

PullRequestReviewEvent

issue closedgo-gl/glfw

glfw.Init() changes os.Getwd() to `./resources/` directory when one exists.

macOS Monterey go1.17.2

Make a project with the following layout:

resources/
go.mod
main.go

main.go:

package main

import (
	"fmt"
	"log"
	"os"

	"github.com/go-gl/glfw/v3.3/glfw"
)

func main() {
	err := glfw.Init()
	if err != nil {
		log.Println(err)
	}

	fmt.Println(os.Getwd())
}
pwd
/Users/$USER/repro

# current working directory incorrectly changes to ./resources
go build .
go run ./repro
/Users/$USER/repro/resources <nil>

# strangely, go run works correctly
go run main.go
/Users/$USER/repro <nil>

# removing resources works correctly
rmdir resources
./repro
/Users/$USER/repro <nil>

Whereas, the modified program without glfw works correctly:

package main

import (
	"fmt"
	"os"
)

func main() {
	fmt.Println(os.Getwd())
}
mkdir resources
go build .
./repro
/Users/$USER/repro <nil>

closed time in 2 days

robertsdionne

issue commentgo-gl/glfw

glfw.Init() changes os.Getwd() to `./resources/` directory when one exists.

As suggested above, this is GLFW working as intended rather than a bug to be fixed. See https://www.glfw.org/docs/latest/intro_guide.html#GLFW_COCOA_CHDIR_RESOURCES_hint.

This behavior can be controlled via the CocoaChdirResources init hint.

robertsdionne

comment created time in 2 days

issue commentgolang/go

x/build/cmd/release: Go installer on macOS 12.2 beta (21D5039d) fails

Bisection suggests the duplicate bg.png file was introduced in the change we made to fix issue #44239, in Feb 2021. go1.15.8 (released just before that change) has one bg.png, but go1.15.9 has two.

That fix involved one line being added to the distribution XML to specify the "background-darkAqua" property:

 <?xml version="1.0" encoding="utf-8" standalone="no"?>
 <installer-gui-script minSpecVersion="1">
   <title>Go</title>
   <background mime-type="image/png" file="bg.png" alignment="left" />
+  <background-darkAqua mime-type="image/png" file="bg.png" alignment="left" />
   <options hostArchitectures="x86_64" customize="never" allow-external-scripts="no" />
 [...]

It seems that reusing the same bg.png file for both "background" and "background-darkAqua" properties may be causing our invocation of the productbuild command (or possibly another, later command in the signing and notarization sequence) to construct a .pkg with two Resources/bg.png entries.

Based on that, I think if we use two different background image files for light and dark themes, it might be sufficient to resolve this issue.

alaroldai

comment created time in 4 days

issue commentgolang/go

x/build/cmd/release: Go installer on macOS 12.2 beta (21D5039d) fails

As it was helpfully pointed out, this may be related to our .pkg having a duplicate file in its table of content:

$ xar -t -f ./go1.17.6.darwin-arm64.pkg
[...]
Resources/bg.png
Resources/bg.png
[...]

A much older .pkg, such as go1.11.1.darwin-amd64.pkg, doesn't have that problem. I'll take a look at how we're building the .pkg file to see what might be causing the duplicate file to appear.

alaroldai

comment created time in 4 days

issue commentgolang/go

x/build/cmd/relui: create production and staging environments

TBD?

In addition to production and staging, I suggest having a third semi-environment, "dry-run mode". It would be intended for local execution and wouldn't need to be deployed anywhere. It would be similar to how releasebot behaves with -dry-run flag: run as much of the same code as possible but skip all external effects.

We can change the color scheme of the header for all 3 modes so they're easy to tell apart, e.g., something like:

image

image

image

toothrot

comment created time in 5 days

issue openedgolang/go

x/build/cmd/gopherbot: assignReviewersToCLs fails to assign reviewers on CL 374434

From gopherbot logs:

2022/01/20 19:15:16 No reviewers or cc: https://go-review.googlesource.com/c/tools/+/374434
2022/01/20 19:15:16 Setting review on https://go-review.googlesource.com/c/tools/+/374434: {Message: Labels:map[] Tag: Comments:map[] Reviewers:[{Reviewer: State:}]}
2022/01/20 19:15:16 Could not set review for change "tools~374434": HTTP status 400 Bad Request; )]}'
{"reviewers":{"":{"input":"","error":"Account \u0027\u0027 is ambiguous (at most 3 shown):\n54144: Alexandre Perrin \u003calex.perrin@isovalent.com\u003e\n54148: Jamie Parrish \u003cjparrishsc@gmail.com\u003e\n54153: Nooras Saba‎ \u003csaba@golang.org\u003e\n does not identify a registered user or group"}},"error":"error adding reviewer"}

Something's went wrong there. It seems it tried to set the reviewer identified by the empty string. Gerrit reports that the empty string is an ambiguous specification of a reviewer.

The logic for adding reviewers in this task looks like this:

// Assign reviewers.
var review gerrit.ReviewInput
for _, owner := range merged.Primary {
	review.Reviewers = append(review.Reviewers, gerrit.ReviewerInput{Reviewer: owner.GerritEmail})
}
for _, owner := range merged.Secondary {
	review.Reviewers = append(review.Reviewers, gerrit.ReviewerInput{Reviewer: owner.GerritEmail, State: "CC"})
}

It seems owner.GerritEmail must be the empty string.

In x/build/internal/gophers there's an entry:

addPerson("Tools Team", "@golang/tools-team", "e37ba6c9c17684849faf885129b25ef8944419e9")

It's possible the change made in CL 247240 is connected, since it results in the Gerrit field becoming an empty string. (Previously, it was "1080@62eb7196-b449-3ce5-99f1-c037f21e1705", which is matched the "group_id@gerrit_instance" format.)

<details><summary>tools-team Gerrit group id source</summary><br>

[
	{
		"url": "#/admin/groups/uuid-e37ba6c9c17684849faf885129b25ef8944419e9",
		"options": {
			"visible_to_all": true
		},
		"description": "Members of the Go tools team. Publicly visible group so it can be cc\u0027d and assigned CLs. Not an ACL group.",
		"group_id": 1080,
		"owner": "tools-team",
		"owner_id": "e37ba6c9c17684849faf885129b25ef8944419e9",
		"created_on": "2020-04-24 21:02:33.000000000",
		"id": "e37ba6c9c17684849faf885129b25ef8944419e9",
		"name": "tools-team"
	}
]

(Source is https://go-review.googlesource.com/groups/?query=inname:tools.)

</details>

CC @hyangah.

created time in 5 days

issue commentgolang/go

x/build/cmd/release: Go installer on macOS 12.2 beta (21D5039d) fails

I found that grr has a .pkg installer for macOS at https://grr-doc.readthedocs.io/en/latest/deploying-grr-clients/overview.html#downloading-clients, although it seems to download the client you may need to run the server, making it somewhat tricky.

alaroldai

comment created time in 6 days

issue commentgolang/go

x/build/cmd/release: Go installer on macOS 12.2 beta (21D5039d) fails

Thanks for testing and confirming this Cherry. Can you try some other macOS installers (e.g., Chrome) and see if they're also affected, or it it only happening to the Go installer?

Given how generic the error message is, it's hard to tell whether it's a bug in macOS or if its requirements changed. I'll try checking if there are any documented changes happening in 12.2 that might explain this.

alaroldai

comment created time in 6 days

push eventgoxjs/websocket

Dmitri Shuralyov

commit sha 42d25217359a4cc2c6cde95dcb90c187c3964e10

add LICENSE file Make the MIT license easier to see by adding a LICENSE file. Use the template at https://choosealicense.com/licenses/mit. Also regenerate README.md and .travis.yml files with gorepogen.

view details

push time in 7 days

push eventgoxjs/glfw

Dmitri Shuralyov

commit sha 4bcee99381f25adc30dbf80419502b91da12ae2b

add LICENSE file Make the MIT license easier to see by adding a LICENSE file. Use the template at https://choosealicense.com/licenses/mit. Also regenerate README.md and .travis.yml files with gorepogen.

view details

push time in 7 days

issue commentgolang/go

x/build/cmd/release: Go Installer v1.17.6 on MacOS 12.2 fails

I tried on macOS 12.1 (21C52) and on macOS 11.6.2 (20G314), and this issue doesn't reproduce. The installer shows up as correctly signed with a Google certificate, and opens okay.

So this may be early signal of a regression in a future macOS release, a problem with beta macOS releases in general, or a problem with the macOS installation on the device you tested with. Are you able to add more information to help us determine if it's one of those possibilities? Thanks.

CC @golang/release.

alaroldai

comment created time in 7 days

issue closedgolang/go

x/website/internal/dl: go-import meta tag isn't served for golang.org/dl/internal/{version,genv}

https://golang.org/dl/internal/version?go-get=1 is 404.

It should be serving something similar to https://golang.org/x/tools/go/vcs?go-get=1, etc.

$ export GOPATH=/tmp/empty
$ go get golang.org/dl/internal/version
package golang.org/dl/internal/version: unrecognized import path "golang.org/dl/internal/version" (parse https://golang.org/dl/internal/version?go-get=1: no go-import meta tags ())

$ goexec 'vcs.RepoRootForImportPath("golang.org/dl/internal/version", false)'
(*vcs.RepoRoot)(nil)
(*errors.errorString)(&errors.errorString{
	s: (string)("unrecognized import path \"golang.org/dl/internal/version\""),
})

This causes https://godoc.org/golang.org/dl/internal/version to show not found, etc.

This affects golang.org/dl/internal/genv package too.

closed time in 7 days

dmitshur

issue commentgolang/go

x/website/internal/dl: go-import meta tag isn't served for golang.org/dl/internal/{version,genv}

Yeah, as far as I can tell, because of how package → module resolution works (documented at https://go.dev/ref/mod#resolve-pkg-mod), in module mode it appears to be sufficient as long as ?go-get=1 works on the module root. At least I'm not aware of any concrete ways that this issue is a problem in module mode.

I can close this issue for now, and consider reopening if we find a good reason to.

dmitshur

comment created time in 7 days

issue commentgolang/go

x/website/internal/talks: go.dev/talks doesn't parse legacy present formatting syntax

It seems the relevant parsing/conversion happens in present.Style:

// Style returns s with HTML entities escaped and font indicators turned into
// HTML font tags.
func Style(s string) template.HTML {
	return template.HTML(font(html.EscapeString(s)))
}

// font returns s with font indicators turned into HTML font tags.
func font(s string) string { ... }

x/website/internal/web defines a wrapper around it:

func presentStyle(s string) template.HTML {
	return template.HTML(present.Style(s))
}

And makes it available as a template function:

t := template.New("site.tmpl").Funcs(template.FuncMap{
	...
	"presentStyle": presentStyle,
})

But then overrides it with a no-op template:

{{define "presentStyle"}}{{.}}{{end}}
dmitshur

comment created time in 8 days

issue openedgolang/go

x/website/internal/talks: go.dev/talks doesn't parse legacy present formatting syntax

https://go.dev/talks hosts some Go talks, many of which use the legacy present syntax (rather than the newer Markdown syntax). The legacy present syntax supports some formatting features, such as:

Formatting:

_italic_
*bold*
`program`
Markup—_especially_italic_text_—can easily be overused.
_Why_use_scoped__ptr_? Use plain ***ptr* instead.

Visit [[https://golang.org][the Go home page]].

This syntax is not parsed in the talks displayed at https://go.dev/talks. Some examples of the breakage:

  • https://go.dev/talks/2011/lex.slide#11
  • https://go.dev/talks/2011/lex.slide#39
  • https://go.dev/talks/2017/state-of-go-may.slide#4
  • https://go.dev/talks/2017/state-of-go-may.slide#7

This syntax is correctly parsed by golang.org/x/tools/cmd/present tool, so this is an x/website-specific bug.

created time in 8 days

startedtdewolff/canvas

started time in 10 days

push eventshurcooL/githubv4

Dmitri Shuralyov

commit sha a14260e6f8a2c38187a2e19c074b338f5ffd6ceb

README: say client rather than s.clQL Use a consistent variable name for the client throughout the README.

view details

push time in 10 days

startedLallassu/bintris

started time in 11 days

issue closedshurcooL/githubv4

Type mismatch between variable and argument for optional String / ID

In trying to query the GitHub repositoryOwner for retrieving repositories for organizations and/or users, I ran into a problem involving the workaround from https://github.com/shurcooL/githubv4/issues/12 as the interface does not appear to like ID for EndCursor.

When calling this query, the following error is returned from GitHub GraphQL API:

Error: Message: Type mismatch on variable $endCursor and argument after (ID / String), Locations: [{Line:1 Column:101}]

type reposQuery struct {
	RepositoryOwner struct {
		Repositories struct {
			Nodes []struct {
				Name string
			}
			PageInfo struct {
				HasNextPage bool
				EndCursor   string
			}
		} `graphql:"repositories(first: 100, after: $endCursor, ownerAffiliations: [OWNER])"`
	} `graphql:"repositoryOwner(login: $owner)"`
}

func getRepos(owner string, endCursor *string) (*reposQuery, error) {
	query := new(reposQuery)
	variables := map[string]interface{}{
		"owner":     graphql.String(owner),
		"endCursor": endCursor,
	}

	err := client.Query("getRepos", query, variables)

	return query, err
}

In stepping through the code, the error emerges in decoding the response from the server where the query is generated as:

"query getRepos($endCursor:ID$owner:String!){repositoryOwner(login: $owner){repositories(first: 100, after: $endCursor, ownerAffiliations: [OWNER]){nodes{name},pageInfo{hasNextPage,endCursor}}}}"

Any assistance would be greatly appreciated 🙇

closed time in 11 days

andyfeller

issue commentshurcooL/githubv4

Type mismatch between variable and argument for optional String / ID

Would you welcome a PR including a section providing an example of this to avoid confusion from other users?

I believe this should be covered by https://github.com/shurcooL/githubv4#pagination; can you please let me know if you think something is missing from there?

I'll close this since I understand the question is resolved.

andyfeller

comment created time in 11 days

issue commentshurcooL/githubv4

Type mismatch between variable and argument for optional String / ID

Ah, that snippet assumed that endCursor was of type string, but in your code its type is *string. In that case, you can just convert it to a *graphql.String directly:

func getRepos(owner string, endCursor *string) (*reposQuery, error) {
	query := new(reposQuery)
	variables := map[string]interface{}{
		"owner":     graphql.String(owner),
		"endCursor": (*graphql.String)(endCursor),
	}

	err := client.Query("getRepos", query, variables)

	return query, err
}

With that change, the program compiles and getRepos makes a successful query with repository names populated. (There are other parts of that program that need modification to run without errors, for example repos = make([]string, 100) creates a slice with 100 empty repository names; it should probably be repos = make([]string, 0, 100) to create an empty slice with 100 capacity.)

andyfeller

comment created time in 11 days

issue commentshurcooL/githubv4

Type mismatch between variable and argument for optional String / ID

From what you've shared, I'm fairly confident the problem is with the variables map you're providing to the Query call, specifically this code:

query := new(reposQuery)
variables := map[string]interface{}{
	"owner":     graphql.String(owner),
	"endCursor": endCursor,
}

err := client.Query("getRepos", query, variables)

I think changing it to the following should work:

query := new(reposQuery)
variables := map[string]interface{}{
	"owner":     graphql.String(owner),
	"endCursor": graphql.NewString(graphql.String(endCursor)),
}

err := client.Query("getRepos", query, variables)

If that doesn't help, can you post a complete program that reproduces the issue for you?

Finally, take a look at https://github.com/shurcooL/githubv4#pagination if you haven't already, since that is a functional example for pagination.

andyfeller

comment created time in 12 days

startedPostgresApp/PostgresApp

started time in 12 days

issue commentshurcooL/githubv4

Type mismatch between variable and argument for optional String / ID

Yes, if it's an optional GraphQL type, using a Go pointer makes sense. That is also what's done in the code example I linked above. The NewString helper exists for convenience of doing this.

andyfeller

comment created time in 12 days

issue commentshurcooL/githubv4

Type mismatch between variable and argument for optional String / ID

If you look at GitHub's RepositoryOwner interface, the after argument of the repositories field has type String, so that's what needs to be provided. Your code can look something like:

variables := map[string]interface{}{
	"owner":     githubv4.String(owner),
	"endCursor": githubv4.String(endCursor),
}

See here for an example of similar code.

andyfeller

comment created time in 13 days

more