Re: [go-nuts] About build Go Archive

But I can use -buildmod=plugin to generate a "ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked", and it can be used. I want to konw if it's the only way to generate a binary package and the builmode=archive/shared not work anymore. 在 2019年8月28日星期三 UTC+8下午10:36:31，Ian

[go-nuts] Re: Seeing 'plugin built with different version' errors with Go1.11 (but not with Go1.10)

To answer my own question, it turned out the problem was a change in behaviour in dh-golang (Debian helper for golang). This changed the build flags used by the default (non-overridden) Go build behaviour to use '-all' with 'trimpath', which changed the file paths embedded in the compiled

[go-nuts] Re: x/net/Listen behaviours

Hello, I tried your program and when you call listener, err := net.Listen("tcp4", addrString) it does indeed only listen to "tcp4". Later, when you call server.ListenAndServe() (because listener is nil), the system seems to "re-listen" from the same port and then it listen to "tcp" and not

[go-nuts] Re: x/net/Listen behaviours

Hi Jacques, Thanks for the help! > when you call listener, err := net.Listen("tcp4", addrString) it does indeed only listen to "tcp4". Later, when you call server.ListenAndServe() (because listener is nil), the system seems to "re-listen" from the same port and then it listen to "tcp" and

[go-nuts] Re: x/mobile: Samples for reverse binding in gomobile

fredag den 6. september 2019 kl. 13.29.33 UTC+2 skrev Jay Sharma: > > Hello All, > > *I can not see any samples for reverse binding (Calling function from go > layer of java layer) in gomobile.* > > > There is the original proposal: https://github.com/golang/go/issues/16876 There is also some

[go-nuts] Re: x/net/Listen behaviours

Ahh, I think I understand the problem! I assumed that "listener, err := ..." would use the existing listener variable (creating err on the spot), rather than creating a new locally-scoped listener? Therefore, as you said, listener is basically always nil outside that "if useListener>0 {}"

Re: [go-nuts] About build Go Archive

On Fri, Sep 6, 2019 at 2:05 AM Jack Wang wrote: > > But I can use -buildmod=plugin to generate a "ELF 64-bit LSB shared object, > x86-64, version 1 (SYSV), dynamically linked", and it can be used. I want to > konw if it's the only way to generate a binary package and the >

[go-nuts] Re: THANKS GO TEAM FOR GOLANG'S NEW VERSION.

I second that emotion, brother. Go makes my daily work just a little bit less irritating. On Thursday, 5 September 2019 21:55:48 UTC-7, jfrank...@gmail.com wrote: > > THIS IS NOT ABOUT MISTAKES IS ABOUT THANKS TO ALL PEOPLE THAT MAKE GOLANG > A FANTASTIC CHOISE IN THE LANDSCAPE OF PROGRAMMING

[go-nuts] CPU profiling with pprof

Hi, The documentation of the profiling (https://blog.golang.org/profiling-go-programs) explains that: "Go program stops about 100 times per second". However, in the code, I could see that the collector has a sleep of 100ms

[go-nuts] x/mobile: Samples for reverse binding in gomobile

Hello All, *I can not see any samples for reverse binding (Calling function from go layer of java layer) in gomobile.* Is anybody tried any samples of reverse binding. Thank in advance. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

FWIW, I think this issue tracks a similar request: #30515 cmd/go: offer a consistent "global install" command https://github.com/golang/go/issues/30515 It was tagged as a release-blocker for Go 1.13, but I think time ran out. One outcome considered there was a new argument to 'go get'

[go-nuts] Re: perfs of a Go binary VS C++

1.35s 10.38% 32.13% 12.99s 99.85% go-hep.org/x/hep/rootio.(*Scanner).Scan /home/binet/dev/go/gocode/src/go-hep.org/x/hep/rootio/scanner.go Looks like you spent your time in a scanner routine. I never used scanners to scan text tokens, but I guess there is a big perfomance penalty

Re: [go-nuts] How to do a forward compatibility support for go 1.13?

This may not be the exact answer you're looking for, but there's a package which handles this even better than Go's builtin error package: https://github.com/pkg/errors Dave Cheney's package is better designed, IMO, and the explicit errors.Wrap() call is more clear than inferring it from your

[go-nuts] Re: How to do a forward compatibility support for go 1.13?

Use import errors "golang.org/x/xerrors" this way later you only have to replace it with `import "errors"` and `errors.Errorf` with `fmt.Errorf`. 2019. szeptember 6., péntek 16:50:10 UTC+2 időpontban changkun a következőt írta: > > I have upgraded my code to Go 1.13 with newly

[go-nuts] Re: x/net/Listen behaviours

You're absolutely right, Jacques! I completely misunderstood this from the Go documentation : Redeclaration does not introduce a new variable; it just assigns a new value to the original. .. because I did not understand the difference

Re: [go-nuts] How to do a forward compatibility support for go 1.13?

I think that in general you will have to only use features available to Go 1.11, meaning, of course, that the new methods in the errors package would be off limits. In the mean time you could use golang.org/x/xerrors, which is a superset of the new errors package and I believe will work with 1.11.

[go-nuts] Re: Go module and local dependencies

Hi t hepudds Yeah this is exactly what I was looking for, thanks a lot. I search everywhere on the Go website and the Go blog but I didn't go on the Github, my bad. With this help, I'm able to build it but in an other more complicated exemple I have an issue : if I add a 2nd library that need

[go-nuts] How to do a forward compatibility support for go 1.13?

I have upgraded my code to Go 1.13 with newly introduced errors APIs. However, I am not able to upgrade the production environment Go version which is Go 1.11, which means I have to run Go 1.13 code on a Go 1.11 environment. What are the way to make my builds both happy on local and production

[go-nuts] Re: x/net/Listen behaviours

Yes! I think that your analysis is correct. The listener inside the if is not the same as the one outside. You can check using fmt.Println() and you will see two different addresses. -- Jacques Le vendredi 6 septembre 2019 15:52:11 UTC+2, jgr...@ou.edu a écrit : > > Ahh, I think I understand