Re: [go-nuts] reading with scanner.Bytes()

You can do b0 := scanner.Bytes() b1 := make([]byte, len(b0)) copy(b0, b1) outChannel <- b0 On Mon, Aug 29, 2016 at 8:23 PM, chris.lu via golang-nuts wrote: > I am reading a file line by line, and send it to a chan []byte, and consume > it on another goroutine. > >

[go-nuts] reading with scanner.Bytes()

I am reading a file line by line, and send it to a chan []byte, and consume it on another goroutine. However, I found I must create a new []byte, because the scanner.Bytes() returned a []byte slice that's shared, and the scanner may still write to the []byte slice. How to efficiently create a

[go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

Hi, Go1.7 is faster in most benchmarks, but still slower than Java in some benchmarks(like Go 1.6). GO Garbage Collector needs time to become mature like JVM. K-nucleotide, binary tree, Regex-dna are bad for GO(lack of fast GC and good standard libraries). But, for me, Go is an awesome

Re: [go-nuts] In case you missed it: language benchmarks for Go 1.7, and language adoption

Well, sure. I read that too. I think it is still useful that my intuition that Go is gaining adoption aligns with what prominent metrics are reporting, even if it is because the reporting changed how they measured. Eric. On Mon, Aug 29, 2016 at 5:22 PM, Ian Lance Taylor wrote:

[go-nuts] Re: Performance Counters

Thanks Diego! I will check it out. Looks like it's what I'm after. On Monday, August 29, 2016 at 2:07:34 PM UTC-4, Diego Medina wrote: > > > Hi, > > You may want to look at > > https://golang.org/pkg/expvar/ > > If your app is already running the built in server, you can > > import _ "expvar" >

Re: [go-nuts] In case you missed it: language benchmarks for Go 1.7, and language adoption

On Mon, Aug 29, 2016 at 4:51 PM, 'Eric Johnson' via golang-nuts wrote: > > And then, for language adoption, the TIOBE language index for August of > 2016: > http://www.tiobe.com/tiobe-index/ > > (Note that the above is updated every six months, and I've not been able

Re: [go-nuts] Behavior of calling (Context).Err without calling (Context).Done

On Mon, Aug 29, 2016 at 4:21 PM, Stephen Day wrote: > Recently, we were examining some ill-structured code that called > (Context).Err() without first calling (Context).Done(). Typically, this > seems to return a nil error without any guarantees as to what that means, > but

[go-nuts] certificates at /etc/ssl/certs/ getting ignored on FreeBSD

What version of Go are you using (go version)? go version devel +e6f9f39 Mon Aug 29 18:25:33 2016 + linux/amd64 Checkout 1.7 from git master branch and compiled. What operating system and processor architecture are you using (go env)? GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64"

[go-nuts] In case you missed it: language benchmarks for Go 1.7, and language adoption

Not that I think these account for much, but sort of fun to point at: https://benchmarksgame.alioth.debian.org/u64q/go.html (Short summary - now with Go 1.7, Go is faster for most benchmarks.) And then, for language adoption, the TIOBE language index for August of 2016:

[go-nuts] Behavior of calling (Context).Err without calling (Context).Done

Recently, we were examining some ill-structured code that called (Context).Err() without first calling (Context).Done(). Typically, this seems to return a nil error without any guarantees as to what that means, but this doesn't seem to be called out explicitly. Should it be required to call

Re: [go-nuts] Conditional compiling for android

you can do this for the pure linux stuff: // +build !android,linux -- 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 golang-nuts+unsubscr...@googlegroups.com. For

Re: [go-nuts] Why does context.CancelFunc exist?

So, just a note... the CancelFunc type doesn't prevent you from passing in any old func(), since those are considered effectively literals (IIRC), so they can be automatically converted to the CancelFunc type. For example: https://play.golang.org/p/QNbVXorlEQ The only time the compiler will

[go-nuts] Re: Why can't you take the address of a function's return value?

On Monday, 29 August 2016 13:36:00 UTC-4, Conrad Irwin wrote: > > because of the automatic escape detection, I no longer think of a pointer > as being the intrinsic address of a value; rather in my mind the & operator > creates a new pointer value that when dereferenced returns the value. > >

[go-nuts] Re: Why can't you take the address of a function's return value?

On Mon, Aug 29, 2016 at 10:17 AM, wrote:On Friday, 26 August 2016 23:58:53 UTC-4, T L wrote:And there is also an exception for the counter rule: map elements are not addressable.Just because you can use the assignment syntax m[k]=v to update a map element does not mean a map

[go-nuts] Re: Why can't you take the address of a function's return value?

On Friday, 26 August 2016 23:58:53 UTC-4, T L wrote: > > And there is also an exception for the counter rule: map elements are not > addressable. > Just because you can use the assignment syntax m[k]=v to update a map element does not mean a map element is a variable ("addressable"). This is

Re: [go-nuts] labeled loop vs for statement inlining

I didn't know it has more levels. thanks On Monday, August 29, 2016 at 6:09:19 PM UTC+3, Sam Whited wrote: > > On Mon, Aug 29, 2016 at 9:40 AM, Ariel Mashraki > wrote: > > Can someone please explain why doesn't the f2 function get inlined ? > > If you build with m=2

Re: [go-nuts] labeled loop vs for statement inlining

On Mon, Aug 29, 2016 at 9:40 AM, Ariel Mashraki wrote: > Can someone please explain why doesn't the f2 function get inlined ? If you build with m=2 (go build -gcflags -m=2) it will spit out a reason: > cannot inline f2: unhandled op for (closures with "for" in them

Re: [go-nuts] labeled loop vs for statement inlining

On 2016-08-29 16:59, 'Chris Manghane' via golang-nuts wrote: I can't explain exactly because my explanation is likely very flawed, but the logic you are looking for is in https://github.com/golang/go/blob/320ddcf8344beb1c322f3a7f0a251eea5e442a10/src/cmd/compile/internal/gc/inl.go#L186.

[go-nuts] labeled loop vs for statement inlining

Hello, Running `go build -gcflags -m` on the given code below will produce: main.go:3: can inline f1 main.go:24: inlining call to f1 Can someone please explain why doesn't the f2 function get inlined ? Thanks package main func f1() int { i := 0 loop: if i > 10

Re: [go-nuts] runtime: split stack overflow

On Mon, Aug 29, 2016 at 12:18 AM, wrote: >> OK, then perhaps we need setsig in os_darwin.go to set >> the sigaction field to a new function, written in assembler, like >> sigtramp, but taking just the sigaction arguments. > > > Could you please explain, why it is

[go-nuts] Re: Go package management committee

this looks great. in my dealing with different developers from non golang community, the package management has been a concern for them. for me, its no too bad once you find on the many, which can be mighty confusing for the new comer to golang. So, i really hope this committee ends up with

Re: [go-nuts] runtime: split stack overflow

> > OK, then perhaps we need setsig in os_darwin.go to set > the sigaction field to a new function, written in assembler, like > sigtramp, but taking just the sigaction arguments. Could you please explain, why it is necessary to use sa_tramp with a custom function instead of using the