Re: [go-nuts] still struggling to understand modules

Hello rob, here's what I do. For every dir in ~/go/src run go mod init with the dir name. e.g.: cd ~/go/src/foo go mod init foo cd ~/go/src/bar go mod init bar ... If package foo depends on libfoo (also in ~/go/src) you can add a replace line in foo's go.mod e.g. echo "replace libfoo => ../libfo

Re: [go-nuts] no generic ?

> > Hello, >> >> thank you very much for clarification. >>> >> I'm just a beginner and come here to understand rationale behind the >>> decision. >> >> >>> Thank you so much ! >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscrib

Re: [go-nuts] confuse about wakep?

On Tue, Feb 23, 2021 at 5:16 AM xie cui wrote: > > https://github.com/golang/go/blob/master/src/runtime/proc.go#L2441 > why not change to if !atomic.Cas(&sched.nmspinning, 0, 1), it seems check > sched.nmspinning no zero is unneccessary in logic, > i am not sure, i guess it's about performence

Re: [go-nuts] Re: Cannot build after upgrading to Go 1.16

On Tue, Feb 23, 2021 at 7:24 PM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > > Insufficient information. What command did you run? What was the output? >> Note that module mode is now the default with Go 1.16. You can get the Go >> 1.15 behavior by exporting GO111MODULE=a

[go-nuts] Re: Cannot build after upgrading to Go 1.16

you could just make non-modules repos 'look like' a module with one version. On Wednesday, 24 February 2021 at 03:23:47 UTC simon place wrote: > On Wednesday, 24 February 2021 at 02:26:39 UTC Kurtis Rader wrote: > >> On Tue, Feb 23, 2021 at 5:03 PM 'simon place' via golang-nuts < >> golan...@goog

[go-nuts] Re: Cannot build after upgrading to Go 1.16

On Wednesday, 24 February 2021 at 02:26:39 UTC Kurtis Rader wrote: > On Tue, Feb 23, 2021 at 5:03 PM 'simon place' via golang-nuts < > golan...@googlegroups.com> wrote: > >> nothing compiles any more! >> >> i seem to be being forced to add, to some projects 9 years old >> (unnecessary) module s

Re: [go-nuts] still struggling to understand modules

On Tue, Feb 23, 2021 at 5:49 PM rob wrote: > > I'm looking for a conversion guide for the complete idiot, or for > dummies if that's preferable. Does this article from the Go blog help? https://blog.golang.org/migrating-to-go-modules Ian -- You received this message because you are subscribed

Re: [go-nuts] still struggling to understand modules

On Wed, Feb 24, 2021 at 12:49 PM rob wrote: > > Hi. I'm a hobby programmer. I've been able to learn and use gopath > mode for a while. I've accumulated 20+ programs that I use that were > build using gopath mode. I'm not using a package manager, as all my > code is in GOPATH, ie, ~/go/src/ > >

[go-nuts] Cannot build after upgrading to Go 1.16

On Tue, Feb 23, 2021 at 5:03 PM 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > nothing compiles any more! > > i seem to be being forced to add, to some projects 9 years old > (unnecessary) module support, or, add notes to all their docs that they > need to be compiled in ve

[go-nuts] still struggling to understand modules

Hi.  I'm a hobby programmer.  I've been able to learn and use gopath mode for a while.  I've accumulated 20+ programs that I use that were build using gopath mode.  I'm not using a package manager, as all my code is in GOPATH, ie, ~/go/src/ I don't understand how to convert this to modules.  I

[go-nuts] Re: Go 1.16 is released

nothing compiles any more! i seem to be being forced to add, to some projects 9 years old (unnecessary) module support, or, add notes to all their docs that they need to be compiled in versions older than 1.16, or have to have an obscure parameter set. there really wasn't a non-breaking way to

Re: [go-nuts] Questions Regarding Go 1.15 Dwarf generation

Thank you, I would certainly do that. On Tue, Feb 23, 2021 at 12:59 PM Than McIntosh wrote: > > I would second Ian's recommendation to look at the 1.16 code -- a lot has > changed since 1.15. > > >>There is a LoadFull function in loader with works with payloads but I > have no idea what function

Re: [go-nuts] Error handling

I’ll only add to this, there is no reason to close in the exception handler - it is automatic by the try-with-resource. The only reason to check null is if you needed to “do something else” based on that state. I think a better pattern with the “something else” is to always use standard wrapper

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

I would refer you back to the other article I linked to on setting up your host name properly. When I test using the default DNS resolving I can resolve both ‘iMac’ and ‘iMac.local’ in 2-3 milliseconds without any entry in my /etc/hosts file. If I add the entry ‘iMac.local’ to my /etc/hosts fi

[go-nuts] Rapidly Developing Golang Microservices

This is a great tutorial on rapid microservice development using Go! https://blog.getambassador.io/go-kubernetes-rapidly-developing-golang-microservices-bfe36cfb5893 -- You received this messag

Re: [go-nuts] Error handling

This has been interesting to watch as I too have somehow been "converted" from java style exceptions to current go-style error flow as preference. In the first example you just shared, I think if you elaborate the comments, "at this point all files are open, if any fail, others are closed", yo

Re: [go-nuts] Questions Regarding Go 1.15 Dwarf generation

I would second Ian's recommendation to look at the 1.16 code -- a lot has changed since 1.15. >>There is a LoadFull function in loader with works with payloads but I have no idea what function and in what phase the raw data for each symbols being created and added to payloads. I would appreciate i

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

>> I don’t understand why ping does not have the same problem. Ping is not >> based on C library? >> > > Looking at the source code, the ping command on macOS use gethostbyname2() > [1][2], while the Go on macOS use C library through getaddrinfo [3][4]. If so, I'd consider it as a performance bug

Re: [go-nuts] Questions Regarding Go 1.15 Dwarf generation

Thanks for your reply. Actually yes, I am looking at the dwarfGenerateDebugSyms function in dwarf.go in cmd/lin/internal/ld trying to understand how and when CUs are being generated and then added to dwarfp2 specially the header and length of each CU. R, Mahdi On Mon, Feb 22, 2021 at 11:36 PM Ian

[go-nuts] ICMP in golang

Hi, I see this ICMP example. But somebody says it is too old. What is the current way to ping a target in go? Thanks. https://gist.github.com/lmas/c13d1c9de3b2224f9c26435eb56e6ef3 -- Regards, Peng -- You received this message because you are subscribed to the Google Groups "golang-nuts" grou

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

Nice work. > On Feb 23, 2021, at 10:16 AM, Shulhan wrote: > >  >> On 23 Feb 2021, at 12.40, Peng Yu wrote: >> >> I don’t understand why ping does not have the same problem. Ping is not >> based on C library? >> > > Looking at the source code, the ping command on macOS use gethostbyname2()

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

> On 23 Feb 2021, at 12.40, Peng Yu wrote: > > I don’t understand why ping does not have the same problem. Ping is not based > on C library? > Looking at the source code, the ping command on macOS use gethostbyname2() [1][2], while the Go on macOS use C library through getaddrinfo [3][4].

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

I looked into it more. You can use GODEBUG to configure to use the Go dns resolver - but even if you don’t there is a significant Go layer to Dial - it is not a simple pass through to the C call. > On Feb 23, 2021, at 8:54 AM, Kevin Chadwick wrote: > > On February 23, 2021 2:46:20 PM UTC, Ro

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

On February 23, 2021 2:46:20 PM UTC, Robert Engels wrote: >I am not 100% certain but the build statement at the top of the Unix >dns client specified Darwin. I would read the Go issues I linked to in >the code snippet. I believe it varies. Android has no universal textual interface - /etc/reso

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

I am not 100% certain but the build statement at the top of the Unix dns client specified Darwin. I would read the Go issues I linked to in the code snippet. > On Feb 23, 2021, at 8:29 AM, Peng Yu wrote: > > Hi Robert, > > Ian Lance Taylor said the exact opposite. "On Darwin I believe that b

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

Hi Robert, Ian Lance Taylor said the exact opposite. "On Darwin I believe that by default we pass DNS lookups to the C library." (I assume "we" means Go developers.) Are you correct or Ian is correct? On Tue, Feb 23, 2021 at 8:14 AM Robert Engels wrote: > > As I pointed out, Go does not use the

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

On February 23, 2021 1:57:07 PM UTC, Peng Yu wrote: >This does not answer the question why net.Dial can not be made with >the same behavior as ping on MacOSX. If the C library behaves >differently on MacOSX and Linux, then the C library should not be >relied on in this case. I just want to use /et

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

As I pointed out, Go does not use the C library. > On Feb 23, 2021, at 7:57 AM, Peng Yu wrote: > > This does not answer the question why net.Dial can not be made with > the same behavior as ping on MacOSX. If the C library behaves > differently on MacOSX and Linux, then the C library should no

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

This does not answer the question why net.Dial can not be made with the same behavior as ping on MacOSX. If the C library behaves differently on MacOSX and Linux, then the C library should not be relied on in this case. I just want to use /etc/hosts but not resolve.conf. On 2/22/21, robert engels

Re: [go-nuts] Error handling

The complexity there is from generators + exceptions. I am not proposing generators for Go as it doesn’t need it. > On Feb 23, 2021, at 6:03 AM, Nigel Tao wrote: > >  > If you're proposing exceptions, be aware of how complicated the control flow > for correct handling can be. Look for what f

Re: [go-nuts] Orderly exit

> So you should probably disregard the sentinel-panic idea, > runtime.Goexit seems strictly superior) Thank you. I shall look into those. WRT Goexit. I was hoping a defer in main would run also. Thinking about it. I shall have to ponder about the relationship of panic and process groups too

[go-nuts] confuse about wakep?

https://github.com/golang/go/blob/master/src/runtime/proc.go#L2441 why not change to if !atomic.Cas(&sched.nmspinning, 0, 1), it seems check sched.nmspinning no zero is unneccessary in logic, i am not sure, i guess it's about performence issue? -- You received this message because you are subs

Re: [go-nuts] Orderly exit

(PS: I've only learned about runtime.Goexit after I came up with the sentinel-panic pattern. I've been thinking for a while, that it is probably a better choice, for various reasons. And after testing it out, I do think it's strictly superior. So you should p

Re: [go-nuts] Orderly exit

On Tue, Feb 23, 2021 at 1:10 PM Kevin Chadwick wrote: > Is it possible to call panic in a way that does not kill the process like > os.Exit, but without log pollution? I am solely thinking of manually instigated panics, so a noop panic called > something like terminate? > You can `recover`. I

[go-nuts] Orderly exit

I only instigate panic manually for one thing. Perhaps that will change, but I doubt it. If I want to send out or write a log to disk then I will call panic rather than os.exit, upon a log.fatal scenario. Think buffered go routine logging. Saving the coder from having to think about it, once in

Re: [go-nuts] Error handling

If you're proposing exceptions, be aware of how complicated the control flow for correct handling can be. Look for what follows `The statement "RESULT = yield from EXPR" is semantically equivalent to...` in https://www.python.org/dev/peps/pep-0380/ -- You received this message because you are sub

Re: [go-nuts] promoted methods confusion

On Tuesday, 23 February 2021 at 07:01:27 UTC+1 Henry wrote: > I think the problem is that people try to use embedding in place of > inheritance. [...] Embedding shares many similarities to inheritance The first part is a real common problem but I have to admit I do not understand where the se

Re: [go-nuts] A problem about Happens Before

On 2/23/21 4:04 PM, Axel Wagner wrote: Because you have a concurrent read/write to a. Specifically, the Memory model says that "the go statement that starts a new goroutine happens before the goroutine's execution begins" . This means the first code is fine

Re: [go-nuts] A problem about Happens Before

Because you have a concurrent read/write to a. Specifically, the Memory model says that "the go statement that starts a new goroutine happens before the goroutine's execution begins" . This means the first code is fine - the write happens before the go statement, w