Re: [go-nuts] Why is this code runs sequentially?

By the way, the readers of channel must not close a channel. Only writer can closes it to indicate to reader that channel is closed and nothing can be read from it. You can let channel opens (there is no resource leak), it will be garbage collected anyway. -- You received this message because

Re: [go-nuts] Why is this code runs sequentially?

Got it! Thanks! On Friday, December 7, 2018 at 2:34:38 AM UTC-8, rog wrote: > > You want to run it concurrently, but you also need the results in order so > that you can concatenate them together in the right order (I'm assuming). > Something like this would do the trick: >

[go-nuts] [ANN] Geometric index Library

Hi, I've released a super fast and light geometric index implementing a STR-Tree. Here are some benchmarks on the size of the tree: BenchmarkSimpleRTree_FindNearestPoint/101000 124 ns/op BenchmarkSimpleRTree_FindNearestPoint/1000 300 465 ns/op

Re: [go-nuts] invalid recursive type alias

I think in the second case it is a reasonable error because the type alias has not been defined yet while the anonymous struct is being declared. On Sat, Dec 8, 2018, 9:33 AM Jan Mercl <0xj...@gmail.com wrote: > This code compiles fine > > package main > > type node struct { >

[go-nuts] Re: invalid recursive type alias

Explained in proposal : Type > cycles > > In a type alias declaration, in contrast to a type declaration, T2 must > never refer,

[go-nuts] invalid recursive type alias

This code compiles fine package main type node struct { next *node } func main() {} (https://play.golang.org/p/ZYg0EciQnOQ) This code does not package main type node = struct { next *node } func

[go-nuts] Re: TCP Listen in windows to recieve data

On Saturday, December 8, 2018 at 6:47:56 AM UTC+1, golang user wrote: > > I am bringing up TCP listener in windows OS, not sure how to recieve data > from listener and send to command line > > > IN UNIX WE DO AS FOLLOWS > > service := ":1200" > tcpAddr, err := net.ResolveTCPAddr("tcp",

Re: [go-nuts] Re: Strange glog.V(level) behavior in go.1.11.2 ?

The best thing to do would be to make a self contained example that reproduces it and file an issue at https://github.com/golang/go/issues On Sat, 8 Dec 2018, at 8:49 AM, Jan wrote: > I still haven't solved the issue (I just keep that odd line _ = ) > in the middle of the code.> > But I quickly

[go-nuts] Re: Strange glog.V(level) behavior in go.1.11.2 ?

I still haven't solved the issue (I just keep that odd line _ = ) in the middle of the code. But I quickly looked at the assembly generated, and there is some inlined code from time.go:790 (!?) oddly in the middle of the call to glog.V(). The code (a wrapper around alpha-beta-prunning