Re: [go-nuts] libgo is more fast that grouting.
I think the team of go programming language should invite other people that out of google join some part of the project. And you all can have more free time. Sometimes Lazy is good habit. It’s 10+ years, go should not be a research project now. How Many 10 years do you have? Like what is the binary package file of go? c/c++ have dll/so file, java has jar file, even php has a phar file. Guess what this project will happen when you all leave google? Only projects like PHP and Python and Java are real open source community driven project. They are all not belong to any company. > On Mar 19, 2020, at 00:00, Ian Lance Taylor wrote: > > On Tue, Mar 17, 2020 at 11:12 PM 'Benjamin' via golang-nuts > wrote: >> >> Benchmark shows that lingo is faster than goroutine. >> >> Many china internet companies use similar c++ libraries to support trillions >> of concurrency. >> Like Tencent use a smiler project libco: >> https://github.com/Tencent/libco >> >> I think the go team should learn some idea from these projects. >> NOT invent new thing is not necessary, its waste of time. Not all developers >> have 10+ years time to wait a new programming language become maturity . > > Go is an open source project. I encourage you, and anyone who is > interested, to investigate these libraries to understand why they are > faster, and what Go can do to speed up. The more people work on Go, > the less time everyone will have to wait for better performance. > Thanks. > > 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/70EE3DB8-EE16-4A70-B72E-D01E48EF4C82%40icloud.com.
Re: [go-nuts] How to clean cache for 'go tool dist test'
On Thu, Mar 19, 2020 at 10:28 PM Xiangdong JI wrote: > > I'm trying to run 'go tool dist test' after the binary has been built > successfully, while always get a cached result, > running "go clean -i -r -testcache " and "go clean -cache" in prior > doesn't help, can anyone please help here? > Thanks. > > $ go tool dist test -run=go_test:crypto/ > > # go tool dist test -run=^go_test:crypto/aes$ > ok crypto/aes (cached) > ok crypto/cipher (cached) > ok crypto/des (cached) > ok crypto/dsa (cached) > ok crypto/ecdsa(cached) > ok crypto/ed25519 (cached) > ok crypto/elliptic (cached) > ok crypto/hmac (cached) > ok crypto/internal/subtle (cached) > ok crypto/md5 (cached) > ok crypto/rand (cached) > ok crypto/rc4 (cached) > ok crypto/rsa (cached) > ok crypto/sha1 (cached) > ok crypto/sha256 (cached) > ok crypto/sha512 (cached) > ok crypto/subtle (cached) > ok crypto/tls (cached) > ok crypto/x509 (cached) Why are you running `go tool dist test` and not just `go test`? Do you have GOARCH or GOOS set? 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/CAOyqgcU0VeHO%2BdOCJO2zmb6hZ3ZWf3WovOscOXarEG5jPELPmg%40mail.gmail.com.
Re: [go-nuts] dynamic number of arguments
Thank you for the advice! It worked.
On Friday, March 20, 2020 at 11:29:20 AM UTC+11, Ian Lance Taylor wrote:
>
> On Thu, Mar 19, 2020 at 5:21 PM >
> wrote:
> >
> > I have an array and the length of this array is dynamic. I want to pass
> this array's values as a list of parameters to a function. Can you please
> suggest what is a good way to do this?
> >
> >
> > For example, func(query string, args ...interface{}). My array is
> arrayExample := []string {"1", "a", "b", "2"}. Then it will be something
> like func(query, arrayExample[0], arrayExample[1], arrayExample[2],
> arrayExample[3]).
> >
> > If my array is arrayExample := []string {"1", "a"}. Then it will be
> something like func(query, arrayExample[0], arrayExample[1])
> >
> > But as I mentioned the array is dynamic so the length can be any number.
> I can get the length, but how can I pass each member in the array to the
> function call as a list of parameters?
>
> Note that what you are calling an array, Go calls a slice.
>
> Write this as `f(query, arrayExample...)`. See
> https://golang.org/ref/spec#Passing_arguments_to_..._parameters .
>
> 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/9ae48a29-afc7-4a9f-bb31-d8357c4b8ad8%40googlegroups.com.
[go-nuts] How to clean cache for 'go tool dist test'
Hi, I'm trying to run 'go tool dist test' after the binary has been built successfully, while always get a cached result, running "go clean -i -r -testcache " and "go clean -cache" in prior doesn't help, can anyone please help here? Thanks. $ go tool dist test -run=go_test:crypto/ # go tool dist test -run=^go_test:crypto/aes$ ok crypto/aes (cached) ok crypto/cipher (cached) ok crypto/des (cached) ok crypto/dsa (cached) ok crypto/ecdsa(cached) ok crypto/ed25519 (cached) ok crypto/elliptic (cached) ok crypto/hmac (cached) ok crypto/internal/subtle (cached) ok crypto/md5 (cached) ok crypto/rand (cached) ok crypto/rc4 (cached) ok crypto/rsa (cached) ok crypto/sha1 (cached) ok crypto/sha256 (cached) ok crypto/sha512 (cached) ok crypto/subtle (cached) ok crypto/tls (cached) ok crypto/x509 (cached) -- 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/6a04b76e-27e1-43bc-87af-06bd4a966216%40googlegroups.com.
Re: [go-nuts] dynamic number of arguments
On Thu, Mar 19, 2020 at 5:21 PM wrote:
>
> I have an array and the length of this array is dynamic. I want to pass this
> array's values as a list of parameters to a function. Can you please suggest
> what is a good way to do this?
>
>
> For example, func(query string, args ...interface{}). My array is
> arrayExample := []string {"1", "a", "b", "2"}. Then it will be something like
> func(query, arrayExample[0], arrayExample[1], arrayExample[2],
> arrayExample[3]).
>
> If my array is arrayExample := []string {"1", "a"}. Then it will be
> something like func(query, arrayExample[0], arrayExample[1])
>
> But as I mentioned the array is dynamic so the length can be any number. I
> can get the length, but how can I pass each member in the array to the
> function call as a list of parameters?
Note that what you are calling an array, Go calls a slice.
Write this as `f(query, arrayExample...)`. See
https://golang.org/ref/spec#Passing_arguments_to_..._parameters .
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/CAOyqgcXdmJNjkXLS1pW%2BzOnGyH%3Dg_LUo5ut1keN%3DiMDsxLw4MA%40mail.gmail.com.
[go-nuts] dynamic number of arguments
Hi,
I have an array and the length of this array is dynamic. I want to pass
this array's values as a list of parameters to a function. Can you please
suggest what is a good way to do this?
For example, func(query string, args ...interface{}). My array is
arrayExample := []string {"1", "a", "b", "2"}. Then it will be something
like func(query, arrayExample[0], arrayExample[1], arrayExample[2],
arrayExample[3]).
If my array is arrayExample := []string {"1", "a"}. Then it will be
something like func(query, arrayExample[0], arrayExample[1])
But as I mentioned the array is dynamic so the length can be any number. I
can get the length, but how can I pass each member in the array to the
function call as a list of parameters?
Thanks a lot!
Regards,
--
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/f6731237-4b66-47ce-ab8c-611a93be942b%40googlegroups.com.
Re: [go-nuts] Re: Go 1.14.1 and Go 1.13.9 are released
The problem is that I have seen using golang in the wrong context, as an example: https://www.gophercon.co.uk/videos/2017/golangs-realtime-gc-in-theory-and-practice/ https://www.gophercon.co.uk/videos/2019/Experimenting-with-Golang-and-Webassembly/ I suspect that new programmers starting to use Go believe that the language name is golang, probably because nobody bothered to correct them. Thanks. On Thursday, March 19, 2020 at 10:25:02 PM UTC+1, Dmitri Shuralyov wrote: > > To add to what Ian said, I've edited the issue titles now, which makes > them slightly shorter and easier to read. > > Also see https://golang.org/doc/faq#go_or_golang. While the language is > called "Go", the term "golang" still comes up occasionally in some contexts. > > > On Thursday, March 19, 2020 at 5:12:41 PM UTC-4, Ian Lance Taylor wrote: >> >> On Thu, Mar 19, 2020 at 1:58 PM Manlio Perillo > > wrote: >> > >> > Thanks for the release. >> > >> > However I'm a bit sad that even the Go team is starting to use "golang" >> instead of "go": >> > https://github.com/golang/go/issues/37613 >> > golang 1.14.rc1 3-5% performance regression from golang 1.13 during >> protobuf marshalling >> >> Don't worry, we aren't. That issue was created by gopherbot, and the >> title came from https://golang.org/issue/37086, which was not written >> by a member of the Go team. All we've done here is not edit the issue >> title (which we could have done but I guess nobody bothered). >> >> Ian >> >> >> >> > Now I see golang instead of go on blog articles, talks and commit >> messages. >> > >> > Manlio >> > >> > On Thursday, March 19, 2020 at 9:48:28 PM UTC+1, Carlos Amedee wrote: >> >> >> >> Hello gophers, >> >> >> >> We have just released Go versions 1.14.1 and 1.13.9, minor point >> releases. >> >> >> >> These releases include fixes to the go command, tools, the runtime, >> >> the toolchain, and to the crypto/cypher package. >> >> >> >> View the release notes for more information: >> >> https://golang.org/doc/devel/release.html#go1.14.minor >> >> >> >> You can download binary and source distributions from the Go web site: >> >> https://golang.org/dl/ >> >> >> >> To compile from source using a Git clone, update to the release with >> >> "git checkout go1.14.1" and build as usual. >> >> >> >> Thanks to everyone who contributed to the release. >> >> >> >> Cheers, >> >> Carlos and Alex for the Go team >> > >> > -- >> > 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 golan...@googlegroups.com . >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/e541681f-df37-4181-bf4f-52b2d6193c60%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/9c8bf799-0046-4f91-9966-3735786c2708%40googlegroups.com.
Re: [go-nuts] Re: Go 1.14.1 and Go 1.13.9 are released
To add to what Ian said, I've edited the issue titles now, which makes them slightly shorter and easier to read. Also see https://golang.org/doc/faq#go_or_golang. While the language is called "Go", the term "golang" still comes up occasionally in some contexts. On Thursday, March 19, 2020 at 5:12:41 PM UTC-4, Ian Lance Taylor wrote: > > On Thu, Mar 19, 2020 at 1:58 PM Manlio Perillo > wrote: > > > > Thanks for the release. > > > > However I'm a bit sad that even the Go team is starting to use "golang" > instead of "go": > > https://github.com/golang/go/issues/37613 > > golang 1.14.rc1 3-5% performance regression from golang 1.13 during > protobuf marshalling > > Don't worry, we aren't. That issue was created by gopherbot, and the > title came from https://golang.org/issue/37086, which was not written > by a member of the Go team. All we've done here is not edit the issue > title (which we could have done but I guess nobody bothered). > > Ian > > > > > Now I see golang instead of go on blog articles, talks and commit > messages. > > > > Manlio > > > > On Thursday, March 19, 2020 at 9:48:28 PM UTC+1, Carlos Amedee wrote: > >> > >> Hello gophers, > >> > >> We have just released Go versions 1.14.1 and 1.13.9, minor point > releases. > >> > >> These releases include fixes to the go command, tools, the runtime, > >> the toolchain, and to the crypto/cypher package. > >> > >> View the release notes for more information: > >> https://golang.org/doc/devel/release.html#go1.14.minor > >> > >> You can download binary and source distributions from the Go web site: > >> https://golang.org/dl/ > >> > >> To compile from source using a Git clone, update to the release with > >> "git checkout go1.14.1" and build as usual. > >> > >> Thanks to everyone who contributed to the release. > >> > >> Cheers, > >> Carlos and Alex for the Go team > > > > -- > > 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/e541681f-df37-4181-bf4f-52b2d6193c60%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/c0d3c3bc-84a5-41b9-93e4-0752e54543e5%40googlegroups.com.
Re: [go-nuts] Re: Go 1.14.1 and Go 1.13.9 are released
On Thu, Mar 19, 2020 at 1:58 PM Manlio Perillo wrote: > > Thanks for the release. > > However I'm a bit sad that even the Go team is starting to use "golang" > instead of "go": > https://github.com/golang/go/issues/37613 > golang 1.14.rc1 3-5% performance regression from golang 1.13 during protobuf > marshalling Don't worry, we aren't. That issue was created by gopherbot, and the title came from https://golang.org/issue/37086, which was not written by a member of the Go team. All we've done here is not edit the issue title (which we could have done but I guess nobody bothered). Ian > Now I see golang instead of go on blog articles, talks and commit messages. > > Manlio > > On Thursday, March 19, 2020 at 9:48:28 PM UTC+1, Carlos Amedee wrote: >> >> Hello gophers, >> >> We have just released Go versions 1.14.1 and 1.13.9, minor point releases. >> >> These releases include fixes to the go command, tools, the runtime, >> the toolchain, and to the crypto/cypher package. >> >> View the release notes for more information: >> https://golang.org/doc/devel/release.html#go1.14.minor >> >> You can download binary and source distributions from the Go web site: >> https://golang.org/dl/ >> >> To compile from source using a Git clone, update to the release with >> "git checkout go1.14.1" and build as usual. >> >> Thanks to everyone who contributed to the release. >> >> Cheers, >> Carlos and Alex for the Go team > > -- > 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/e541681f-df37-4181-bf4f-52b2d6193c60%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/CAOyqgcXbOeLQo_5ORyafk3-1qtUCFc2%3D-0WhHtEKonV4nXi64A%40mail.gmail.com.
[go-nuts] Re: Go 1.14.1 and Go 1.13.9 are released
Thanks for the release. However I'm a bit sad that even the Go team is starting to use "golang" instead of "go": https://github.com/golang/go/issues/37613 golang 1.14.rc1 3-5% performance regression from golang 1.13 during protobuf marshalling Now I see golang instead of go on blog articles, talks and commit messages. Manlio On Thursday, March 19, 2020 at 9:48:28 PM UTC+1, Carlos Amedee wrote: > > Hello gophers, > > We have just released Go versions 1.14.1 and 1.13.9, minor point releases. > > These releases include fixes to the go command, tools, the runtime, > the toolchain, and to the crypto/cypher package. > > View the release notes for more information: > https://golang.org/doc/devel/release.html#go1.14.minor > > You can download binary and source distributions from the Go web site: > https://golang.org/dl/ > > To compile from source using a Git clone, update to the release with > "git checkout go1.14.1" and build as usual. > > Thanks to everyone who contributed to the release. > > Cheers, > Carlos and Alex for the Go team > -- 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/e541681f-df37-4181-bf4f-52b2d6193c60%40googlegroups.com.
[go-nuts] Go 1.14.1 and Go 1.13.9 are released
Hello gophers, We have just released Go versions 1.14.1 and 1.13.9, minor point releases. These releases include fixes to the go command, tools, the runtime, the toolchain, and to the crypto/cypher package. View the release notes for more information: https://golang.org/doc/devel/release.html#go1.14.minor You can download binary and source distributions from the Go web site: https://golang.org/dl/ To compile from source using a Git clone, update to the release with "git checkout go1.14.1" and build as usual. Thanks to everyone who contributed to the release. Cheers, Carlos and Alex for the Go team -- 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/CAD7Aq3TOQ%3DisqF-U3yjZkJiJc3svwgEeCFq8rY7PLszq3odV2w%40mail.gmail.com.
Re: [go-nuts] go build output depending on project structure
It might help to read https://golang.org/cmd/go/#hdr-Package_lists_and_patterns, including the paragraph starting "As a special case, if the package list is a list of .go files from a single directory," Ian On Thu, Mar 19, 2020 at 8:59 AM Jake Montgomery wrote: > > > > On Thursday, March 19, 2020 at 10:21:31 AM UTC-4, Nitish Saboo wrote: >> >> Hi Jake, >> >> Is there some reason that you want, or need, to be using go build this way, >> by specifying files? Or is it just curiosity about how the tools work? >> >>There is no particular reason to use go build by specifying the files. I >> >>was trying different ways to compile the project and ended up with this >> >>scenario. >> I am curious to know the reason for this. >> >> The typical way to use go build is to build without specifying individual >> files. If you are using CGO, I would certainly recommend that you do it by >> building as a package, just to keep things simple. Not that CGO is ever >> simple. >> >> I will try compiling the package without specifying the individual files. > > > Right, as I said, this is the standard way. You should always build the > package this way, unless you have a specific use case that requires compiling > a single file. > >> But the following case works all fine whether we pass the individual file or >> not.: > > > The reason that works is because the package you are building only contains > one file, 'main.go'. The other files are actually in different packages, so > they are pulled in by import. So `go build -v - x` builds the package > `nitish`, which only contains one file, `main.go`. Since the package name is > `nitish` you get an executable named `nitish`. `go build -v - x main.go` is a > special use of the tool. I mostly use it for quick code tests, when the > playground will not suffice, or for using go to write quick scripts. It will > not build the package `nitish`, instead it will build only the single file, > and produce an executable named after the file, in this case `main.exe`. > Since the `nitish` package only contains one file, the result is otherwise > the same (AFAIK). > > Hope this has some useful information. >> >> >> Case 1 >> -- >> >> I have a project called 'nitish' where the folder structure looks like the >> following: >> >> nitish >>main.go >>util >> util.go >>lib >> node.c >> node.h >> a.go >> >> When I try compiling this project in the following ways: >> >> 1) go build -v - x >> >> >> This creates a binary called 'nitish' >> >> 2) go build -v - x main.go >> >> >> This creates a binary called 'main' >> >> ldd output of both the binaries is the same. >> >> Thanks, >> Nitish >> >> >> On Thu, Mar 19, 2020 at 7:18 PM Jake Montgomery wrote: >>> >>> Nitish, >>> >>> Is there some reason that you want, or need, to be using go build this way, >>> by specifying files? Or is it just curiosity about how the tools work? >>> The typical way to use go build is to build without specifying individual >>> files. If you are using CGO, I would certainly recommend that you do it by >>> building as a package, just to keep things simple. Not that CGO is ever >>> simple. >>> >>> >>> On Wednesday, March 18, 2020 at 10:27:19 AM UTC-4, Nitish Saboo wrote: Hi Gregor, Do you mean like this 'go build -v -x main.go node.c' ? But it does not compile and gives the following output: WORK=/tmp/go-build714119815 named files must be .go files Thanks, Nitish On Wed, Mar 18, 2020 at 7:44 PM Gregor Best wrote: > > Hi, > > it looks like my initial reply wasn't entirely correct. It should build > if you pass in both the `.go` file and the `.c` file. > > On 18.03.20 15:02, Nitish Saboo wrote: > > Hi Gregor, > > nitish >main.go >node.c >node.h > > I compiled using 'go build -v -x main.go' > But if my cgo directive is defined in main.go, this should have compiled > successfully..right? But it fails with the following whereas 'go build -v > -x' works fine. > > /tmp/go-build439591561/b001/_x002.o: In function > `_cgo_5637ad3d75e4_Cfunc_load_pattern_db': > /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' > collect2: error: ld returned 1 exit status > > package main > > //#include > //#include "node.h" > import "C" > import ( > "fmt" > _ "fmt" > "os" > "path" > "unsafe" > ) > > Please let me know what am I missing here? > > Thanks, > Nitish > > On Wed, Mar 18, 2020 at 7:20 PM Nitish Saboo wrote: >> >> Hi Gregor, >> >> Got your point.Thank you for your response. >> That explains why the binaries have different names post compilation. >> >> Thanks, >> Nitish >> >> >> On Wed, Mar 18, 2020 at
Re: [go-nuts] Benchmarking code that mutates its input data
On Wednesday, 18 March 2020 15:50:33 UTC, Sam Whited wrote: > > Just call b.ResetTimer() after setting up your data: > https://godoc.org/testing#B.ResetTimer > Thanks, I'll take a look -- 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/8245d0ae-9fd2-4022-a0c0-109f3fea76c7%40googlegroups.com.
Re: [go-nuts] Benchmarking code that mutates its input data
On Wednesday, 18 March 2020 17:53:05 UTC, Robert Engels wrote: > > The test package has methods to disable the timing - wrap the setup in > these. > Thanks. I guess you're referring to StoptTimer, StartTimer and ResetTimer? I think that in my case ResetTimer will do the trick. Unless I'm mistaken StartTimer and StopTimer are useful in more complex scenarios. -- 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/31cce81a-ca4c-4f7b-bb35-6b1fde3c093e%40googlegroups.com.
Re: [go-nuts] Benchmarking code that mutates its input data
On Wednesday, 18 March 2020 15:50:33 UTC, Sam Whited wrote: > > Just call b.ResetTimer() after setting up your data: > https://godoc.org/testing#B.ResetTimer > > Thanks, I'll take a look -- 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/3c492bd7-389a-4cf4-9221-1f4779c91221%40googlegroups.com.
Re: [go-nuts] go build output depending on project structure
On Thursday, March 19, 2020 at 10:21:31 AM UTC-4, Nitish Saboo wrote: > > Hi Jake, > > Is there some reason that you want, or need, to be using go build this > way, by specifying files? Or is it just curiosity about how the tools work? > >>There is no particular reason to use go build by specifying the files. I > was trying different ways to compile the project and ended up with this > scenario. > I am curious to know the reason for this. > > The typical way to use go build is to build without specifying individual > files. If you are using CGO, I would certainly recommend that you do it by > building as a package, just to keep things simple. Not that CGO is ever > simple. > >> I will try compiling the package without specifying the individual > files. > Right, as I said, this is the standard way. You should always build the package this way, unless you have a specific use case that requires compiling a single file. But the following case works all fine whether we pass the individual file > or not.: > The reason that works is because the package you are building only contains one file, 'main.go'. The other files are actually in different packages, so they are pulled in by import. So `go build -v - x` builds the package `nitish`, which only contains one file, `main.go`. Since the package name is `nitish` you get an executable named `nitish`. `go build -v - x main.go` is a special use of the tool. I mostly use it for quick code tests, when the playground will not suffice, or for using go to write quick scripts. It will not build the package `nitish`, instead it will build only the single file, and produce an executable named after the file, in this case `main.exe`. Since the `nitish` package only contains one file, the result is otherwise the same (AFAIK). Hope this has some useful information. > > > > *Case 1--* > I have a project called 'nitish' where the folder structure looks like the > following: > > nitish >main.go >util > util.go >lib > node.c > node.h > a.go > > When I try compiling this project in the following ways: > > 1) go build -v - x > > >> This creates a binary called 'nitish' > > 2) go build -v - x main.go > > >> This creates a binary called 'main' > > ldd output of both the binaries is the same. > > Thanks, > Nitish > > > On Thu, Mar 19, 2020 at 7:18 PM Jake Montgomery > wrote: > >> Nitish, >> >> Is there some reason that you want, or need, to be using go build this >> way, by specifying files? Or is it just curiosity about how the tools work? >> The typical way to use go build is to build without specifying individual >> files. If you are using CGO, I would certainly recommend that you do it by >> building as a package, just to keep things simple. Not that CGO is ever >> simple. >> >> >> On Wednesday, March 18, 2020 at 10:27:19 AM UTC-4, Nitish Saboo wrote: >>> >>> Hi Gregor, >>> >>> Do you mean like this 'go build -v -x main.go node.c' ? But it does not >>> compile and gives the following output: >>> >>> WORK=/tmp/go-build714119815 >>> named files must be .go files >>> >>> Thanks, >>> Nitish >>> >>> On Wed, Mar 18, 2020 at 7:44 PM Gregor Best >>> wrote: >>> Hi, it looks like my initial reply wasn't entirely correct. It should build if you pass in both the `.go` file and the `.c` file. On 18.03.20 15:02, Nitish Saboo wrote: Hi Gregor, nitish main.go node.c node.h I compiled using 'go build -v -x main.go' But if my cgo directive is defined in main.go, this should have compiled successfully..right? But it fails with the following whereas 'go build -v -x' works fine. /tmp/go-build439591561/b001/_x002.o: In function `_cgo_5637ad3d75e4_Cfunc_load_pattern_db': /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' collect2: error: ld returned 1 exit status package main //#include //#include "node.h" import "C" import ( "fmt" _ "fmt" "os" "path" "unsafe" ) Please let me know what am I missing here? Thanks, Nitish On Wed, Mar 18, 2020 at 7:20 PM Nitish Saboo wrote: > Hi Gregor, > > Got your point.Thank you for your response. > That explains why the binaries have different names post compilation. > > Thanks, > Nitish > > > On Wed, Mar 18, 2020 at 7:06 PM Gregor Best > wrote: > >> Hi, >> >> In both `go build main.go`-examples, you tell the compiler to _only_ >> build `main.go`. >> >> In your first example, `main.go` probably imports both `util` and >> `lib` (you might want to give them less generic names by the way). The >> go >> compiler thus knows "to build `main.go`, I need to build both `util` and >> `lib`
[go-nuts] Gophercon 2020 Postponed
We're postponing Gophercon 2020 (originally scheduled for June in Orlando). Details in this post on the GopherAcademy blog: https://blog.gopheracademy.com/gophercon-2020-news/ TL;DR: We don't have a new date yet, but expect to announce one the first week of April. Stay safe, Go friends! Brian Ketelsen & Erik St. Martin Your Gophercon Hosts -- 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/f553c9d8-18a6-4192-841e-6229dcfe5c51%40googlegroups.com.
Re: [go-nuts] Re: Mem-Leak in Go method
And
https://blog.golang.org/pprof
> On Mar 19, 2020, at 9:27 AM, Robert Engels wrote:
>
>
> https://www.freecodecamp.org/news/how-i-investigated-memory-leaks-in-go-using-pprof-on-a-large-codebase-4bec4325e192/amp/
>
>>> On Mar 19, 2020, at 9:24 AM, Nitish Saboo wrote:
>>>
>>
>> Hi,
>>
>> Are there any other commands that provide an exact allocation of memory for
>> each of the functions or help to analyze the memory allocation much better?
>>
>> Thanks,
>> Nitish
>>
>>> On Thu, Mar 19, 2020 at 7:08 PM Robert Engels wrote:
>>> You are only using 1.5 mb on the Go side... so if your process is consuming
>>> lots of memory it’s on the C side.
>>>
> On Mar 19, 2020, at 7:55 AM, Nitish Saboo
> wrote:
>
Hi Michael,
I used something like this to generate a mem-prof for 60 minutes
func main() {
flag.Parse()
if *cpuprofile != "" {
f, err := os.Create(*cpuprofile)
if err != nil {
fmt.Println("could not create CPU profile: ", err)
}
defer f.Close() // error handling omitted for example
if err := pprof.StartCPUProfile(f); err != nil {
fmt.Print("could not start CPU profile: ", err)
}
defer pprof.StopCPUProfile()
}
timeout := time.After(60 * time.Minute)
A_chan := make(chan bool)
B_chan := make(chan bool)
go util.A(A_chan)
go util.B(B_chan)
(..Rest of the code..)
for {
select {
case <-A_chan:
continue
case <-B_chan:
continue
case <-timeout:
break
}
break
}
if *memprofile != "" {
count = count + 1
fmt.Println("Generating Mem Profile:")
fmt.Print(count)
f, err := os.Create(*memprofile)
if err != nil {
fmt.Println("could not create memory profile: ", err)
}
defer f.Close() // error handling omitted for example
runtime.GC()// get up-to-date statistics
if err := pprof.WriteHeapProfile(f); err != nil {
fmt.Println("could not write memory profile: ", err)
}
}
}
I got the following output from the mem.prof:
~/Desktop/memprof:go tool pprof mem.prof
File: main
Build ID: 331d79200cabd2a81713918e51b8c9a63e3f7d29
Type: inuse_space
Time: Mar 19, 2020 at 3:57pm (IST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top 14
Showing nodes accounting for 1581.40kB, 100% of 1581.40kB total
flat flat% sum%cum cum%
1024.14kB 64.76% 64.76% 1024.14kB 64.76%
github.com/aws/aws-sdk-go/aws/endpoints.init.ializers
557.26kB 35.24% 100% 557.26kB 35.24% crypto/elliptic.initTable
0 0% 100% 557.26kB 35.24%
crypto/elliptic.(*p256Point).p256BaseMult
0 0% 100% 557.26kB 35.24% crypto/elliptic.GenerateKey
0 0% 100% 557.26kB 35.24%
crypto/elliptic.p256Curve.ScalarBaseMult
0 0% 100% 557.26kB 35.24% crypto/tls.(*Conn).Handshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*Conn).clientHandshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*clientHandshakeState).doFullHandshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*clientHandshakeState).handshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*ecdheKeyAgreement).processServerKeyExchange
0 0% 100% 557.26kB 35.24%
crypto/tls.generateECDHEParameters
0 0% 100% 557.26kB 35.24%
net/http.(*persistConn).addTLS.func2
0 0% 100% 1024.14kB 64.76% runtime.main
0 0% 100% 557.26kB 35.24% sync.(*Once).Do
(pprof)
Can you please share some commands or any link which I can refer to to
analyze the data?
Thanks,
Nitish
> On Fri, Mar 13, 2020 at 6:22 PM Michael Jones
> wrote:
> hi. get the time at the start, check the elapsed time in your infinite
> loop, and trigger the write/exit after a minute, 10 minutes, 100 minutes,
> ...
>
>> On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
>> wrote:
>> Hi Michael,
>>
>> Thanks for your response.
>>
>> That code looks wrong. I see the end but not the start. Look here and
>> copy carefully:
>>
>> >>Since I did not want cpu profiling I omitted the start of the code and
>> >>just added memory profiling part.
>>
>> Call at end, on way out.
>>
>> >>Oh yes, I missed that.I have to call memory profiling code at the end
>> >>on the way out.But the thing is that it runs as a service in infinite
>> >>for loop.
>>
>> func main() {
>> flag.Parse()
>> if *cpuprofile != "" {
>> f, err := os.Create(*cpuprofile)
>> if err != nil {
>> fmt.Println("could not create CPU profile: ", err)
Re: [go-nuts] Re: Mem-Leak in Go method
https://www.freecodecamp.org/news/how-i-investigated-memory-leaks-in-go-using-pprof-on-a-large-codebase-4bec4325e192/amp/
> On Mar 19, 2020, at 9:24 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> Are there any other commands that provide an exact allocation of memory for
> each of the functions or help to analyze the memory allocation much better?
>
> Thanks,
> Nitish
>
>> On Thu, Mar 19, 2020 at 7:08 PM Robert Engels wrote:
>> You are only using 1.5 mb on the Go side... so if your process is consuming
>> lots of memory it’s on the C side.
>>
On Mar 19, 2020, at 7:55 AM, Nitish Saboo wrote:
>>>
>>> Hi Michael,
>>>
>>> I used something like this to generate a mem-prof for 60 minutes
>>>
>>> func main() {
>>> flag.Parse()
>>> if *cpuprofile != "" {
>>> f, err := os.Create(*cpuprofile)
>>> if err != nil {
>>> fmt.Println("could not create CPU profile: ", err)
>>> }
>>> defer f.Close() // error handling omitted for example
>>> if err := pprof.StartCPUProfile(f); err != nil {
>>> fmt.Print("could not start CPU profile: ", err)
>>> }
>>> defer pprof.StopCPUProfile()
>>> }
>>> timeout := time.After(60 * time.Minute)
>>> A_chan := make(chan bool)
>>> B_chan := make(chan bool)
>>> go util.A(A_chan)
>>> go util.B(B_chan)
>>> (..Rest of the code..)
>>>
>>> for {
>>> select {
>>> case <-A_chan:
>>> continue
>>> case <-B_chan:
>>> continue
>>> case <-timeout:
>>> break
>>> }
>>> break
>>> }
>>>
>>> if *memprofile != "" {
>>> count = count + 1
>>> fmt.Println("Generating Mem Profile:")
>>> fmt.Print(count)
>>> f, err := os.Create(*memprofile)
>>> if err != nil {
>>> fmt.Println("could not create memory profile: ", err)
>>> }
>>> defer f.Close() // error handling omitted for example
>>> runtime.GC()// get up-to-date statistics
>>> if err := pprof.WriteHeapProfile(f); err != nil {
>>> fmt.Println("could not write memory profile: ", err)
>>> }
>>>
>>> }
>>> }
>>>
>>> I got the following output from the mem.prof:
>>>
>>> ~/Desktop/memprof:go tool pprof mem.prof
>>> File: main
>>> Build ID: 331d79200cabd2a81713918e51b8c9a63e3f7d29
>>> Type: inuse_space
>>> Time: Mar 19, 2020 at 3:57pm (IST)
>>> Entering interactive mode (type "help" for commands, "o" for options)
>>> (pprof) top 14
>>> Showing nodes accounting for 1581.40kB, 100% of 1581.40kB total
>>> flat flat% sum%cum cum%
>>> 1024.14kB 64.76% 64.76% 1024.14kB 64.76%
>>> github.com/aws/aws-sdk-go/aws/endpoints.init.ializers
>>> 557.26kB 35.24% 100% 557.26kB 35.24% crypto/elliptic.initTable
>>> 0 0% 100% 557.26kB 35.24%
>>> crypto/elliptic.(*p256Point).p256BaseMult
>>> 0 0% 100% 557.26kB 35.24% crypto/elliptic.GenerateKey
>>> 0 0% 100% 557.26kB 35.24%
>>> crypto/elliptic.p256Curve.ScalarBaseMult
>>> 0 0% 100% 557.26kB 35.24% crypto/tls.(*Conn).Handshake
>>> 0 0% 100% 557.26kB 35.24%
>>> crypto/tls.(*Conn).clientHandshake
>>> 0 0% 100% 557.26kB 35.24%
>>> crypto/tls.(*clientHandshakeState).doFullHandshake
>>> 0 0% 100% 557.26kB 35.24%
>>> crypto/tls.(*clientHandshakeState).handshake
>>> 0 0% 100% 557.26kB 35.24%
>>> crypto/tls.(*ecdheKeyAgreement).processServerKeyExchange
>>> 0 0% 100% 557.26kB 35.24%
>>> crypto/tls.generateECDHEParameters
>>> 0 0% 100% 557.26kB 35.24%
>>> net/http.(*persistConn).addTLS.func2
>>> 0 0% 100% 1024.14kB 64.76% runtime.main
>>> 0 0% 100% 557.26kB 35.24% sync.(*Once).Do
>>>
>>> (pprof)
>>>
>>> Can you please share some commands or any link which I can refer to to
>>> analyze the data?
>>>
>>> Thanks,
>>> Nitish
>>>
>>>
>>>
On Fri, Mar 13, 2020 at 6:22 PM Michael Jones
wrote:
hi. get the time at the start, check the elapsed time in your infinite
loop, and trigger the write/exit after a minute, 10 minutes, 100 minutes,
...
> On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
> wrote:
> Hi Michael,
>
> Thanks for your response.
>
> That code looks wrong. I see the end but not the start. Look here and
> copy carefully:
>
> >>Since I did not want cpu profiling I omitted the start of the code and
> >>just added memory profiling part.
>
> Call at end, on way out.
>
> >>Oh yes, I missed that.I have to call memory profiling code at the end
> >>on the way out.But the thing is that it runs as a service in infinite
> >>for loop.
>
> func main() {
> flag.Parse()
> if *cpuprofile != "" {
> f, err := os.Create(*cpuprofile)
> if err != nil {
> fmt.Println("could not create CPU profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> if err := pprof.StartCPUProfile(f); err != nil {
> fmt.Print("could not start CPU profile: ", err)
> }
> defer pprof.StopCPUProfile()
> }
>
> A_chan :=
Re: [go-nuts] Re: Mem-Leak in Go method
Hi,
Are there any other commands that provide an exact allocation of memory for
each of the functions or help to analyze the memory allocation much better?
Thanks,
Nitish
On Thu, Mar 19, 2020 at 7:08 PM Robert Engels wrote:
> You are only using 1.5 mb on the Go side... so if your process is
> consuming lots of memory it’s on the C side.
>
> On Mar 19, 2020, at 7:55 AM, Nitish Saboo
> wrote:
>
>
> Hi Michael,
>
> I used something like this to generate a mem-prof for 60 minutes
>
> func main() {
> flag.Parse()
> if *cpuprofile != "" {
> f, err := os.Create(*cpuprofile)
> if err != nil {
> fmt.Println("could not create CPU profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> if err := pprof.StartCPUProfile(f); err != nil {
> fmt.Print("could not start CPU profile: ", err)
> }
> defer pprof.StopCPUProfile()
> }
> timeout := time.After(60 * time.Minute)
> A_chan := make(chan bool)
> B_chan := make(chan bool)
> go util.A(A_chan)
> go util.B(B_chan)
> (..Rest of the code..)
>
> for {
> select {
> case <-A_chan:
> continue
> case <-B_chan:
> continue
> case <-timeout:
> break
> }
> break
> }
>
> if *memprofile != "" {
> count = count + 1
> fmt.Println("Generating Mem Profile:")
> fmt.Print(count)
> f, err := os.Create(*memprofile)
> if err != nil {
> fmt.Println("could not create memory profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> runtime.GC()// get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> fmt.Println("could not write memory profile: ", err)
> }
>
> }
> }
>
> I got the following output from the mem.prof:
>
> ~/Desktop/memprof:go tool pprof mem.prof
> File: main
> Build ID: 331d79200cabd2a81713918e51b8c9a63e3f7d29
> Type: inuse_space
> Time: Mar 19, 2020 at 3:57pm (IST)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top 14
> Showing nodes accounting for 1581.40kB, 100% of 1581.40kB total
> flat flat% sum%cum cum%
> 1024.14kB 64.76% 64.76% 1024.14kB 64.76%
> github.com/aws/aws-sdk-go/aws/endpoints.init.ializers
> 557.26kB 35.24% 100% 557.26kB 35.24% crypto/elliptic.initTable
> 0 0% 100% 557.26kB 35.24%
> crypto/elliptic.(*p256Point).p256BaseMult
> 0 0% 100% 557.26kB 35.24% crypto/elliptic.GenerateKey
> 0 0% 100% 557.26kB 35.24%
> crypto/elliptic.p256Curve.ScalarBaseMult
> 0 0% 100% 557.26kB 35.24% crypto/tls.(*Conn).Handshake
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.(*Conn).clientHandshake
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.(*clientHandshakeState).doFullHandshake
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.(*clientHandshakeState).handshake
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.(*ecdheKeyAgreement).processServerKeyExchange
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.generateECDHEParameters
> 0 0% 100% 557.26kB 35.24%
> net/http.(*persistConn).addTLS.func2
> 0 0% 100% 1024.14kB 64.76% runtime.main
> 0 0% 100% 557.26kB 35.24% sync.(*Once).Do
>
> (pprof)
>
> Can you please share some commands or any link which I can refer to to
> analyze the data?
>
> Thanks,
> Nitish
>
>
>
> On Fri, Mar 13, 2020 at 6:22 PM Michael Jones
> wrote:
>
>> hi. get the time at the start, check the elapsed time in your infinite
>> loop, and trigger the write/exit after a minute, 10 minutes, 100 minutes,
>> ...
>>
>> On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
>> wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your response.
>>>
>>> That code looks wrong. I see the end but not the start. Look here and
>>> copy carefully:
>>>
>>> >>Since I did not want cpu profiling I omitted the start of the code and
>>> just added memory profiling part.
>>>
>>> Call at end, on way out.
>>>
>>> >>Oh yes, I missed that.I have to call memory profiling code at the end
>>> on the way out.But the thing is that it runs as a service in infinite for
>>> loop.
>>>
>>> func main() {
>>> flag.Parse()
>>> if *cpuprofile != "" {
>>> f, err := os.Create(*cpuprofile)
>>> if err != nil {
>>> fmt.Println("could not create CPU profile: ", err)
>>> }
>>> defer f.Close() // error handling omitted for example
>>> if err := pprof.StartCPUProfile(f); err != nil {
>>> fmt.Print("could not start CPU profile: ", err)
>>> }
>>> defer pprof.StopCPUProfile()
>>> }
>>>
>>> A_chan := make(chan bool)
>>> B_chan := make(chan bool)
>>> go util.A(A_chan)
>>> go util.B(B_chan)
>>> (..Rest of the code..)
>>>
>>> for {
>>> select {
>>> case <-A_chan:
>>> continue
>>> case <-B_chan:
>>> continue
>>>
>>> }
>>> }
>>>
>>> }
>>>
>>> What would be the correct way to add the memprofile code changes, since
>>> it is running in an infinite for loop ?
>>>
>>> Also, as shared by others above, there are no promises about how soon
>>> the dead allocations go away, The speed gets faster and faster version to
>>> version, and is
Re: [go-nuts] go build output depending on project structure
Hi Jake, Is there some reason that you want, or need, to be using go build this way, by specifying files? Or is it just curiosity about how the tools work? >>There is no particular reason to use go build by specifying the files. I was trying different ways to compile the project and ended up with this scenario. I am curious to know the reason for this. The typical way to use go build is to build without specifying individual files. If you are using CGO, I would certainly recommend that you do it by building as a package, just to keep things simple. Not that CGO is ever simple. >> I will try compiling the package without specifying the individual files. But the following case works all fine whether we pass the individual file or not.: *Case 1--* I have a project called 'nitish' where the folder structure looks like the following: nitish main.go util util.go lib node.c node.h a.go When I try compiling this project in the following ways: 1) go build -v - x >> This creates a binary called 'nitish' 2) go build -v - x main.go >> This creates a binary called 'main' ldd output of both the binaries is the same. Thanks, Nitish On Thu, Mar 19, 2020 at 7:18 PM Jake Montgomery wrote: > Nitish, > > Is there some reason that you want, or need, to be using go build this > way, by specifying files? Or is it just curiosity about how the tools work? > The typical way to use go build is to build without specifying individual > files. If you are using CGO, I would certainly recommend that you do it by > building as a package, just to keep things simple. Not that CGO is ever > simple. > > > On Wednesday, March 18, 2020 at 10:27:19 AM UTC-4, Nitish Saboo wrote: >> >> Hi Gregor, >> >> Do you mean like this 'go build -v -x main.go node.c' ? But it does not >> compile and gives the following output: >> >> WORK=/tmp/go-build714119815 >> named files must be .go files >> >> Thanks, >> Nitish >> >> On Wed, Mar 18, 2020 at 7:44 PM Gregor Best >> wrote: >> >>> Hi, >>> >>> it looks like my initial reply wasn't entirely correct. It should build >>> if you pass in both the `.go` file and the `.c` file. >>> On 18.03.20 15:02, Nitish Saboo wrote: >>> >>> Hi Gregor, >>> >>> nitish >>>main.go >>>node.c >>>node.h >>> >>> I compiled using 'go build -v -x main.go' >>> But if my cgo directive is defined in main.go, this should have compiled >>> successfully..right? But it fails with the following whereas 'go build -v >>> -x' works fine. >>> >>> /tmp/go-build439591561/b001/_x002.o: In function >>> `_cgo_5637ad3d75e4_Cfunc_load_pattern_db': >>> /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' >>> collect2: error: ld returned 1 exit status >>> >>> package main >>> >>> //#include >>> //#include "node.h" >>> import "C" >>> import ( >>> "fmt" >>> _ "fmt" >>> "os" >>> "path" >>> "unsafe" >>> ) >>> >>> Please let me know what am I missing here? >>> >>> Thanks, >>> Nitish >>> >>> On Wed, Mar 18, 2020 at 7:20 PM Nitish Saboo >>> wrote: >>> Hi Gregor, Got your point.Thank you for your response. That explains why the binaries have different names post compilation. Thanks, Nitish On Wed, Mar 18, 2020 at 7:06 PM Gregor Best wrote: > Hi, > > In both `go build main.go`-examples, you tell the compiler to _only_ > build `main.go`. > > In your first example, `main.go` probably imports both `util` and > `lib` (you might want to give them less generic names by the way). The go > compiler thus knows "to build `main.go`, I need to build both `util` and > `lib` and link them in". > > In the second example, it has no way of knowing where > `load_pattern_db` comes from, since you didn't tell it to compile a file > that defines that function. > > The examples where you omit the `main.go` tell the compiler "build the > package in this directory", which includes all `.go`-files in the > directory. `node.c` and `node.h` are likely built because of `cgo` > directives in `a.go`. > > The compiler and linker did exactly as you told them to. > On 18.03.20 14:17, Nitish Saboo wrote: > > Hi, > > > > *Case 1 -- * > I have a project called 'nitish' where the folder structure looks like > the following: > > nitish >main.go >util > util.go >lib > node.c > node.h > a.go > > When I try compiling this project in the following ways: > > 1) go build -v - x > > >> This creates a binary called 'nitish' > > 2) go build -v - x main.go > > >> This creates a binary called 'main' > > ldd output of both the binaries is the same. > > > > *Case 2 --* > > Now, when I restructure the
Re: [go-nuts] go build output depending on project structure
Nitish, Is there some reason that you want, or need, to be using go build this way, by specifying files? Or is it just curiosity about how the tools work? The typical way to use go build is to build without specifying individual files. If you are using CGO, I would certainly recommend that you do it by building as a package, just to keep things simple. Not that CGO is ever simple. On Wednesday, March 18, 2020 at 10:27:19 AM UTC-4, Nitish Saboo wrote: > > Hi Gregor, > > Do you mean like this 'go build -v -x main.go node.c' ? But it does not > compile and gives the following output: > > WORK=/tmp/go-build714119815 > named files must be .go files > > Thanks, > Nitish > > On Wed, Mar 18, 2020 at 7:44 PM Gregor Best > wrote: > >> Hi, >> >> it looks like my initial reply wasn't entirely correct. It should build >> if you pass in both the `.go` file and the `.c` file. >> On 18.03.20 15:02, Nitish Saboo wrote: >> >> Hi Gregor, >> >> nitish >>main.go >>node.c >>node.h >> >> I compiled using 'go build -v -x main.go' >> But if my cgo directive is defined in main.go, this should have compiled >> successfully..right? But it fails with the following whereas 'go build -v >> -x' works fine. >> >> /tmp/go-build439591561/b001/_x002.o: In function >> `_cgo_5637ad3d75e4_Cfunc_load_pattern_db': >> /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' >> collect2: error: ld returned 1 exit status >> >> package main >> >> //#include >> //#include "node.h" >> import "C" >> import ( >> "fmt" >> _ "fmt" >> "os" >> "path" >> "unsafe" >> ) >> >> Please let me know what am I missing here? >> >> Thanks, >> Nitish >> >> On Wed, Mar 18, 2020 at 7:20 PM Nitish Saboo > > wrote: >> >>> Hi Gregor, >>> >>> Got your point.Thank you for your response. >>> That explains why the binaries have different names post compilation. >>> >>> Thanks, >>> Nitish >>> >>> >>> On Wed, Mar 18, 2020 at 7:06 PM Gregor Best >> > wrote: >>> Hi, In both `go build main.go`-examples, you tell the compiler to _only_ build `main.go`. In your first example, `main.go` probably imports both `util` and `lib` (you might want to give them less generic names by the way). The go compiler thus knows "to build `main.go`, I need to build both `util` and `lib` and link them in". In the second example, it has no way of knowing where `load_pattern_db` comes from, since you didn't tell it to compile a file that defines that function. The examples where you omit the `main.go` tell the compiler "build the package in this directory", which includes all `.go`-files in the directory. `node.c` and `node.h` are likely built because of `cgo` directives in `a.go`. The compiler and linker did exactly as you told them to. On 18.03.20 14:17, Nitish Saboo wrote: Hi, *Case 1 -- * I have a project called 'nitish' where the folder structure looks like the following: nitish main.go util util.go lib node.c node.h a.go When I try compiling this project in the following ways: 1) go build -v - x >> This creates a binary called 'nitish' 2) go build -v - x main.go >> This creates a binary called 'main' ldd output of both the binaries is the same. *Case 2 --* Now, when I restructure the project 'nitish' in the following manner: nitish main.go util.go node.c node.h a.go When I try compiling this project in the following ways: 1) go build -v - x >> This creates a binary called 'nitish' 2) go build -v - x main.go >> This error out with the following: /tmp/go-build074530518/b001/_x002.o: In function `_cgo_8eab385aa676_Cfunc_load_pattern_db': /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' collect2: error: ld returned 1 exit status 1) In Case 1, why the binaries are created with different names though both the binaries have the same 'ldd output' and work the same manner? 2) Why we see an error with the command 'go build -v - x main.go' in Case 2 but not in Case 1? Thanks, Nitish -- 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 golan...@googlegroups.com . To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALjMrq6gpXPbED%2BK2xiOKYvRg08FZwkjoPSUaGg%3DFu5hKP-%2BKQ%40mail.gmail.com
Re: [go-nuts] Re: Mem-Leak in Go method
You are only using 1.5 mb on the Go side... so if your process is consuming
lots of memory it’s on the C side.
> On Mar 19, 2020, at 7:55 AM, Nitish Saboo wrote:
>
>
> Hi Michael,
>
> I used something like this to generate a mem-prof for 60 minutes
>
> func main() {
> flag.Parse()
> if *cpuprofile != "" {
> f, err := os.Create(*cpuprofile)
> if err != nil {
> fmt.Println("could not create CPU profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> if err := pprof.StartCPUProfile(f); err != nil {
> fmt.Print("could not start CPU profile: ", err)
> }
> defer pprof.StopCPUProfile()
> }
> timeout := time.After(60 * time.Minute)
> A_chan := make(chan bool)
> B_chan := make(chan bool)
> go util.A(A_chan)
> go util.B(B_chan)
> (..Rest of the code..)
>
> for {
> select {
> case <-A_chan:
> continue
> case <-B_chan:
> continue
> case <-timeout:
> break
> }
> break
> }
>
> if *memprofile != "" {
> count = count + 1
> fmt.Println("Generating Mem Profile:")
> fmt.Print(count)
> f, err := os.Create(*memprofile)
> if err != nil {
> fmt.Println("could not create memory profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> runtime.GC()// get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> fmt.Println("could not write memory profile: ", err)
> }
>
> }
> }
>
> I got the following output from the mem.prof:
>
> ~/Desktop/memprof:go tool pprof mem.prof
> File: main
> Build ID: 331d79200cabd2a81713918e51b8c9a63e3f7d29
> Type: inuse_space
> Time: Mar 19, 2020 at 3:57pm (IST)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top 14
> Showing nodes accounting for 1581.40kB, 100% of 1581.40kB total
> flat flat% sum%cum cum%
> 1024.14kB 64.76% 64.76% 1024.14kB 64.76%
> github.com/aws/aws-sdk-go/aws/endpoints.init.ializers
> 557.26kB 35.24% 100% 557.26kB 35.24% crypto/elliptic.initTable
> 0 0% 100% 557.26kB 35.24%
> crypto/elliptic.(*p256Point).p256BaseMult
> 0 0% 100% 557.26kB 35.24% crypto/elliptic.GenerateKey
> 0 0% 100% 557.26kB 35.24%
> crypto/elliptic.p256Curve.ScalarBaseMult
> 0 0% 100% 557.26kB 35.24% crypto/tls.(*Conn).Handshake
> 0 0% 100% 557.26kB 35.24% crypto/tls.(*Conn).clientHandshake
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.(*clientHandshakeState).doFullHandshake
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.(*clientHandshakeState).handshake
> 0 0% 100% 557.26kB 35.24%
> crypto/tls.(*ecdheKeyAgreement).processServerKeyExchange
> 0 0% 100% 557.26kB 35.24% crypto/tls.generateECDHEParameters
> 0 0% 100% 557.26kB 35.24%
> net/http.(*persistConn).addTLS.func2
> 0 0% 100% 1024.14kB 64.76% runtime.main
> 0 0% 100% 557.26kB 35.24% sync.(*Once).Do
>
> (pprof)
>
> Can you please share some commands or any link which I can refer to to
> analyze the data?
>
> Thanks,
> Nitish
>
>
>
>> On Fri, Mar 13, 2020 at 6:22 PM Michael Jones
>> wrote:
>> hi. get the time at the start, check the elapsed time in your infinite loop,
>> and trigger the write/exit after a minute, 10 minutes, 100 minutes, ...
>>
>>> On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
>>> wrote:
>>> Hi Michael,
>>>
>>> Thanks for your response.
>>>
>>> That code looks wrong. I see the end but not the start. Look here and copy
>>> carefully:
>>>
>>> >>Since I did not want cpu profiling I omitted the start of the code and
>>> >>just added memory profiling part.
>>>
>>> Call at end, on way out.
>>>
>>> >>Oh yes, I missed that.I have to call memory profiling code at the end on
>>> >>the way out.But the thing is that it runs as a service in infinite for
>>> >>loop.
>>>
>>> func main() {
>>> flag.Parse()
>>> if *cpuprofile != "" {
>>> f, err := os.Create(*cpuprofile)
>>> if err != nil {
>>> fmt.Println("could not create CPU profile: ", err)
>>> }
>>> defer f.Close() // error handling omitted for example
>>> if err := pprof.StartCPUProfile(f); err != nil {
>>> fmt.Print("could not start CPU profile: ", err)
>>> }
>>> defer pprof.StopCPUProfile()
>>> }
>>>
>>> A_chan := make(chan bool)
>>> B_chan := make(chan bool)
>>> go util.A(A_chan)
>>> go util.B(B_chan)
>>> (..Rest of the code..)
>>>
>>> for {
>>> select {
>>> case <-A_chan:
>>> continue
>>> case <-B_chan:
>>> continue
>>>
>>> }
>>> }
>>>
>>> }
>>>
>>> What would be the correct way to add the memprofile code changes, since it
>>> is running in an infinite for loop ?
>>>
>>> Also, as shared by others above, there are no promises about how soon the
>>> dead allocations go away, The speed gets faster and faster version to
>>> version, and is impressive indeed now, so old versions are not the best to
>>> use, ubt even so, if the allocation feels small to th GC the urgency to
>>> free it will be low. You need to loop in
Re: [go-nuts] Re: Mem-Leak in Go method
Hi Michael,
I used something like this to generate a mem-prof for 60 minutes
func main() {
flag.Parse()
if *cpuprofile != "" {
f, err := os.Create(*cpuprofile)
if err != nil {
fmt.Println("could not create CPU profile: ", err)
}
defer f.Close() // error handling omitted for example
if err := pprof.StartCPUProfile(f); err != nil {
fmt.Print("could not start CPU profile: ", err)
}
defer pprof.StopCPUProfile()
}
timeout := time.After(60 * time.Minute)
A_chan := make(chan bool)
B_chan := make(chan bool)
go util.A(A_chan)
go util.B(B_chan)
(..Rest of the code..)
for {
select {
case <-A_chan:
continue
case <-B_chan:
continue
case <-timeout:
break
}
break
}
if *memprofile != "" {
count = count + 1
fmt.Println("Generating Mem Profile:")
fmt.Print(count)
f, err := os.Create(*memprofile)
if err != nil {
fmt.Println("could not create memory profile: ", err)
}
defer f.Close() // error handling omitted for example
runtime.GC()// get up-to-date statistics
if err := pprof.WriteHeapProfile(f); err != nil {
fmt.Println("could not write memory profile: ", err)
}
}
}
I got the following output from the mem.prof:
~/Desktop/memprof:go tool pprof mem.prof
File: main
Build ID: 331d79200cabd2a81713918e51b8c9a63e3f7d29
Type: inuse_space
Time: Mar 19, 2020 at 3:57pm (IST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top 14
Showing nodes accounting for 1581.40kB, 100% of 1581.40kB total
flat flat% sum%cum cum%
1024.14kB 64.76% 64.76% 1024.14kB 64.76%
github.com/aws/aws-sdk-go/aws/endpoints.init.ializers
557.26kB 35.24% 100% 557.26kB 35.24% crypto/elliptic.initTable
0 0% 100% 557.26kB 35.24%
crypto/elliptic.(*p256Point).p256BaseMult
0 0% 100% 557.26kB 35.24% crypto/elliptic.GenerateKey
0 0% 100% 557.26kB 35.24%
crypto/elliptic.p256Curve.ScalarBaseMult
0 0% 100% 557.26kB 35.24% crypto/tls.(*Conn).Handshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*Conn).clientHandshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*clientHandshakeState).doFullHandshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*clientHandshakeState).handshake
0 0% 100% 557.26kB 35.24%
crypto/tls.(*ecdheKeyAgreement).processServerKeyExchange
0 0% 100% 557.26kB 35.24%
crypto/tls.generateECDHEParameters
0 0% 100% 557.26kB 35.24%
net/http.(*persistConn).addTLS.func2
0 0% 100% 1024.14kB 64.76% runtime.main
0 0% 100% 557.26kB 35.24% sync.(*Once).Do
(pprof)
Can you please share some commands or any link which I can refer to to
analyze the data?
Thanks,
Nitish
On Fri, Mar 13, 2020 at 6:22 PM Michael Jones
wrote:
> hi. get the time at the start, check the elapsed time in your infinite
> loop, and trigger the write/exit after a minute, 10 minutes, 100 minutes,
> ...
>
> On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
> wrote:
>
>> Hi Michael,
>>
>> Thanks for your response.
>>
>> That code looks wrong. I see the end but not the start. Look here and
>> copy carefully:
>>
>> >>Since I did not want cpu profiling I omitted the start of the code and
>> just added memory profiling part.
>>
>> Call at end, on way out.
>>
>> >>Oh yes, I missed that.I have to call memory profiling code at the end
>> on the way out.But the thing is that it runs as a service in infinite for
>> loop.
>>
>> func main() {
>> flag.Parse()
>> if *cpuprofile != "" {
>> f, err := os.Create(*cpuprofile)
>> if err != nil {
>> fmt.Println("could not create CPU profile: ", err)
>> }
>> defer f.Close() // error handling omitted for example
>> if err := pprof.StartCPUProfile(f); err != nil {
>> fmt.Print("could not start CPU profile: ", err)
>> }
>> defer pprof.StopCPUProfile()
>> }
>>
>> A_chan := make(chan bool)
>> B_chan := make(chan bool)
>> go util.A(A_chan)
>> go util.B(B_chan)
>> (..Rest of the code..)
>>
>> for {
>> select {
>> case <-A_chan:
>> continue
>> case <-B_chan:
>> continue
>>
>> }
>> }
>>
>> }
>>
>> What would be the correct way to add the memprofile code changes, since
>> it is running in an infinite for loop ?
>>
>> Also, as shared by others above, there are no promises about how soon the
>> dead allocations go away, The speed gets faster and faster version to
>> version, and is impressive indeed now, so old versions are not the best to
>> use, ubt even so, if the allocation feels small to th GC the urgency to
>> free it will be low. You need to loop in allocating and see if the memory
>> grows and grows.
>>
>> >> Yes, got it.I will try using the latest version of Go and check the
>> behavior.
>>
>> Thanks,
>> Nitish
>>
>> On Fri, Mar 13, 2020 at 6:20 AM Michael Jones
>> wrote:
>>
>>> That code looks wrong. I see the end but not the start. Look here and
>>> copy carefully:
>>> https://golang.org/pkg/runtime/pprof/
>>>
>>> Call at end, on way out.
>>>
>>> Also, as shared by others above, there are no promises about how soon
[go-nuts] "Unused" transitive module requirements and licenses
Hi all, I raised the following question in #tools on Gophers Slack (https://gophers.slack.com/) but re-raising here for slightly wider discussion/pointers. It is very related to Bryan Mills' excellent proposal in https://github.com/golang/go/issues/36460 for lazy module loading. Q: If my main module requires module M1, but only uses packages within M1 such that transitive module requirements (of M1) M2 and M3 are used (and not M4 or M5), what's the situation with respect to the licenses of M4 and M5? By "uses packages" here I'm considering the output of go list -test -deps on the packages of the main module. I had never considered this question until the other day when it dawned on me in the context of lazy module loading. Bryan kindly responded with the following: > I can't give you legal advice, but I can describe the technical aspects. > > If your main module is already tidy, then (barring a bug) only the source code > and go.mod files from M1, M2, and M3 would be read. > > When a new dependency needs to be resolved, then the go.mod files — but not > the source code — for M4 (and perhaps M5) would also be read in order to > determine what version of the new dependency to add. Bryan makes a distinction between the go.mod files for M4 and M5 and the source code in those modules. Is anyone well-placed to offer some pointers on this question of whether or to what extent the licenses of M4 and M5 are significant? Many thanks Paul -- 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/CACoUkn6NyvgZFvWJVJBBna4txwbCjsGoRKXFDV8S2_ER%3D5Chiw%40mail.gmail.com.
