Re: [go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

On Friday, 5 May 2017 13:26:33 UTC+8, Ronald wrote: > > Wouldn't it better to just keep the nil channels out of the cases in the > select > statement at the very beginning like epoll_wait does? > (I think the select statement in golang is very similar to the epoll_wait > at sys/epoll.h.) > >

Re: [go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

Wouldn't it better to just keep the nil channels out of the cases in the select statement at the very beginning like epoll_wait does? (I think the select statement in golang is very similar to the epoll_wait at sys/epoll.h.) Or this is a compromise to let the programmer do anything they want?

Re: [go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

On Fri, May 5, 2017 at 1:35 PM, Ronald wrote: > > So the question: > > Isn't it better just to throw a panic when user send/recv on a nil > channel instead of forever blocking it? If not, what is the benefits? There is value in the ability to have a select case be a

[go-nuts] Re: "Selling" Go to Management

Thanks to all who replied! On Sunday, April 30, 2017 at 11:13:52 AM UTC+3, Miki Tebeka wrote: > > And of course the community :) > > On Sunday, April 30, 2017 at 10:41:14 AM UTC+3, Miki Tebeka wrote: >> >> Hi, >> >> I'm giving a 1 hour talk on Go to mid/high level management. Here are the >>

[go-nuts] Re: Fully-qualified import paths and Pull Requests

On Friday, 5 May 2017 13:37:26 UTC+10, st ov wrote: > > By "fork" I mean in the GItHub sense, the forking of original project > *github.com/original/foo > * through their console so that > *github.com/me/foo > * is created. > > And

[go-nuts] Re: Fully-qualified import paths and Pull Requests

By "fork" I mean in the GItHub sense, the forking of original project *github.com/original/foo* through their console so that *github.com/me/foo* is created. And "clone" would be running "git clone https://github.com/original/foo.git; on my local machine so I have a local copy of the original

[go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

The program will simply panic when you write to a closed channel, because that kind of operations is just nonsense after the action of closing the channel. I afraid that the situation is similar to the nil channel operation.Because the nil channel is not been initialized yet, so there is must

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

On Friday, May 5, 2017 at 2:10:03 AM UTC+8, Jesper Louis Andersen wrote: > > To see why the "immediately" solution is not adequate: > > Step 1: Create a single linked list or a binary tree of a couple billion > elements. Make sure there is only a single reference to the head element. > Step 2:

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

On Friday, May 5, 2017 at 12:33:57 AM UTC+8, Axel Wagner wrote: > > As so often is the question: Why? > > I don't believe this will ever be supported by gc; but if you think it's a > good idea, you can of course do it and see whether it actually solves your > problems (my prediction would be

Re: [go-nuts] Missing binary operator shortcuts &&= and ||=

On Thu, May 4, 2017 at 1:38 PM, wrote: > Le jeudi 4 mai 2017 21:43:19 UTC+2, Ian Lance Taylor a écrit : >> >> ... it is potentially confusing >> to see `a &&= f()` when f() may or may not be called. > > > How is that more confusing than `a && f()` when f() may or may not

Re: [go-nuts] Missing binary operator shortcuts &&= and ||=

Le jeudi 4 mai 2017 21:43:19 UTC+2, Ian Lance Taylor a écrit : > > ... it is potentially confusing > to see `a &&= f()` when f() may or may not be called. > How is that more confusing than `a && f()` when f() may or may not be called? Da -- You received this message because you are

Re: [go-nuts] Missing binary operator shortcuts &&= and ||=

What is *actually* missing is boolean operators for boolean types. On Thu, May 4, 2017 at 12:43 PM, Ian Lance Taylor wrote: > On Thu, May 4, 2017 at 9:42 AM, wrote: > > > > One apparently random omission in C, which was fixed in Perl, is &&= and > >

Re: [go-nuts] Missing binary operator shortcuts &&= and ||=

On Thu, May 4, 2017 at 9:42 AM, wrote: > > One apparently random omission in C, which was fixed in Perl, is &&= and > ||=: > > a &&= b > a = a && b > a ||= b > a = a || b > > except that a gets evalutated only once (e.g. myarray[f(2)] &&= b) > > Besides being

[go-nuts] Missing binary operator shortcuts &&= and ||=

One apparently random omission in C, which was fixed in Perl, is &&= and ||=: a &&= b a = a && b a ||= b a = a || b except that a gets evalutated only once (e.g. myarray[f(2)] &&= b) Besides being useful, this would make Go more consistent. Of course relative operators also do not

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

To see why the "immediately" solution is not adequate: Step 1: Create a single linked list or a binary tree of a couple billion elements. Make sure there is only a single reference to the head element. Step 2: Release the pointer to the head Step 3: Twiddle your thumbs while your program is

[go-nuts] Re: Should we use frameworks like Go IRIS based on fasthttp to create foundation of my web application or do I start create framework from scratch

Start out using the stdlib until you feel like you need something else. gorillamux tends to be a commonly used helper for defining routes. On Sunday, April 30, 2017 at 2:11:59 PM UTC-4, Gaurav Rai wrote: > > Should we use frameworks like Go IRIS based on fasthttp to create > foundation of our

Re: [go-nuts] Goroutine leak?

Just add defer timer.Stop() after NewTimer... instead of explicit time.Stop() in the done case. On 04/05/2017 17:50, yuri.shakhma...@gmail.com wrote: Hello, all! There is a part of code:... // RunTimeout runs the given command with the given timeout. // If the command times out, it attempts

[go-nuts] Goroutine leak?

Hello, all! There is a part of code: ... // RunTimeout runs the given command with the given timeout. // If the command times out, it attempts to kill the process. func RunTimeout(c *exec.Cmd, timeout time.Duration) error { if err := c.Start(); err != nil { return err

Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

As so often is the question: Why? I don't believe this will ever be supported by gc; but if you think it's a good idea, you can of course do it and see whether it actually solves your problems (my prediction would be "there won't be a net change in problems", but am ready to be proven wrong). On

[go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

sometimes, I really want to some memory blocks be collected when they become unreferenced immediately.. -- 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

Re: [go-nuts] Interface-keyed maps and non-comparable dynamic key values

Just realised I accidentally replied to Ian off-list: > My question is why something that could be caught at compile time is not > > caught at compile time: > > I suspect mostly because nobody thought of it. > > That said, note that this in effect a language change. It is possible > to construct

Re: [go-nuts] "%T" verb sometimes prints the name of the source file when passed an untyped constant

Thanks Ian and Jan, I see my error now. On Thursday, May 4, 2017 at 2:27:55 PM UTC+2, Ian Lance Taylor wrote: > > On Thu, May 4, 2017 at 5:22 AM, Alberto Cortes > wrote: > > I'm sorry Jan, I still don't understand why the type of `a` is > `main.go`. > > I don't see

Re: [go-nuts] "%T" verb sometimes prints the name of the source file when passed an untyped constant

On Thu, May 4, 2017 at 2:22 PM Alberto Cortes wrote: > Can you elaborate on your answer? %T produces packageName.typeName, where 'packageName' is the name of the package where 'typeName' is defined. But the universe scope is not a package, hence no 'packageName.'. --

[go-nuts] Re: How to output coverage profile data for multiple packages?

Anyone else noticed how slow it is to run `go test` separately for every package? On Wednesday, May 4, 2016 at 2:37:57 AM UTC+3, Fabricio Godoy wrote: > > Solution for Makefile: > https://gist.github.com/13ebe8220822bc19494c8b076aabe9fc.git > > .PHONY: test-cover-html >> PACKAGES = $(shell find

Re: [go-nuts] "%T" verb sometimes prints the name of the source file when passed an untyped constant

I'm sorry Jan, I still don't understand why the type of `a` is `main.go`. Can you elaborate on your answer? On Thursday, May 4, 2017 at 2:03:06 PM UTC+2, Jan Mercl wrote: > > On Thu, May 4, 2017 at 1:54 PM wrote: > > > Can you help me explain this behaviour? > > The

Re: [go-nuts] "%T" verb sometimes prints the name of the source file when passed an untyped constant

On Thu, May 4, 2017 at 1:54 PM wrote: > Can you help me explain this behaviour? The universe scope is not a package. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] "%T" verb sometimes prints the name of the source file when passed an untyped constant

I would expect the following code to print `int`, but it prints `main.go`, which was quite a surprise for me: ``` package main import ( "fmt" ) type foo int const ( _ foo = iota a ) func main() { fmt.Printf("%T\n", a) } ``` playground link: https://play.golang.org/p/8f8sUATRwm On the other

[go-nuts] Donating to Go/related causes

Hi Burke, thanks a lot. I recently started using Go. I really would love to contribute but two things you mentioned can be more motivating. First, I need a mentor. Second, I need financial backup or support to help. Feel free to let me know what next to do. My email is sait...@gmail.com --

[go-nuts] Unreliable Network Testing

Hi, Before I re-invent the wheel: We've (all) used net.Pipe to model a network connection in testbenches. For my purposes it would be handy if I had one that was more realistic. i.e. it dropped some packets and re-ordered some, maybe even duplicated a few, added (random) delays to sending etc.

[go-nuts] Re: [ANN] listser/mutexer/channeler: generators.

hi, happy it helped! On Thursday, May 4, 2017 at 10:13:42 AM UTC+2, Ben Davies wrote: > > Interesting stuff! Thanks for the pointer on > https://github.com/mh-cbon/mutexer > , >

[go-nuts] Re: [ANN] listser/mutexer/channeler: generators.

Interesting stuff! Thanks for the pointer on https://github.com/mh-cbon/mutexer , missed that! I have noticed that the https://github.com/mh-cbon/mutexer

Re: [go-nuts] why iota can't be assigned to variables?

On 4 May 2017 at 03:52, T L wrote: > > > On Thursday, May 4, 2017 at 1:21:52 AM UTC+8, Axel Wagner wrote: >> >> On Wed, May 3, 2017 at 7:04 PM, T L wrote: >>> >>> >>> >>> On Thursday, May 4, 2017 at 12:46:47 AM UTC+8, Axel Wagner wrote: but