profile
viewpoint
Dmitri Shuralyov dmitshur Google, Go team NYC https://dmitri.shuralyov.com I seek a better understanding of the world, so I can help make it simpler and better. I enjoy writing correct, high-quality Go code. Minimalist.

avelino/awesome-go 55593

A curated list of awesome Go frameworks, libraries and software

gopherjs/gopherjs 9480

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

glfw/glfw 6467

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

google/go-github 5931

Go library for accessing the GitHub API

dustin/go-humanize 2243

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

golang/tour 1146

[mirror] A Tour of Go

google/crfs 990

CRFS: Container Registry Filesystem

go-interpreter/wagon 871

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

gregjones/httpcache 533

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

mdempsky/unconvert 297

Remove unnecessary type conversions from Go source

issue commentgolang/go

WebAssembly not executing/compiling due to incorrect response MIME type. Expected 'application/wasm'.

http.FileServer should be serving files with .wasm extension as "application/wasm" since Go 1.11, see commit 534ddf741f6a5fc38fb0bb3e3547d3231c51a7be.

Is it possible your /etc/mime.types or another similar file overrides it to something else?

What does this program print for you? It should be "application/wasm". If not, check your local MIME files(/etc/mime.types, /etc/apache2/mime.types, /etc/apache/mime.types).

bbloks

comment created time in 2 hours

issue commentgolang/go

x/blog: go generate example not working (?)

It seems that error is expected. The next paragraph says:

Oops! We didn't include a ConnectionInfo or tell Wire how to build one. Wire helpfully tells us the line number and types involved. We can either add a provider for it to wire.Build, or add it as an argument:

[...]

Now go generate will create a new file with the generated code:

Did you follow those steps?

Also, what's the output if you run go generate -x?

jeffdahl

comment created time in 3 hours

startednikolaydubina/calendarheatmap

started time in 11 hours

issue commentgolang/go

crypto/tls: generate_cert.go sets KeyEncipherment KU for non-RSA keys [freeze exception]

Fixing this during freeze seems okay to me. Chrome 83 was released after the Go 1.15 freeze started, so some of the information here wasn't available earlier. A +build ignored file doesn't contribute to the stability of the final release, and won't compromise testing that has been done via Go 1.15 Beta 1.

cpu

comment created time in a day

startedgoogle/safehtml

started time in 2 days

issue commentgolang/go

x/pkgsite/internal/fetch/dochtml/internal/render: leave a sample of values when trimming large string literals and composite literals

The relevant code is in declVisitor.

Right now it replaces the entire thing that's too big, leaving just a comment. It can instead leave the first N elements/bytes and trim the rest, as long as it's viable to do so in a way that doesn't create misleading documentation.

It should be balanced with leaving too much that packages start hitting the maximum documentation size limit and not being displayed at all.

/cc @julieqiu @shaqque

pjebs

comment created time in 2 days

issue commentgolang/go

all: switch to Go 1.15 as default inside Google

@elfgoh There’s some additional motivation described on the Go Release Cycle page:

One of the criteria for issuing a release candidate is that Google be using that version of the code for new production builds by default: if we at Google are not willing to run it for production use, we shouldn't be asking others to.

I recommend reading that entire page as it provides context for each milestone and the process leading up to the final release.

dmitshur

comment created time in 2 days

issue commentgolang/go

godoc: long map variables should give a sample of values.

Thanks for this feature request. I think this is a good idea to consider.

We're currently prioritizing feature development in the new x/pkgsite codebase per https://blog.golang.org/pkg.go.dev-2020, so this is likely better suited as an issue for that project. Does that sound good to you? (Otherwise, the issue tracker for godoc.org specifically is at https://github.com/golang/gddo/issues.)

pjebs

comment created time in 3 days

issue commentgolang/go

cmd/go: support overlays in the go command

/cc @matloob @jayconrod @bcmills per owners.

stamblerre

comment created time in 3 days

issue commentgolang/go

x/text/message: documentation for i18n HTML template example?

/cc @mpvl per owners.

raspi

comment created time in 3 days

issue commentgolang/go

x/mobile: Required use of deprecated environment variables for Android

/cc @eliasnaur @hyangah @hajimehoshi

ToJen

comment created time in 3 days

issue commentgolang/go

x/crypto/ssh/test: TestRunCommandStdinError go test fails

/cc @hanwen @FiloSottile per owners.

rogers0

comment created time in 3 days

issue commentgolang/go

x/net/icmp: bind fails SOCK_DGRAM IPPROTO_ICMP

/cc @mikioh per owners.

isedev

comment created time in 3 days

issue commentgolang/go

cmd/link: incorrect GC bitmap when global's type is in another shared object [1.14 backport]

@aclements Can you please include a short rationale about why the backport might be needed? (Per MinorReleases.) Thanks.

gopherbot

comment created time in 3 days

issue commentgolang/go

encoding/json: Unmarshal behavior changed to match its documented behavior about not reusing slice elements

@mvdan @dsnet Are you in agreement with the plan suggested for 1.15 in https://github.com/golang/go/issues/39427#issuecomment-650249580?

bobotu

comment created time in 3 days

issue closedgolang/go

runtime: deadlock on blocking call

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions --> This happens when compiling Go code into wasm with: GOOS=js GOARCH=wasm go build -o ./Go/assets/main.wasm wasm.go

What version of Go are you using (go version)?

<pre> $ go version go1.14.4 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/peter/.cache/go-build" GOENV="/home/peter/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/usr/local/go:/home/peter/work" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/snap/go/5830" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/snap/go/5830/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build651075817=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

What did you do?

Attempted to make a request from compiled Wasm code.

func query(this js.Value, args []js.Value) interface{} {
	var rv interface{}

	c1 := make(chan string)
	go func() {
		c1 <- makeRequest()
	}()

	target:= fmt.Sprintf("%s", args[0]) + "Result"

	select {
	case color := <-c1:
		js.Global().Get("document").Call("getElementById", target).Set("innerHTML", color)
	}
	return rv
}

What did you expect to see?

A string in a HTML element.

What did you see instead?

fatal error: all goroutines are asleep - deadlock! wasm_exec.js:47 wasm_exec.js:47 goroutine 1 [select (no cases)]:

closed time in 3 days

pigfox

issue commentgolang/go

runtime: deadlock on blocking call

Yep, that code is making query the callback handler by setting an element's onclick property:

onclick="query('colors');

The deadlock is working as intended per documentation at https://golang.org/pkg/syscall/js/#FuncOf. (Thanks @agnivade.)

pigfox

comment created time in 3 days

issue openedgolang/go

x/playground: output caching is not working

It looks like #31889 has regressed. The same snippet can be used to observe it, rerunning this program produces successful but different output each time:

https://play.golang.org/p/979rn6Bd7QN

I've noticed this when sharing a snippet (/cc @julieqiu) where a timeout due to a large dependency would happen occasionally. Usually, with output caching, getting it to succeed once makes it possible to share the snippet so it no longer needs to execute again, but that wasn't the case.

/cc @toothrot @cagedmantis @andybons

created time in 3 days

issue commentgolang/go

runtime: deadlock on blocking call

Thanks for reporting. This may be a problem in the code rather than the Go runtime. In order to investigate, we'll need to know how query being called. Can you provide more information on that please?

@neelance Is there a restriction on where blocking calls can be made (e.g., inside callbacks), and do you know if we've documented it somewhere? I'm not finding it in https://golang.org/wiki/WebAssembly.

pigfox

comment created time in 4 days

issue closedgolang/go

x/playground: support txtar input files

(Pulling out of related third-party imports bug #31944)

This is a tracking bug to support multiple input files.

We'll start with txtar format, and use txtar behind the scenes when saving shared snippets. But we might add web UI to have separate <textarea> boxes later.

closed time in 4 days

bradfitz

issue commentgolang/go

x/playground: support txtar input files

Multiple input files are supported (via txtar format) by now, so I'll close this.

Adding a web UI to have separate <textarea> boxes seems to be better tracked in a new dedicated issue.

bradfitz

comment created time in 4 days

issue commentgolang/go

x/playground: support third-party imports

The Playground largely supports third-party imports by now.

@bradfitz Should we close this issue now, or are there specific things that remain to be done here?

/cc @toothrot

bradfitz

comment created time in 4 days

issue commentshurcooL/graphql

Struct Field Tag not Properly Working

variables := map[string]interface{}{
	"query": graphql.String(fmt.Sprintf(`\"updated_at:>'%s'\"`, date)),
}

That seems over-quoted. Can you try something like this:

variables := map[string]interface{}{
	"query": graphql.String(fmt.Sprintf(`updated_at:>'%s'`, date)),
}
achempak

comment created time in 4 days

issue closedgolang/go

x/pkgsite: Add Github Gopherbot -> Gerrit review

<!-- Please answer these questions before submitting your issue. Thanks! -->

What is the URL of the page with the issue?

What is your user agent?

N/A

Screenshot

N/A

What did you do?

Open a PR on Github for x/pkgsite

What did you expect to see?

Gopherbot imports the PR to Gerrit for code review

What did you see instead?

No import to Gerrit for code review

closed time in 4 days

kush-patel-hs

issue commentgolang/go

x/pkgsite: Add Github Gopherbot -> Gerrit review

That PR was created at 2020-06-17T03:22:44Z and closed at 2020-06-17T03:23:01Z (17 seconds later). It may take GerritBot a minute or two to import a PR, so it looks like it just didn't get a chance to.

I don't think there's an issue here, you should be able to send either Gerrit CLs or GitHub PRs as documented at https://golang.org/wiki/GerritBot to contribute code changes. If you try it and run into a problem, please don't hesitate to reopen this issue or file a new one. Thanks.

kush-patel-hs

comment created time in 4 days

issue commentgolang/go

x/pkgsite: Add Github Gopherbot -> Gerrit review

Open a PR on Github for x/pkgsite

What was the PR you opened?

kush-patel-hs

comment created time in 4 days

issue commentgolang/go

x/website: missing alt tags on gopher images in 3 pages

Thank you for contributing a fix for this issue!

nel417

comment created time in 4 days

issue commentgolang/go

x/website: missing alt tags on gopher images in 3 pages

No worries, I can submit for you. (You can read more about Gerrit access here.) I just wanted to give you a chance to update the commit message if you wanted. I'll submit soon.

The update will be live on golang.org after the next time it's redeployed. The change in the /help/ file will take longer, because it's in the main Go repo, so it'll get updated when 1.15 is out.

nel417

comment created time in 4 days

issue commentgolang/go

proposal: dl/gotip: allow building branches

I wonder why gopherbot hasn't pinged this issue yet.

It should be because the CL didn't use a fully qualified issue reference (i.e., it was missing the "golang/go" prefix). /cc @FiloSottile

vearutop

comment created time in 4 days

issue commentgolang/go

x/website: missing alt tags on gopher images in 3 pages

@nohe427 I didn't see there was already precedent for it on the same page, thanks for spotting that. Looks like it's not consistent with the blog post. Oh well, we're going with an empty string alt attribute, so let's not change other things for now.

nel417

comment created time in 4 days

issue commentgolang/go

x/build: add builder for macOS on Apple silicon

@tzeejay Thanks for the offer to help! We're currently in the release freeze period for Go 1.15, so active work on this will likely wait until the tree re-opens in a bit over a month from now. Also follow issue #38485 for any port-specific updates. We'll reach out to you if we find a way you can contribute.

Based on what you said, it seems like the darwin/amd64 port is working via Rosetta 2, which is great to see.

cagedmantis

comment created time in 4 days

issue openedgolang/go

x/build/cmd/gopherbot: GopherBot avatar on github.com has become cut-off

GitHub has recently made design changes on github.com, and avatars are now displayed in a circle rather than a square with rounded corners.

This makes the GopherBot avatar appear cut-off:

<img src=https://user-images.githubusercontent.com/1924134/85929995-e24c4880-b886-11ea-99c1-c62d3bf2e163.png width=318px>

<img src=https://user-images.githubusercontent.com/1924134/85930001-e8dac000-b886-11ea-9bc3-ffba0782eefe.png width=234px>

The Gopher is good at adapting to changes in environments, I'm sure we can find a way to make it fit inside the new circular constraints of GitHub avatars.

/cc @golang/osp-team

created time in 4 days

push eventshurcooL/home

Dmitri Shuralyov

commit sha 42f39a1766d60c03c287a018805e19ea8d670c56

internal/exp/cmd/spa: preserve URL fragment when navigating As one example of why this change is helpful, consider clicking on a notification pointing to a specific comment (which is a URL with a fragment). Now that the URL fragment is preserved, it highlights the target comment upon navigation, instead of just staying at the top of the page.

view details

push time in 5 days

issue openedholzschu/a-shell

environment variables are not provided to executed wasm modules

Thank you for making a-Shell, it already brings me a lot of joy. This is a feature request.

It's possible to execute a WebAssembly module in a-Shell, as documented at https://github.com/holzschu/a-shell#programming--add-more-commands, which is very useful. However, environment variables that are set in the shell are not propagated to the executed program. As far as I can see, the relevant code is:

https://github.com/holzschu/a-shell/blob/7572fb5b82e3b17c38402067784a86fd236711a7/hterm.html#L128

Environment variables are a critical input for many existing programs, so many more useful programs could be compiled to WebAssembly and used in a-Shell if this is implemented.

created time in 5 days

issue commentgolang/go

x/website: missing alt tags on gopher images in 3 pages

Thank you. I can re-run the trybots now.

nel417

comment created time in 6 days

push eventshurcooL/githubv4

jlamb1

commit sha e003124d66e430e2f6b853080a90ddbc280a159b

README: mention support for GitHub Enterprise in Usage section Both GitHub.com and GitHub Enterprise servers are supported. Document both in the Usage section, so it's easier to see. GitHub-Pull-Request: https://github.com/shurcooL/githubv4/pull/53

view details

push time in 6 days

PR merged shurcooL/githubv4

Add documentation for NewEnterpriseClient

adds a simple example how to connect to an enterprise GitHub instance.

+7 -0

3 comments

1 changed file

jlamb1

pr closed time in 6 days

issue commentgolang/go

x/website: missing alt tags on gopher images in 3 pages

Not sure where the help file is located at. Any guidance would be appreciated.

That file is still in the main Go repository, here.

nel417

comment created time in 6 days

push eventshurcooL/vfsgen

Dmitri Shuralyov

commit sha cf84b0e9e8dd1e590624967990600f0e24e94693

.travis.yml: use go vet instead of go tool vet As of Go 1.12, go tool vet is no longer supported.¹ Start using the go vet command instead. Use RCS format for gofmt diff. It results in cleaner, easier to read gofmt diffs. ¹ https://golang.org/doc/go1.12#vet

view details

Dmitri Shuralyov

commit sha 92b8a710ab6cab4c09182a1fcf469157bc938f8f

remove unconditional write to stdout Writiting to the stdout unconditionally is noisy and inflexible. The caller is in a better position to decide if anything should be printed to stdout, and it can already do that. So remove the uncoditional write from the Generate function. Don't add anything to vfsgendev, keeping it quiet when everything is successful. This is consistent with various Go code generators like stringer, and testing it out over the last few weeks did not make me feel like something is missing. It's also more consistent with the philosophy for Unix and Plan 9 tools, where it's nice to be quiet when all goes as planned. For https://github.com/shurcooL/vfsgen/issues/81.

view details

push time in 6 days

pull request commentshurcooL/vfsgen

Add fallback file for single page applications

Hi there, thanks for the PR.

This functionality makes sense, but it can and should be out of scope for vfsgen. The goal of vfsgen is to convert a dynamic http.FileSystem into a statically-encoded one. Everything else that is higher level should be done by other libraries or application.

The functionality to serve a fallback file can be implemented quite easily:

f, err := fs.Open(path)
if os.IsNotExist(err) {
    f, err = fs.Open("/index.html")
}
if err != nil {
    // handle error
}
// serve file f (e.g., with http.ServeContent)
cwen0

comment created time in 6 days

issue commentgolang/go

fmt: Shouldn't %q (and %s) treat nil as a valid value?

I've also run into this issue in the past, and my initial suspicion was that was an issue in fmt package that needed to be fixed. I've spend more time investigating and considering what can be done, but in the end, I couldn't convince myself that there was anything that could be done in fmt itself.

I instead modified the code to use %v in cases where the error might be nil, and reserved my use of %s (or %q) in cases where I've checked that it's not.

musiphil

comment created time in 7 days

issue commentgolang/go

x/pkgsite:

Can you please provide answers to the questions "What did you expect to see?" and "What did you see instead?" in the issue template? Otherwise, it's hard to tell what this issue is about. Thanks.

Also please see https://pkg.go.dev/license-policy, as it might be relevant.

/cc @julieqiu

Darthsoviet

comment created time in 7 days

issue commentgolang/go

x/pkgsite: replace all internal Googler links

Only 7 more to go after CL 240187.

mvdan

comment created time in 7 days

IssuesEvent

issue commentgolang/go

x/pkgsite: replace all internal Googler links

There are a few more instances that can be found without the "TODO" prefix:

$ git log -1 --oneline --no-decorate
08e8e66 internal/worker: add /poll and /enqueue endpoints.
$ git grep -E 'b/[0-9]{4}' | wc -l
      12
mvdan

comment created time in 7 days

issue commentgolang/go

x/pkgsite/internal/fetch/dochtml, x/tools/cmd/godoc: BUG, TODO etc. should be re-thought

And godoc.org completely ignores them

This might've been true at the time that comment was made (in 2013), but by now, they are displayed on godoc.org as well as on pkg.go.dev.

a nice UI for [...] presenting BUG(foo), TODO(bar) etc.

Various websites that display Go package documentation so far have used slightly different URL schemes for linking to these sections. Compare:

  • https://golang.org/cmd/gofmt/#pkg-note-BUG
  • https://godoc.org/rsc.io/pdf#pkg-note-bug
  • https://pkg.go.dev/rsc.io/pdf#pkg-note-BUG

Pkg.go.dev has so far followed suit from x/tools/cmd/godoc, but perhaps it would be better to make the fragment in the URL lower case. These URLs are used relatively infrequently, so if there can be a usability improvement made, it might not be too late. As more time passes, it becomes more expensive to make any change, and the current scheme is more likely to stay.

/cc @julieqiu

robpike

comment created time in 7 days

issue openedgolang/go

x/pkgsite/internal/fetch/dochtml: complete iteration and development, ensure the API can be used effectively in other contexts, then move the package out of "internal"

This is a high level tracking issue for the task of completing the documentation rendering API and being able to move that package out from an "internal" package.

The package started out as an internal copy of CL 72890, and it was iterated on and developed as part of pkgsite. Being an internal package (currently, under golang.org/x/pkgsite/internal) made development and testing easier, but it means the package cannot be used directly elsewhere yet. A goal is to eventually be able to replace the need for the original documentation renderer which is currently less featureful but available via the high-level golang.org/x/tools/godoc package.

/cc @julieqiu @jba @shaqque @hyangah @stamblerre @dsnet

created time in 7 days

issue commentgolang/go

encoding/json: behavior changed when decoding into []interface{}

Here's another relevant minified test case I've come across. This might not be exactly the same issue, but it's related to the same fix CL. It is an example of code that was directly relying on the opposite-of-what-documentation-said behavior in Go 1.14, and so it breaks in 1.15 where #21092 is fixed:

package main

import (
	"encoding/json"
	"fmt"
	"log"
)

type combo struct {
	One  one
	Many []one
}

type one struct {
	A string
	B string
}

func main() {
	b := []byte(`{
		"One":  {"A":"hello"},
		"Many":[{"B":"there"}]
	}`)

	var v combo
	if err := json.Unmarshal(b, &v); err != nil {
		log.Fatalln(err)
	}

	// Initialize many with one.
	for i := range v.Many {
		v.Many[i] = v.One
	}

	// Unmarshal again, which in 1.14 would reuse slice elements
	// when decoding (counter to encoding/json documentation).
	if err := json.Unmarshal(b, &v); err != nil {
		log.Fatalln(err)
	}

	fmt.Println(len(v.Many), v.Many[0].A, v.Many[0].B)

	// Output (Go 1.14): 1 hello there
	// Output (Go 1.15): 1  there
}

As far as I see, the original issue with the mismatch in documentation and behavior was reported in #21092. That was in July 2017. The general preference of package owners at the time was to fix it. @rsc said back then:

I agree that when appending to a slice, unmarshal should start with fresh zeroed slice elements and not the old slice elements that happen to sit between len and cap. Too late for Go 1.10 though.

The relevant CL notes:

The previous behavior directly contradicted the docs that have been in place for years

If it's been in place for years, another option is to update documentation to match the (unintended) behavior.

We should decide what is better to do at this point. I've seen us update the documentation more often than change behavior in such cases, but I'll let people more familiar with encoding/json and these subtle trade-offs weigh in. Marking as NeedsDecision release-blocker for 1.15.

/cc @mvdan @rsc @neild

bobotu

comment created time in 8 days

issue commentgolang/go

x/website: missing alt tags

A few pages on the Go website, Documents, Project, And Help,

From that description, I understand it's these URLs:

  • https://golang.org/doc/ - two img.gopher elements are missing alt attribute
  • https://golang.org/project/ - img.gopher is missing alt attribute
  • https://golang.org/help/ - img.gopher is missing alt attribute

They are indeed missing alt attribute on the gopher images. Please let us know if I misunderstood, @nel417.

/cc @andybons

nel417

comment created time in 8 days

issue commentgolang/go

net/http: performance degradation in 1.15beta1

I reproduced this with results similar to what's posted above on a macOS laptop, and I don't have much new information to add. The difference between 1.14.4 and tip is very small compared to the variance of the micro benchmark, and I wasn't able to narrow it down further.

It seems to correlate to the various changes to net/http between 1.14 and tip (https://github.com/golang/go/commits/master/src/net/http), most of which were minor strictness/correctness improvements, and none were optimizations.

Perhaps someone else can narrow it down further or more conclusively, but I did not find an actionable issue here.

proyb6

comment created time in 8 days

issue commentgolang/go

go/doc: associated type of factory functions may not be the first returned type

Thanks for reporting.

The Forecast function is being considered as a "factory function" for the type Confidence because it returns a slice of that type, and all other return value types are predeclared type.

This is working as intended given the current implementation, see the relevant code in go/doc here.

Note that this is a heuristic, so it is expected it may not produce absolutely ideal results in all cases. The heuristic was chosen with a goal of working as well as possible as often as possible. Based on your description, it sounds this is a case where it's not optimal.

We could consider changing the heuristic to require associated type of factory functions to be the first result type, rather than the first visible result type. In order to gain confidence that it would be a net positive to make such a change, we could test it out on a large corpus of Go packages and evaluate whether it results in more changes that are more helpful than unhelpful.

/cc @griesemer

pjebs

comment created time in 8 days

issue commentgolang/go

crypto/x509: update bundled iOS roots

@FiloSottile With CL 239557 submitted, should the milestone be updated to 1.16, or is there more to do here for 1.15?

FiloSottile

comment created time in 9 days

issue commentgolang/go

misc/cgo/testcshared: sometimes stalls on windows-amd64-longtest builder in non-sharded longtest mode

There may have been an occurrence of this exact problem or a similar problem in the SlowBot run of CL 239738 just now:

[...]
scatter = 0000000000569860
sqrt is: 0
hello from C
ok  	misc/cgo/test	16.696s

##### ../misc/cgo/testgodefs
PASS

##### ../misc/cgo/testso
ok  	misc/cgo/testso	1.981s

##### ../misc/cgo/testsovar
ok  	misc/cgo/testsovar	2.256s

##### ../misc/cgo/testcarchive
PASS


Error: runTests: dist test failed: all buildlets had network errors or timeouts, yet tests remain
dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

When the reason parameter to wantStale helper is the empty string, it disables the reason check (the staleness is still checked independently of the reason), see here.

Hmm, I wrote that based on memory, but now that I look at the code, it looks like it would fail even if reason parameter is the empty string, if isStale gives a non-empty why.

In that case, the smallest direct test fix I can think of is to add a new wantStaleIgnoreReason helper. That's probably better than a hack like a single space as the reason.

dmitshur

comment created time in 9 days

issue closedgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

This test failure is uncovered as of linux-386-longtest builder now testing linux/386, but currently masked by #39309. It became exposed when I was testing a fix for #39309 in CL 237617 and CL 237619.

TestBuildIDContainsArchModeEnv was added in CL 43855 to test that GOARM and GO386 environment variables contribute to the build ID and staleness checks. It's always skipped in short mode.

I haven't confirmed it, but there's a chance that the TestBuildIDContainsArchModeEnv/386 subtest may not have taken into account that it might be run on linux/386, where GOARCH=386 is already the starting condition.

Either because of that, or for another reason, TestBuildIDContainsArchModeEnv/386 has a different stale reason when run on linux/386:

go_test.go:4901: wrong reason for Stale=true: "build ID mismatch", want "stale dependency"

The check for stale reason changed from "build ID mismatch" to "stale dependency: runtime/internal/sys" as part of CL 73212, later changed to just "stale dependency" in CL 112975 (/cc @ysmolsky), and finally was completely removed in the test refactor in CL 214387 (/cc @matloob) (it still checks for staleness, just not the exact reason). This is why this issue is happening on 1.14 and 1.13, but not 1.15.

Next step in this issue is to investigate if this failure suggests there is a problem in cmd/go, or whether the test on 1.14 and 1.13 release branches is bad and should be fixed for linux/386.

/cc @bcmills @matloob @jayconrod

closed time in 9 days

dmitshur

issue commentgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

I've opened 2 backport issues. Closing this, since this is resolved for 1.15.

dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

@gopherbot Please backport to the last 2 releases. This is a test fix. It makes a cmd/go test less strict and enables it to pass in all environments, which matches the behavior of the same test in the latest version, which has been confirmed to be most optimal.

dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

Thanks for confirming.

@bcmills FWIW, if backporting the test script test proves to be tricky due to merge conflicts or missing code in previous versions, another way to fix the test in 1.14 and 1.13 release branches would be with by removing the stale reason from the wantStale helper:

-tg.wantStale("mycmd", "stale dependency", "should be stale after environment variable change")
+tg.wantStale("mycmd", "", "should be stale after environment variable change")

When the reason parameter to wantStale helper is the empty string, it disables the reason check (the staleness is still checked independently of the reason), see here.

dmitshur

comment created time in 9 days

issue commentgolang/go

internal/cfg: GOROOT_FINAL isn't included in KnownEnv, hard to tell if that's a bug or intentional

GOROOT_FINAL has some (albeit indirect) effect

It might be indirect enough to be considered no effect. Perhaps the scope of these env vars are vars that can be set after a Go tree has been installed, and cmd/go tests are out of scope. I wasn't sure from the documentation, which is in large part what this issue is about.

dmitshur

comment created time in 9 days

issue openedgolang/go

internal/cfg: GOROOT_FINAL isn't included in KnownEnv, hard to tell if that's a bug or intentional

I've noticed the current cfg.KnownEnv list does not include the GOROOT_FINAL environment variable.

We know from #39385 that GOROOT_FINAL has some (albeit indirect) effect on the behavior of the Go command (fortunately, GOROOT_FINAL_OLD no longer does).

Should GOROOT_FINAL be included in cfg.KnownEnv, or is it intentional that it's not listed?

The documentation for KnownEnv is somewhat brief:

// KnownEnv is a list of environment variables that affect the operation
// of the Go command.

It'd be nice to clarify if it's meant to be an exhaustive list or not, and whether some env vars should be intentionally left out or not.

/cc @bcmills @matloob @jayconrod

created time in 9 days

issue commentgolang/go

runtime: aix-ppc64 builder is failing with "bad prune", "addr range base and limit are not in the same memory segment" fatal errors

I'm puzzled about what happened in this issue. It's still open, yet I see CL 233497 was merged on May 14th into the main Go repo with the text "Fixes #38966", which is this very issue. Yet it never got closed?

(That CL caused #39128, which was fixed via roll-forward.)

Maybe GitHub had an service disruption that caused the "Fixes #38966" to get skipped somehow.

@mknyszek Can you confirm this issue should be closed now, or am I missing something? Thanks.

dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

@jayconrod What we need here for the 1.15 milestone is to confirm the current 1.15 test behavior (which is different from 1.14 and 1.13 test behavior) is intended and correct. If it isn't, it should be fixed before the 1.15 release.

Based on your comment and @bcmills's reaction, it sounds like that's the case, and are now just thinking about how to address the issue in 1.14 and 1.13. Is that the case? Or is there more investigation to do for 1.15 here? Thanks.

dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/gofmt: inconsistent indentation with comments in switch

This is a bug that has existed for many years, and it's very minor. It seems too late to work on a fix this late in the 1.15 cycle, so I'll move this to backlog and we can revisit in the future.

seankhliao

comment created time in 9 days

issue commentgolang/go

net/http: performance degradation in 1.15beta1

Thanks for looking @dr2chase. I can try reproducing this on a Mac laptop too.

it would be nice if the bug filer could try tip and see if things look better

@proyb6 Are you able to try again with the latest tip commit? (The gotip command may be convenient for this.)

proyb6

comment created time in 10 days

issue commentgolang/go

crypto/x509: build tag "ios" broken at tip on darwin/amd64

I am spotting an issue now. As you mentioned, it's not using embedded roots in iOS mode (only when GOARCH is amd64; not when it's arm64).

The following test cases, which I forgot to include earlier, catch this:

{
	"iOS 64-bit in iOS simulator on Intel-based macOS (darwin/amd64, ios build tag), Cgo on",
	"darwin", "amd64", true, []string{"ios"},
	"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_darwin_arm64.go sec1.go verify.go x509.go",
},
{
	"iOS 64-bit in iOS simulator on Intel-based macOS (darwin/amd64, ios build tag), Cgo on, x509omitbundledroots build tag",
	"darwin", "amd64", true, []string{"ios", "x509omitbundledroots"},
	"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_omit.go sec1.go verify.go x509.go",
},
$ go test -v -run=TestBuildModes crypto/x509
=== RUN   TestBuildModes
    x509_test.go:1464: iOS 64-bit in iOS simulator on Intel-based macOS (darwin/amd64, ios build tag), Cgo on: source files = "cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_darwin_amd64.go sec1.go verify.go x509.go root_cgo_darwin_amd64.go", want "cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_darwin_arm64.go sec1.go verify.go x509.go"
    x509_test.go:1464: iOS 64-bit in iOS simulator on Intel-based macOS (darwin/amd64, ios build tag), Cgo on, x509omitbundledroots build tag: source files = "cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_darwin_amd64.go sec1.go verify.go x509.go root_cgo_darwin_amd64.go", want "cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_omit.go sec1.go verify.go x509.go"
--- FAIL: TestBuildModes (0.01s)
FAIL
FAIL	crypto/x509	0.394s
FAIL
bradfitz

comment created time in 10 days

issue commentgolang/go

crypto/x509: build tag "ios" broken at tip on darwin/amd64

I'm not spotting an issue with the selected files from a first look.

I am spotting an issue now. As you mentioned, it's not using embedded roots in iOS mode. Sorry for a misleading comment.

The problem is that I don't know if Security.framework is acceptable in the iOS simulator (while maybe neither cgo nor shelling out were), or if we need to reintroduce the tag.

I think keeping the same behavior for iOS as it was in 1.14 would be the safest path forward, which means it should continue to use embedded roots (optionally compressed/lazy loaded if x509omitbundledroots build tag is also specified).

Upgrading iOS from using embedded roots to fetching them from via APIs, if it happens to be possible now via Security.framework, can be a feature request to be investigated for 1.16 or later.

I am still not sure what this is supposed to do, besides "compile".

Is the fourth paragraph in https://github.com/golang/go/issues/38710#issuecomment-647483240 helpful? In iOS mode (regardless if the GOARCH used is arm64 or amd64), embedded roots should be used.

is there a way to run the simulator from the command line?

As far as I know, the only officially supported way will need to use x/mobile's gomobile tool, and it will need an Apple developer identity to be available in the environment. I don't think that a test that can be added to crypto/x509. Adding a new builder is a reasonable request, but seems out of scope for this issue.

bradfitz

comment created time in 10 days

issue commentgolang/go

crypto/x509: build tag "ios" broken at tip on darwin/amd64

I'll look into if the right files are selected, and maybe send a test that checks that for all relevant build configurations, so we have more confidence and this doesn't regress.

I'm not spotting an issue with the selected files from a first look.

@FiloSottile, does the aforementioned test that checks various build configurations and the .go files that are selected sound worth including? A draft looks like this:

<details><br>


// Test supported build modes. Primarily to provide coverage for
// mobile platforms (Android, iOS) and special build tags.
func TestBuildModes(t *testing.T) {
	if testing.Short() {
		t.Skip("skipping in -short mode")
	}

	tests := []struct {
		name         string
		goos, goarch string
		cgo          bool
		tags         []string
		wantGoFiles  string // Space-separated list of all .go files selected in the build.
	}{
		{
			"Linux (linux/arm64), Cgo on",
			"linux", "ppc64", true, nil,
			"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_linux.go root_unix.go sec1.go verify.go x509.go",
		},
		{
			"Android (android/arm64), Cgo on",
			"android", "amd64", true, nil,
			"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_linux.go root_unix.go sec1.go verify.go x509.go",
		},

		{
			"macOS Intel-based 64-bit (darwin/amd64), Cgo off",
			"darwin", "amd64", false, nil,
			"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_darwin_amd64.go sec1.go verify.go x509.go",
		},
		{
			"macOS Intel-based 64-bit (darwin/amd64), Cgo on",
			"darwin", "amd64", true, nil,
			"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_darwin_amd64.go sec1.go verify.go x509.go root_cgo_darwin_amd64.go",
		},
		{
			"iOS 64-bit (darwin/arm64, ios build tag), Cgo on",
			"darwin", "arm64", true, []string{"ios"},
			"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_darwin_arm64.go sec1.go verify.go x509.go",
		},
		{
			"iOS 64-bit (darwin/arm64, ios build tag), Cgo on, x509omitbundledroots build tag",
			"darwin", "arm64", true, []string{"ios", "x509omitbundledroots"},
			"cert_pool.go pem_decrypt.go pkcs1.go pkcs8.go root.go root_omit.go sec1.go verify.go x509.go",
		},
	}

	for _, test := range tests {
		bctx := build.Default
		bctx.GOOS, bctx.GOARCH = test.goos, test.goarch
		bctx.CgoEnabled = test.cgo
		bctx.BuildTags = test.tags

		p, err := bctx.Import("crypto/x509", "", 0)
		if err != nil {
			t.Fatal(err)
		}
		if len(p.InvalidGoFiles) != 0 {
			t.Errorf("%s: InvalidGoFiles = %q, want none", test.name, p.InvalidGoFiles)
		}
		if got, want := strings.Join(append(p.GoFiles, p.CgoFiles...), " "), test.wantGoFiles; got != want {
			t.Errorf("%s: source files = %q, want %q", test.name, got, want)
		}
	}
}

</details>

(It doesn't include all build configurations, only the ones that seem at risk because they're in x/mobile and might not get easily caught.)

bradfitz

comment created time in 10 days

issue commentgolang/go

x/pkgsite: automatically link RFCs in package documentation

In https://go-review.googlesource.com/c/pkgsite/+/239497/2#message-28fcd23ae3ef481ce5643c7439d214e06f36f313, @shaqque asked:

Currently does not support RFCxxxx (i.e. without space/s between "RFC" and the number). Should we also consider linking that?

I think we want to strike a good balance of being opinionated, so that it incentivizes people to write higher quality, consistent documentation, but not too opinionated where we are unnecessarily strict in a way that isn't helpful to humans.

The Go tree is heavily consistent at preferring including a space. There are 700 matches for [\s]RFC[\s][\d] (with space), and 55 for [\s]RFC[\d] (no space), many of which are references to time package's RFC3339 and such.

In my opinion, based on data I see now, it would be safe to start with requiring a space, but if we learn over time that it would be net positive to also accept the no-space version, we can add that later.

@FiloSottile may know if there's a spec that requires a space to be present or provides other guidance on what syntax to match precisely.

audiolion

comment created time in 10 days

issue commentgolang/go

go install of shared std fails

Thank you for testing beta 1 and reporting this.

I'm not sure if this is a problem, and if so, where the problem is, but the error is coming from the linker, so that might be involved. /cc @aclements @cherrymui

/cc @cagedmantis @toothrot

jcajka

comment created time in 10 days

issue commentgolang/go

x/build: add builder for macOS on Apple silicon

This issue corresponds to the following bullet points in https://golang.org/wiki/PortingPolicy#requirements-for-a-new-port:

  • A developer must be named (and agree) to maintain the builder, the machine trying each git revision and providing data for https://build.golang.org.

  • The builder must already be running (and failing, because the code is not yet in the main repository).

cagedmantis

comment created time in 10 days

issue commentgolang/go

runtime: tracking bug for ARM-based macOS and GOOS/GOARCH values

@jpap Thanks for the heads up. A recording of that talk is available at https://developer.apple.com/videos/play/wwdc2020/102/. The phrase I heard around the 20:34 mark is a less definitive "we've already done the initial work for some of the more widely used open-source projects", so we may need to wait to learn details.

bradfitz

comment created time in 11 days

issue commentgolang/go

runtime: tracking bug for ARM-based macOS and GOOS/GOARCH values

It is! Apple has announced it during the WWDC20 keynote. Here are more sources:

  • https://developer.apple.com/macos/
  • https://developer.apple.com/programs/universal/

The timeline they've announced is that it'll be a 2 year transition, with the first Apple Silicon Macs shipping by the end of the year and development kits this week. There will be more Intel-powered macOS devices coming out too.

I believe with this information, the plan to update release notes for Go 1.15 mentioned in https://github.com/golang/go/issues/38485#issuecomment-647584660 is still valid. All other changes can wait until the tree re-opens for 1.16 development. Feedback is welcome. I plan to send a CL for the release note entry for review this week.

bradfitz

comment created time in 11 days

issue commentgolang/go

runtime: tracking bug for ARM-based macOS and GOOS/GOARCH values

I expect we will learn relevant official information from Apple's WWDC 20 Keynote later today, and be able to use that information to make any definitive 1.15-specific decision.

However, given we are well into the code freeze for 1.15 with not much time left, and a change to build tags now would require getting a freeze exception (per bullet point 3 from the planning thread), I started investigating the plan for 1.15 @ianlancetaylor described in https://github.com/golang/go/issues/38485#issuecomment-622504803 in advance to learn more and be able to move quickly today if needed.

Based on what I've learned from the investigation (also see a draft DNS CL 239278), I suspect we will not need or want to make any code changes for 1.15, only add a note to the release notes. The rationale follows.

The motivation behind doing "add ios as a valid build tag that implies darwin" for 1.15, as I understand, is to enable people to start moving their iOS-specific code away from darwin,arm64 to something else as early as 1.15, rather than later. However, as @hyangah mentioned in https://github.com/golang/go/issues/38485#issuecomment-622526879, the gomobile tool already sets an "ios" build constraint whenever targeting iOS (see code here, here and here). That means we don't need to make changes in Go 1.15 for people to be able to start moving iOS-specific code behind a potentially more future-proof ios build constraint. They can already do that now, even with Go 1.14, 1.13, etc. (Runtime code that attempts to check runtime.GOOS to tell whether iOS is the target is a separate matter, and I'll address that in a later comment.)

Work to add a new port must be started before the code freeze, so by now we know for sure that Go 1.15 will not be able to support macOS on any new architectures beyond amd64. We can also defer any changes to the main tree until we know for certain we need to reclaim darwin,arm64 (as @rsc emphasized in his original comment).

This suggests for 1.15 it's likely sufficient to update release notes without any code changes.

I'll revisit and update this after the WWDC keynote, based on new official information that may be made available.

bradfitz

comment created time in 11 days

issue commentgolang/go

crypto/x509: build tag "ios" broken at tip on darwin/amd64

The build failure can't be reproduced on tip anymore.

It turns out it was fixed during Cthulhu's great awakening in CL 227037 (/cc @FiloSottile), sadly missing out on a chance to add another "Fixes" line:

x509 $ git co 6f52790a20a2432ae61e0ec9852a3df823a16d40^
HEAD is now at 6ea19bb668 crypto/tls: rotate session keys in older TLS versions
x509 $ go build -tags=ios                              
# crypto/x509
./cert_pool.go:65:9: undefined: loadSystemRoots
./root.go:21:32: undefined: loadSystemRoots
x509 $ git co 6f52790a20a2432ae61e0ec9852a3df823a16d40 
Previous HEAD position was 6ea19bb668 crypto/tls: rotate session keys in older TLS versions
HEAD is now at 6f52790a20 crypto/x509: use Security.framework without cgo for roots on macOS
x509 $ go build -tags=ios                             
x509 $ echo $?
0

I'll look into if the right files are selected, and maybe send a test that checks that for all relevant build configurations, so we have more confidence and this doesn't regress.

Filippo has offered to look at this issue this week, so I'm counting on him to look things over afterwards.

bradfitz

comment created time in 11 days

issue commentgolang/go

crypto/x509: build tag "ios" broken at tip on darwin/amd64

I've looked into the history and understand this better now.

The ios build tag was only used in crypto/x509, and not documented anywhere I could find. Is "like iOS but on amd64" a supported configuration?

I found some documentation for it in Go 1.5 release notes:

On Darwin, the use of the system X.509 certificate interface can be disabled with the <code>ios</code> build tag.

There's more background in CL 12301 that added it and issue #11736 that it fixed (/cc @crawshaw).

So as I understand it now, "Issue #38710 mode" (in the tables of my previous comment) is indistinguishable from "iOS mobile" mode: it just means to disable the code to fetch system rooms via API calls and use the embedded ones instead.

So, for 1.15 specifically, this shouldn't intersect with #38485, because the described behavior can be applied for both amd64 and arm64 architectures.

I see there has been a new x509omitbundledroots build tag added in CL 229762 (/cc @bradfitz) for 1.15, but it should work the same for darwin,amd64,ios and darwin,arm64,ios, so I'm not seeing a conflict.

Is crypto/x509 really the only thing that needs to support it?

@hyangah's comment in https://github.com/golang/go/issues/38485#issuecomment-622526879 also suggested that the ios tag is only used in crypto/x509 package.

bradfitz

comment created time in 11 days

push eventshurcooL/cmd

Dmitri Shuralyov

commit sha 7fad5abedd75f35b9afd37e11e7e6c1853196ccf

wasmserve: create a simple command similar to gopherjs serve It can be helpful for running a quick experiment with Go WebAssembly in the browser, without needing to set things up in advance. It supports quick iteration, because the Go command is recompiled on each page refresh. It's also possible to reload just the WebAssembly module by using the Alt+R shortcut.

view details

push time in 13 days

issue commentgopherjs/gopherjs

Output file size analyzer tool

I was pretty sure I've seen a tool or a script that does this, but after spending a few minutes searching, I couldn't find it now. Hopefully someone else can recall, find, or create one.

It's not very hard to write a script, as the minifized .js file has one line per imported package.

For non-GopherJS size analysis, I've used goweight.

nevkontakte

comment created time in 13 days

delete branch shurcooL/home

delete branch : spa

delete time in 13 days

push eventshurcooL/home

Dmitri Shuralyov

commit sha 776deced3c71ec7ca56522314b4338df7df4cd53

internal/exp/service/notification: add {Subscribe,Notify}Thread methods Also rename MarkNotificationRead method to MarkThreadRead because it operates on threads rather than individual notifications.

view details

Dmitri Shuralyov

commit sha 1554b588cd10cfbfd513fd108a3e741729981cf8

internal/exp/service/notification/fs: add filesystem-backed notification.Service implementation

view details

Dmitri Shuralyov

commit sha 6c0839ef00d7eade5823b231b3854b7d89691730

internal/code: create and expose an HTTP API

view details

Dmitri Shuralyov

commit sha ae55f492f92fb84b25b1511b797718d1611b833d

migrate to notif service v2 fs implementation for local notifications

view details

Dmitri Shuralyov

commit sha 9f6be71b0bb2abf7220932c53af1fe34852e6d05

migrate to notification service v2 API Start using the new API in as many places as viable. Don't bother updating legacy apps, keep those on v1.

view details

Dmitri Shuralyov

commit sha d894fe6afc2d6c340e6ac84ad7fb4331d555ff3e

convert notifsapp to isomorphic single-page app For https://github.com/shurcooL/home/issues/40.

view details

Dmitri Shuralyov

commit sha 4cfef6767dbdbe3618d443150759fd9d0f379629

promote /notificationsv2 app to /notifications for all users Move the /notifications v1 app to /notificationsv1 so that it's still available for me compare it with v2. It'll be removed after some time. This marks another milestone on the notification service and app v2 initiative started in https://github.com/shurcooL/home/pull/32.

view details

Dmitri Shuralyov

commit sha 2101261c5a336d8021fbc74a9f68df280255701e

internal/exp/{service,app}: add copies of github.com/shurcooL/issues{,app}/... Add internal copies of github.com/shurcooL/issues/... packages at commit https://github.com/shurcooL/issues/commit/669a77a17f95b37fcf483cbcb33ba077602274b1, and internal copies of github.com/shurcooL/issuesapp/... packages at commit https://github.com/shurcooL/issuesapp/commit/926c51c28eca69d7a945f378982997804d2d534a. They will be used for development and iteration, which is faster and more efficient when packages are internal.

view details

Dmitri Shuralyov

commit sha 60e321f2670003b721bd28b9c71134c191fb35ac

internal/exp/{service,app}: add copies of dmitri.shuralyov.com/...change... Add internal copies of dmitri.shuralyov.com/service/change/... packages at commit https://dmitri.shuralyov.com/service/change/...$commit/1161aef33b4aafec8f04c40d9863324a08f5c912, and internal copies of dmitri.shuralyov.com/app/changes/... packages at commit https://dmitri.shuralyov.com/app/changes/...$commit/e22f40b3687320a8bfbc863f27da771ed17d7b05. They will be used for development and iteration, which is faster and more efficient when packages are internal.

view details

Dmitri Shuralyov

commit sha bbab6a6590be1a3e66da7199c3feb5b1ce9678dc

internal/exp/...issue...: move ListTimeline into Service, delete List{Comments,Events} The ListTimeline method has proven to be a good idea by now. Delete old ListComments and ListEvents methods and make the ListTimeline method a non-optional part of Service interface to simplify code. Delete the issues.CopierFrom interface and its implementation in the issue/fs package, because it requires maintenance but is rarely used. It can be re-added if it's needed in the future.

view details

Dmitri Shuralyov

commit sha 1ac145823f08ab420df018571e6a56387b01ec75

internal/exp/...issue...: add Create issue API endpoint, use in app This enables deleting a POST handler for creating issues in issuesapp, simplifying the code slightly.

view details

Dmitri Shuralyov

commit sha a337e9e1cd6fad98cd0634876e0b23160295ef49

internal/exp/app/{issues,changes}app: delete internal error handler The caller can bring their own. This reduces code duplication.

view details

Dmitri Shuralyov

commit sha f86292ecb0f208ba67080f114b98338b8ad89d9e

internal/exp/service/{issue,change}/httpclient: add path parameter to client This makes it possible to serve more than one API endpoint, and have distinct clients connect to each API endpoint. It will become useful when moving to issue/change service v2 API, where the repo parameter will be replaced with a pattern parameter, and separate clients will be needed to access distinct namespaces.

view details

Dmitri Shuralyov

commit sha eb848791c3ba21c3602df5b628614691f7b950bf

internal/exp/service/{issue,change}: delete State, use state package Simplify and deduplicate code by reusing a common type in state package.

view details

Dmitri Shuralyov

commit sha ac4580039f17d0387b20a5522884b171c46b28b0

internal/exp/app/issuesapp: remove state.ForceIssuesApp field In order to make the new issuesapp simpler and easier to iterate on, support for this feature is dropped.

view details

Dmitri Shuralyov

commit sha 98a50fe9cd5de3d60822894f5bb4a81ccfb7357a

internal/exp/app/{issues,changes}app: simplify Options.BodyPre field Change it to static HTML, rather than a dynamic html/template.

view details

Dmitri Shuralyov

commit sha 6cf0388ca7b0e8136087991a5bc7e7fcb3da4748

internal/exp/app/{issues,changes}app: remove Options.DisableReactions field It's not used, simplify code by deleting it.

view details

Dmitri Shuralyov

commit sha 63f745e6efaff5609499495d5772b4f2aced86f5

internal/exp/app/{issues,changes}app: remove Options.Notifications field It needs to be updated to use notification service v2 anyway, so delete it for now to simplify code, and it can be re-added later.

view details

Dmitri Shuralyov

commit sha 6e37b35628fed400c15563934731039036191359

internal/exp/app/{issues,changes}app: remove State.DisableUsers field Simplify code for now. It can be returned later if needed.

view details

Dmitri Shuralyov

commit sha 3dfa238016cde48623974b1739683b56e178486a

internal/exp/app/changesapp: remove MockHandler Reduce amount of code for now. It can be returned later if needed.

view details

push time in 13 days

PR merged shurcooL/home

combine issuesapp, changesapp, and notifsapp into a single-page application

There's room for improvement, but this is functional, and it will work as a stopping point. More can be done later.

Fixes #40.

+18969 -1895

0 comment

132 changed files

dmitshur

pr closed time in 13 days

issue closedshurcooL/home

move web app logic to frontend, implemented as a single-page application

I want to move in the general direction of having web app logic run primarily on the frontend rather than on the backend. This means the web apps for notifications, issues, and changes (perhaps more in the future) should be implemented as a single-page application.

The motivation is to prioritize and improve:

  • the speed at which I can iterate and implement changes to said applications
  • ability to have highly interactive pages with real-time updates

At some short- and medium-term (but not long-term) cost to:

  • page load performance
  • page load resource size

(I might explain the reasons in more detail later, when I'm feeling less lazy.)

This is the tracking issue for this work.

closed time in 13 days

dmitshur

issue closedshurcooL/home

move web app logic to frontend, implemented as a single-page application

I want to move in the general direction of having web app logic run primarily on the frontend rather than on the backend. This means the web apps for notifications, issues, and changes (perhaps more in the future) should be implemented as a single-page application.

The motivation is to prioritize and improve:

  • the speed at which I can iterate and implement changes to said applications
  • ability to have highly interactive pages with real-time updates

At some short- and medium-term (but not long-term) cost to:

  • page load performance
  • page load resource size

(I might explain the reasons in more detail later, when I'm feeling less lazy.)

This is the tracking issue for this work.

closed time in 13 days

dmitshur

issue commentgolang/go

Updating system

Those paths don't look related to the $HOME/go/bin path I mentioned earlier. There may be an issue, but it's hard to know where it is.

Please take a look at the existing Go installation instructions at https://golang.org/doc/install, and the install troubleshooting wiki page at https://golang.org/wiki/InstallTroubleshooting.

If you're still having a problem, it'll be easier to get to the bottom of it by using one of the mediums listed at https://golang.org/wiki/Questions, as they're better suited for discussing these kind of questions. If you think there's something specific we should change, please open a new issue and fill in the template fully. I'll close this now.

sadesakaswl

comment created time in 15 days

issue closedgolang/go

Updating system

"Go get" command is useless.You can use old versions in linux.We want "rustup update stable" like updating system("go update version/latest")."Go get" command must be for getting libraries etc.

closed time in 15 days

sadesakaswl

issue commentgolang/go

Updating system

I reinstalled golang and bin folder changed now

What was it before? What did it change to?

sadesakaswl

comment created time in 15 days

issue commentgolang/go

Updating system

It shouldn't be necessary to change PATH after each install. The go1.14.4 binary and others like it get installed in $HOME/go/bin by default, so if you add that one location to PATH, it should work for all future Go versions.

sadesakaswl

comment created time in 15 days

issue commentgolang/go

Updating system

Hi there,

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For asking questions, see:

If you believe there is a bug, please answer the 5 questions in the issue template:

  1. What version of Go are you using (go version)?
  2. What operating system and processor architecture are you using (go env)?
  3. What did you do?
  4. What did you expect to see?
  5. What did you see instead?

Without that information, it's hard to understand where the problem is.

See CONTRIBUTING.md#filing-issues and golang.org/wiki/Questions for more information.

Thank you.

sadesakaswl

comment created time in 15 days

issue closedgolang/go

access: trybot access

Gerrit email: leitzler@gmail.com Trybot access ("may-start-trybots") https://go-review.googlesource.com/#/admin/groups/1030,members

closed time in 15 days

leitzler

issue commentgolang/go

access: trybot access

Hi Pontus,

Thank you for your contributions, and for requesting trybot access! I've added you to the may-start-trybots group, so you should be able to do so now.

As you've probably seen at https://golang.org/wiki/GerritAccess#trybot-access-may-start-trybots, please be sure to skim CLs before starting a trybot run.

Let us know if you have any questions or issues with it, and thanks again!

leitzler

comment created time in 15 days

issue openedgolang/go

all: switch to Go 1.15 as default inside Google

This is the tracking bug for switching to Go 1.15 inside Google.

When all internal release-blocking bugs & performance regressions are fixed and the default is flipped, then this can be closed.

This is a release-blocker for go1.15rc1, per our normal release policy (a precondition for public rc1 == Google's using it themselves already).

Previously #36717.

/cc @golang/osp-team

created time in 15 days

issue commentgolang/go

crypto/x509: update bundled iOS roots

please either provide instructions

I believe there are instructions in the original issue body. This might also be related to #38710, which I looked into recently. I can take a look here as well (if it's helpful).

FiloSottile

comment created time in 15 days

pull request commentshurcooL/githubv4

Add documentation for NewEnterpriseClient

@BlackVegetable Yes, thanks.

jlamb1

comment created time in 15 days

issue commentgolang/go

crypto/x509: build tag "ios" broken at tip on darwin/amd64

I have no clue about the history other than it used to work and I stumbled into a project that was depending on it.

@bradfitz Can you elaborate on how the project is depending on it? What was the expected behavior? If we can make it more clear what the mode represents and is supposed to do, it will make it easier to make progress here. I'll update the issue state to NeedsInvestigation because I don't think we know what the fix needs to be yet (as confirmed from discussion above).

While it's true this is a regression, if we take the potential plan for 1.15 described in https://github.com/golang/go/issues/38485#issuecomment-622504803 into account, we may want to deliberately make a change here anyway. This would be in scope of Go 1 compatibility promise since the mobile support is considered experimental and the ios tag was not documented. I don't know yet if we'll want or need to do that, just pointing out that issue is relevant here.

I understand the current (Go 1.14) modes of operation and the tags that are satisfied are:

Mode Satisfied Build Tags
macOS, x86 64-bit darwin, amd64, !ios
iOS mobile, ARM 64-bit darwin, arm64, !ios
Issue #38710 mode darwin, amd64, ios

We would execute the plan in https://github.com/golang/go/issues/38485#issuecomment-622504803 only if we know that darwin/arm64 needs to be reclaimed for macOS, which would be if there is an announcement of a future ARM-based macOS configuration (we may learn more from WWDC 2020 keynote in 4~ days). So the forward-looking table may look like this:

Mode Satisfied Build Tags
macOS, x86 64-bit darwin, amd64, !ios
macOS, ARM 64-bit darwin, arm64, !ios
iOS mobile, ARM 64-bit darwin, arm64, ios
Issue #38710 mode darwin, amd64, ios

At that point, it would only be possible to preserve "Issue #38710 mode" behavior of Go 1.14 on an incomplete subset of macOS configurations. If it's important for this mode to be available to all macOS users, some change will be needed.

@bradfitz From the commit message of https://github.com/tailscale/go/commit/1f0b2d1000d3b2998054cf69c6ccded48601a8a0, I understand "Issue #38710 mode" is related to the iOS simulator. Do you know if it needs to be different from normal iOS mobile (other than the architecture difference)?

bradfitz

comment created time in 16 days

issue commentgolang/go

proposal: dl/gotip: allow building branches

As a workaround, you can pick a recent commit from the dev.go2go branch and use its CL number.

What do you propose should happen if gotip download notexist is executed, where notexist is a branch that does not exist?

What should happen if gotip download go1.15beta1 is executed, where go1.15beta1 is a tag (not a branch) that exists?

/cc @FiloSottile

vearutop

comment created time in 16 days

issue openedgolang/go

misc/cgo/testcshared: sometimes stalls on windows-amd64-longtest builder in release testing mode

I've observed the following failure scenario while testing all.bash via x/build/cmd/release. The build stalled on the ##### ../misc/cgo/testcshared test and did not make progress for several hours:

[...]
PASS
scatter = 0000000000EDD070
sqrt is: 0
hello from C
ok  	misc/cgo/test	7.344s

##### ../misc/cgo/testgodefs
PASS

##### ../misc/cgo/testso
ok  	misc/cgo/testso	1.977s

##### ../misc/cgo/testsovar
ok  	misc/cgo/testsovar	2.309s

##### ../misc/cgo/testcarchive
PASS

##### ../misc/cgo/testcshared

I've observed this just twice, on the latest commit of release-branch.go1.14, and on a recent commit of master (to be 1.15), using the windows-amd64-longtest builder:

$ release -target=windows-amd64-longtest -watch -version go1.14beta2 -rev=e98cafae04b78f1e994d52ea66d228451c8e6f81
$ release -target=windows-amd64-longtest -watch -version go1.15beta2 -rev=dea6d928f6c293631ce93bd3a3bb8b4020188954

It didn't happen a second time, after I re-tried. I don't yet know how common of an occurrence this is.

This is the tracking issue to collect information and investigate.

/cc @cagedmantis @toothrot @andybons @bcmills

created time in 16 days

Pull request review commentgoogleapis/google-cloud-go

internal/gapicgen: use draft PRs for google-cloud-go

 git push -f origin $BRANCH_NAME 	}) 	return err }++// MarkPRReadyForReview switches a draft pull request to a reviewable pull+// request.+func (gc *GithubClient) MarkPRReadyForReview(ctx context.Context, repo string, number int) error {+	// Query to get the PR ID.+	var q struct {+		Repository struct {+			PullRequest struct {+				ID githubv4.ID+			} `graphql:"pullRequest(number: $prNumber)"`+		} `graphql:"repository(owner: $repositoryOwner, name: $repositoryName)"`+	}+	vars := map[string]interface{}{+		"repositoryOwner": githubv4.String("googleapis"),+		"repositoryName":  githubv4.String(repo),+		"prNumber":        githubv4.Int(number),+	}+	if err := gc.cql.Query(ctx, &q, vars); err != nil {+		return err+	}

(Although this should probably be refactored in the future so we are not using two different clients)

It's worth taking into account that it's been a number of years since GitHub API V4 has been released, and there are still some GitHub API features that are in-V3-but-not-yet-in-V4, and some that are in-V4-but-not-in-V3. As a result, it might be acceptable to maintain both clients even longer term, depending on your project's needs.

codyoss

comment created time in 16 days

Pull request review commentgoogleapis/google-cloud-go

internal/gapicgen: use draft PRs for google-cloud-go

 git push -f origin $BRANCH_NAME 	}) 	return err }++// MarkPRReadyForReview switches a draft pull request to a reviewable pull+// request.+func (gc *GithubClient) MarkPRReadyForReview(ctx context.Context, repo string, number int) error {+	// Query to get the PR ID.+	var q struct {+		Repository struct {+			PullRequest struct {+				ID githubv4.ID+			} `graphql:"pullRequest(number: $prNumber)"`+		} `graphql:"repository(owner: $repositoryOwner, name: $repositoryName)"`+	}+	vars := map[string]interface{}{+		"repositoryOwner": githubv4.String("googleapis"),+		"repositoryName":  githubv4.String(repo),+		"prNumber":        githubv4.Int(number),+	}+	if err := gc.cql.Query(ctx, &q, vars); err != nil {+		return err+	}

Oh, it would need to be a field named "node_id" in GitHub V3 response, not "id".

As I understand GitHub docs, "id" in V3 is equivalent to databaseId in v4 (which used to be deprecated, but doesn't seem to be anymore), and "node_id" in V3 is equivalent to id in V4. See https://developer.github.com/v4/guides/using-global-node-ids/ and https://developer.github.com/v4/scalar/id/.

I don't think it's worth making changes as part of this PR; I just wanted to share the observation.

codyoss

comment created time in 16 days

more