Re: [go-nuts] Avoiding resource leaks with racing channels

On Mon, Jul 8, 2019 at 9:14 PM Daniel Eloff wrote: > > If a select statement has multiple channels ready when it runs, then it will > choose one at a random. So if you fire something across a channel that holds > a resource, like an open file descriptor - you have no guarantees that the > other

Re: [go-nuts] Avoiding resource leaks with racing channels

On Mon, Jul 8, 2019 at 10:54 PM Tamás Gulácsi wrote: > > // Wait on the channel, or for timeout > select { > case fd := <-channel: > return fd, nil > case <-time.After(queue.timeout): > // Check again > select { > case fd := <-channel: > return fd, nil > defaul

[go-nuts] Avoiding resource leaks with racing channels

// Wait on the channel, or for timeout select { case fd := <-channel: return fd, nil case <-time.After(queue.timeout): // Check again select { case fd := <-channel: return fd, nil default: return nil, ErrTimeoutElapsed } } -- You received this m

Re: [go-nuts] Avoiding resource leaks with racing channels

Only a buffered channel can "hold" anything. If the channel is unbuffered, then you are guaranteed that another goroutine has at least received the item you sent when the send statement returns. On Mon, Jul 8, 2019 at 9:42 PM Burak Serdar wrote: > On Mon, Jul 8, 2019 at 10:14 PM Daniel Eloff wr

Re: [go-nuts] Avoiding resource leaks with racing channels

On Mon, Jul 8, 2019 at 10:14 PM Daniel Eloff wrote: > > If a select statement has multiple channels ready when it runs, then it will > choose one at a random. So if you fire something across a channel that holds > a resource, like an open file descriptor - you have no guarantees that the > othe

[go-nuts] Avoiding resource leaks with racing channels

If a select statement has multiple channels ready when it runs, then it will choose one at a random. So if you fire something across a channel that holds a resource, like an open file descriptor - you have no guarantees that the other end of the channel receives it. The (possibly full) channel

[go-nuts] Build kubernetes with gollvm

Hi, I'm working on converting some Go projects to llvm IR for static analysis. When I build kubernetes with gollvm, an unexpected error occurred as : I0709 10:48:29.158892 16573 deepcopy.go:266] Type k8s.io/apimachinery/pkg/apis/meta/v1.map_StatusDetails is not copyable I0709 10:48:29.158899

[go-nuts] [ANN] Lossless data compression in Go - Kanzi 1.6 released

The latest release contains many code improvements, faster decompression and improved compression ratios. Code available here: https://github.com/flanglet/kanzi-go -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

[go-nuts] Go 1.12.7 and Go 1.11.12 are released

Hello gophers, We have just released Go versions 1.12.7 and 1.11.12, minor point releases. These releases include fixes to cgo, the compiler, and the linker. View the release notes for more information: https://golang.org/doc/devel/release.html#go1.12.minor You can download the binary and s

Re: [go-nuts] Re: net/http and the GC

Very fortunate! On Mon, Jul 8, 2019 at 1:20 PM B Carr wrote: > > > On Monday, July 8, 2019 at 1:01:26 PM UTC-6, Burak Serdar wrote: >> >> >> > I'll need to study this a bit more. Can you give me a pointer? >> >> I don't know really, other than the obvious ones like: >> >> http://devs.cloudimmuni

Re: [go-nuts] Does invoking a method with an interface variable avoid dependency analysis?

sorry. i misunderstood your question. the paragraph you quoted refers to reference to methods values (t.m) or expressions (T.m) and not method calls t.m() as in your example. does that help solve the question? On 08.07.19 20:09, Martin Schnabel wrote: On 08.07.19 02:51, Il-seob Bae wrote: As

Re: [go-nuts] Re: net/http and the GC

On Monday, July 8, 2019 at 1:01:26 PM UTC-6, Burak Serdar wrote: > > > > I'll need to study this a bit more. Can you give me a pointer? > > I don't know really, other than the obvious ones like: > > http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/ > https://golang.org/do

Re: [go-nuts] Re: net/http and the GC

On Mon, Jul 8, 2019 at 11:02 AM B Carr wrote: > > > Thank you, that means I'm thinking correctly about this and need to keep > plugging along. > > >>"the total number of concurrent requests you can handle depends on how you > >>handle your GET requests." > > I'll need to study this a bit more. C

Re: [go-nuts] Does invoking a method with an interface variable avoid dependency analysis?

On 08.07.19 02:51, Il-seob Bae wrote: As per the spec , A reference to a method m is a method value or method expression of the form t.m, where the (static) type of t is not an interface type, and the method m is in the method se

[go-nuts] Re: [ANN] Gomail v2: sending emails faster

Hello, from Russia. It would be nice to add a function for embed and attach file from byte array, not just from file среда, 2 сентября 2015 г., 14:55:26 UTC+3 пользователь Alexandre Cesaro написал: > > Hi, > > I just released the second version of Gomail > .

[go-nuts] Re: net/http and the GC

Thank you, that means I'm thinking correctly about this and need to keep plugging along. >>"the total number of concurrent requests you can handle depends on how you handle your GET requests." I'll need to study this a bit more. Can you give me a pointer? -- You received this message because

Re: [go-nuts] net/http and the GC

On Mon, Jul 8, 2019 at 9:30 AM B Carr wrote: > > Gophers - > > Trying to learn Go (I'm a hobbyist) and have a fundamental net/http question. > I have a web server running with a web page set to refresh every 2 seconds. I > have 3 different browsers making webserver GET requests. Each browser's

[go-nuts] net/http and the GC

Gophers - Trying to learn Go (I'm a hobbyist) and have a fundamental net/http question. I have a web server running with a web page set to refresh every 2 seconds. I have 3 different browsers making webserver GET requests. Each browser's refresh is spinning up a new goroutine on the server, rig

[go-nuts] Re: GOPROXY="https://proxy.golang.org,direct" behaviour

GOPROXY=https://goproxy.io is work for me. 在 2019年7月5日星期五 UTC+8下午2:34:59，Lei Ni写道： > > Hi all, > > I am a little bit confused at what is the expected behaviour for GOPROXY=" > https://proxy.golang.org,direct";. > > On my system when using Go 1.13 beta 1, go env reports that GOPROXY=" > https://pr

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

I think the xerrors proposal will solve a lot of people's problems. You still repetitive boilerplate, but at least decent debugging is possible.-Original Message- From: Chris Broadfoot Sent: Jul 8, 2019 9:04 AM To: Robert Engels Cc: Chris Passas , golang-nuts Subject: Re: [go-nuts] Go 20

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

On Mon, Jul 8, 2019 at 3:48 PM Chris Passas wrote: > > Number 4,5,6 on the list all are listed at 5% so that's why I said "tied" for > 4th. Sorry, you're right. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

See the errors proposal here: https://golang.org/design/29934-error-values Implementation in tip (available in 1.13 beta) https://tip.golang.org/pkg/errors/ Implementation in x/xerrors (backwards compatible): https://godoc.org/golang.org/x/xerrors xerrors - GoDoc On Mon, Jul 8, 2019, 9:54 AM Ro

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

Thank you, I think you did a better job describing than I did. I think this could be done backward compatible because if the "Type()" "SubType()" etc... are not filled out they could just default to returning the Err() value. It would be good to get the whole standard library to support this bu

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

I think you are on to something. As I've said, the boilerplate is ugly, but manageable. It is the process of using and reporting errors that is the problem.If the error interface were expanded, to included methods likeint Type()int SubType()[]Stack StackTrace()error Cause()Log(w Writer,string forma

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

Number 4,5,6 on the list all are listed at 5% so that's why I said "tied" for 4th. Not sure this is an important point of discussion. On Monday, July 8, 2019 at 9:39:10 AM UTC-4, Jan Mercl wrote: > > > > On Mon, Jul 8, 2019 at 3:33 PM Chris Passas > wrote: > > > > We are all aware error handling

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

On Mon, Jul 8, 2019 at 3:33 PM Chris Passas wrote: > > We are all aware error handling was tied for 4th most common challenging when working with Go in the 2018 survey. [image: image.png] It's 5th, not 4th. (src: https://blog.golang.org/survey2018-results) -- You received this message because

[go-nuts] Does invoking a method with an interface variable avoid dependency analysis?

As per the spec , > A reference to a method m is a method value or method expression of the > form t.m, where the (static) type of t is not an interface type, and the > method m is in the method set of t. It is immaterial whether the resulting

[go-nuts] Go 2018 Survey "Error handling 5%"

We are all aware error handling was tied for 4th most common challenging when working with Go in the 2018 survey. There is not description of what about error handling. I'm sure I missed the conversation but how did we get to the point of deciding it was the if err!=nil that was the "challengin

Re: [go-nuts] ANN: The universal "check" built-in proposal.

Much of the stdlib works in the manner I describe. Yes Go allows invocations on nil interface references, but most implementations will panic. Multiple Close is almost never a good thing, and most implementations guard against it. So in the case where the gerReader() succeeds and getDB() fail

Re: [go-nuts] ANN: The universal "check" built-in proposal.

On Mon, 8 Jul 2019 07:37:20 -0500 Robert Engels wrote: > This will never work because of dependent resource allocation. > And you wouldn’t be able to check resources against nil if they are structs, > so you have no way to properly cleanup up. > If would quickly degenerate back to if err != nil.

Re: [go-nuts] Citation Needed

They rewrote the Doom game engine in Java a long time ago. If was faster than the original. GC was not an issue, and Go GC pauses now are a lot lower than Javas was then. > On Jul 8, 2019, at 6:55 AM, Jesper Louis Andersen > wrote: > >> On Mon, Jul 8, 2019 at 11:22 AM Martin Schnabel wrote:

Re: [go-nuts] ANN: The universal "check" built-in proposal.

This will never work because of dependent resource allocation. And you wouldn’t be able to check resources against nil if they are structs, so you have no way to properly cleanup up. If would quickly degenerate back to if err != nil. As in check(err!=nil){ token, err = getToken() reader,err =

[go-nuts] ANN: The universal "check" built-in proposal.

The `func check(Condition bool) {}` applies to the block that follows. Within this block, every statement that on its left-hand side has any variable that is present in the "Condition" expression is supplemented with an implicit check of `if Condition { goto catch }` form. The 'catch:' label can b

Re: [go-nuts] Citation Needed

On Mon, Jul 8, 2019 at 11:22 AM Martin Schnabel wrote: > I would guess, that most of respondents using go for game development, > use it on the server side. Think multi-, browser- or mobile-games. > > Many modern games have considerable server side code bases as well for all kinds of things. And

Re: [go-nuts] Citation Needed

On 06.07.19 08:50, go je wrote: Is the Category "Games" gaining attention in the go community? Are the Developers writing for production level? Do we have an examples? image.png I would guess, that most of respondents using go for game development, use it on the server side. Think multi-, br