[go-nuts] CPU profiling with pprof

[Vincent Blanchon]

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 
https://github.com/golang/go/blob/master/src/runtime/pprof/pprof.go#L779. 
Therefore, it collects data only 10 times per second?
Also, it does not stop the program since it is a separated 
goroutine 
https://github.com/golang/go/blob/master/src/runtime/pprof/pprof.go#L764.

Did I miss something here?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3d516ed5-f657-40a6-bbab-c3002a0ba65b%40googlegroups.com.

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

[Rick]

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 LANGUAGES.
> I'M A NOVATE WITH GOLANG BUT I HOPE TO CAN HELP SOME DAY AND AGAIN THANKS 
> A LOT. AND GREETINGS FROM GUATEMALA
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/40fd8d4f-04e6-4eb2-8666-930f2e07c593%40googlegroups.com.

Re: [go-nuts] About build Go Archive

[Ian Lance Taylor]

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 
> builmode=archive/shared not work anymore.

If I understand you correctly, the answer is yes.  See
https://golang.org/doc/go1.12#binary-only and
https://golang.org/doc/go1.13#go-command .

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVSFzt-Qqb-pgErzV%2BJv7FJvhiao%3DQsh_P9CFX3cC5PxA%40mail.gmail.com.

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

[jgrime]

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 between the *scope* of a 
variable and the *block* in which it was declared.

Thanks again for the help!

J.

On Friday, September 6, 2019 at 10:00:13 AM UTC-5, Jacques Supcik wrote:
>
> 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 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 {}" scope? So server.ListenAndServe() is always invoked?
>>
>> If so, then - thanks a lot for the help! :)
>>
>> Cheers,
>>
>> J.
>>
>> On Friday, September 6, 2019 at 8:09:37 AM UTC-5, Jacques Supcik wrote:
>>>
>>> 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 only "tcp4" (
>>> https://github.com/golang/go/blob/master/src/net/http/server.go#L2826)
>>>
>>> I don't understand why you call both "net.Listen" and 
>>> "server.ListenAndServe". If you want an HTTP server, I think that you can 
>>> just use "server.ListenAndServe" and you don't need anything more. If you 
>>> want an HTTP server and a generic TCP server, then you need 2 different 
>>> ports, one for the HTTP server and another for the generic TCP server. But 
>>> perhaps I did not understand your problem ;-)
>>>
>>> -- Jacques
>>>
>>>
>>> Le jeudi 5 septembre 2019 22:13:31 UTC+2, jgr...@ou.edu a écrit :

 Hi!

 I'm having some confusion over the behaviour of net.Listen() and it's 
 interactions with http.Server.

 Can anyone take a look at this, and let me know what I'm doing wrong?

 Thanks!


 System description
 -

 Go: go version go1.12.9 darwin/amd64

 OS: macOS Mojave (10.14.6)


 Problem description
 --

 Passing a net.Listener from net.Listen() into the Serve() method of an 
 http.Server does not behave how I expect ...


 Test program
 -

 A simple server that responds to connections by echoing info regarding 
 the URL by which it was contacted (see below):

 package main

 import (
 "context"
 "flag"
 "fmt"
 "log"
 "net"
 "net/http"
 "os"
 "os/signal"
 "strconv"
 "syscall"
 "time"
 )

 // Print information about the local machine's network interfaces
 func printNetworkInterfaces() {
 ifaces, err := net.Interfaces()
 if err != nil { panic("net.Interfaces()") }

 if len(ifaces)<1 {
 log.Println("No network interfaces found.")
 return
 }

 hostname, _ := os.Hostname()
 log.Println( "Network interfaces for " + hostname )

 for _, iface := range ifaces {
 addrs, err := iface.Addrs()
 if err != nil { panic("iface.Addrs()") }
 if len(addrs) < 1 { continue }
 log.Println("-",iface.Name,iface.HardwareAddr)
 for _, addr := range addrs {
 switch v := addr.(type) {
 case *net.IPNet:
 str := fmt.Sprintf("IPNet: IP=%s, mask=%s, network=%s, string=%s", 
 v.IP, v.Mask, v.Network(), v.String())
 log.Println(" ", str)
 case *net.IPAddr:
 str := fmt.Sprintf("IPAddr: IP=%s, zone=%s, network=%s, string=%s", 
 v.IP, v.Zone, v.Network(), v.String())
 log.Println(" ", str)
 default:
 log.Println("")
 }
 }
 }
 }

 // Just write the incoming url back to the sender
 func echoHandler(w http.ResponseWriter, r *http.Request) {
 txt := fmt.Sprintf("Echo: (%s)",r.URL.Path)
 w.Write( []byte(txt+"\n") )
 log.Println(txt)
 }

 var (
 listener_ = flag.Int("listener", 0, "Use an explicit net.Listener.")
 port_ = flag.Int("port", 0, "Set the port to listen on (0 = any 
 free port?).")
 timeout_  = flag.Int("wait", 0, "Timout (in seconds) before server 
 killed (0 = no timout).")
 )

 func main() {

 onShutdown := func(what string, cleanup func()) {
 log.Println( fmt.Sprintf("- Shutting down %s ...",what) )
 cleanup()
 log.Println( fmt.Sprintf("  %s shut down.",what) 

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

[Tamás Gulácsi]

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 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 
> environment with a single code base?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/13b770a9-6cee-4e81-9915-305efa4f5e08%40googlegroups.com.

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

[Marcin Romaszewicz]

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 format string.

-- Marcin


On Fri, Sep 6, 2019 at 7:50 AM changkun  wrote:

> 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
> environment with a single code base?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0a915d38-39f4-4083-b730-75320a4eecc6%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtD9MbOjkoJh7r2X--jWgi8QWY7gB933C0dQxxYVPdNSA%40mail.gmail.com.

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

[Tyler Compton]

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.

On Fri, Sep 6, 2019, 7:50 AM changkun  wrote:

> 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
> environment with a single code base?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0a915d38-39f4-4083-b730-75320a4eecc6%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1cXxzt7B4L%2B7sHw%3DxT-%2BA5J44n1PdtszQ%3DxTAoJOwU_g%40mail.gmail.com.

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

[Jacques Supcik]

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 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 {}" scope? So server.ListenAndServe() is always invoked?
>
> If so, then - thanks a lot for the help! :)
>
> Cheers,
>
> J.
>
> On Friday, September 6, 2019 at 8:09:37 AM UTC-5, Jacques Supcik wrote:
>>
>> 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 only "tcp4" (
>> https://github.com/golang/go/blob/master/src/net/http/server.go#L2826)
>>
>> I don't understand why you call both "net.Listen" and 
>> "server.ListenAndServe". If you want an HTTP server, I think that you can 
>> just use "server.ListenAndServe" and you don't need anything more. If you 
>> want an HTTP server and a generic TCP server, then you need 2 different 
>> ports, one for the HTTP server and another for the generic TCP server. But 
>> perhaps I did not understand your problem ;-)
>>
>> -- Jacques
>>
>>
>> Le jeudi 5 septembre 2019 22:13:31 UTC+2, jgr...@ou.edu a écrit :
>>>
>>> Hi!
>>>
>>> I'm having some confusion over the behaviour of net.Listen() and it's 
>>> interactions with http.Server.
>>>
>>> Can anyone take a look at this, and let me know what I'm doing wrong?
>>>
>>> Thanks!
>>>
>>>
>>> System description
>>> -
>>>
>>> Go: go version go1.12.9 darwin/amd64
>>>
>>> OS: macOS Mojave (10.14.6)
>>>
>>>
>>> Problem description
>>> --
>>>
>>> Passing a net.Listener from net.Listen() into the Serve() method of an 
>>> http.Server does not behave how I expect ...
>>>
>>>
>>> Test program
>>> -
>>>
>>> A simple server that responds to connections by echoing info regarding 
>>> the URL by which it was contacted (see below):
>>>
>>> package main
>>>
>>> import (
>>> "context"
>>> "flag"
>>> "fmt"
>>> "log"
>>> "net"
>>> "net/http"
>>> "os"
>>> "os/signal"
>>> "strconv"
>>> "syscall"
>>> "time"
>>> )
>>>
>>> // Print information about the local machine's network interfaces
>>> func printNetworkInterfaces() {
>>> ifaces, err := net.Interfaces()
>>> if err != nil { panic("net.Interfaces()") }
>>>
>>> if len(ifaces)<1 {
>>> log.Println("No network interfaces found.")
>>> return
>>> }
>>>
>>> hostname, _ := os.Hostname()
>>> log.Println( "Network interfaces for " + hostname )
>>>
>>> for _, iface := range ifaces {
>>> addrs, err := iface.Addrs()
>>> if err != nil { panic("iface.Addrs()") }
>>> if len(addrs) < 1 { continue }
>>> log.Println("-",iface.Name,iface.HardwareAddr)
>>> for _, addr := range addrs {
>>> switch v := addr.(type) {
>>> case *net.IPNet:
>>> str := fmt.Sprintf("IPNet: IP=%s, mask=%s, network=%s, string=%s", v.IP, 
>>> v.Mask, v.Network(), v.String())
>>> log.Println(" ", str)
>>> case *net.IPAddr:
>>> str := fmt.Sprintf("IPAddr: IP=%s, zone=%s, network=%s, string=%s", 
>>> v.IP, v.Zone, v.Network(), v.String())
>>> log.Println(" ", str)
>>> default:
>>> log.Println("")
>>> }
>>> }
>>> }
>>> }
>>>
>>> // Just write the incoming url back to the sender
>>> func echoHandler(w http.ResponseWriter, r *http.Request) {
>>> txt := fmt.Sprintf("Echo: (%s)",r.URL.Path)
>>> w.Write( []byte(txt+"\n") )
>>> log.Println(txt)
>>> }
>>>
>>> var (
>>> listener_ = flag.Int("listener", 0, "Use an explicit net.Listener.")
>>> port_ = flag.Int("port", 0, "Set the port to listen on (0 = any free 
>>> port?).")
>>> timeout_  = flag.Int("wait", 0, "Timout (in seconds) before server 
>>> killed (0 = no timout).")
>>> )
>>>
>>> func main() {
>>>
>>> onShutdown := func(what string, cleanup func()) {
>>> log.Println( fmt.Sprintf("- Shutting down %s ...",what) )
>>> cleanup()
>>> log.Println( fmt.Sprintf("  %s shut down.",what) )
>>> }
>>>
>>> flag.Parse()
>>>
>>> useListener := *listener_
>>> port := *port_
>>> timeout := *timeout_
>>>
>>> // Let's see what interfaces are present on the local machine
>>>
>>> printNetworkInterfaces()
>>>
>>> // Simple server for incoming connections.
>>>
>>> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) 
>>> {echoHandler(w,r)});
>>>
>>> var listener net.Listener = nil
>>> addrString := fmt.Sprintf(":%d",port)
>>>
>>> // Using an explicit Listener provides more control over the specifics,
>>> // e.g. tcp4/6 and letting the system select a currently free port.
>>>
>>> if useListener>0 {
>>> 

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

[changkun]

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 
environment with a single code base?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0a915d38-39f4-4083-b730-75320a4eecc6%40googlegroups.com.

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

[Guillaume Lescure]

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 the 1st, I have 
a weird error :

go: xxx/myLib@v0.0.0-0001010100-: unrecognized import path 
"xxx/myLib" (import path does not begin with hostname) 
go: error loading module requirements

Can I use the "replace design" with any number of project like :
* myLIb
* myWrapper => need myLib
* myBin => need myWrapper

Source code is attached.


Le jeudi 5 septembre 2019 03:57:51 UTC+2, t hepudds a écrit :
>
> Hello Guillaume,
>
> I haven't had a chance to look at your example closely, but it seems you 
> have two modules defined on your local filesystem, with two go.mod files 
> total.
>
> If that is what you are trying to do, one approach is to use a `replace` 
> directive to let one module know about the on-disk location of the other 
> module. Otherwise, they don't know how to find each other.
>
> Also, you usually want to name your modules as if you will publish them 
> someday, which means the `module` line in a go.mod would read something 
> like `module github.com/some/repo` , rather 
> I think you might have something like `module xxx/myLib`, which can be 
> problematic.
>
> In general, when importing code with an import statement, you should 
> always use the full import path, which will start with the module path, 
> such as `import "github.com/some/repo/some/pkg"`. You should always use 
> the full import path when importing packages inside the same modules, as 
> well as when importing packages from a different module.
>
> You can read more about how to use `replace` to let modules find each 
> other on your local filesystem in these two FAQs on the modules wiki:
>
> FAQ: When should I use the `replace` directive?
> 
> https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive
>   
> FAQ: Can I work entirely outside of VCS on my local filesystem?
> 
> https://github.com/golang/go/wiki/Modules#can-i-work-entirely-outside-of-vcs-on-my-local-filesystem
>
> Here is a link to a small runnable example that shows two modules 
> side-by-side on the filesystem that use `replace` to make things work. I 
> think that is at least somewhat similar to what you are trying to do, if I 
> followed:
>
> https://groups.google.com/d/msg/golang-nuts/1nYoAMFZVVM/eppaRW2rCAAJ
>
> Hope that helps at least somewhat. Please don't hesitate to post more 
> questions or comments.
>
> Regards,
> thepudds
>
> On Sunday, September 1, 2019 at 6:02:21 AM UTC-4, Guillaume Lescure wrote:
>>
>> Hi,
>>
>> Thanks for the comments and the ideas :)
>>
>> 1. Try 'go build ./...'  from the root directory of the module to build 
>>> all the packages in the module.  'go build'  without any arguments is the 
>>> same as 'go build .'  which means just build the current directory/package. 
>>
>>
>> I didn't know the command "go build ./..." and that directly answer my 
>> 1st question, thanks a lot. Now my library is totally built.
>> Thanks a lot for the tips and the explanation (maybe it sould be 
>> documented ?).
>>
>> 2.  With only one go.mod, you should not need a 'replace'  to find local 
>>> code in your own module. 
>>
>>
>> I  have 2 go.mod, 1 in myLib folder and 1 other in myBin folder and I 
>> don't want to merge them.
>> The idea behind that is to simulate 2 repositories, 1 for the library and 
>> 1 for a random application that use that library.
>>
>> 3.  Make sure you use the full import path in any import statements in 
>>> your code when importing other packages, even when importing other packages 
>>> in the same module.  The import path should always start with the module 
>>> path. (The module path what you see on the 'module' line of your go.mod). 
>>>
>>  If that doesn’t help, you might need to share the exact error messages, 
>>> along with the exact go.mod and exact import statements in question. 
>>
>>
>> My code is attached.
>>
>> Regards,
>>  
>>
>>>
>>>
>>> (I am on mobile, so sorry this is brief). 
>>>
>>> Regards, 
>>> thepudds
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/64d862c6-2fae-462a-b87f-681dabd0c341%40googlegroups.com.


testGo.tar.gz
Description: Binary data

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

[Elias Naur]

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 example code in

https://github.com/golang/mobile/blob/master/bind/testdata/classes.go

-- elias

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5f00b73e-eb21-4076-8508-6df651245519%40googlegroups.com.

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

[jgrime]

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 {}" scope? So server.ListenAndServe() is always invoked?

If so, then - thanks a lot for the help! :)

Cheers,

J.

On Friday, September 6, 2019 at 8:09:37 AM UTC-5, Jacques Supcik wrote:
>
> 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 only "tcp4" (
> https://github.com/golang/go/blob/master/src/net/http/server.go#L2826)
>
> I don't understand why you call both "net.Listen" and 
> "server.ListenAndServe". If you want an HTTP server, I think that you can 
> just use "server.ListenAndServe" and you don't need anything more. If you 
> want an HTTP server and a generic TCP server, then you need 2 different 
> ports, one for the HTTP server and another for the generic TCP server. But 
> perhaps I did not understand your problem ;-)
>
> -- Jacques
>
>
> Le jeudi 5 septembre 2019 22:13:31 UTC+2, jgr...@ou.edu a écrit :
>>
>> Hi!
>>
>> I'm having some confusion over the behaviour of net.Listen() and it's 
>> interactions with http.Server.
>>
>> Can anyone take a look at this, and let me know what I'm doing wrong?
>>
>> Thanks!
>>
>>
>> System description
>> -
>>
>> Go: go version go1.12.9 darwin/amd64
>>
>> OS: macOS Mojave (10.14.6)
>>
>>
>> Problem description
>> --
>>
>> Passing a net.Listener from net.Listen() into the Serve() method of an 
>> http.Server does not behave how I expect ...
>>
>>
>> Test program
>> -
>>
>> A simple server that responds to connections by echoing info regarding 
>> the URL by which it was contacted (see below):
>>
>> package main
>>
>> import (
>> "context"
>> "flag"
>> "fmt"
>> "log"
>> "net"
>> "net/http"
>> "os"
>> "os/signal"
>> "strconv"
>> "syscall"
>> "time"
>> )
>>
>> // Print information about the local machine's network interfaces
>> func printNetworkInterfaces() {
>> ifaces, err := net.Interfaces()
>> if err != nil { panic("net.Interfaces()") }
>>
>> if len(ifaces)<1 {
>> log.Println("No network interfaces found.")
>> return
>> }
>>
>> hostname, _ := os.Hostname()
>> log.Println( "Network interfaces for " + hostname )
>>
>> for _, iface := range ifaces {
>> addrs, err := iface.Addrs()
>> if err != nil { panic("iface.Addrs()") }
>> if len(addrs) < 1 { continue }
>> log.Println("-",iface.Name,iface.HardwareAddr)
>> for _, addr := range addrs {
>> switch v := addr.(type) {
>> case *net.IPNet:
>> str := fmt.Sprintf("IPNet: IP=%s, mask=%s, network=%s, string=%s", v.IP, 
>> v.Mask, v.Network(), v.String())
>> log.Println(" ", str)
>> case *net.IPAddr:
>> str := fmt.Sprintf("IPAddr: IP=%s, zone=%s, network=%s, string=%s", v.IP, 
>> v.Zone, v.Network(), v.String())
>> log.Println(" ", str)
>> default:
>> log.Println("")
>> }
>> }
>> }
>> }
>>
>> // Just write the incoming url back to the sender
>> func echoHandler(w http.ResponseWriter, r *http.Request) {
>> txt := fmt.Sprintf("Echo: (%s)",r.URL.Path)
>> w.Write( []byte(txt+"\n") )
>> log.Println(txt)
>> }
>>
>> var (
>> listener_ = flag.Int("listener", 0, "Use an explicit net.Listener.")
>> port_ = flag.Int("port", 0, "Set the port to listen on (0 = any free 
>> port?).")
>> timeout_  = flag.Int("wait", 0, "Timout (in seconds) before server killed 
>> (0 = no timout).")
>> )
>>
>> func main() {
>>
>> onShutdown := func(what string, cleanup func()) {
>> log.Println( fmt.Sprintf("- Shutting down %s ...",what) )
>> cleanup()
>> log.Println( fmt.Sprintf("  %s shut down.",what) )
>> }
>>
>> flag.Parse()
>>
>> useListener := *listener_
>> port := *port_
>> timeout := *timeout_
>>
>> // Let's see what interfaces are present on the local machine
>>
>> printNetworkInterfaces()
>>
>> // Simple server for incoming connections.
>>
>> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) 
>> {echoHandler(w,r)});
>>
>> var listener net.Listener = nil
>> addrString := fmt.Sprintf(":%d",port)
>>
>> // Using an explicit Listener provides more control over the specifics,
>> // e.g. tcp4/6 and letting the system select a currently free port.
>>
>> if useListener>0 {
>> log.Println("Using net.Listener")
>>
>> listener, err := net.Listen("tcp4", addrString) // :0 -> use any free port
>> if err != nil { log.Fatalln(err) }
>>
>> defer onShutdown("listener", func() {listener.Close()} )
>>
>> addrString = listener.Addr().String()
>> host, portStr, err := net.SplitHostPort(addrString) // as port may have 
>> been assigned by system
>> if err != nil { log.Fatalln(err) }
>>
>> log.Println( fmt.Sprintf("Listener Addr string: %s 

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

[jgrime]

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 not only "tcp4" (
https://github.com/golang/go/blob/master/src/net/http/server.go#L2826)

I only call server.ListenAndServe() if the listener object is nil; therefore, 
ListenAndServe() should not be called after listener, err := 
net.Listen("tcp4", addrString)?

The listener is nil by default, unless specified otherwise on the command 
line (e.g., --listener=1); at that point. it is initialised (listener, err 
:= net.Listen("tcp4", addrString)) and the server object should then use 
server.Serve(listener) rather than server.ListenAndServe().

Sorry for the lack of code clarity - and thanks again for the help, I 
appreciate it!

Cheers,

J.

On Friday, September 6, 2019 at 8:09:37 AM UTC-5, Jacques Supcik wrote:
>
> 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 only "tcp4" (
> https://github.com/golang/go/blob/master/src/net/http/server.go#L2826)
>
> I don't understand why you call both "net.Listen" and 
> "server.ListenAndServe". If you want an HTTP server, I think that you can 
> just use "server.ListenAndServe" and you don't need anything more. If you 
> want an HTTP server and a generic TCP server, then you need 2 different 
> ports, one for the HTTP server and another for the generic TCP server. But 
> perhaps I did not understand your problem ;-)
>
> -- Jacques
>
>
> Le jeudi 5 septembre 2019 22:13:31 UTC+2, jgr...@ou.edu a écrit :
>>
>> Hi!
>>
>> I'm having some confusion over the behaviour of net.Listen() and it's 
>> interactions with http.Server.
>>
>> Can anyone take a look at this, and let me know what I'm doing wrong?
>>
>> Thanks!
>>
>>
>> System description
>> -
>>
>> Go: go version go1.12.9 darwin/amd64
>>
>> OS: macOS Mojave (10.14.6)
>>
>>
>> Problem description
>> --
>>
>> Passing a net.Listener from net.Listen() into the Serve() method of an 
>> http.Server does not behave how I expect ...
>>
>>
>> Test program
>> -
>>
>> A simple server that responds to connections by echoing info regarding 
>> the URL by which it was contacted (see below):
>>
>> package main
>>
>> import (
>> "context"
>> "flag"
>> "fmt"
>> "log"
>> "net"
>> "net/http"
>> "os"
>> "os/signal"
>> "strconv"
>> "syscall"
>> "time"
>> )
>>
>> // Print information about the local machine's network interfaces
>> func printNetworkInterfaces() {
>> ifaces, err := net.Interfaces()
>> if err != nil { panic("net.Interfaces()") }
>>
>> if len(ifaces)<1 {
>> log.Println("No network interfaces found.")
>> return
>> }
>>
>> hostname, _ := os.Hostname()
>> log.Println( "Network interfaces for " + hostname )
>>
>> for _, iface := range ifaces {
>> addrs, err := iface.Addrs()
>> if err != nil { panic("iface.Addrs()") }
>> if len(addrs) < 1 { continue }
>> log.Println("-",iface.Name,iface.HardwareAddr)
>> for _, addr := range addrs {
>> switch v := addr.(type) {
>> case *net.IPNet:
>> str := fmt.Sprintf("IPNet: IP=%s, mask=%s, network=%s, string=%s", v.IP, 
>> v.Mask, v.Network(), v.String())
>> log.Println(" ", str)
>> case *net.IPAddr:
>> str := fmt.Sprintf("IPAddr: IP=%s, zone=%s, network=%s, string=%s", v.IP, 
>> v.Zone, v.Network(), v.String())
>> log.Println(" ", str)
>> default:
>> log.Println("")
>> }
>> }
>> }
>> }
>>
>> // Just write the incoming url back to the sender
>> func echoHandler(w http.ResponseWriter, r *http.Request) {
>> txt := fmt.Sprintf("Echo: (%s)",r.URL.Path)
>> w.Write( []byte(txt+"\n") )
>> log.Println(txt)
>> }
>>
>> var (
>> listener_ = flag.Int("listener", 0, "Use an explicit net.Listener.")
>> port_ = flag.Int("port", 0, "Set the port to listen on (0 = any free 
>> port?).")
>> timeout_  = flag.Int("wait", 0, "Timout (in seconds) before server killed 
>> (0 = no timout).")
>> )
>>
>> func main() {
>>
>> onShutdown := func(what string, cleanup func()) {
>> log.Println( fmt.Sprintf("- Shutting down %s ...",what) )
>> cleanup()
>> log.Println( fmt.Sprintf("  %s shut down.",what) )
>> }
>>
>> flag.Parse()
>>
>> useListener := *listener_
>> port := *port_
>> timeout := *timeout_
>>
>> // Let's see what interfaces are present on the local machine
>>
>> printNetworkInterfaces()
>>
>> // Simple server for incoming connections.
>>
>> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) 
>> {echoHandler(w,r)});
>>
>> var listener net.Listener = nil
>> addrString := fmt.Sprintf(":%d",port)
>>
>> // Using an explicit Listener provides more control over the specifics,
>> // e.g. tcp4/6 and 

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

[Jacques Supcik]

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 only 
"tcp4" (
https://github.com/golang/go/blob/master/src/net/http/server.go#L2826)

I don't understand why you call both "net.Listen" and 
"server.ListenAndServe". If you want an HTTP server, I think that you can 
just use "server.ListenAndServe" and you don't need anything more. If you 
want an HTTP server and a generic TCP server, then you need 2 different 
ports, one for the HTTP server and another for the generic TCP server. But 
perhaps I did not understand your problem ;-)

-- Jacques


Le jeudi 5 septembre 2019 22:13:31 UTC+2, jgr...@ou.edu a écrit :
>
> Hi!
>
> I'm having some confusion over the behaviour of net.Listen() and it's 
> interactions with http.Server.
>
> Can anyone take a look at this, and let me know what I'm doing wrong?
>
> Thanks!
>
>
> System description
> -
>
> Go: go version go1.12.9 darwin/amd64
>
> OS: macOS Mojave (10.14.6)
>
>
> Problem description
> --
>
> Passing a net.Listener from net.Listen() into the Serve() method of an 
> http.Server does not behave how I expect ...
>
>
> Test program
> -
>
> A simple server that responds to connections by echoing info regarding the 
> URL by which it was contacted (see below):
>
> package main
>
> import (
> "context"
> "flag"
> "fmt"
> "log"
> "net"
> "net/http"
> "os"
> "os/signal"
> "strconv"
> "syscall"
> "time"
> )
>
> // Print information about the local machine's network interfaces
> func printNetworkInterfaces() {
> ifaces, err := net.Interfaces()
> if err != nil { panic("net.Interfaces()") }
>
> if len(ifaces)<1 {
> log.Println("No network interfaces found.")
> return
> }
>
> hostname, _ := os.Hostname()
> log.Println( "Network interfaces for " + hostname )
>
> for _, iface := range ifaces {
> addrs, err := iface.Addrs()
> if err != nil { panic("iface.Addrs()") }
> if len(addrs) < 1 { continue }
> log.Println("-",iface.Name,iface.HardwareAddr)
> for _, addr := range addrs {
> switch v := addr.(type) {
> case *net.IPNet:
> str := fmt.Sprintf("IPNet: IP=%s, mask=%s, network=%s, string=%s", v.IP, 
> v.Mask, v.Network(), v.String())
> log.Println(" ", str)
> case *net.IPAddr:
> str := fmt.Sprintf("IPAddr: IP=%s, zone=%s, network=%s, string=%s", v.IP, 
> v.Zone, v.Network(), v.String())
> log.Println(" ", str)
> default:
> log.Println("")
> }
> }
> }
> }
>
> // Just write the incoming url back to the sender
> func echoHandler(w http.ResponseWriter, r *http.Request) {
> txt := fmt.Sprintf("Echo: (%s)",r.URL.Path)
> w.Write( []byte(txt+"\n") )
> log.Println(txt)
> }
>
> var (
> listener_ = flag.Int("listener", 0, "Use an explicit net.Listener.")
> port_ = flag.Int("port", 0, "Set the port to listen on (0 = any free 
> port?).")
> timeout_  = flag.Int("wait", 0, "Timout (in seconds) before server killed 
> (0 = no timout).")
> )
>
> func main() {
>
> onShutdown := func(what string, cleanup func()) {
> log.Println( fmt.Sprintf("- Shutting down %s ...",what) )
> cleanup()
> log.Println( fmt.Sprintf("  %s shut down.",what) )
> }
>
> flag.Parse()
>
> useListener := *listener_
> port := *port_
> timeout := *timeout_
>
> // Let's see what interfaces are present on the local machine
>
> printNetworkInterfaces()
>
> // Simple server for incoming connections.
>
> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) 
> {echoHandler(w,r)});
>
> var listener net.Listener = nil
> addrString := fmt.Sprintf(":%d",port)
>
> // Using an explicit Listener provides more control over the specifics,
> // e.g. tcp4/6 and letting the system select a currently free port.
>
> if useListener>0 {
> log.Println("Using net.Listener")
>
> listener, err := net.Listen("tcp4", addrString) // :0 -> use any free port
> if err != nil { log.Fatalln(err) }
>
> defer onShutdown("listener", func() {listener.Close()} )
>
> addrString = listener.Addr().String()
> host, portStr, err := net.SplitHostPort(addrString) // as port may have 
> been assigned by system
> if err != nil { log.Fatalln(err) }
>
> log.Println( fmt.Sprintf("Listener Addr string: %s (host: %s, port: 
> %s)",addrString,host,portStr) )
>
> port, err = strconv.Atoi(portStr)
> if err != nil { log.Fatalln(err) }
>
> addrString = fmt.Sprintf(":%d",port) // as port may have been assigned by 
> the system
> }
>
> server := http.Server { Addr: addrString }
>
> // Run web server in a separate goroutine so it doesn't block our progress
>
> go func(server *http.Server, listener net.Listener) {
>
> var err error
>
> if listener == nil {
> err = server.ListenAndServe()
> } else {
> err = server.Serve(listener)
> }
>
> switch err {
> case nil:
> case http.ErrServerClosed:
> log.Println("Caught ErrServerClosed")
> default:
> panic(err)
> }
> }(, 

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

[Ingo Krabbe]

 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 depending on the structure of your data.
The most important problem in scanners is when they start copying the data 
for scanning.

If you for example would have an STX [LENGTH] [DATA BLOCK]  logic in your 
data, the scanner is a big gun shooting for nothing. You could then 
generate []byte blobs pointing into your hopefully mmapped data file, that 
you can communicate through channels and put concurrent parallel worker to 
classify your data blocks. I guess that's exactly how you should 
sequentuallly streamline your data for HEP analysis. Actually that approach 
would be something , that golang is very good at.

Am Montag, 16. Oktober 2017 17:53:56 UTC+2 schrieb Sebastien Binet:
>
> hi there,
>
> I have this Go program that reads a binary file format coming from CERN.
> I am trying to get it running almost as fast as its C++ counter-part.
>
> the profile and code are here:
> - https://cern.ch/binet/go-hep/rootio.cpu.pprof
> - https://cern.ch/binet/go-hep/read-data.go
>
> on my machine, I get the following timings for the C++ (g++-7.2.0) and the 
> Go-1.9.1 programs:
>
> === C++/ROOT ===
> real=6.84 user=6.29 sys=0.52 CPU=99% MaxRSS=258384 I/O=0/0
> real=6.99 user=6.42 sys=0.55 CPU=99% MaxRSS=258312 I/O=0/0
> real=6.68 user=6.12 sys=0.55 CPU=99% MaxRSS=257956 I/O=0/0
> real=6.88 user=6.33 sys=0.54 CPU=99% MaxRSS=258964 I/O=0/0
> real=6.87 user=6.30 sys=0.56 CPU=99% MaxRSS=258024 I/O=0/0
> real=6.89 user=6.32 sys=0.56 CPU=99% MaxRSS=260452 I/O=0/0
> real=6.70 user=6.14 sys=0.56 CPU=99% MaxRSS=258368 I/O=0/0
> real=7.02 user=6.47 sys=0.54 CPU=99% MaxRSS=258128 I/O=0/0
> real=7.46 user=6.44 sys=0.56 CPU=93% MaxRSS=257972 I/O=1840/0
> real=7.11 user=6.47 sys=0.55 CPU=98% MaxRSS=258148 I/O=3984/0
>
> === go-hep/rootio ===
> real=13.06 user=12.43 sys=0.61 CPU=99%  MaxRSS=40864 I/O=0/0
> real=13.05 user=12.46 sys=0.58 CPU=100% MaxRSS=40892 I/O=0/0
> real=13.05 user=12.46 sys=0.59 CPU=100% MaxRSS=40888 I/O=0/0
> real=13.07 user=12.48 sys=0.58 CPU=99%  MaxRSS=40940 I/O=0/0
> real=13.08 user=12.48 sys=0.60 CPU=100% MaxRSS=40924 I/O=0/0
> real=13.09 user=12.46 sys=0.60 CPU=99%  MaxRSS=40976 I/O=0/0
> real=13.01 user=12.41 sys=0.60 CPU=100% MaxRSS=40876 I/O=0/0
> real=13.09 user=12.52 sys=0.58 CPU=100% MaxRSS=40880 I/O=0/0
> real=13.01 user=12.41 sys=0.60 CPU=100% MaxRSS=40880 I/O=0/0
> real=12.99 user=12.41 sys=0.58 CPU=100% MaxRSS=40872 I/O=0/0
>
> any idea on how to speed that up?
>
> I have also this rather interesting strace-log for the Go program:
> - https://cern.ch/binet/go-hep/strace-read-go.txt
>
> ie: there is a clear pattern of "epoll_wait/pselect6" on one thread 
> followed by a bunch of "pread64" on another thread.
> I suspect this is the runtime I/O layer (?) dispatching data to the 
> "worker" thread/goroutine ?
> (I have tried with GOGC=off and it was still there, as well as the same 
> timings for my Go binary.)
>
> I have put a ~764Mb data file there:
> - https://cern.ch/binet/go-hep/f64s.root
>
> if anybody wants to have a look.
>
> I initially thought it was a (lack of) bufio.Reader issue (as the file 
> format forces you to do a bunch of seeks or readat, using bufio.Reader 
> wasn't completely straightforward.)
> but, mmap-ing the whole file in memory didn't help.
>
> here is the top50 from the CPU profile:
>
> (pprof) top50   
> Showing nodes accounting for 12.90s, 99.15% of 13.01s total
> Dropped 4 nodes (cum <= 0.07s)
>   flat  flat%   sum%cum   cum%
>  2.83s 21.75% 21.75%  3.21s 24.67%  
> go-hep.org/x/hep/rootio.(*LeafD).readBasket /home/binet/dev/go/gocode/src/
> go-hep.org/x/hep/rootio/leaf_gen.go
>  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
>  1.26s  9.68% 41.81%  1.26s  9.68%  
> go-hep.org/x/hep/rootio.(*tbranch).loadEntry 
> /home/binet/dev/go/gocode/src/go-hep.org/x/hep/rootio/basket.go
>  1.17s  8.99% 50.81%  2.01s 15.45%  
> go-hep.org/x/hep/rootio.(*tbranch).loadBasket 
> /home/binet/dev/go/gocode/src/go-hep.org/x/hep/rootio/branch.go
>  1.15s  8.84% 59.65%  7.15s 54.96%  
> go-hep.org/x/hep/rootio.(*tbranch).loadEntry 
> /home/binet/dev/go/gocode/src/go-hep.org/x/hep/rootio/branch.go
>  0.82s  6.30% 65.95%  3.06s 23.52%  
> go-hep.org/x/hep/rootio.(*tbranch).scan /home/binet/dev/go/gocode/src/
> go-hep.org/x/hep/rootio/branch.go
>  0.76s  5.84% 71.79%  3.90s 29.98%  
> go-hep.org/x/hep/rootio.(*Basket).readLeaf /home/binet/dev/go/gocode/src/
> go-hep.org/x/hep/rootio/basket.go
>  0.62s  4.77% 76.56%  1.55s 11.91%  
> go-hep.org/x/hep/rootio.(*LeafD).scan /home/binet/dev/go/gocode/src/
> 

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

[Jay Sharma]

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 unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4e960e3d-e543-4735-a9ba-de23387dff16%40googlegroups.com.

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

[t hepudds]

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' such as 'go get 
-b', where '-b' might be for 'binary' or 'bare' and would just install a 
binary without updating the current go.mod.  A less likely outcome might be 
re-purposing 'go install' to do the same thing.

That issue could be a good place to comment if you have a specific idea, 
etc.

Regards,
thepudds

On Thursday, September 5, 2019 at 10:02:31 PM UTC-4, kortschak wrote:
>
> I also. 
>
> We have to add additional mess to our build scripts when we get testing 
> dependencies that are not part of our distribution to avoid 
> contaminating the go.{mod,sum} in the repo root. 
>
> This has repeatedly been a source of irritation and frustration. 
>
> Dan 
>
> On Thu, 2019-09-05 at 11:36 -0700, Michael Ellis wrote: 
> > I second Jan's request for light-shedding.  It's one thing to add 
> > real 
> > indirect dependencies. I can sort of understand that.  Can't think of 
> > a 
> > sensible reason for adding dependencies that are unrelated to the 
> > code in 
> > the module. 
> > 
> > On Thursday, September 5, 2019 at 2:23:11 PM UTC-4, Jan Mercl wrote: 
> > > 
> > > On Thu, Sep 5, 2019 at 8:18 PM > 
> > > wrote: 
> > > 
> > > > Running 'go get ...' inside a module can add indirect 
> > > > dependencies to 
> > > 
> > > go.mod. 
> > > 
> > > I'm surprised. There's probably some rationale behind `go get` 
> > > having 
> > > such side effects. Can anyone please shed some light on this? 
> > > 
> > 
> > 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b3f9ba20-563f-412f-b1a6-2e950a4033fa%40googlegroups.com.

Re: [go-nuts] About build Go Archive

[Jack Wang]

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 Lance Taylor写道：
>
> On Wed, Aug 28, 2019 at 5:53 AM > wrote: 
> > 
> > As we know, Go 1.13 will drop support for binary-only packages. it seems 
> we have to use buildmode=plugin/archive if we want to build go archive to 
> provide to others. 
> > 
> > when I try go buildmode=archive or buildmode=shared(go 1.12, go module 
> project), it throw error like cannot use packages ... from different roots, 
> i want to ask if i do something wrong, or it can't support well with 1.12? 
>
> Using -buildmode=archive or -buildmode=shared isn't a way to step 
> around the restrictions on binary packages.  Now that support for 
> binary packages has been removed, the "go build" process inherently 
> expects to be able to see the source code of a package. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2527561f-96ea-41f0-bf4c-18b409250cec%40googlegroups.com.

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

[William Ivory]

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 
code.  As the plugins use an override to build (dh-golang doesn't allow for 
buildmode=plugin), this caused the paths for the exact same shared code to 
appear to be different, and the plugins wouldn't load.

I'd be interested if anyone can explain why the default Go behaviour is not 
to trim paths back to the root of GOPATH, given the problems this can cause 
with plugins.  To my mind, the current hashing algorithm used to check 
plugins have been built with the same version as the caller of the plugin 
is actually wrong, as it rejects plugins built with the same code as the 
caller of the plugin.  Using trimpath / all flags is a workaround, but no 
more than that.

Regards,

William

On Thursday, 5 September 2019 17:48:01 UTC+1, William Ivory wrote:
>
> Hi,
>
> I've been using Go plugins with Go1.10, and after initial problems getting 
> our build system to build using identical paths to avoid the dreaded 
> 'plugin was built with a different version of package' error, it all 
> settled down and was working well for 6 months or so.  We're now trying to 
> switch to Go1.11, and the exact same code and Debian build rules now 
> consistently produces the 'different version' error.  Is anyone aware of 
> any changes between Go1.10 and Go1.11 that might explain this?
>
> Thanks,
>
> William
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5c8ab433-7ecc-42ec-8dc1-fe8a73528d1c%40googlegroups.com.