strings.Builder is not available in yunabe/lgo:20190218

[kortschak]

We have stabilised the graph API in gonum, so I've taken up trying your graphprac-binder with the following URL https://mybinder.org/v2/gh/yunabe/graphprac-binder/master, however it doesn't build. Failing with (briefly because mybinder doesn't allow raw, copiable text logs to be see)

---> Running in 607a579ad9be
# gonum,org/v1/gonum/graph/formats/dot/internal/errors
/go/src/gonum.org/v1/gonum/graph/formats/dot/internal/errors/errors.go:34:11 undefined: strings.Builder
/go/src/gonum.org/v1/gonum/graph/formats/dot/internal/errors/errors.go:55:11 undefined: strings.Builder

So presumably the docker image has a <go1.10 standard library. Is there a more recent version?

[yunabe]

I pushed yunabe/lgo:20190320 with go1.11.

One problem of go1.11 is lgo has a performance issue since go1.10 due to a regression in golang and the overhead of code execution is 5x slower with go1.11.

With my Macbook Pro Late 13, the overhead is around 3 secs. The overhead can be longer if you don't use SSD.

See https://github.com/yunabe/lgo#go110 for details and the route cause of the issue in golang.

[kortschak]

Thanks for that. Yes, I also tried another version. Yesterday I built a go1.10 lgo and tried the code I wanted to use. It was unreasonably slow.

It does run though, but fails halfway through with this

panic: runtime error: growslice: cap out of range

goroutine 68 [running]:
runtime/debug.Stack(0xc400000008, 0x7f8f0285ca88, 0xc4204063b0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0xa9
github.com/yunabe/lgo/core.(*resultCounter).recordResult(0xc420406398, 0x7f8f02766cc0, 0x7f8f02863f90)
	/go/src/github.com/yunabe/lgo/core/core.go:95 +0xce
github.com/yunabe/lgo/core.(*resultCounter).recordResultInDefer(0xc420406398)
	/go/src/github.com/yunabe/lgo/core/core.go:100 +0x3b
panic(0x7f8f02766cc0, 0x7f8f02863f90)
	/usr/local/go/src/runtime/panic.go:502 +0x23a
fmt.(*buffer).WriteString(...)
	/usr/local/go/src/fmt/print.go:82
fmt.(*fmt).padString(0xc4204e0040, 0x7f8f027d9d00, 0x7f8f027a58a0)
	/usr/local/go/src/fmt/format.go:110 +0x10d
fmt.(*fmt).fmt_s(0xc4204e0040, 0x7f8f027d9d00, 0x7f8f027a58a0)
	/usr/local/go/src/fmt/format.go:328 +0x63
fmt.(*pp).fmtString(0xc4204e0000, 0x7f8f027d9d00, 0x7f8f027a58a0, 0x7f8f00000076)
	/usr/local/go/src/fmt/print.go:437 +0x121
fmt.(*pp).printValue(0xc4204e0000, 0x7f8f02673e80, 0xc420437dd8, 0x198, 0x7f8f00000076, 0x2)
	/usr/local/go/src/fmt/print.go:734 +0x2211
fmt.(*pp).printValue(0xc4204e0000, 0x7f8ef47ed180, 0xc420437dd0, 0x199, 0xc400000076, 0x1)
	/usr/local/go/src/fmt/print.go:783 +0x1b2e
fmt.(*pp).printValue(0xc4204e0000, 0x7f8ef47eca00, 0xc420437dd0, 0x16, 0x76, 0x0)
	/usr/local/go/src/fmt/print.go:853 +0x1975
fmt.(*pp).printArg(0xc4204e0000, 0x7f8ef47eca00, 0xc420437dd0, 0x7f8f00000076)
	/usr/local/go/src/fmt/print.go:689 +0x1d8
fmt.(*pp).doPrintln(0xc4204e0000, 0xc42037ff78, 0x1, 0x1)
	/usr/local/go/src/fmt/print.go:1146 +0x47
fmt.Fprintln(0x55b95b6af1a0, 0xc42015e068, 0xc42037ff78, 0x1, 0x1, 0x45, 0x0, 0x0)
	/usr/local/go/src/fmt/print.go:254 +0x5a
fmt.Println(0xc42037ff78, 0x1, 0x1, 0x45, 0x0, 0x0)
	/usr/local/go/src/fmt/print.go:264 +0x5c
github.com/yunabe/lgo/sess7b2274696d65223a313535333131333737373232333235393335307d/exec4.lgo_init()
	/go/src/github.com/yunabe/lgo/sess7b2274696d65223a313535333131333737373232333235393335307d/exec4/src.go:10 +0x96
github.com/yunabe/lgo/cmd/runner.loadShared.func3()
	/go/src/github.com/yunabe/lgo/cmd/runner/runner.go:62 +0x26
github.com/yunabe/lgo/core.startExec.func1(0xc420406360, 0xc42059ffd0)
	/go/src/github.com/yunabe/lgo/core/core.go:256 +0x83
created by github.com/yunabe/lgo/core.startExec
	/go/src/github.com/yunabe/lgo/core/core.go:253 +0xcb
main routine failed

I have that here.

Related: in order to get lgo to build I needed to remove main packages from the gonum tree. Otherwise I saw errors for those like this

panic: runtime error: index out of range

goroutine 1 [running]:
cmd/go/internal/work.(*Builder).linkSharedAction.func2(0x831da0)
        /usr/local/go/src/cmd/go/internal/work/action.go:708 +0x995
cmd/go/internal/work.(*Builder).cacheAction(0xc42011f2c0, 0xc420532f40, 0x14, 0x0, 0xc42037a150, 0xc420532f40)
        /usr/local/go/src/cmd/go/internal/work/action.go:300 +0x9f
cmd/go/internal/work.(*Builder).linkSharedAction(0xc42011f2c0, 0x1, 0x1, 0xc4200254e8, 0x6, 0xc420139680, 0xc4200254e8)
        /usr/local/go/src/cmd/go/internal/work/action.go:701 +0x29f
cmd/go/internal/work.(*Builder).buildmodeShared(0xc42011f2c0, 0x1, 0x1, 0xc42001e0d0, 0x1, 0x1, 0x0, 0x0, 0x0, 0xc420139680, ...)
        /usr/local/go/src/cmd/go/internal/work/action.go:612 +0x12f
cmd/go/internal/work.InstallPackages(0xc42001e0d0, 0x1, 0x1, 0x0)
        /usr/local/go/src/cmd/go/internal/work/build.go:478 +0xdac
cmd/go/internal/work.runInstall(0xb01a40, 0xc42001e0d0, 0x1, 0x1)
        /usr/local/go/src/cmd/go/internal/work/build.go:412 +0x49
main.main()
        /usr/local/go/src/cmd/go/main.go:140 +0x7e1
(16/121) failed to install "gonum.org/v1/gonum/blas/testblas/benchautogen": exit status 2

I have asked about this on go-nuts, but have not had an answer yet. Do you know anything about this?

I also tried go1.12, but that failed completely (possibly because I have GO111MODULE=on).

[yunabe]

Yesterday I built a go1.10 lgo and tried the code I wanted to use. It was unreasonably slow.

go install ignores prebuilt so files and it rebuilds all libraries your code depends on from scratch due to golang/go#24034. So, the code execution with a lot of third-party dependencies can be extremely slow until the bug is fixed.

Related: in order to get lgo to build I needed to remove main packages from the gonum tree.

I committed a change to ignore main packages (34ba4a2).

I also tried go1.12, but that failed completely (possibly because I have GO111MODULE=on).

Yes, I noticed the compilation of lgo is broken with go1.12. I think it's related to golang/go#30768. But I need further investigation.

[kortschak]

Thank you for working on this.

[kortschak]

BTW I think that the gc linker should not panic no matter what the input, but I have not been able to reproduce it outside lgo so that I an file an issue against golang/go. Do you have any suggestions?