[go-nuts] Working with Floating-Point numbers

When working with Floating-point values in Go, what considerations need to be made? The same for any other language? The Spec says that "Floating-point values are comparable and ordered" https://golang.org/ref/spec#Comparison_operators So is comparing by some epsilon value not needed? or only

Re: [go-nuts] Is the reflect package performant?

Thanks for the advice. On Friday, October 27, 2017 at 6:57:39 AM UTC-7, Ian Lance Taylor wrote: > > On Fri, Oct 27, 2017 at 1:32 AM, go-question > <question@gmail.com > wrote: > > > > I'm accustomed to avoiding reflection in other languages due to

[go-nuts] Is the reflect package performant?

I'm accustomed to avoiding reflection in other languages due to performance concerns, is that unfounded with Go's reflect package? -- 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,

Re: [go-nuts] Are all running goroutines killed when main ends?

Thanks for clearing that up! On Thursday, October 5, 2017 at 9:52:30 PM UTC-7, Dave Cheney wrote: > > The only answer I have is to ask those goroutines to exit, the wait for > them to exit. Context is part of this, combined with a waitgroup to track > goroutines in flight. -- You received

[go-nuts] Are all running goroutines killed when main ends?

When a program's main ends, will all running goroutines that were created by the program also be stopped and cleaned up? -- 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

[go-nuts] Re: Second nested done case in a select statement

Thanks again. On Monday, October 2, 2017 at 5:36:41 AM UTC-7, Tamás Gulácsi wrote: > > Yes. > Receiving drom c with (<-c) would wait indefinitely. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Re: Why have an empty default case when sending heartbeats

I see sending to a channel with no receivers blocks on the sender side, Thanks. On Sunday, October 1, 2017 at 10:36:14 PM UTC-7, Tamás Gulácsi wrote: > > To skip send if nothing is receiving, avoiding the block. -- You received this message because you are subscribed to the Google Groups

[go-nuts] Re: Second nested done case in a select statement

the done channel could have been signaled after the initial check and while reading from <-c so it has to be checked again, is that right? On Sunday, October 1, 2017 at 10:34:58 PM UTC-7, Tamás Gulácsi wrote: > > done may happen before value arriving from valStream. -- You received this

[go-nuts] Why have an empty default case when sending heartbeats

In the following snippet for having a function representing work send a heartbeat to any listeners. Why is a select statement used in `sendPulse` instead of just executing `heartbeat <- struct{}{}`? And why provide an empty default case? doWork := func( done <-chan interface{}, pulseInterval

[go-nuts] Second nested done case in a select statement

What is the purpose of the second nested <-done case in the code snippet below? Wouldn't the first <-done case handle the cancellation? orDone := func(done, c <-chan interface{}) <-chan interface{} { valStream := make(chan interface{}) go func() { defer close(valStream) for { select { case

Re: [go-nuts] Why does the close built-in panic on previously closed channels?

I see, from reading the Golang spec on the close builtin it wasn't clear to me that it was communicating with the receivers. Thanks for clarifying! On Tuesday, December 13, 2016 at 10:19:46 AM UTC-8, Ian Lance Taylor wrote: > > On Tue, Dec 13, 2016 at 10:03 AM, go-question >

[go-nuts] Why does the close built-in panic on previously closed channels?

Whats the reason behind panicking when calling close on a closed channel? Receiving on a closed channel returns the zero value. Wouldn't it be safer to do a no-op and rely on the multivar return to inform the caller when it is successful? Though, maybe the latter point could be confusing with

Re: [go-nuts] Function scoped method receivers

Thanks rog for the suggestions. I can see the case for mocking as well. On Tuesday, December 13, 2016 at 5:11:26 AM UTC-8, rog wrote: > > On 13 December 2016 at 01:08, go-question <question@gmail.com > > wrote: > > > > I noticed that its possible to de

[go-nuts] Re: Function scoped method receivers

Thanks again. On Monday, December 12, 2016 at 7:13:28 PM UTC-8, Dave Cheney wrote: > > It's unlikely to be added. > > On Tuesday, 13 December 2016 14:09:52 UTC+11, go-question wrote: >> >> Thanks for confirming. Would you know if its a valid feature on the >>

[go-nuts] Re: Function scoped method receivers

Thanks for confirming. Would you know if its a valid feature on the roadmap? On Monday, December 12, 2016 at 5:14:13 PM UTC-8, Dave Cheney wrote: > > No, it is not currently possible to do this, > https://play.golang.org/p/S8w_ztCobQ > > On Tuesday, 13 December 2016 12:0

[go-nuts] Function scoped method receivers

I noticed that its possible to define/scope types/interfaces in functions. Now I'm not arguing that this is good practice, but for the sake of curiosity. How can I then add a method w/ a receiver to type foo so that it satisfies interface ifoo? (in function scope) func main() { type

Re: [go-nuts] Re: A more elegant way to store references with a slice?

Thanks all for the resources! So just to confirm, that (ref) is the only way to hold "references" to objects (and not a "reference" to a new copy) in a slice, so that I can iterate over the original objects using the slice. Correct? And In my tryref example, the issue is with the append and