text:
can't install off head

go install github.com/gohugoio/hugo

 % go install github.com/gohugoio/hugo
# github.com/gohugoio/hugo/hugolib
../../../.src/.golang-linux/src/github.com/gohugoio/hugo/hugolib/hugo_sites.go:72: h.Deps.Log.LogCountForLevelsGreaterThanorEqualTo undefined (type *jwalterweatherman.Notepad has no field or method LogCountForLevelsGreaterThanorEqualTo)
../../../.src/.golang-linux/src/github.com/gohugoio/hugo/hugolib/hugo_sites.go:304: h.Deps.Log.ResetLogCounters undefined (type *jwalterweatherman.Notepad has no field or method ResetLogCounters)
../../../.src/.golang-linux/src/github.com/gohugoio/hugo/hugolib/hugo_sites_build.go:82: h.Deps.Log.LogCountForLevel undefined (type *jwalterweatherman.Notepad has no field or method LogCountForLevel)```

This is also happening in my travis build environment; been working for weeks.
v1.5.2
$ go version
go version go1.11.1 linux/amd64
go.env
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/travis/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/travis/gopath"
GOPROXY=""
GORACE=""
GOROOT="/home/travis/.gimme/versions/go1.11.1.linux.amd64"
GOTMPDIR=""
GOTOOLDIR="/home/travis/.gimme/versions/go1.11.1.linux.amd64/pkg/tool/linux_amd64"
GCCGO="gccgo"
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-build976235694=/tmp/go-build -gno-record-gcc-switches"
install.1
37.22s$ go get -u -d github.com/gohugoio/hugo
15.87s$ go install github.com/gohugoio/hugo
# github.com/gohugoio/hugo/hugolib
../../gohugoio/hugo/hugolib/hugo_sites.go:72:18: h.Deps.Log.LogCountForLevelsGreaterThanorEqualTo undefined (type *jwalterweatherman.Notepad has no field or method LogCountForLevelsGreaterThanorEqualTo)
../../gohugoio/hugo/hugolib/hugo_sites.go:304:7: h.Deps.Log.ResetLogCounters undefined (type *jwalterweatherman.Notepad has no field or method ResetLogCounters)
../../gohugoio/hugo/hugolib/hugo_sites_build.go:82:21: h.Deps.Log.LogCountForLevel undefined (type *jwalterweatherman.Notepad has no field or method LogCountForLevel)```

repo: gohugoio/hugo


text:
Distribution using SPM

Currently our open source library Clickstream can be installed using Cocoa pods but projects supporting Carthage and SPM would not be able to install Clickstream.
This PR aims to add distribution of Clickstream using SPM feature to it.
Add dependency using:
.package(url: "https://github.com/gojek/clickstream-ios.git", .upToNextMajor(from: "1.0.0"))
Add target dependency using:
.product(name: "Clickstream", package: "clickstream-ios")

@RishavG96 Also update the Readme.md file for steps to install Clickstream using SPM

source: gharchive/pull-request

repo: gojek/clickstream-ios

license: MIT

license_type: permissive

license_source: github-api


text:
Recents menu empty

I walked the code and the paths are read correctly from the saved json so perhaps the problem is with the menu. I assumed at first it was a stale prefs file but no that isn't it.

the menu works fine for the "local" main menu -- in this menu, you get a JIT notification step from the first menu and that is when it fills out the sub-menu with current state.  I'll see if we can somehow get that intermediate step from the mac menus.  meanwhile, use the local one, which will be what users on other platforms see.

I missed where to turn that on and I don't see it in any of the prefs

gogi prefs, main window, Params

Got it, thanks!

source: gharchive/issue

authors: rcoreilly rohrlich

repo: goki/gide


text:
Import during solve

This epic covers all the tasks necessary before we can flip the switch on importing external config "on-the-fly" during solve.

#821 - Import external configuration from dependencies during init (see PR #1277)
#1358 - Import external configuration from dependencies during ensure
#1315 - Importers should not hard fail on errors
#1316 - Importers need a more conservative mode for use during solve

As of v0.4.1 having prune set to unused-packages or non-go will remove manifest files from other tools, I've tested this with Godep.json files, I assume other tools have similar issues. Should prune be aware of the metadata files used by the Importers and prevent them from being deleted?

@allenpetersen I've split your question off into its own issue, since it's not related to this epic.
https://github.com/golang/dep/issues/1631

Any progress ?

authors: allenpetersen carllhw carolynvs

repo: golang/dep

license_source: bigquery


text:
encoding/binary: Add WriteVarint and WriteUvarint

Issue #2748 removed WriteVarint and WriteUvarint due to excessive allocations. With the introduction of io.ByteWriter, it is possible to implement these without the original performance penalty. It also makes the library more symmetrical.

Closing. See the discussion in CL/13094.

repo: golang/go


text:
SWIG generate too long path on windows

https://github.com/chai2010/hello-swig-bug

Long Path Tool can help you to remove blocked files or too long path files. You can easily fix file errors with this software.

I think https://github.com/golang/go/issues/3358 is related.

if use cgo, it is ok. the bug is only for build with x.swig.

It looks like these filenames are chosen by SWIG, not by Go. Is there anything we can do about that?

What is the file whose path is too long?
What created that file?
Is the problem that the total path is too long, or that an individual name in the path is too long?

1. swig generate the hello_with_tooooooo_long_path.go
swig -go -cgo -intgosize 64 -module hello_with_tooooooo_long_path -o "C:\Users\chai\AppData\Local\Temp\go-build509547282\github.com\chai2010\hello-swig-bug\_test\_obj_test\hello_with_tooooooo_long_path_wrap.c" -outdir "C:\Users\chai\AppData\Local\Temp\go-build509547282\github.com\chai2010\hello-swig-bug\_test\_obj_test\" hello_with_tooooooo_long_path.swig
the full path length is 135.
2. then cgo use the hello_with_tooooooo_long_path.go to generate xxx.cgo1.go
go tool cgo -objdir "C:\Users\chai\AppData\Local\Temp\go-build509547282\github.com\chai2010\hello-swig-bug\_test\_obj_test\" -importpath github.com/chai2010/hello-swig-bug  "C:\Users\chai\AppData\Local\Temp\go-build509547282\github.com\chai2010\hello-swig-bug\_test\_obj_test\hello_with_tooooooo_long_path.go"
the xxx.cgo1.go full path length large than 260 (overflow).
open C:\Users\chai\AppData\Local\Temp\go-build509547282\github.com\chai2010\hello-swig-bug\_test\_obj_test\\C___Users__chai__AppData__Local__Temp__go-build509547282__github.com__chai2010__hello-swig-bug___test___obj_test__hello_with_tooooooo_long_path.cgo1.go: The system cannot find the path specified.

Thanks.  I don't think there is any swig problem here.  The problem is cgo.  cgo is generating the file WORKDIR/WORKDIRNAME_FILE.cgo1.go where WORKDIRNAME is WORKDIR with the slashes replaced by underscores.  When WORKDIR is long, as it often is, the resulting file name is quite long.  One way to fix this is to have cmd/go pass a -srcdir option to cmd/cgo, which will cause WORKDIRNAME to contain just the file name, which is all we really need anyhow.

The root cause here is #3358, which we have yet to fix.
Why is cgo putting WORKDIRNAME into the generated file name at all?
Also, cgo has no -srcdir option (that's a local Google modification we should upstream).

cgo putting WORKDIRNAME into the generated file name predates the go tool, when apparently cgo files could live in a separate directory.  It was added in https://golang.org/cl/1734047 to fix #533.  Maybe we could just stop doing that now.

authors: Luisa456 Thomasdezeeuw chai2010 ianlancetaylor quentinmit rsc


text:
cmd/compile: fixedbug/issue10958.go failures

The fixedbug/issue10958.go test, introduced in 7f1ff65c3947b916cc4d0827fd8c1307d7efd7bf ( cmd/compile: insert scheduling checks on loop backedges), is flaky.
What version of Go are you using (go version)?
go version devel +7f1ff65 Mon Jan 9 21:01:29 2017 +0000 linux/amd64
What operating system and processor architecture are you using (go env)?
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="XXX/gocode"
GORACE=""
GOROOT="XXX/go1.7/go"
GOTOOLDIR="XXX/go1.7/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build124360425=/tmp/go-build"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?
Ran all.bash 3 times on a CentOS 6.5 server.
What did you see?
It failed reliably with:
##### ../test
# go run run.go -- fixedbugs/issue10958.go
signal: killed

It happened on the linux/mips64 builder too:
https://build.golang.org/log/3f4be6b0c792fd179683d0046a2e6f178f8928d2

Can you try upping the timeout in that test?  See https://go-review.googlesource.com/35051 for an example:
--- a/test/fixedbugs/issue10958.go
+++ b/test/fixedbugs/issue10958.go
@@ -1,5 +1,5 @@
 // +build !nacl
-// buildrun -t 2  -gcflags=-d=ssa/insert_resched_checks/on,ssa/check/on
+// buildrun -t 10  -gcflags=-d=ssa/insert_resched_checks/on,ssa/check/on

 // Copyright 2016 The Go Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style

I figure I get one try at not-flaky, if it fails, we yank the test.

Do I have to launch the test via all.bash or running go run issue10958.go is enough?
Because if I go run it I hangs forever (there's a data race in the code, is that normal?).

In test directory go run run.go -- fixedbugs/issue10958.go.
Standalone, go run -gcflags -d=ssa/insert_resched_checks/on issue10958.go
I should add a test comment explaining that it is normally expected to hang.
The data race is more or less required -- the threads have to enter their actually-but-not-obviously infinite loops, and those loops cannot contain calls.  The test is whether the compiler is properly inserting rescheduling checks into those loops, and if they have the intended effect.

I patched the file bumping to 10s and ran all.bash and it still failed (same error)

$ go run run.go -- fixedbugs/issue10958.go in test gives:

# go run run.go -- fixedbugs/issue10958.go
exit status 2
# command-line-arguments
compile: Did not find a phase matching insert_resched_checks in -d=ssa/... debug option

go run -gcflags -d=ssa/insert_resched_checks/on issue10958.go in test/fixedbugs gives

# command-line-arguments
compile: Did not find a phase matching insert_resched_checks in -d=ssa/... debug option

That message is from an "old" compiler.  There's a new phase in the one paired with that test, and the phase is present whether GOEXPERIMENT is set or not.

Yeah sorry I set a bad GOROOT while trying.
go run run.go -- fixedbugs/issue10958.go never fails (not even with 2s).
Still seeing failures with all.bash and 10s.

Too much concurrency in all.bash, perhaps?  Thanks for checking this.

Ok. I'll let you decide what to do with this issue. all.bash has always been quite slow on that machine (not sure why) so maybe it's not worth yanking the test... or maybe we could wait to see how frequent the flake is.

It's worth disabling. It's only for an experiment, and flaky tests are vile.

A few thoughts:
You should be able to reproduce it with just go run run.go from the test directory, which runs everything in there with full concurrency, but doesn't require the full all.bash. If that succeeds, then something is weird about the all.bash environment.
If you run with GOTRACEBACK=crash and send it a SIGQUIT before it times out (maybe increase the timeout to something really high), the traceback may be useful.

Thanks for the suggestion.
go run run.go fails (after a while), as expected:
$ gotip run run.go

# go run run.go -- fixedbugs/issue10958.go
signal: killed

FAIL	fixedbugs/issue10958.go	2.005s

In the meantime, another CL was merged, the builders tested it and two failed on this test:
freebsd/arm: https://build.golang.org/log/02cb9ac66d2d9a19feb6fb479917e709a50850d5
linux/mips: https://build.golang.org/log/9f3e8129e95710b42ac5528f523bfbcaf171a5f1
so yeah, it's really flaky.

With a really high timeout (I tried 600) it does not fail, so I guess the machine is just choking a little on that test. It has been disabled now so we're fine.

@ALTree can you say more about the machine? Is it a VM? Hardware? Software? How many cores? What is GOMAXPROCS? Are there other things running on the machine?
It's possible the OS descheduled a thread for 10 seconds but that seems like a long time.

Just to confirm that the timeout was correctly set to 10, I tried again (with all.bash):
##### ../test
# go run run.go -- fixedbugs/issue10958.go
signal: killed

FAIL	fixedbugs/issue10958.go	10.025s

(note 10.025s at the end).
No VM, it's real hardware. The machine is an old NeXtScale cluster (we'll dismiss it during 2017 I believe).  OS is CentOS 6.5, uname -a says
Linux nodeXXX 2.6.32-431.el6.x86_64 #1 SMP x86_64 GNU/Linux

There are many nodes, and each node has 2 x Intel Xeon E5-2670v2 2.50 GHz and 128 GB ram, but the resources that I'm requesting to the jobs manager are select=1:ncpus=8:mem=32gb (8 cores, 32 gb ram, all on the same node).
Maybe what's happening is that all.bash sees the hardware of the whole node, and it spawns many threads (20? 40?), which are then pinned to the 8 cores I requested, chocking them a little.

What is GOMAXPROCS?

Not set.

Are there other things running on the machine?

Possibly. Since I've only requested about half a node, if another user asks for just a few cores the job manager could assign the job to the same node. The 8 cores I requested are mine though (and they're guaranteed).

I think all we need to do here is increase the timeout, for Go 1.9.

I modified the test (and the rescheduling code also) in this CL, it may work better now: https://go-review.googlesource.com/c/36206/

Seen on our openbsd-amd64 builder https://build.golang.org/log/86fd5a7f6d52845eeecce77a39bb5e799ebf2b6a
Alex

The last four openbsd-386 builds all failed with this too.
I'm going to disable the test.

Moved to 1.12, the test will likely change or be obsoleted when we add signal-based preemption.

Punting to 1.13, we aren't going to do anything for this cycle.

authors: ALTree aclements alexbrainman bradfitz dr2chase randall77 rsc


text:
Should panic when trying to read or write to nil channel in goroutine

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.8.3
What operating system and processor architecture are you using (go env)?
linux xubuntu 17.04/amd64
What did you do?
I write to a uninitialized channel inside a goroutine. In stead of throwing a panic, the goroutine just exit quitely. It's hard to find bugs if Go doesn't print any message.
https://play.golang.org/p/U0zjeatykp
What did you expect to see?
write to chan
read from chan
Recovered
END

What did you see instead?
write to chan
read from chan
END

The goroutines did not exit quietly, they're both blocked and that's what the specification prescribes.

@cznic When I try to read or write to a nil channel in main function, nothing is blocked and a panic is thrown
https://play.golang.org/p/Mpdf2AgDMb
So why does it just block in gorountine? Its clear that programmer has forgotten to initialize the channel. I think it's better to throw the error right.

That's not panicking because of the nil channel send/receive itself, but because of the obvious deadlock in your code. https://golang.org/ref/spec#Channel_types specifies the behaviour of using nil channels. Quoting:

A nil channel is never ready for communication.

This is working as intended. If you have any more questions, I recommend you take them to one of the various forums instead. They may even explain why nil channels can be very useful.

@dmitris that make sense, but I still don't understand why does it panic in main function but not in goroutine? both have deadlock in it.
https://play.golang.org/p/wndl-1xLUy
The above code should behave be the same regardless of it is in a goroutine or not.

authors: cznic dominikh thanhpk


text:
cmd/go: doc doesn't show exported fields acquired by embedding non-exported types.

What version of Go are you using (go version)?
go version go1.11 linux/amd64
Does this issue reproduce with the latest release?
yes
What did you do?
package foo

type t struct {
	X int
}

type Config struct {
	t
	Y int
}

$ go doc foo.Config

What did you expect to see?
The current output is not bad, but not perfect.
The reason is the field Config.X is also exported, but it is not mentioned in the printed doc.
Users of the foo package must read code to know that the field Config.X is usable.
What did you see instead?
package foo // import "foo"

type Config struct {
	Y int
	// Has unexported fields.
}

Duplicate of https://github.com/golang/go/issues/6600.


text:
cmd/compile: panic in cmd/compile/internal/gc.typecheck1

What did you do?
Working on my project BCplus (here on github) I changed the code then 'go build'
What did you expect to see?
Generally the build completes (sometimes with errors in my code, sometimes with success;)
What did you see instead?
I see ICE:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x70 pc=0xb7bbae]
goroutine 1 [running]:
cmd/compile/internal/gc.typecheck1(0xc00048c300, 0x2, 0xa8c9bb)
/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:1270 +0x3ece
cmd/compile/internal/gc.typecheck(0xc00048c300, 0x2, 0xc000489701)
/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheck1(0xc00048c480, 0x2, 0x5002000000005)
/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:584 +0x2c8a
cmd/compile/internal/gc.typecheck(0xc00048c480, 0x2, 0x0)
/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheck1(0xc00048c280, 0x1, 0x0)
/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:2051 +0xaaf9
cmd/compile/internal/gc.typecheck(0xc00048c280, 0x1, 0xb8f17f)
/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:238 +0x6ad
cmd/compile/internal/gc.typecheckslice(0xc000058140, 0x5, 0x8, 0x1)
/usr/local/go/src/cmd/compile/internal/gc/typecheck.go:68 +0x50
cmd/compile/internal/gc.Main(0xcc0f50)
/usr/local/go/src/cmd/compile/internal/gc/main.go:518 +0x2059
main.main()
/usr/local/go/src/cmd/compile/main.go:51 +0x96
System details
go version go1.11 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/marcus/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/marcus/gows"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version go1.11 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -sr: Linux 4.9.0-8-amd64
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.5 (stretch)
Release:	9.5
Codename:	stretch
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.24-11+deb9u3) stable release version 2.24, by Roland McGrath et al.
gdb --version: GNU gdb (Debian 7.12-6) 7.12.0.20161007-git

It helps greatly if you link to the exact project or mention the exact steps to build it.
Is it this https://github.com/CmdrVasquess/BCplus ?
What are the exact steps to clone and build it ?

https://github.com/CmdrVasquess/BCplus is the project that produces the crash. Take the commit f2593416ec5faa5155d1b0de256771b9abf088cb into a clean go environment. Then 'go build' makes the compile crash – at least on my machine.

Could it be the return parameter name len that collides with the built-in function len()? See webui/tpc_missions.go line 87. With another name the thing compiles again!

Smells like #27356 and #27433. Closing here as a dup.

Just added some information as comment to the issue: Project Link, Git
commit label, go.mod
Am Donnerstag, den 20.09.2018, 01:14 -0700 schrieb Agniva De Sarker:

It helps greatly if you link to the exact project or mention the
exact steps to build it.
Is it this https://github.com/CmdrVasquess/BCplus ?
What are the exact steps to clone and build it ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c5
5493e4bb","name":"GitHub"},"entity":{"external_key":"github/golang/go
","title":"golang/go","subtitle":"GitHub
repository","main_image_url":"https://assets-cdn.github.com/images/em
ail/message_cards/header.png","avatar_image_url":"https://assets-
cdn.github.com/images/email/message_cards/avatar.png","action":{"name
":"Open in
GitHub","url":"https://github.com/golang/go"}},"updates":{"snippets":
[{"icon":"PERSON","message":"@agnivade in #27771: It helps greatly if
you link to the exact project or mention the exact steps to build
it.\r\n\r\nIs it this https://github.com/CmdrVasquess/BCplus
?\r\n\r\nWhat are the exact steps to clone and build it
?"}],"action":{"name":"View
Issue","url":"https://github.com/golang/go/issues/27771#issuecomment-
423085882"}}}
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/golang/go/issues/27771#issuecomment-423
085882",
"url": "https://github.com/golang/go/issues/27771#issuecomment-423085
882",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [golang/go] 'go build' crashes with SIGSEGV (#27771)",
"sections": [
{
"text": "",
"activityTitle": "Agniva De Sarker",
"activityImage": "https://assets-cdn.github.com/images/email/message_
cards/avatar.png",
"activitySubtitle": "@agnivade",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName":
"IssueComment",\n"repositoryFullName":
"golang/go",\n"issueId": 27771,\n"IssueComment":
"{{IssueComment.value}}"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "IssueClose",\n"repositoryFullName":
"golang/go",\n"issueId": 27771\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/golang/go/issues/27771#issuecomment-423085
882"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "MuteNotification",\n"threadId":
382089355\n}"
}
],
"themeColor": "26292E"
}
]

authors: ALTree CmdrVasquess agnivade


text:
cmd/go: confusing compiler errors because of gomod.go

When compiling the following inside a Go module project (containing go.mod in a parent directory):
package main

var string = "variable named 'string'"

func main() {}

you get the following very confusing error message:
dirbaio@jupiter:~/reby/backend/nexus$ go build weirderror/main.go
# command-line-arguments
/tmp/go-build698262353/b001/_gomod_.go:7:22: string is not a type

It seems this is because there is an autogenerated file trying to declare a variable of type string.
dirbaio@jupiter:~/reby/backend/nexus$ go build -x weirderror/main.go
WORK=/tmp/go-build835159733
mkdir -p $WORK/b001/
cat >$WORK/b001/_gomod_.go << 'EOF' # internal

		package main
		import _ "unsafe"
		//go:linkname __debug_modinfo__ runtime/debug.modinfo
		var __debug_modinfo__ string
		func init() {
			__debug_modinfo__ = "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tgithub.com/rebythecode/backend/nexus/weirderror\nmod\tgithub.com/rebythecode/backend\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
		}
	EOF
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile runtime=/usr/lib/go/pkg/linux_amd64/runtime.a
EOF
cd /home/dirbaio/reby/backend/nexus/weirderror
/usr/lib/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -complete -buildid _XG4Y2LGaLdfLVCNTPfu/_XG4Y2LGaLdfLVCNTPfu -goversion go1.11.1 -D _/home/dirbaio/reby/backend/nexus/weirderror -importcfg $WORK/b001/importcfg -pack -c=4 ./main.go $WORK/b001/_gomod_.go
# command-line-arguments
/tmp/go-build835159733/b001/_gomod_.go:7:22: string is not a type

This does not happen when trying to build in a non-modules project.
Go version and env:
dirbaio@jupiter:~$ go version
go version go1.11.1 linux/amd64
dirbaio@jupiter:~$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dirbaio/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/dirbaio/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
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-build429522809=/tmp/go-build -gno-record-gcc-switches"

/cc @rsc @bcmills @hyangah, the three people who have touched the code generation in question.
I presume there could be other ways to break it, such as declaring __debug_modinfo__, or assigning to it in one's init function. I'm not sure what a good fix here could be.

@rsc I think it's better to add the info in a way similar to link's -X flag or gc's buildid recording.

Can you still reproduce this with a go command built from source?
https://golang.org/cl/134915 should have fixed the string is not a type error. (See #27584.)

You're right @bcmills, the particular error seems like a duplicate. I wonder if we should still be worried about the __debug_modinfo__ name, although that seems extremely unlikely to cause issues.

It's theoretically a problem, but empirically much less likely than shadowing string.

I just checked. The error is not present in current master.

authors: Dirbaio bcmills hyangah mvdan


text:
cmd/go: go list fails when run in $GOPATH/pkg/mod

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

$ go version
go version go1.11.5 darwin/amd64

$ go version
go version go1.12rc1 darwin/amd64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/pdm/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/pdm/example"
GOPROXY=""
GORACE=""
GOROOT="/Users/pdm/SourceRef/go-go1.12rc1"
GOTMPDIR=""
GOTOOLDIR="/Users/pdm/SourceRef/go-go1.12rc1/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/pdm/example/pkg/mod/github.com/gocql/gocql@v0.0.0-20190208221138-c53c3654dc8a/go.mod"
CGO_CFLAGS="-I/usr/local/include"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ml/qr7r1km5315bsm79wn1q60c00000gn/T/go-build465168117=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Tried to go list a module in $GOPATH/pkg/mod.
mkdir example && cd example
export GOPATH="$PWD"
mkdir main && cd main
cat > main.go <<EOF
package main

import "github.com/gocql/gocql"

func main() {
    gocql.NewCluster("192.168.1.1", "192.168.1.2", "192.168.1.3")
}
EOF
cat > go.mod <<EOF
module main

require github.com/gocql/gocql v0.0.0-20190208221138-c53c3654dc8a
EOF
go mod download
cd "$GOPATH/pkg/mod/github.com/gocql/gocql@v0.0.0-20190208221138-c53c3654dc8a" && go list

What did you expect to see?
$ go list
github.com/gocql/gocql

What did you see instead?
In go1.11.5:
$ cd "$GOPATH/pkg/mod/github.com/gocql/gocql@v0.0.0-20190208221138-c53c3654dc8a" && go list
go: writing go.sum: open $GOPATH/pkg/mod/github.com/gocql/gocql@v0.0.0-20190208221138-c53c3654dc8a/go.sum: permission denied

In go1.12rc1:
$ cd "$GOPATH/pkg/mod/github.com/gocql/gocql@v0.0.0-20190208221138-c53c3654dc8a" && go list
go: writing go.sum: open $GOPATH/pkg/mod/github.com/gocql/gocql@v0.0.0-20190208221138-c53c3654dc8a/go.sum389063318.tmp: permission denied

Related
https://github.com/golang/go/issues/27161

Dup of #30185.

Sorry to comment.
#30185 redirect to #34054, but it seems this is by design?
gopls rely go list, so if it's by design, how can we use gopl for project in $GOPATH/pkg/mod?
LSP :: Connected to [gopls:94397 status:starting].
LSP :: go [list -f {{context.GOARCH}} {{context.Compiler}} -- unsafe]: exit status 1: error writing go.mod: open $GOPATH/pkg/mod/github.com/cep21/circuit/v3@v3.1.0/go.mod298498081.tmp: permission denied

commented in #35485

authors: bcmills ianthehat jiacai2050 pmer


text:
Why go get path@version is not working

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

$ go version
go version go1.11.5 windows/amd64

Does this issue reproduce with the latest release?
I Don't know
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\rakhil\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\rakhil\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\rakhil\AppData\Local\Temp\go-build895664346=/tmp/go-build -gno-record-gcc-switches

What did you do?

I was trying to install the branch or version of a package in GitHub.
go get github.com/ibmdb/go_ibm_db@GoPointerFix
What did you expect to see?
Download and the install the GoPointerFix version of go_ibm_db package from GitHub.
What did you see instead?
go: cannot use path@version syntax in GOPATH mode

See the paragraph on GO111MODULE in https://golang.org/cmd/go/#hdr-Preliminary_module_support.


text:
runtime: optionally (reliably) avoid netpoller

The gVisor project implements a user-space Kernel, and its implementation performance-sensitive, which forces a manual avoidance of the netpoller by avoiding certain APIs.
It would be nice to automate and enforce this avoidance, either by exposing some API that could be use to assert in a test that the netpoller has never been used, or by exposing a build tag that would guarantee that the netpoller is inactive. As of this writing it seems concretely that we want to avoid ever incrementing netpollWaiters.
cc @iangudger @nlacasse @prattmic @amscanne

This seems like the beginnings of a proposal but there’s no concrete next steps.
What changes would you like to be made specifically?
Thanks
@randall77 @ianlancetaylor

Do you want gVisor to never use the net poller full stop, or does this need to apply only to certain operations within gVisor?
The whole point of the netpoller is to be more efficient (particularly, in the # of OS threads needed) than just blocking an OS thread on each read/write. I'm curious in what circumstances netpoll needs to be avoided. Maybe we could solve that problem instead of this one.

We never want gVisor to use netpoll, full stop. One way of doing this that we have discussed is adding some way to detecting if it was ever used to the runtime and then running all of our tests and failing any which use netpoll.
golang.org/cl/78915 has more context on why netpoll is a problem.

Could you just check runtime.netpollInited? Or does that get set despite netpoll never being used?

golang.org/cl/78915 has more context on why netpoll is a problem.

That CL has been merged for a long time now. I don't see any comments there about other issues besides the one that was fixed in the CL.

Could you just check runtime.netpollInited? Or does that get set despite netpoll never being used?

Correct. runtime.netpollInited gets initialized when files are created with os.File regardless of whether netpoll is actually used.

golang.org/cl/78915 has more context on why netpoll is a problem.

That CL has been merged for a long time now. I don't see any comments there about other issues besides the one that was fixed in the CL.

The benefits documented in the CL are only if netpoll is not in use.

Correct. runtime.netpollInited gets initialized when files are created with os.File regardless of whether netpoll is actually used.

Bummer.

The benefits documented in the CL are only if netpoll is not in use.

So you want the 12% improvement to CPU usage that this CL provides? But you only get that 12% if you never use netpoll? Or are you interested in the 0.5% latency improvement?
How close is your app to those benchmarks?  They are really corner case benchmarks, with lots of very quick trips into and out of the poller/channel ops/scheduler, with no work on top of that.

It is mostly the CPU usage. gVisor is used in high-density environments. gVisor's CPU usage is much higher than Linux and we are currently looking into other options for reducing CPU usage as well.
Latency is important too though. We measure latency in nanoseconds and shaving even a few nanoseconds in a hot path can be a win for us.

How close is your app to those benchmarks? They are really corner case benchmarks, with lots of very quick trips into and out of the poller/channel ops/scheduler, with no work on top of that.

At the time golang.org/cl/78915 was written, it reduced total runtime of a Tensorflow model training benchmark running inside gVisor by 5% (and total CPU usage by 10%).
Tensorflow can be extremely futex heavy, as it coordinates very small units of work (size depends on the model) on a threadpool, where workers contend on resources. When an application calls futex inside gVisor and it actually blocks, that ultimately becomes a wait on a channel. Since new work is likely to be available very soon, this application becomes very sensitive to overall latency and CPU usage of the Go scheduler.
https://github.com/google/gvisor/issues/205 is a similar situation. In general, I think overall scheduler improvements (such as making netpoll cheaper) for these cases would be a possible alternative to an explicit API.

Ideally we'd like to prevent the netpoller from ever running, but I'd be happy just with a way to check whether the netpoller has run.
Here two proposals:

Add a new "implementation" of netpoll that just panics, and put that behind a nonetpoll build tag.

Add a boolean that is set to true whenever netpoll is called. Users that want to avoid netpoll could link against this boolean and check that it is false (likely inside tests).

Are there preferences/objections, or better alternatives to this?

From my perspective this is so special purpose that it's hard to get excited about having to maintain some publicly visible API for it.  I'm pretty skeptical that it would ever have more than one user.
We've talked about having some sort of runtime package stats access (#15490).  Perhaps we could make sure that those stats include some data on use the netpoller.  Then your tests could use that.

authors: andybons iangudger ianlancetaylor nlacasse prattmic randall77 tamird


text:
x/tools/gopls: completions overwrite text after cursor on insert

What did you do?
A constructed example:
package main

import "fmt"

type Tree struct {
	Left  *Tree
	Right *Tree
}

func (t *Tree) DoSomething() {
	fmt.Println(t)
}

func main() {
	t := &Tree{
		Left:  &Tree{},
		Right: &Tree{},
	}

	t.DoSomething()
}

I'd like to replace t.DoSomething() with t.Left.DoSomething(). I start typing Left after the . and accept the completion.
What did you expect to see?
Left gets inserted after I select the completion; everything to the right of my cursor stays.
What did you see instead?
DoSomething is deleted and replaced with Left. I have to retype DoSomething to put it back. This is a reduced example of this happening, and it gets a bit more annoying when you don't realize it was deleted and have to undo and type it all manually (especially if you don't remember what got deleted).
I don't think this behavior matches the completions of other languages, or VS Code's fallback word-level completions (which also just insert without touching anything to the right).
Build info
golang.org/x/tools/gopls v0.1.3
    golang.org/x/tools/gopls@v0.1.4-0.20190830223141-573d9926052a h1:GHSDcXHHvdapqqDYPriYzm7tvh64EQYFlmHI/MvS/yg=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20190830223141-573d9926052a h1:XAHT1kdPpnU8Hk+FPi42KZFhtNFEk4vBg1U4OmIeHTU=
    golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7 h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc=

Built on master just to keep it recent, but happens on 0.1.3 and has on previous versions as well.
Go info
go version go1.12.9 linux/amd64

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jake/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jake/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jake/testproj/overwritebug/go.mod"
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-build685890683=/tmp/go-build -gno-record-gcc-switches"

Not related, but I think it's a bit funny to have gopherbot yell at me for submitting an issue using gopls bug. :smile:

Thanks for reporting. Filed https://github.com/golang/go/issues/34042 for the GopherBot issue.

/cc @muir

There is definitely something to improve here, but I'm not sure changing it to never overwrite the postfix is the solution.
In general we can't be sure if your intent is to prepend something new or to replace entirely. In your example, you might instead want to replace t.DoSomething() with t.LeftyRighty(), in which case the current behavior of replacing the entire identifier is what you want.
It also would be a bit weird for gopls to leave an invalid identifier after performing a completion (e.g. leaving t.LeftDoSomething() per your expected behavior). Note that it currently leaves t.Left() which is also invalid.
On master, deep completions give you another option. In your example, I get a completion candidate for Left.DoSomething, which when selected results in t.Left.DoSomething().
A maybe good idea is to augment the deep completion matching to take into account the postfix. In your example t.L<>DoSomething() the prefix "L" matches "Left", but we could see the postfix "DoSomething" matches really well to "Left.DoSomething", so we present the deep candidate "Left.DoSomething" ranked above the non-deep candidate "Left". I feel like this approach is pretty flexible and could let people do something cool things once they get a feel for how it works.
One other workaround is to insert an extra "." (or space) before completing, i.e. t.L<>.DoSomething().

Personally, I don't find leaving invalid code after a completion "wrong", at least not in the course of editing. Every editor/IDE I've used has the same behavior, where a completion will insert what you asked it to, then you're left to finish it off (including Go completion, pre-gopls). Overwriting the whole token to the right is unexpected and I spend more time trying to undo things. I get that gopls itself has no idea what the intent is when a user types something, but my guess says that deleting code is usually not what the user wants to do when accepting a completion.
Deep completions are something I've never seen until gopls (and they're interesting, if not sometimes offputting; I've been using master for a while now), but I feel like using them as the solution to this problem is not entirely correct, since there are cases where there wouldn't be a match. I constructed this case to be short enough to show the overwrite, but it doesn't really represent a piece of code I've ever written.
Inserting an extra . is certainly a workaround that prevents the issue. I'll see if I can remember to make a note the next time this happens to me to show it in a non-constructed light.

At the least, it'd be nice to have an option to force gopls to use insert-only edits, just to have it match everything else my editor is doing and not trip me up all the time...

Every editor/IDE I've used has the same behavior, where a completion will insert what you asked it to

We may very well end up just going with this behavior, but I'd like see if there is a smarter approach that does what the user wants and saves time/keystrokes vs the status quo.

using [deep completions] ... is not entirely correct, since there are cases where there wouldn't be a match

Can you give an example where you don't want to overwrite but the postfix doesn't match a deep completion?

Deep completions are .. sometimes offputting

Can you elaborate on this? I'm very interested in feedback regarding deep completions.

Can you give an example where you don't want to overwrite but the postfix doesn't match a deep completion?

The most obvious case is when there's a method call in the middle. The example I gave really only works because it's a single extra thing and is a member access. I'd have to go looking for a better example, as I wrote down this bug to report (and then waited a bit too long before sending it in...)

Can you elaborate on this? I'm very interested in feedback regarding deep completions.

I'd have to sit down and code and see if I can produce any specific examples, but my main issue has been that they've almost never been what I wanted, and seemed to appear at the top in some cases.
An odd case I can come up with from playing around is when you're just starting to type the package name, and it's suggesting stuff inside the package before you've finished it at random. For example, if I start to type opentracing, I'll get a completion item for opentracing the package, but then 3 random members of opentracing that change depending on the number of characters of opentracing I've finished typing... It's weird.
Another thing is that it seems like gopls will try to pick the "best" completion item based on an expected type, so the deep completions will often show up first, even though I'm much less likely to want to access something that's a deep completion away.

The most obvious case is when there's a method call in the middle

Not sure I understand, exactly. Hopefully you come across a good example you can share.

if I start to type opentracing, I'll get a completion item for opentracing the package, but then 3 random members of opentracing that change depending on the number of characters of opentracing I've finished typing

It is true that the deep completions in that case are a bit arbitrary, but it is convenient if, for example, you are trying to call opentracing.DoSomething() you can probably just type "DoSo" or "otds" or maybe just "ds" and complete straight to what you want. If you don't know what you want, "opentracing" the package is still the first candidate, like you said. But, it sounds like the deep candidates are still distracting to some degree. We can probably do a better job filtering out low quality candidates.

gopls will try to pick the "best" completion item based on an expected type, so the deep completions will often show up first, even though I'm much less likely to want to access something that's a deep completion away.

Deep candidates will always be ranked below non-deep candidates, so if deep candidates show up first it means either there are no non-deep candidates that match the type, or your search prefix matches the deep candidates much better than the non-deep candidates. Do you have an example where a deep candidate you did not want was ranked higher than a non-deep candidate you did want?
The general goal is deep candidates never get in your way and often save a lot of typing. If you have examples where they slowed you down I'd love to see so I can improve things.

@muirrn Forgive me for not commenting on gerrit (haven't used it yet), but wouldn't that CL not fix this issue per se? It says that it only works if the prefix is empty, which to me seems like will never be the case in normal usage, as presumably one would want to type a few characters to select the right completion rather than using no prefix and arrowing through until the right selection is found. I get that it's a middle ground, but it's not exactly what I thought would happen.
Forgive me for not giving more feedback; I've been busy and haven't had any interesting thoughts about deep completion to share.

Yes, you are right of course. Let me try again later.

authors: muirrn stamblerre zikaeroh


text:
os: make os.OpenFile() 'perm' argument variadic to match POSIX open signature

What are you proposing?
The os.OpenFile interface takes perm FileMode as a required argument. Since perm is only relevant in os.O_CREATE (basing this statement off of POSIX open), it would make more sense for it to be a variadic/optional argument with a signature like the one below.
func OpenFile(name string, flag int, perm ...FileMode) (*File, error)

Why are you proposing this?
SYNOPSIS
       #include <sys/stat.h>
       #include <fcntl.h>

       int open(const char *path, int oflag, ...);
       int openat(int fd, const char *path, int oflag, ...);

The proposed change to the os.OpenFile function signature will make it resemble the POSIX function signature for the open system call.

Thanks for the suggestion.
This would break backward compatibility,so it's not something that can be done for Go1.
https://golang.org/doc/go1compat

It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification.

It may be considered for Go2, I guess.

I do not like this idea, personally. Variadic arguments in C are strictly seen as "additional arguments" and really don't have any additional meaning. This means that variadic arguments in C are used sometimes to express optional arguments, as they are with open.
In Go, variadic arguments are represented as a slice, which brings the convention that many arguments should be acceptable as a valid input. In this case, we would only want a single FileMode argument to be passed as a bitflag (if we want to keep it close to the POSIX syscall).
I think requiring the bitflag is a bit more "loyal" to the original syscall than allowing multiple FileModes to be passed.

@deanveloper doesn't the POSIX system call itself theoretically allow for multiple mode params to be passed though only the first one has any meaning?
For example, the following compiles and runs on Linux 5.3.10-arch1-1 with gcc 9.2.0 with glibc 2.30.
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
  int fd = open(
                "/tmp/test.txt",
                O_CREAT|O_WRONLY|O_TRUNC,
                S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,
                S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,
                S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,
                S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,
                S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH
           );
  if (fd != -1)
  {
    close(fd);
  }
  return 0;
}

I noticed that the interfaces for open differ when viewing man -S2 open versus man -S3 open. What I assume the Linux manual page -S2 is implying is that the two signatures listed are the only two of any meaning so any argument after mode has no meaning. However, the POSIX manual page -S3 intends to leave the arguments after oflags as variadic hence the actual interface has variadic arguments that are ignored. Feel free to correct me if my understanding is mistaken.

@ALTree I wanted to ask about the 'backward compatibility' requirement mentioned in the link you provided for Go1.

compile and run correctly, unchanged

Does unchanged include the way parameters are passed too?
If users invoke os.OpenFile like below, this change shouldn't affect previous code from compiling, but perm the user provided would be passed into a slice with the change.
os.OpenFile("notes.txt", os.O_RDWR|os.O_CREATE, 0755)

Compatibility is at the source level. Binary compatibility for
compiled packages is not guaranteed between releases. After a point
release, Go source will need to be recompiled to link against the
new release.

For the line Compatibility is at the source level., I guess its ensuring that function signatures remain the same for provided interfaces even if a change to the signature would not affect backwards compilation?
Thanks.

I noticed that the interfaces for open differ when viewing man -S2 open versus man -S3 open. What I assume the Linux manual page -S2 is implying is that the two signatures listed are the only two of any meaning so any argument after mode has no meaning. However, the POSIX manual page -S3 intends to leave the arguments after oflags as variadic hence the actual interface has variadic arguments that are ignored. Feel free to correct me if my understanding is mistaken.

You are not mistaken, that's pretty much spot on IIRC.
Note that if you supply any more than one argument for the variadic arguments, they will be ignored, and it's not really logical for them to be anything but that. This is because C does not specify a length for it's variadic arguments, just as it does with arrays. The way it can even tell that you supplied a variadic argument is if you specified the O_CREAT flag in the oflag argument. If you specified that flag, it will pull a single element from the va_list and uses that as the mode flag in the syscall.
That's getting a bit off topic though. Getting back to the proposal - I personally think it's better to leave OpenFile as-is, however I can see the justification for making it variadic

Optional arguments are form of function overloading, and Go doesn't have or want function overloading.  If we feel that this is important, then, rather than changing the signature of os.OpenFile in some future version of the os package, we would introduce a new function with a different name that only takes two arguments.  So, closing this issue.  Please comment if you disagree.

authors: ALTree Binary-Eater deanveloper ianlancetaylor


text:
net/mail: ParseDate incorrectly prunes out RFC 5322 date with a capital "T" when dealing with an obsolete timezone

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

$ go version
go version go1.14.3 linux/amd64

Does this issue reproduce with the latest release?
The version i'm using is the latest at the time of writing.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home//.cache/go-build"
GOENV="/home//.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home//go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/c/Users//Documents/projects//backend/go.mod"
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-build302313865=/tmp/go-build -gno-record-gcc-switches"

What did you do?
https://play.golang.org/p/KEedWiDqkyz
package main

import (
	"net/mail"
)

func main() {
	_, err := mail.ParseDate("Thu, 14 May 2020 11:44:40 GMT")
	if err != nil {
		panic(err)
	}

	println("ok")
}

What did you expect to see?
I expect the time string "Thu, 14 May 2020 11:44:40 GMT" to be parsed correctly without error.
What did you see instead?
mail: header could not be parsed

Research
Before posting here I did spend some time researching the problem. Here is a plaground link with the full ParseDate code extracted and isolated to be able to investigate.
I did at first regenerate all the time layouts using buildDateLayouts(), and my specific time string did match with two of the generated layouts. So that's a good start.
But looking at the ParseDate(date string) (time.Time, error) we can see that the following code seems to rewrite the date string sequence leaving only the letter T:
        else if ind := strings.Index(p.s, "T"); ind != -1 && len(p.s) >= ind+1 {
		// The last letter T of the obsolete time zone is checked when no standard time zone is found.
		// If T is misplaced, the date to parse is garbage.
		date = p.s[:ind+1]
		p.s = p.s[ind+1:]
	}

It seems that this particular time string triggers this come into thinking that the T from Thu is about an obsolete timezone. Changing the time string to "Mon, 14 May 2020 11:44:40 GMT" for example solves the problem.
I hope my report is complete, and it may help you identify the logic bug causing this problem. If can help with anything, let me know. With some explanations about the logic the problematic code section I may even be able to make a pull request :D
Thanks for your time,

Thank you for catching this interesting bug @sywesk, for the investigation, but also welcome to the Go project, it is great to receive your report!
This issue was introduced almost 2 years ago (September 2018 in Go1.12) in the bug fix for https://github.com/golang/go/issues/22661 in CL https://go-review.googlesource.com/c/go/+/117596. As you noticed, the presence of "T" anywhere in the string will choke it and return an error, so other days of the week will work except for "Tue" and "Thur". I believe a fix for this will include:
a) Invoking strings.LastIndex instead of strings.Index
b) Ensuring that the found index+1 <= len(p.s)
which will hopefully be a trivial fix and we'll also need more tests to catch the bug and prevent regressions.
Kindly paging @iWdGo @ianlancetaylor.

Hello @odeke-em ! Thank you for your kind & quick message, plus the quick CL 👍 I went through your modifications and saw you did a wonderful job correcting other problematic cases ;)

@gopherbot please consider this for backport to 1.14.
This is breaking my program when parsing email header Dates. Ironically the problematic emails are coming from Google.

@gopherbot please consider this for backport to 1.14.
This is breaking my program when parsing email header Dates. Ironically the problematic emails are coming from Google.

Thanks for requesting the backport @geniass, however in the future just let Gobot automatically open the backports directly so that it can target the last 2 releases, as we do either all or none for backports. To ensure coherence, please also request it to backport to Go1.15, explicitly like you did for Go1.14. Thank you.

Thanks for requesting the backport @geniass, however in the future just let Gobot automatically open the backports directly so that it can target the last 2 releases, as we do either all or none for backports. To ensure coherence, please also request it to backport to Go1.15, explicitly like you did for Go1.14. Thank you.

We can't currently file a second backport request on an issue via gopherbot (known bug, unless fixed recently?). The release team will add a second issue.
cc @dmitshur @toothrot

We can't currently file a second backport request on an issue via gopherbot (known bug, unless fixed recently?). The release team will add a second issue.
cc @dmitshur @toothrot

@odeke-em I do remember reading somewhere (can't find it now) that gopherbot only responds to the first backport request.
Do you mean something like please consider this for backport (without the version)? If so, do you think it's possible to modify the wiki to clarify this? (https://github.com/golang/go/wiki/MinorReleases)

@odeke-em I do remember reading somewhere (can't find it now) that gopherbot only responds to the first backport request.
Do you mean something like please consider this for backport (without the version)? If so, do you think it's possible to modify the wiki to clarify this? (https://github.com/golang/go/wiki/MinorReleases)

authors: geniass networkimprov odeke-em sywesk


text:
spec: struct can implement an interface with an inherited method but attempting to call that method can cause an unexpected panic

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

$ go version
go version go1.14.4 linux/amd64

Does this issue reproduce with the latest release?
I believe go1.14.4 is the latest stable release, so yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/finnb/.cache/go-build"
GOENV="/home/finnb/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/finnb/go:/home/finnb/git/finnbear/mazean"
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-build362984802=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Playground link: https://play.golang.org/p/Xf3mskprGZV
package main

import (
	"fmt"
)

type Nilable interface {
	IsNil() bool
}

type Child struct {

}

func (child *Child) IsNil() bool {
	return child == nil
}

type Parent struct {
	Child
}

func main() {
	var something Nilable

	var child *Child
	something = child
	fmt.Println(something.IsNil())

	var parent *Parent
	something = parent
	fmt.Println(something.IsNil()) // Panic here
}

What did you expect to see?
true
true

What did you see instead?
true
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4919f5]

goroutine 1 [running]:
main.(*Parent).IsNil(0x0, 0xc0000b6008)
	<autogenerated>:1 +0x5
main.main()
	/tmp/sandbox080043792/prog.go:36 +0xad

I suspect what is happening is that calling IsNil on parent acts on parent.Child, thus dereferencing Child from a nil pointer parent, but this happens silently. I think one of the following should be done:

Assuming my theory is correct, the panic message should be improved to not act as if the issue occurred in the (*Child) IsNil receiver but in the intermediate step of accessing parent.Child
The documentation should be updated to warn about this behavior
In the unlikely event that this is a bug in Go, it should be fixed

@griesemer @ianlancetaylor

This is intended behavior.  Dereferencing a nil pointer in order to access an embedded field panics.
But in a quick glance at the language spec I don't see that documented anywhere, so I guess we ought to have an additional sentence in the spec somewhere.
I think the panic message is as good as it is going to get.  The IsNil method is promoted to become a method of *Parent, and that is where the crash happens.  There isn't an intermediate step that could appear in the stack trace or the panic message.

I now realize my statement

the panic message should be improved to not act as if the issue occurred in the (*Child) IsNil receiver

was wrong, since the panic actually states the location was in main.(*Parent).IsNil
An additional line in the spec/doc would be nice though.

Parent doesn't implement Nilable, *Parent does.
related: https://github.com/golang/go/issues/32021 https://github.com/golang/go/issues/32035

Parent doesn't implement Nilable, *Parent does.

I misspoke, my question was directed at why *Parent can implement Nilable. I have to do more research into whether *Parent has an internal Child, *Child, or something else...

I believe this is exactly the case described in #18617.
(Note that that issue is a proposal for a backward-incompatible change to the language.)

@finnbear
By the current rules,

type struct{T} gets all the methods of type T,
type *struct{T}, type struct{*T}, and type *struct{*T} get all the methods of type *T (as the method set of *T is always of T, so the three types also get all the methods of T)

authors: andybons bcmills dotaheor finnbear ianlancetaylor


text:
x/tools/gopls: code action for extracting into interface

Consider the following program:
type bar struct {}
func (b *bar) x() {}
func (b *bar) y() {}
type Foo struct {
    bar *bar
}
func (f *Foo) baz() {
    f.b.y()
}

Now assume we would like to test foo and for this we'd want to mock bar. The recommended way of doing this is to extract the way that bar is used into an interface and use that in lieu of bar in foo.
type bar struct {}
func (b *bar) x() {}
func (b *bar) y() {}

type barI interface {
    y()
}
type Foo struct {
    bar barI
}
func (f *Foo) baz() {
    f.b.y()
}

Note that only y() was extracted.
Supporting such a code action in gopls would make life a lot easier for devs who write unit tests.
This is at least viable to implement for unexported members, as no new methods can be added in other packages which access this member.

Thanks for the feature request. I agree that this could be a useful refactoring operation, and is certainly doable.  It's also useful for more than just testing.

authors: findleyr js-sketch


text:
x/arch/x86/x86asm: add AVX-256 and AVX-512 registers and instructions

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

$ go version
go version go1.15.8 windows/amd64

Does this issue reproduce with the latest release?
Didn't try. Documentation says no.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\me\AppData\Local\go-build
set GOENV=C:\Users\me\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\me\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\me\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=off
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\me\AppData\Local\Temp\go-build560694702=/tmp/go-build -gno-record-gcc-switches

What did you do?

package main

import (
	"golang.org/x/arch/x86/x86asm"
	"log"
)

func main() {
	bs := []byte{
		0x62, 0xf1, 0x7c, 0x48, 0x10, 0xc1,
		0x62, 0x71, 0x7c, 0x48, 0x10, 0x46, 0x07 }

	off := 0
	for off < len(bs) {
		inst, err := x86asm.Decode(bs[off:], 64)
		if err != nil {
			log.Fatal(err)
		}
		log.Println(inst)
		off += inst.Len
	}
}

What did you expect to see?
vmovups zmm0,zmm1 or something
What did you see instead?
unrecognized instruction

cc @cherrymui

package main

import (
	"golang.org/x/arch/x86/x86asm"
	"log"
)

func main() {
	bs := []byte{
		0xc5, 0xf9, 0xef, 0xc0}

	off := 0
	for off < len(bs) {
		inst, err := x86asm.Decode(bs[off:], 64)
		if err != nil {
			log.Fatal(err)
		}

		log.Println(inst)
		off += inst.Len
	}
}

2021/07/22 14:40:40 Prefix(0xc5) Prefix(0xf9) OUT DX, EAX
2021/07/22 14:40:40 Prefix(0xc0) Op(0)

Should be a vpxor.

authors: TACIXAT seankhliao


text:
cmd/go: confusing error for non-existent go source files

% go build notexist.go
cannot find package "." in:
	/Users/rsc/go/src/notexist.go
%

For what it's worth, I'm not in /Users/rsc/go/src.
That's just the error looking for a std package named notexist.go.
It should show me an error more like 'no such file notexist.go'.
/cc @bcmills @jayconrod @matloob

@bcmills This is in the 1.18 milestone; time to move to 1.19?  Thanks.
(The current error isn't great since it treats nonexist.go as the name of a package.  That is technically correct but maybe if it doesn't exist we can treat a trailing ".go" as a special case and give a different error message.)

Whoops, sorry, didn't mean to close this.

This was improved somewhat by the fix for #48907, but it's still not ideal.

This also turns out to be another in the cluster of go list -e error-reporting bugs. There are a number of ]base.Fatalf calls in load.GoFilesPackage](https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/load/pkg.go;l=2900-2935;drc=c016133c50512e9a83e7442bd7ac614fe7ca62de) that could just as easily be returned as errors.

authors: bcmills ianlancetaylor rsc


text:
access: may-start-trybots

Hi, I'd like to request access for the may-start-trybots privilege, so I can request trybots on the viewcore (x/debug) repo.
Thanks!
Here is the group URL: https://go-review.googlesource.com/#/admin/groups/1030,members
My Gerrit email address is jordanthelewis@gmail.com.

cc @golang/release

@jordanlewis: since the trybots are relatively sensitive infrastructure, we try to keep the set of people who can trigger them low. We're happy to expand the set to include frequent contributors for whom it'll be a big time-saver, but so far it looks like you've only sent a CL or two. For a low volume of changes, we hope that relying on your reviewers to trigger trybots should be acceptable.
I'm going to close this issue. Feel free to reapply if you find that not being able to trigger trybots is a major impediment to your work.

authors: heschi jordanlewis mvdan


text:
net: TestDialParallel failures due to longer-than-expected delay on Windows

--- FAIL: TestDialParallel (6.16s)
    dial_test.go:173: dialClosedPort: measured delay 1.0028044s
    dial_test.go:313: #5: got 1.2757236s; want <= 1.20336528s
FAIL
FAIL	net	55.514s

greplogs --dashboard -md -l -e 'FAIL: TestDialParallel .*(?:\n    .*)*got .*; want <= .*'
2022-04-05T18:01:26-9e16cc1/windows-amd64-longtest
Note that the test currently uses a hard-coded heuristic for the timing bounds:
https://cs.opensource.google/go/go/+/master:src/net/dial_test.go;l=302-309;drc=da7891f6f36c48f2931ed916ed305330c06f9bd7
(See previously #35616; CC @ianlancetaylor @neild.)

Since windows/amd64 is a first-class port, this is a release-blocker for Go 1.19.
(It may be possible to resolve by making the timing bounds even more lax, or by somehow eliminating the timing bounds entirely if the test is meaningful without them.)

FWIW, I've been attempting to reproduce a different Windows issue, but have managed to reproduce this twice thus far in ~1hr of testing with 25 windows-amd64-longtest gomotes using https://github.com/mknyszek/goswarm/.

@prattmic is this OK after beta 1?

@neild will know better, but I imagine so, it is quite rare now.

Yes, this is okay after beta1.
The test is irredeemably flaky. I think it needs to be rewritten.

authors: bcmills heschi neild prattmic


text:
x/review/git-codereview: mail requires -trust=false

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

$ go version
go version go1.19.2 linux/amd64

Does this issue reproduce with the latest release?
Yes, I ran go install golang.org/x/review/git-codereview@latest
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/johan/.cache/go-build"
GOENV="/home/johan/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/johan/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/johan/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/nix/store/8s8mxpa681mbddak431k8nxg1ib5pw0g-go-1.19.2/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/nix/store/8s8mxpa681mbddak431k8nxg1ib5pw0g-go-1.19.2/share/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.2"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1025149787=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I was following the contribution guide (https://go.dev/doc/contribute), and after running git mail to submit a change I got an unexpected error.
What did you expect to see?
I expected for git mail to create a CL with my changes.
What did you see instead?
$ git mail
remote: Processing changes: refs: 1, done
To https://go.googlesource.com/go
 ! [remote rejected]       HEAD -> refs/for/master%l=Trust (label "Trust" is not a configured label)
error: failed to push some refs to 'https://go.googlesource.com/go'
(running: git push -q origin HEAD:refs/for/master%l=Trust)
git-codereview: exit status 1

Running git mail -trust=false fixes the issue, but I don't understand why this is required. Nothing in the contribution guide mentions this flag.

-trust is not used anymore: https://github.com/golang/review/commit/f2105c4cf825fe09ece01c9d554f6c0a5bc06a03
Sounds like you want @master instead of @latest.

Given that the majority of people will default to using "latest", perhaps we can aim to regularly tag x/review. Especially when breaking changes like these are made. cc @golang/release

On second thought, the latest commit is already tagged. So I guess we already do this. I'm confused.

The -trust flag is obsolete and was removed in CL 399117, which is included in v1.1.0. Maybe the git-codereview binary you installed with go install golang.org/x/review/git-codereview@latest isn't in your PATH? What's the output go version -m $(which git-codereview)?

The -trust flag is obsolete and was removed in CL 399117, which is included in v1.1.0. Maybe the git-codereview binary you installed with go install golang.org/x/review/git-codereview@latest isn't in your PATH? What's the output go version -m $(which git-codereview)?

Oops, this does seem to be what happened here, thanks for the tip! False alarm 😄.

authors: cuonglm dmitshur johanbrandhorst mvdan


text:
net/http: on panic http.server re-runs the handler multiple times on Windows

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

$ go version
go version go1.19.4 windows/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Aljosja\AppData\Local\go-build
set GOENV=C:\Users\Aljosja\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Aljosja\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Aljosja\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19.4
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\Aljosja\documents\code\u4tools\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\Aljosja\AppData\Local\Temp\go-build1729482487=/tmp/go-build -gno-record-gcc-switches

What did you do?
In a simple HTTP server with a handler that panics (either through calling panic() or by dereferencing a nil pointer) on Windows, the server runs the handler again multiple times for the same request. On Linux, the handler runs only once.
package main

import (
	"fmt"
	"net/http"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/panic", func(w http.ResponseWriter, r *http.Request) {
		fmt.Println("hello world!")
		panic("damn")
	})
	mux.HandleFunc("/npe", func(w http.ResponseWriter, r *http.Request) {
		fmt.Println("hello world!")
		var err error
		fmt.Println("Error: %s", err.Error())
	})
	mux.HandleFunc("/success", func(w http.ResponseWriter, r *http.Request) {
		fmt.Println("hello world!")
	})

	http.ListenAndServe(":8080", mux)
}

What did you expect to see?
I expect the console log to show one stack trace indicating a panic, and the HTTP connection to close. (This is the behaviour on Linux.)
What did you see instead?
The HTTP connection remains open, and the console log shows several stack traces.
Example log file. This log file is for a single request.
$  go run cmd/main.go
hello world!
2023/01/04 21:31:18 http: panic serving [::1]:54121: runtime error: invalid memory address or nil pointer dereference
goroutine 6 [running]:
net/http.(*conn).serve.func1()
        C:/Program Files/Go/src/net/http/server.go:1850 +0xbf
panic({0x718c00, 0x923ae0})
        C:/Program Files/Go/src/runtime/panic.go:890 +0x262
main.main.func2({0x3b?, 0xffffffffffffffff?}, 0x58eada?)
        C:/Users/Aljosja/documents/code/u4tools/cmd/main.go:17 +0x58
net/http.HandlerFunc.ServeHTTP(0xc00006faf0?, {0x7c8348?, 0xc0001a8000?}, 0x0?)
        C:/Program Files/Go/src/net/http/server.go:2109 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0x7c8348, 0xc0001a8000}, 0xc000142000)
        C:/Program Files/Go/src/net/http/server.go:2487 +0x149
net/http.serverHandler.ServeHTTP({0xc0001011a0?}, {0x7c8348, 0xc0001a8000}, 0xc000142000)
        C:/Program Files/Go/src/net/http/server.go:2947 +0x30c
net/http.(*conn).serve(0xc000000be0, {0x7c8720, 0xc0001010b0})
        C:/Program Files/Go/src/net/http/server.go:1991 +0x607
created by net/http.(*Server).Serve
        C:/Program Files/Go/src/net/http/server.go:3102 +0x4db
hello world!
2023/01/04 21:31:19 http: panic serving [::1]:54122: runtime error: invalid memory address or nil pointer dereference
goroutine 34 [running]:
net/http.(*conn).serve.func1()
        C:/Program Files/Go/src/net/http/server.go:1850 +0xbf
panic({0x718c00, 0x923ae0})
        C:/Program Files/Go/src/runtime/panic.go:890 +0x262
main.main.func2({0x3b?, 0xffffffffffffffff?}, 0x58eada?)
        C:/Users/Aljosja/documents/code/u4tools/cmd/main.go:17 +0x58
net/http.HandlerFunc.ServeHTTP(0xc000097af0?, {0x7c8348?, 0xc000148000?}, 0x0?)
        C:/Program Files/Go/src/net/http/server.go:2109 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0x7c8348, 0xc000148000}, 0xc0000a8000)
        C:/Program Files/Go/src/net/http/server.go:2487 +0x149
net/http.serverHandler.ServeHTTP({0xc00008a090?}, {0x7c8348, 0xc000148000}, 0xc0000a8000)
        C:/Program Files/Go/src/net/http/server.go:2947 +0x30c
net/http.(*conn).serve(0xc00008e000, {0x7c8720, 0xc0001010b0})
        C:/Program Files/Go/src/net/http/server.go:1991 +0x607
created by net/http.(*Server).Serve
        C:/Program Files/Go/src/net/http/server.go:3102 +0x4db
hello world!
2023/01/04 21:31:19 http: panic serving [::1]:54124: runtime error: invalid memory address or nil pointer dereference
goroutine 35 [running]:
net/http.(*conn).serve.func1()
        C:/Program Files/Go/src/net/http/server.go:1850 +0xbf
panic({0x718c00, 0x923ae0})
        C:/Program Files/Go/src/runtime/panic.go:890 +0x262
main.main.func2({0x3b?, 0xffffffffffffffff?}, 0x58eada?)
        C:/Users/Aljosja/documents/code/u4tools/cmd/main.go:17 +0x58
net/http.HandlerFunc.ServeHTTP(0xc000099af0?, {0x7c8348?, 0xc0001480e0?}, 0x0?)
        C:/Program Files/Go/src/net/http/server.go:2109 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0x7c8348, 0xc0001480e0}, 0xc0000a8100)
        C:/Program Files/Go/src/net/http/server.go:2487 +0x149
net/http.serverHandler.ServeHTTP({0xc00008a180?}, {0x7c8348, 0xc0001480e0}, 0xc0000a8100)
        C:/Program Files/Go/src/net/http/server.go:2947 +0x30c
net/http.(*conn).serve(0xc00008e0a0, {0x7c8720, 0xc0001010b0})
        C:/Program Files/Go/src/net/http/server.go:1991 +0x607
created by net/http.(*Server).Serve
        C:/Program Files/Go/src/net/http/server.go:3102 +0x4db
hello world!
2023/01/04 21:31:19 http: panic serving [::1]:54125: runtime error: invalid memory address or nil pointer dereference
goroutine 9 [running]:
net/http.(*conn).serve.func1()
        C:/Program Files/Go/src/net/http/server.go:1850 +0xbf
panic({0x718c00, 0x923ae0})
        C:/Program Files/Go/src/runtime/panic.go:890 +0x262
main.main.func2({0x3b?, 0xffffffffffffffff?}, 0x58eada?)
        C:/Users/Aljosja/documents/code/u4tools/cmd/main.go:17 +0x58
net/http.HandlerFunc.ServeHTTP(0xc00005baf0?, {0x7c8348?, 0xc0001a80e0?}, 0x0?)
        C:/Program Files/Go/src/net/http/server.go:2109 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0x7c8348, 0xc0001a80e0}, 0xc0000a8200)
        C:/Program Files/Go/src/net/http/server.go:2487 +0x149
net/http.serverHandler.ServeHTTP({0xc00008a210?}, {0x7c8348, 0xc0001a80e0}, 0xc0000a8200)
        C:/Program Files/Go/src/net/http/server.go:2947 +0x30c
net/http.(*conn).serve(0xc000000c80, {0x7c8720, 0xc0001010b0})
        C:/Program Files/Go/src/net/http/server.go:1991 +0x607
created by net/http.(*Server).Serve
        C:/Program Files/Go/src/net/http/server.go:3102 +0x4db
hello world!
2023/01/04 21:31:24 http: panic serving [::1]:54134: runtime error: invalid memory address or nil pointer dereference
goroutine 20 [running]:
net/http.(*conn).serve.func1()
        C:/Program Files/Go/src/net/http/server.go:1850 +0xbf
panic({0x718c00, 0x923ae0})
        C:/Program Files/Go/src/runtime/panic.go:890 +0x262
main.main.func2({0x3b?, 0xffffffffffffffff?}, 0x58eada?)
        C:/Users/Aljosja/documents/code/u4tools/cmd/main.go:17 +0x58
net/http.HandlerFunc.ServeHTTP(0xc00005baf0?, {0x7c8348?, 0xc0001a81c0?}, 0x0?)
        C:/Program Files/Go/src/net/http/server.go:2109 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0x7c8348, 0xc0001a81c0}, 0xc000184300)
        C:/Program Files/Go/src/net/http/server.go:2487 +0x149
net/http.serverHandler.ServeHTTP({0xc000186210?}, {0x7c8348, 0xc0001a81c0}, 0xc000184300)
        C:/Program Files/Go/src/net/http/server.go:2947 +0x30c
net/http.(*conn).serve(0xc000218000, {0x7c8720, 0xc0001010b0})
        C:/Program Files/Go/src/net/http/server.go:1991 +0x607
created by net/http.(*Server).Serve
        C:/Program Files/Go/src/net/http/server.go:3102 +0x4db
hello world!
2023/01/04 21:31:54 http: panic serving [::1]:54135: runtime error: invalid memory address or nil pointer dereference
goroutine 36 [running]:
net/http.(*conn).serve.func1()
        C:/Program Files/Go/src/net/http/server.go:1850 +0xbf
panic({0x718c00, 0x923ae0})
        C:/Program Files/Go/src/runtime/panic.go:890 +0x262
main.main.func2({0x3b?, 0xffffffffffffffff?}, 0x58eada?)
        C:/Users/Aljosja/documents/code/u4tools/cmd/main.go:17 +0x58
net/http.HandlerFunc.ServeHTTP(0xc000093af0?, {0x7c8348?, 0xc0001a82a0?}, 0x0?)
        C:/Program Files/Go/src/net/http/server.go:2109 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0x7c8348, 0xc0001a82a0}, 0xc0000a8300)
        C:/Program Files/Go/src/net/http/server.go:2487 +0x149
net/http.serverHandler.ServeHTTP({0xc00008a2d0?}, {0x7c8348, 0xc0001a82a0}, 0xc0000a8300)
        C:/Program Files/Go/src/net/http/server.go:2947 +0x30c
net/http.(*conn).serve(0xc00008e140, {0x7c8720, 0xc0001010b0})
        C:/Program Files/Go/src/net/http/server.go:1991 +0x607
created by net/http.(*Server).Serve
        C:/Program Files/Go/src/net/http/server.go:3102 +0x4db
hello world!
2023/01/04 21:31:54 http: panic serving [::1]:54183: runtime error: invalid memory address or nil pointer dereference
goroutine 23 [running]:
net/http.(*conn).serve.func1()
        C:/Program Files/Go/src/net/http/server.go:1850 +0xbf
panic({0x718c00, 0x923ae0})
        C:/Program Files/Go/src/runtime/panic.go:890 +0x262
main.main.func2({0x3b?, 0xffffffffffffffff?}, 0x58eada?)
        C:/Users/Aljosja/documents/code/u4tools/cmd/main.go:17 +0x58
net/http.HandlerFunc.ServeHTTP(0xc000057af0?, {0x7c8348?, 0xc0001481c0?}, 0x0?)
        C:/Program Files/Go/src/net/http/server.go:2109 +0x2f
net/http.(*ServeMux).ServeHTTP(0x0?, {0x7c8348, 0xc0001481c0}, 0xc000184600)
        C:/Program Files/Go/src/net/http/server.go:2487 +0x149
net/http.serverHandler.ServeHTTP({0xc0001863f0?}, {0x7c8348, 0xc0001481c0}, 0xc000184600)
        C:/Program Files/Go/src/net/http/server.go:2947 +0x30c
net/http.(*conn).serve(0xc0002180a0, {0x7c8720, 0xc0001010b0})
        C:/Program Files/Go/src/net/http/server.go:1991 +0x607
created by net/http.(*Server).Serve
        C:/Program Files/Go/src/net/http/server.go:3102 +0x4db
exit status 0xc000013a

Thanks for looking with me and very sharp observation about the different port numbers, I hadn't noticed that yet. The requests from the example log were made through Chrome, Firefox and Edge. I now tried a curl through Windows PowerShell which resulted in 2 retries, a curl from Git Bash gave the expected 1. Interestingly enough the devtools in the browsers don't seem to show they're making new requests, but apparently they are doing that silently (as is PowerShell doing once).

The Chromium family browsers automatically retry requests on certain errors (see bug 143425), and ERR_EMPTY_RESPONSE (which happens when a handler panics) is among those.

authors: antichris groenspans


text:
net/http: http.response not flushing body after writing 1XX headers when client has header Expect: 100-continue

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

$ go version
go version go1.19.4 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
Not relevant

What did you do?

func runServer() {
	panic(http.ListenAndServe(":80", http.HandlerFunc(func(writer http.ResponseWriter, request *http.Request) {
		_, _ = io.Copy(io.Discard, request.Body)
		writer.WriteHeader(100)
		writer.WriteHeader(201)
		_, _ = io.WriteString(writer, "CREATED")
	})))
}

func Test100Http(t *testing.T) {
	go runServer()
	time.Sleep(time.Second)
	conn, _ := net.Dial("tcp", "127.0.0.1:80")
	file, _ := os.Open("/tmp/go1.20rc2.src.tar.gz")
	req, _ := http.NewRequest(http.MethodPut, "http://127.0.0.1/go.tar.gz", file)
	req.Header.Set("Expect", "100-continue")
	_ = req.Write(conn)
	_, _ = io.Copy(os.Stdout, conn)
}

What did you expect to see?
output
HTTP/1.1 100 Continue

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Date: Mon, 09 Jan 2023 09:00:36 GMT
Content-Length: 7
Content-Type: text/plain; charset=utf-8

CREATED

What did you see instead?
The program hangs with the following output
HTTP/1.1 100 Continue

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Date: Mon, 09 Jan 2023 09:00:36 GMT
Content-Length: 7
Content-Type: text/plain; charset=utf-8

notice response body is not written CREATED
Additional Info
This problem was first discovered when a caddy user find his webdav server not longer works when he upgraded caddy version. Caddy is using a heavily modified reverse_proxy handler from stdlib and merged 1xx status codes which was backported from 53164.
After some digging in caddy, I determined it's a problem with golang http. The handler is a reduced version of caddy reverse_proxy which forwards 1XX from backend. And the example file is small 25MB, using large files like 134MB will produce the correct output.

(attn @neild)
Compare:

#45834 (HTTP/2 instead of 1.1)

Still the same problem with go 1.19.7 (and using Caddy 2.6.4)

authors: WeidiDeng bcmills helmut72


text:
cmd/dist: loadinternal: cannot find runtime/cgo during bootstrapping on ios

https://build.golang.org/log/baada2af5f73ef484b066c8c6495db12b3ee442d:

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
warning: unable to find runtime/cgo.a
Building Go toolchain2 using go_bootstrap and Go toolchain1.
# cmd/asm
loadinternal: cannot find runtime/cgo
# cmd/cgo
loadinternal: cannot find runtime/cgo
# cmd/link
loadinternal: cannot find runtime/cgo
# cmd/compile
loadinternal: cannot find runtime/cgo
Building Go toolchain3 using go_bootstrap and Go toolchain2.
# cmd/asm
loadinternal: cannot find runtime/cgo
# cmd/cgo
loadinternal: cannot find runtime/cgo
# cmd/link
loadinternal: cannot find runtime/cgo
# cmd/compile
loadinternal: cannot find runtime/cgo
Building packages and commands for ios/arm64.
# cmd/asm
loadinternal: cannot find runtime/cgo
# cmd/buildid
loadinternal: cannot find runtime/cgo
# cmd/cgo
loadinternal: cannot find runtime/cgo
# cmd/addr2line
loadinternal: cannot find runtime/cgo
# cmd/compile
loadinternal: cannot find runtime/cgo
# cmd/covdata
loadinternal: cannot find runtime/cgo
# cmd/cover
loadinternal: cannot find runtime/cgo
# cmd/doc
loadinternal: cannot find runtime/cgo
# cmd/dist
loadinternal: cannot find runtime/cgo
# cmd/fix
loadinternal: cannot find runtime/cgo
# cmd/gofmt
loadinternal: cannot find runtime/cgo
# cmd/link
loadinternal: cannot find runtime/cgo
# cmd/nm
loadinternal: cannot find runtime/cgo
# cmd/objdump
loadinternal: cannot find runtime/cgo
# cmd/pack
loadinternal: cannot find runtime/cgo
# cmd/go
loadinternal: cannot find runtime/cgo
# cmd/test2json
loadinternal: cannot find runtime/cgo
# cmd/pprof
loadinternal: cannot find runtime/cgo
# cmd/trace
loadinternal: cannot find runtime/cgo
# cmd/vet
loadinternal: cannot find runtime/cgo
---
Installed Go for ios/arm64 in /tmp/workdir-host-ios-arm64-corellium-ios/go
Installed commands in /tmp/workdir-host-ios-arm64-corellium-ios/go/bin
Test "go_test:archive/tar" ran over 20m0s limit (20m0.000436379s); saw output:

It looks like the loadinternal call is happening here:
https://cs.opensource.google/go/go/+/master:src/cmd/link/internal/ld/lib.go;l=576-592;drc=ba913774543d7388b7bb1843fc7c1b935aebedda
It isn't clear to me whether this message is actually indicating a problem, or just noisy. If it does not indicate a real problem, it should be adjusted to avoid logging to stderr.

This appears to have started at or around CL 454836, which changed cmd/dist to always build cmd without cgo enabled.
(attn @golang/compiler @golang/ios)

Duplicate of #31544

@cherrymui points out that this is related to #31544. It's not obvious to me whether this failure mode (on ios) is the same as the typestate bug described in https://github.com/golang/go/issues/31544#issuecomment-490607180, or a separate bug (perhaps in cmd/link).

To be clear, the loadinternal: cannot find runtime/cgo is printed by the linker, but it is not an error. It does't make the linking process fail, and the result binaries often runs fine. ("often" doesn't mean nondeterministic. I say it because it is a not well tested and well supported configuration.)
The last "ok" on the iOS builder https://build.golang.org/log/4c18d54f1d9bc8e08844d19e57b7873640c2729e also has the message for go_bootstrap (not other binaries), and it worked fine. (I'm pretty sure this was the case for quite some time, at least a couple of years.)

It isn't clear to me whether the ios build with CGO_ENABLED=0 really requires the runtime/cgo package or not.

Currently ios build requires external linking. I'm not sure we explicitly say external linking requires the runtime/cgo package. But as the C linker will likely pull in C stuff to the binary, it is pretty much a C/Go mixed binary, linking in runtime/cgo seems reasonable. If I understand correctly cmd/go tries to add runtime/cgo dependency when external linking, but sometimes doesn't? (I think that is #31544.)
It might be possible to make ios internal linking work. But I'm not sure it's worth it, as users for iOS build use external linking, as the Go code would be linked with C/objective-C/swift/etc. for there iOS app.
Or, maybe we could make sure external linking work without runtime/cgo, document it and test it. This would also fix #31544. Not sure how hard that would be (on all platforms). Also not sure it's worth it, as most users don't do this?

I'm not sure this is a linker bug. Unless we decide to implement internal linking on iOS.

This also occurs on the android-.*-emu builders today — we just happened not to notice because the rest of the build and test cycle somehow succeeds anyway:
https://build.golang.org/log/1575c55e51b0fcee52b35365d413fbeb94eee305
To me, that reinforces that the log message is not appropriate — it adds a huge amount of noise that can bury the real errors (such as in https://storage.googleapis.com/go-build-log/b968f088/android-amd64-emu_65dfd1a1.log).

Or, I guess, to put it a different way: if runtime/cgo is actually needed, the linker should emit a hard error (and exit with a nonzero status), not a warning.

If we want to emit an error, I'd hope

decide explicitly external linking requires cgo, and document it somewhere
fix #31544

Otherwise go build -ldflags=-linkmode=external works today on some platforms but will be broken if we emit an error.

authors: bcmills cherrymui


text:
cmd/compile, go/types: the "have" section with variadic argument show slice and not variadic in "not-enough/too-many values" compiler error message

Go version
go version devel go1.24-851ebc2dca Tue Oct 29 08:17:00 2024 +0000 linux/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOAUTH='netrc'
GOBIN='/home/emmanuel/go/src/go.googlesource.com/go/bin'
GOCACHE='/home/emmanuel/.cache/go-build'
GOENV='/home/emmanuel/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/emmanuel/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/emmanuel/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/emmanuel/go/src/go.googlesource.com/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/emmanuel/go/src/go.googlesource.com/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.24-851ebc2dca Tue Oct 29 08:17:00 2024 +0000'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/emmanuel/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/emmanuel/go/src/github.com/googleapis/google-cloud-go/spanner/go.mod'
GOWORK='/home/emmanuel/go/src/github.com/googleapis/google-cloud-go/go.work'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2861148706=/tmp/go-build -gno-record-gcc-switches'

What did you do?
https://go.dev/play/p/OwK-zDVUefq
package main

import "context"

func main() {
	values := []int{10, 12, 20}
	vari(context.Background(), values...)
	vari(context.Background(), "ab", "cd", values...)
}

func vari(ctx context.Context, method string, values ...int) {
	_ = values
}

What did you see happen?
./prog.go:7:29: not enough arguments in call to vari
	have (context.Context, []int)
	want (context.Context, string, ...int)
./prog.go:8:41: too many arguments in call to vari
	have (context.Context, string, string, []int)
	want (context.Context, string, ...int)

What did you expect to see?
./prog.go:7:29: not enough arguments in call to vari
	have (context.Context, ...int)
	want (context.Context, string, ...int)
./prog.go:8:41: too many arguments in call to vari
	have (context.Context, string, string, ...int)
	want (context.Context, string, ...int)

Kindly cc-ing @griesemer @findleyr

Related Issues and Documentation

cmd/compile: ICE when unpacking arguments of variadic generic function #51925 (closed)
cmd/compile: internal error with variadic calls with a wrong number of arguments #46957 (closed)
cmd/compile: make error message involving variadic calls clearer
cmd/compile: align formal parameters with actual argument when reporting incorrect number of arguments #34138
gopls: fails to detect invalid argument types in variadic function call #60893 (closed)
Can't mix and explicit arg with varargs returned by a function call #41975 (closed)
compiler error logger #63475 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Change https://go.dev/cl/624335 mentions this issue: cmd/compile: print the variadic argument in variadic form in compiler error message

I have a fix, PTAL.

authors: fengyoulin gabyhelp odeke-em


text:
all: gofmt -w -r 'interface{} -> any' src

Example PR to see what this commit would look like in github.dev.

Ahh, my bad. I meant to base against my own repo sorry all.


text:
jsonpb should support custom JSON serialization

This would be done by delegating to the message if it implements json.Marshaler or json.Unmarshaler.
FWIW, this could simplify how the well-known types are handled, e.g. no need to special-case them in this package. (So, in a way, this issue relates to #169.)
Both the binary and text encodings already support the same concept, where a message can implement a particular interface (proto.Marshaler/proto.Unmarshaler, encoding.TextMarshaler/encoding.TextUnmarshaler) to customize serialization/de-serialization. This just extends that same concept to JSON encoding/decoding.
I've also opened a pull request that implements the change: https://github.com/golang/protobuf/pull/325
I think consistency with binary and text marshaling is a reasonable justification for the change. But I also have my own reason for the change: allow users of a dynamic message library to use jsonpb as they would with any other proto.Message.

ping

@bcmills, pinging you since git blame identifies you as the last to touch the jsonpb package. Mind giving this a brief glance?

"Last to touch the package" isn't a great heuristic.  I think @dsnet, @cherrymui, and @randall77 have been working on proto stuff lately.

"Last to touch the package" isn't a great heuristic.

Agreed, it isn't. But outsiders have pretty poor visibility into anything better, and I was hoping to get some feedback on this vs. letting it languish like so many other issues and pull requests.
Thanks for tagging the relevant folks!

\cc @cybrcodr, who will be handling some of the jsonpb-related PRs and issues.

@cybrcodr: ping

I think this sounds reasonable for dynamic messages.  But it would be better for WKT's JSON (de)serialization be as implemented right now.  I'll review your PR soon.

Fixed in #325

authors: bcmills cybrcodr dsnet jhump

repo: golang/protobuf


text:
SDM630: timestamp of last change?

If it were physically possible to read the timestamp of last change from the Modbus protocol it would be helpful to include this in the API output. Not the timestamp of the reading but the timestamp of the last meter-internal change.

No information if supported by modbus- closing.


text:
all: harmonise APIs across all packages

There is a low level of variety in the conventions we use across the different repos. We should take the opportunity when merging repos and the concomitant breakage that comes with that to fix these into a smaller number of consistent conventions.
For example (feel free to add more):

[ ] https://github.com/gonum/matrix/pull/436
[ ] https://github.com/gonum/stat/issues/179
[ ] https://github.com/gonum/stat/pull/170
[ ] https://github.com/gonum/matrix/issues/403

There are a bunch of API changes we've discussed. Would you like me to add them here, or should they be different issues?

This is an aggregator for issues that exist in the other repos. If you have issues that exist (or you are writing) and need to be addressed after the merge, then this is the right place to remind us about them. I avoided writing issues here because there is nothing code here to have issues yet.
I don't recall the exact changes, but if they exist in particular repo, write the issue there and link here. If they are general things, write a new issue here.

Using this to keep track of the major changes

[] Moved import paths to gonum.org/v1/gonum/pkg
[] Moved c-wrappers for BLAS and Lapack out of main repository into gonum.org/v1/netlib/pkg
[] Plot still it's own repository (not a change, but important to note)

Looks like these are all done. Agreed @kortschak ?

Seems so.

authors: btracey kortschak

repo: gonum/gonum


text:
stat/combin: add Cartesian for constructing the cartesian product of …

…a set of slices

PTAL @sbinet  @kortschak

PTAL


text:
mediapy seems not to work outside of jupyter?

Hi,
I'm a engineer and I'm trying to use MuJoCo for my open-source humanoid Kayra.
I'm looking for some help with mediapy / rendering images without the conventional mujoco-viewer,
as I'm planning to write a viewer that shows not only the robot but also provides an interface to see
the different forces, contact points etc over time as graphs and can listen to the whole keyboard.
I've concatenated two of the examples in the introductory jupyter notebook of mujoco to generate
a rendering of the scene as well as the matlibplots.
(I didn't dare to file a bug report as I suspect that the problem is sitting in front of the screen)
I get the following error:
python3 plots.py
<IPython.core.display.HTML object>
Exception ignored in: <function GLContext.del at 0x7f23419e72e0>
Traceback (most recent call last):
File "/home/ramin/.local/lib/python3.10/site-packages/mujoco/glfw/init.py", line 41, in del
File "/home/ramin/.local/lib/python3.10/site-packages/mujoco/glfw/init.py", line 35, in free
TypeError: 'NoneType' object is not callable
Here is a repository which refers to my question, the source code
I gobbled together is plots.py in the mujoco folder.
When commenting out the line
media.show_image(renderer.render())
the script displays the matplotlib stuff.
I'm running on a Mac M2 / Python 3.9 and Ubuntu Linux, Python 3.10.12. Both machines report the same error.

Working on a fix.

Could you let us know if the latest release fixes your issues?

Hi @assadollahi, can you check if the latest release (3.1.0) fixes your issue? We've added a close method that you should call to free up resources associated with the renderer object. You can use it as follows:
# Option 1.
renderer = Renderer(...)
# Use renderer.
renderer.close()

# Option 2.
with Renderer(...) as renderer:
# Use renderer.

Hi @assadollahi, going to close this. Feel free to re-open if you're still running into issues after updating to the latest release.

authors: assadollahi kevinzakka

repo: google-deepmind/mujoco