Re: [go-nuts] Re: Replacement for net.Error.Temporary in server Accept loops

On Wed, Apr 20, 2022 at 6:46 PM 'Damien Neil' via golang-nuts wrote: > > The reason for deprecating Temporary is that the set of "temporary" errors > was extremely ill-defined. The initial issue for https://go.dev/issue/45729 > discusses the de facto definition of Temporary and the confusion

Re: [go-nuts] [GoLLVM/gofrontend] Different itab implementation?

Thanks On Thursday, April 21, 2022 at 6:37:10 AM UTC+8 Ian Lance Taylor wrote: > On Wed, Apr 20, 2022 at 6:31 AM Lanzhiguan Huang > wrote: > > > > In gc's implementation, the itab struct has an interface type and an > object type field and a method table, while in the GoLLVM's implementation,

Re: [go-nuts] Executing a tar command from within a Go program

The variadic args worked perfectly. Thanks. I did not use the archive/tar and compress/gzip approach because that wold be a lot more complicated than just executing a tar command. Those packages are oriented towards reading/writing the contents of archive/compressed files into the program

[go-nuts] Re: Replacement for net.Error.Temporary in server Accept loops

The reason for deprecating Temporary is that the set of "temporary" errors was extremely ill-defined. The initial issue for https://go.dev/issue/45729 discusses the de facto definition of Temporary and the confusion resulting from it. Perhaps there's a useful definition of temporary or

[go-nuts] Replacement for net.Error.Temporary in server Accept loops

In Go 1.18 net.Error.Temporary was deprecated (see https://go.dev/issue/45729). However, in trying to remove it from my code, I found one way in which Temporary is used for which there is no obvious replacement: in a TCP server's Accept loop, when deciding whether to wait and retry an Accept

Re: [go-nuts] Re: Protective buffered channel that never triggers deadlock

" Strangely I found the start testing and disconnect log clustered and the disconnect did actually happen. Then I switch back to the sequential case that the receiving channel gots filled without receiving until disconnection. It works now." -- I found the error occurred again. It turned out

Re: [go-nuts] zero value for generic types?

On Wed, Apr 20, 2022 at 3:30 PM Arthur Comte wrote: > > Actually, even with proper error handling, I still need to return a value. In > some functions I can just return a variable that was defined in the function, > but that is not always available. In those cases, the only solution I've >

Re: [go-nuts] [GoLLVM/gofrontend] Different itab implementation?

On Wed, Apr 20, 2022 at 6:31 AM Lanzhiguan Huang wrote: > > In gc's implementation, the itab struct has an interface type and an object > type field and a method table, while in the GoLLVM's implementation, the type > descriptor was moved to the first field of the method table. I think they

Re: [go-nuts] zero value for generic types?

Actually, even with proper error handling, I still need to return a value. In some functions I can just return a variable that was defined in the function, but that is not always available. In those cases, the only solution I've found is to use `*new(E)`, which seems plain terrible. Is there an

[go-nuts] zero value for generic types?

Hi! I was trying the following code, but it does not compile. How can I check if a generic value is its zero value. More broadly, can you explain where this issue comes from? ```go type MemoryRepository[E identifiable.Identifiable] struct { elements []E } func (repo MemoryRepository[E])

Re: [go-nuts] Executing a tar command from within a Go program

On Wed, Apr 20, 2022 at 6:16 PM Dean Schulze wrote: > I need to execute this tar command > > *tar xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/* > > from within a Go program. I've verified that it works from the command > line. I've tried using > > > *argStr := "xzf dir1/dir2/somefile.tgz

Re: [go-nuts] Executing a tar command from within a Go program

Also, the Output method only returns what was wrote to stdout, tar argument parsing errors are probably in stderr, using CombinedOutput() has better effect to debug. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

Re: [go-nuts] Executing a tar command from within a Go program

On Wed Apr 20, 2022 at 6:16 PM CEST, Dean Schulze wrote: > I need to execute this tar command > > *tar xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/* > Did you considered using the packages "archive/tar" and "compress/gzip" to achive this? > *argStr := "xzf dir1/dir2/somefile.tgz

[go-nuts] Executing a tar command from within a Go program

I need to execute this tar command *tar xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/* from within a Go program. I've verified that it works from the command line. I've tried using *argStr := "xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/"output, err := exec.Command("tar",

[go-nuts] [Remote Job] Software Engineer at Expertlead 

We are looking for a Fullstack Software Engineer with hands-on experience with Golang. *Our tech stack: ReactJS, NodeJS, and GoLang* *Curious? Apply here! * We are looking for a dedicated Software Engineer with both

[go-nuts] google/gopacket abandoned?

Hi there, the github.com/google/gopacket appears to no longer have a maintainer. The last commit was about one year ago (29. April 2021), and it appears that around the same time the previous maintainer, gconnell, has left Google. gopacket is used as a dependency in a large-ish number of

[go-nuts] Re: Interfaces holding integers and memory allocations

Sorry to revive a dead thread. I have also been playing with an interpreter and found that increasing the size of runtime.staticuint64s helps with the convT64 issue a lot. https://github.com/golang/go/blob/aa8262d800f0cba2e4d4472a7e344eb60481b0ff/src/runtime/iface.go#L493-L526 I'm guessing that

[go-nuts] [GoLLVM/gofrontend] Different itab implementation?

Hi, In gc's implementation, the itab struct has an interface type and an object type field and a method table, while in the GoLLVM's implementation, the type descriptor was moved to the first field of the method table. I think they just maintain the same information but do not understand the