profile
viewpoint
mattn mattn Osaka, Japan https://mattn.kaoriya.net/ Long-time Golang user&contributor, Google Dev Expert for Go, and author of many Go tools, Vim plugin author. Windows hacker C#/Java/C/C++

jugyo/earthquake 664

Twitter terminal client with streaming API support.

jugyo/termtter 200

moved to https://github.com/termtter/termtter

dufferzafar/cheat 196

Cheatsheets for command line, because, you know, life is too short to read manpages.

cznic/99c 188

github.com/cznic/99c has moved to modernc.org/99c

c9s/Vimana 184

Vimana is an easy to use system for searching , installing, and downloading vim script. Vimana provides a command-line interface such like aptitude programe on Debian linux, for you to search , download , install , upgrade scripts from http://www.vim.org (vimonline site).

c9s/gomon 181

Monitor for any changes in your go package and automatically restart commands (run, build, server or anything)

cznic/cc 166

github.com/cznic/cc has moved to modernc.org/cc

c9s/perlomni.vim 125

perl omnicompletion for vim (including base class function compleltions .. etc)

jugyo/notify 59

The notification function for many platforms.

jwerle/fs.c 55

File system API much like Node's fs module (synchronous)

startednakabonne/gosivy

started time in 11 minutes

issue commentgolang/go

cmd/go2go: cannot infer generic interface types

I am much less certain about the case where A is a parameterized type, in particular where we are compiling a parameterized function for which A's methods are defined by a constraint

The rules would obviously need to be thought about, and codified but my intuition is that the method set of any type is known (if generically typed) and once we've established the set of common methods, unifying should be very similar to unifying func types in the existing proposal.

I have no idea whether people will write many parameterized interface types (other than for use as constraints). I don't quite see the point of a parameterized interface type. Of course it must work, but will they be used frequently enough that it's worth writing type inference rules for them?

I have only one data point: my own experience; but I've played around with a couple of not-entirely-trivial pieces of generic Go code (I ported a concurrent ordered map implementation and I made the stdlib io library generic).

In both cases, generic interfaces were a key part of the design, and I'm pretty sure that they will continue to be as useful in general as I found them there.

This is a Good Thing IMHO. It's showing that Go's existing generic feature, the interface value concept, is entirely orthogonal to, and composible with, the proposed new type parameter feature.

One nice property of generically typed interface types is that values inside them can "hide" their own type parameters, which is something that a struct type cannot, because any generic member of the struct must have its type parameters declared on the containing type. Thus generic interface types are an important part of the backward-compatibility story: they are a way of adding potentially generic functionality without changing the type parameters (any change to type parameters being a backwardly incompatible change)

And that's quite apart from the more direct applications such as for iterators (the io package being an example of a batched iterator package - it could [be made (https://twitter.com/rogpeppe/status/1301189885836001281?s=19) without much difficulty. Why shouldn't we be able to use the io.Pipe to pipe batches of floating point numbers, for example).

rogpeppe

comment created time in 22 minutes

issue openedgolang/go

JSON: disable HTML escaping and omit final newline

I am encoding some JSON. I need to disable HTML escaping, and I need no trailing newline. It seems no easy way to do this.

If I try json#Marshal, it does HTML escaping with no option to change. If I try json#Encoder.Encode, it adds newline with no option to change. I came up with this as a workaround:

package main

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

func compact(dst *bytes.Buffer, v interface{}) error {
   var src bytes.Buffer
   enc := json.NewEncoder(&src)
   enc.SetEscapeHTML(false)
   err := enc.Encode(v)
   if err != nil {
      return err
   }
   return json.Compact(dst, src.Bytes())
}

func main() {
   var dst bytes.Buffer
   e := compact(&dst, []string{"May", "June & July"})
   if e != nil {
      log.Fatal(e)
   }
   fmt.Printf("%q", dst.String())
}

but its pretty awkward. Also if you wanted to indent, it is difficult, since you are now calling Compact, using json#Encoder.SetIndent would be pointless, you would have to call json#Indent after everything is done.

created time in 22 minutes

push eventmruby/mruby

Yukihiro "Matz" Matsumoto

commit sha 2e33c2d120b5487e9be2ef9881b41329c4eeabcd

Remove unnecessary bit shift in `rational_new_f`.

view details

push time in 23 minutes

issue commentgolang/go

all: Go 1.16rc1 release status

We've tagged Go 1.16RC1, but have not yet finished releasing signed binaries due to an issue we're working to resolve. We have not sent an announcement because of this.

We'll send our normal release announcement when we release the binaries (hopefully in the next day).

toothrot

comment created time in 28 minutes

startedShopify/tapioca

started time in 29 minutes

issue closedgolang/go

runtime: TestGdbPython fails when CGO isn't enabled

go version: 1.15.7

$ CGO_ENABLED=0 go test -run=TestGdbPython runtime
--- FAIL: TestGdbPython (0.60s)
    runtime-gdb_test.go:77: gdb version 9.1
    runtime-gdb_test.go:270: gdb output:
        No auto-load scripts.
        Breakpoint 1 at 0x49b498: file /tmp/go-build021787039/main.go, line 26.
        hi
        
        Thread 1 "a.exe" hit Breakpoint 1, main.main () at /tmp/go-build021787039/main.go:26
        26		gslice = slicevar
        BEGIN info goroutines
        Undefined info command: "goroutines".  Try "help info".
        END
        BEGIN print mapvar
        $1 = (map[string]string) 0xc000118f48
        END
        BEGIN print slicemap
        $2 = (map[string][]string) 0xc000110150
        END
        BEGIN print strvar
        $3 = 0x4bf2c1 "abc"
        END
        BEGIN print chanint
        $4 = (chan int) 0xc00013e000
        END
        BEGIN print chanstr
        $5 = (chan string) 0xc000136120
        END
        BEGIN info locals
        mapvar = 0xc000118f48
        chanstr = 0xc000136120
        chanint = 0xc00013e000
        strvar = 0x4bf2c1 "abc"
        slicemap = 0xc000110150
        ptrvar = <optimized out>
        slicevar = {array = 0xc000142000, len = 824634835376, cap = 824634835328}
        END
        BEGIN goroutine 1 bt
        Undefined command: "goroutine".  Try "help".
        END
        BEGIN goroutine all bt
        Undefined command: "goroutine".  Try "help".
        END
        No breakpoint at main.go:15.
        Breakpoint 2 at 0x49b611: file /tmp/go-build021787039/main.go, line 29.
        map[a:[b c d] e:[f g h]], 99, spongepants
        
        Thread 1 "a.exe" hit Breakpoint 2, main.main () at /tmp/go-build021787039/main.go:29
        29	}  // END_OF_PROGRAM
        BEGIN goroutine 1 bt at the end
        Undefined command: "goroutine".  Try "help".
        END

In runtime-gdb_test.go, we have:

        if cgo {
                // When we build the cgo version of the program, the system's
                // linker is used. Some external linkers, like GNU gold,
                // compress the .debug_gdb_scripts into .zdebug_gdb_scripts.
                // Until gold and gdb can work together, temporarily load the
                // python script directly.
                args = append(args,
                        "-ex", "source "+filepath.Join(runtime.GOROOT(), "src", "runtime", "runtime-gdb.py"),
                )
        } else {
                args = append(args,
                        "-ex", "info auto-load python-scripts",
                )
        }

If I remove the if condition and always load src/runtime/runtime-gdb.py , the test passes. But I am not sure if that's the right fix.

closed time in 30 minutes

nehaljwani

issue commentgolang/go

runtime: TestGdbPython fails when CGO isn't enabled

Updating from gdb-9.1-6.fc32.x86_64 to gdb-9.1-7.fc32.x86_64 seems to have resolved the issue. Closing.

nehaljwani

comment created time in 30 minutes

startedwayofthepie/ephemeral-actions-blog

started time in 36 minutes

startedarduino/arduino-create-agent

started time in an hour

startedadam-mcdaniel/chess-engine

started time in an hour

issue closedgolang/go

proposal: os: Mkdir differentiate between file and directory existing

If you are creating a directory, three things can happen:

  1. path not exist
  2. path exist as directory
  3. path exist as file

MkdirAll handles these three cases:

https://github.com/golang/go/blob/b634f5d97a6e65f19057c00ed2095a1a872c7fa8/src/os/path.go#L18-L26

However Mkdir does not. It lumps 2 and 3 together, which is bad because one is an error and one is not. This situation is further compounded by the fact that os.ErrNotDir is not currently available:

https://github.com/golang/go/blob/b634f5d97a6e65f19057c00ed2095a1a872c7fa8/src/os/error.go#L17-L29

I see a reference to it here:

https://github.com/golang/go/blob/b634f5d97a6e65f19057c00ed2095a1a872c7fa8/src/cmd/go/internal/fsys/fsys.go#L240

so without that, a user would need to either just use MkdirAll for everything, or use the syscall package, or I made a function like this as a workaround:

func mkdir(path string) error {
   dir, err := os.Stat(path)
   if err == nil && dir.IsDir() {
      return nil
   }
   return os.Mkdir(path, os.ModeDir)
}

closed time in an hour

89z

issue commentgolang/go

proposal: os: Mkdir differentiate between file and directory existing

I think the two functions I put are good enough workarounds, I will close this for now. If others are interested I can reopen, thanks

89z

comment created time in an hour

issue commentgolang/go

net/http: ServeContent()/ServeFile() doesn't return expected response when WriteTimeout happens

@dmitshur @toothrot @cagedmantis This issue might be worthy of a backport, so we may want to consider adding CL 285914 to 1.16 even though rc1 is out. I'd like @neild to take a look at the test, though. Thanks.

fuweid

comment created time in an hour

issue commentgolang/go

gccgo: MemmoveAtomicity fails on ppc64x since it uses C's memmove

@laboger You have to use an unpatched version of autoconf 2.69. Unfortunately distros often patch autoconf, so you can't use a distro autoconf, you have to build it yourself. That said, I can fix this up for you.

laboger

comment created time in an hour

issue closedgolang/go

x/review/git-codereview: data race in cmdPending via TestBranchConfig

==================
WARNING: DATA RACE
Write at 0x000000c6a8c0 by goroutine 15:
  golang.org/x/review/git-codereview.loadGerritOriginInternal()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/api.go:108 +0x7ca
  golang.org/x/review/git-codereview.loadGerritOrigin()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/api.go:51 +0x187
  golang.org/x/review/git-codereview.fullChangeID()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/api.go:285 +0x49
  golang.org/x/review/git-codereview.(*pendingBranch).load()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/pending.go:51 +0x3a5
  golang.org/x/review/git-codereview.cmdPending.func2()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/pending.go:139 +0x50

Previous read at 0x000000c6a8c0 by goroutine 133:
  golang.org/x/review/git-codereview.loadGerritOrigin()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/api.go:42 +0x54
  golang.org/x/review/git-codereview.fullChangeID()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/api.go:285 +0x49
  golang.org/x/review/git-codereview.(*pendingBranch).load()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/pending.go:51 +0x3a5
  golang.org/x/review/git-codereview.cmdPending.func2()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/pending.go:139 +0x50

Goroutine 15 (running) created at:
  golang.org/x/review/git-codereview.cmdPending()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/pending.go:136 +0x51c
  golang.org/x/review/git-codereview.main()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/review.go:141 +0x27e
  golang.org/x/review/git-codereview.testMain()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/util_test.go:359 +0x449
  golang.org/x/review/git-codereview.TestBranchConfig()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/sync_test.go:179 +0xd4b
  testing.tRunner()
      /tmp/workdir/go/src/testing/testing.go:1194 +0x202

Goroutine 133 (running) created at:
  golang.org/x/review/git-codereview.cmdPending()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/pending.go:136 +0x51c
  golang.org/x/review/git-codereview.main()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/review.go:141 +0x27e
  golang.org/x/review/git-codereview.testMain()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/util_test.go:359 +0x449
  golang.org/x/review/git-codereview.TestBranchConfig()
      /tmp/workdir/gopath/src/golang.org/x/review/git-codereview/sync_test.go:179 +0xd4b
  testing.tRunner()
      /tmp/workdir/go/src/testing/testing.go:1194 +0x202
==================

2021-01-13T14:40:17-b8a6970/freebsd-amd64-race 2021-01-13T14:40:11-b916a6f/freebsd-amd64-race 2021-01-13T14:39:58-4aa052d/freebsd-amd64-race

CC @rsc @mdempsky @aclements

closed time in an hour

bcmills

push eventgolang/review

Ian Lance Taylor

commit sha 28abaf57728215cca0c42bf4ef3291109c9e271a

git-codereview: avoid race in loadGerritOrigin Use a mutex in loadGerritOrigin to avoid race when called in parallel by "git coderevew pending". Add a new initialized field so that the code knows when auth has been initialized. Adjust tests accordingly. The test is simply "go test -race". Fixes golang/go#43670 Change-Id: Ifb060fca6ed463f1d11a2959d03fca5e14e238c6 Reviewed-on: https://go-review.googlesource.com/c/review/+/287012 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>

view details

push time in an hour

startednical/lyon

started time in an hour

issue commentgolang/go

cmd/go2go: cannot infer generic interface types

I think that what we are talking about here is extending the type inference rules so that if the function parameter's type T is a parameterized interface type I, then given type argument A we infer the arguments to I based on the methods of A. We would presumably do this by walking through the methods of I, finding the identically named methods of A, and trying to unify the types of the two methods. I agree that the results are likely to be unsurprising if A is a fully concrete type. I am much less certain about the case where A is a parameterized type, in particular where we are compiling a parameterized function for which A's methods are defined by a constraint.

Maximizing potential type inference is definitely not a goal. The primary guideline is that type inference must never be surprising. A secondary guideline is that it must come up often enough to be useful. I have no idea whether people will write many parameterized interface types (other than for use as constraints). I don't quite see the point of a parameterized interface type. Of course it must work, but will they be used frequently enough that it's worth writing type inference rules for them?

rogpeppe

comment created time in an hour

issue commentgolang/go

proposal: spec: add native support for programming persistent memory in Go

Thanks Russ for your response. We understand that our design is not well-proven and there could be flaws that we have not thought about. Even if our proposal is not acccepted in its entirety, we feel it still can be broken into pieces that can be used to add support for programming persistent memory in a phased manner.

The first step can be to provide an interface which lets a Go program map a persistent memory file into its address space. One option could be to support an additional flag MAP_SYNC [2] in the Mmap API to let users map files that specifically support direct-access (DAX). Also, data written to persistent memory can be guaranteed to be made persistent only when they are flushed from the CPU caches as well. An API needs to be made available that can flush a range of memory address using appropriate CPU instructions.

Adding these two support will make it possible for Go programs to easily program persistent memory. It then becomes possible for external packages to be written which provides other features such as memory management, transactions, etc. Note that this is similar to what was implemented in OpenJDK through JEP 352 [1]

There are advantages to providing these features in the core runtime than as an external package - these are the bare-minimal changes required to support persistent memory programming and it becomes much easier later to expand the language to add additional features such as a garbage-collected persistent memory heap, support for transactionally updating persistent memory datastructures, etc. If there is sufficient interest to expand on the initial support added to Go, more features can be added later on.

[1] https://bugs.openjdk.java.net/browse/JDK-8207851 [2] https://man7.org/linux/man-pages/man2/mmap.2.html

jerrinsg

comment created time in an hour

startedm-cat/org-recur

started time in an hour

issue commentgolang/go

runtime: TestGdbPython fails when CGO isn't enabled

Here is my go env:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/wani/.cache/go-build"
GOENV="/home/wani/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/wani/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/wani/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/path/to/some/prefix/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/path/to/some/prefix/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="/dev/null"
CXX="/dev/null"
CGO_ENABLED="0"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build882123789=/tmp/go-build -gno-record-gcc-switches"

The go binary itself was built with:

# Disable CGO, and set compilers to /dev/null
export CGO_ENABLED=0
export CC=/dev/null
export CXX=/dev/null
export FC=/dev/null

I'm running this on Fedora 32.

nehaljwani

comment created time in an hour

issue commentgolang/go

x/pkgsite: removing some packages

If we remove github.com/mu-io/jwt-go, we'll remove everything underneath it as well. Is that OK?

jun-sheaf

comment created time in an hour

issue commentgolang/go

runtime: TestGdbPython fails when CGO isn't enabled

You deleted the issue without filling it out. Please provide that information. It matters; running

CGO_ENABLED=0 go test -run=TestGdbPython runtime

passes for me, and the first thing we need to do is understand whether I am running it in a similar environment. Thanks.

nehaljwani

comment created time in 2 hours

startedfengdu78/Coursera-ML-AndrewNg-Notes

started time in 2 hours

issue commentgolang/go

all: Go 1.16rc1 release status

Latest build: go1.16rc1

  • src (tar.gz)
  • linux-386 (tar.gz)
  • linux-armv6l (tar.gz)
  • linux-amd64 (tar.gz)
  • linux-arm64 (tar.gz)
  • freebsd-386 (tar.gz)
  • freebsd-amd64 (tar.gz)
  • windows-386 (zip) (msi)
  • windows-amd64 (zip) (msi)
  • darwin-amd64 (tar.gz)
  • darwin-arm64 (tar.gz)
  • linux-s390x (tar.gz)
  • linux-ppc64le (tar.gz)
  • linux-amd64-longtest (test only) - not built
    • skipped because of -skip-test="linux-amd64-longtest" flag
  • windows-amd64-longtest (test only) - ok

Log

2021/01/27 17:20:15 starting
2021/01/27 17:20:15 working in /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1
2021/01/27 17:20:15 $ git fetch origin master
2021/01/27 17:20:15 $ git fetch origin release-branch.go1.16
2021/01/27 17:20:18 $ git clone --reference /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gitmirror -b release-branch.go1.16 https://go.googlesource.com/go /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gitwork
2021/01/27 17:20:19 $ git codereview change relwork
2021/01/27 17:20:20 $ git config gc.auto 0
2021/01/27 17:20:21 an associated security release branch "release-branch.go1.16-security" does not exist; assuming it has been merged and deleted, so proceeding as usual
2021/01/27 17:20:21 Release status issue title: "all: Go 1.16rc1 release status"
2021/01/27 17:20:21 Release status issue: https://golang.org/issue/43955
2021/01/27 17:20:21 $ git rev-parse go1.16rc1
2021/01/27 17:21:00 $ git tag go1.16rc1 3e06467282c6d5678a6273747658c04314e013ef
2021/01/27 17:21:00 $ git push origin go1.16rc1
2021/01/27 17:21:06 $ go get golang.org/x/build/cmd/release
2021/01/27 17:22:13 skipping test-only target linux-amd64-longtest because of -skip-test="linux-amd64-longtest" flag
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target windows-386 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target freebsd-386 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target darwin-arm64 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target linux-s390x -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target linux-armv6l -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target linux-arm64 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target linux-amd64 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target src -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target linux-ppc64le -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target darwin-amd64 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target windows-amd64-longtest -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target linux-386 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target freebsd-amd64 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:22:13 $ /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/gopath/bin/release -target windows-amd64 -user go-dev -version go1.16rc1 -staging_dir /usr/local/google/home/rakoczy/go-releasebot-work/go1.16rc1/release-staging/3e06467282c6d5678a6273747658c04314e013ef_543190122 -rev 3e06467282c6d5678a6273747658c04314e013ef -skip_tests
2021/01/27 17:32:50 

The release stage has completed. Thanks for riding with releasebot today!

Please refer to the playbook for the next steps.
toothrot

comment created time in 2 hours

startedPiotrekp94/GGJ2021-RacoonTeam

started time in 2 hours

issue openedgolang/go

TestGdbPython fails when CGO isn't enabled

go version: 1.15.7

$ CGO_ENABLED=0 go test -run=TestGdbPython runtime
--- FAIL: TestGdbPython (0.60s)
    runtime-gdb_test.go:77: gdb version 9.1
    runtime-gdb_test.go:270: gdb output:
        No auto-load scripts.
        Breakpoint 1 at 0x49b498: file /tmp/go-build021787039/main.go, line 26.
        hi
        
        Thread 1 "a.exe" hit Breakpoint 1, main.main () at /tmp/go-build021787039/main.go:26
        26		gslice = slicevar
        BEGIN info goroutines
        Undefined info command: "goroutines".  Try "help info".
        END
        BEGIN print mapvar
        $1 = (map[string]string) 0xc000118f48
        END
        BEGIN print slicemap
        $2 = (map[string][]string) 0xc000110150
        END
        BEGIN print strvar
        $3 = 0x4bf2c1 "abc"
        END
        BEGIN print chanint
        $4 = (chan int) 0xc00013e000
        END
        BEGIN print chanstr
        $5 = (chan string) 0xc000136120
        END
        BEGIN info locals
        mapvar = 0xc000118f48
        chanstr = 0xc000136120
        chanint = 0xc00013e000
        strvar = 0x4bf2c1 "abc"
        slicemap = 0xc000110150
        ptrvar = <optimized out>
        slicevar = {array = 0xc000142000, len = 824634835376, cap = 824634835328}
        END
        BEGIN goroutine 1 bt
        Undefined command: "goroutine".  Try "help".
        END
        BEGIN goroutine all bt
        Undefined command: "goroutine".  Try "help".
        END
        No breakpoint at main.go:15.
        Breakpoint 2 at 0x49b611: file /tmp/go-build021787039/main.go, line 29.
        map[a:[b c d] e:[f g h]], 99, spongepants
        
        Thread 1 "a.exe" hit Breakpoint 2, main.main () at /tmp/go-build021787039/main.go:29
        29	}  // END_OF_PROGRAM
        BEGIN goroutine 1 bt at the end
        Undefined command: "goroutine".  Try "help".
        END

In runtime-gdb_test.go, we have:

        if cgo {
                // When we build the cgo version of the program, the system's
                // linker is used. Some external linkers, like GNU gold,
                // compress the .debug_gdb_scripts into .zdebug_gdb_scripts.
                // Until gold and gdb can work together, temporarily load the
                // python script directly.
                args = append(args,
                        "-ex", "source "+filepath.Join(runtime.GOROOT(), "src", "runtime", "runtime-gdb.py"),
                )
        } else {
                args = append(args,
                        "-ex", "info auto-load python-scripts",
                )
        }

If I remove the if condition and always load src/runtime/runtime-gdb.py , the test passes. But I don't think that's the right fix.

created time in 2 hours

created taggolang/go

taggo1.16rc1

The Go programming language

created time in 2 hours

push eventgolang/go

Alexander Rakoczy

commit sha 3e06467282c6d5678a6273747658c04314e013ef

[release-branch.go1.16] go1.16rc1 Change-Id: I978f6df491a19a9c45ab906dbc5194b8665bf4a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/287352 Run-TryBot: Alexander Rakoczy <alex@golang.org> Trust: Alexander Rakoczy <alex@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

view details

push time in 2 hours

more