Re: [go-nuts] golang closure variable

On Wed, Nov 2, 2016 at 11:48 PM, 刘桂祥 wrote: > I just want to look what variable datastructure is passed to the closure > func but I am confused with the assemble code > > > // example.go > > package main > > > import "time" > > > func main() { > > s := []int{100, 200} > > func() { > > s[0] = 300

Re: [go-nuts] golang closure variable

I just want to look what variable datastructure is passed to the closure func but I am confused with the assemble code // example.go package main import "time" func main() { s := []int{100, 200} func() { s[0] = 300 s = []int{300, 400} }() time.Sleep(1 * time.Second) } And I

Re: [go-nuts] golang closure variable

On Wed, Nov 2, 2016 at 8:03 PM, 刘桂祥 wrote: > > In golang closure func ,the needed outer variable is passed by reference > > but when the variable self is a reference in example.go , the closure func > paras is *[&map[int]int,...] is so ? I'm not completely sure what you are asking, but I think t

[go-nuts] Re: Error when using go tool trace

On Tuesday, October 11, 2016 at 7:21:17 AM UTC-7, xavier zebier wrote: > > C:\repo\gonew\src\github.com\tixu\trace>go tool trace Trace > 2016-10-11T153554.out > 2016/10/11 15:36:45 Parsing trace... > failed to parse trace: no EvFrequency event > > Can you help me .? > > Thanks in advance, > > X

[go-nuts] golang closure variable

In golang closure func ,the needed outer variable is passed by reference but when the variable self is a reference in example.go , the closure func p

Re: [go-nuts] nil slices

This explanation is awesome! 在 2012年7月12日星期四 UTC+8上午12:42:41，Paul Borman写道： > > This has nothing to do with it being nil. The following always fails: > > s[len(s)] = hello > > The length of a nil slice is 0. > > You can "add" to a nil slice, "add" is spelled "append". > > -Paul > > On Wed

Re: [go-nuts] Re: Float32 math and slice arithmetics using SIMD

On Tue, Nov 1, 2016 at 8:58 PM, Ondrej wrote: > It seems that a universal binary, as Go requires it, would be slow on > dispatch, because there would be too much checking for individual intrinsics > support. Do I understand it correctly, that to overcome this, people either > compile natively (whi

[go-nuts] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

I just discovered this thread. I used to be an avid reader of Golang-nuts mailing list, also of Golang-dev and I am in disbelief at what it has come to recently. Aram Hăvărneanu is a very important contributor to the Go Language Project, I feel embarrased on behalf of the of the Go Language P

Re: [go-nuts] Context cancellation

You said the function would return whether it got cancelled or not, so I assumed something like err := foo.CallAPI(ctx), which would be awkward to return without actually canceling. Yes, if the function is documented to return with background activity, it's of course fine. That said, It's extremel

Re: [go-nuts] Context cancellation

In a concurrent world, assuming that a call to cancel means that thing actually got cancelled is dubious at best. For example, you could call cancelFunc, then immediately enter a GC pause, the other goroutine finishes their work in a orderly fashion, you unpause and close the underlying channel. Ve

Re: [go-nuts] Context cancellation

On Thu, Nov 3, 2016 at 1:27 AM, Axel Wagner wrote: > That is actually a great point I haven't thought about and the crux of the > matter (sorry for repeating it, but I think it's worth making very > explicit): > > While cancelFunc can only be called from the goroutine that created the > context,

Re: [go-nuts] Context cancellation

That is actually a great point I haven't thought about and the crux of the matter (sorry for repeating it, but I think it's worth making very explicit): While cancelFunc can only be called from the goroutine that created the context, Err can be called downstack. Meaning, if I call cancelFunc, a ca

Re: [go-nuts] Context cancellation

On Wed, Nov 2, 2016 at 9:11 PM, Ian Davis wrote: > On Wed, Nov 2, 2016, at 10:35 PM, Gustavo Niemeyer wrote: > > Hello there, > > On Wed, Nov 2, 2016 at 11:09 AM, Ian Davis wrote: > > > > On Wed, Nov 2, 2016, at 12:56 PM, 'Axel Wagner' via golang-nuts wrote: > > AIUI: A child or grandchild funct

Re: [go-nuts] Context cancellation

On Wed, Nov 2, 2016, at 10:35 PM, Gustavo Niemeyer wrote: > Hello there, > > On Wed, Nov 2, 2016 at 11:09 AM, Ian Davis wrote: >> __ >> >> On Wed, Nov 2, 2016, at 12:56 PM, 'Axel Wagner' via golang- >> nuts wrote: >>> AIUI: A child or grandchild function is not supposed to signal that. >>> They ca

Re: [go-nuts] Context cancellation

Hello there, On Wed, Nov 2, 2016 at 11:09 AM, Ian Davis wrote: > On Wed, Nov 2, 2016, at 12:56 PM, 'Axel Wagner' via golang-nuts wrote: > > AIUI: A child or grandchild function is not supposed to signal that. They > can return an error and let the parent cancel, or they can create their own > ch

Re: [go-nuts] How to convert struct type to another struct type？

So, this is a known issue and is addressed in 1.8 https://github.com/golang/go/issues/16085#issuecomment-258016579 On Wednesday, November 2, 2016 at 6:05:02 PM UTC-4, Camilo Aguilar wrote: > > It seems they can't be converted due to the field tags being different :/ > > On Wednesday, November 2,

Re: [go-nuts] How to convert struct type to another struct type？

It seems they can't be converted due to the field tags being different :/ On Wednesday, November 2, 2016 at 6:01:29 PM UTC-4, Camilo Aguilar wrote: > > I have a similar need. I'm using gRPC and some of my domain types are > similar to the protobuffer messages, they pretty much have the same fiel

Re: [go-nuts] How to convert struct type to another struct type？

I have a similar need. I'm using gRPC and some of my domain types are similar to the protobuffer messages, they pretty much have the same fields and types but the struct type is different. I haven't been able to convert them using normal means, is there any suggestion about how to go about it t

Re: [go-nuts] gopkg.in updated: snap, Let's Encrypt, etc

There are some conversations in the wild related to that, but I have no proper information or opinion about it. The limitations I described are purely technical. The git binary in distributions as recent as 2014 linked with a gnutls library that was unable to take the available ciphers. It was wor

Re: [go-nuts] gopkg.in updated: snap, Let's Encrypt, etc

> On Nov 2, 2016, at 1:09 PM, Gustavo Niemeyer wrote: > > The problem was that git from very recent distributions linked against gnutls > and did not support elliptic curve certificates. > Did something happen that made elliptic curve certificates undesirable? -- You received this message be

[go-nuts] Re: gomobile - error building android library on osx

Hi, Please file a new issue with the reproduction steps and the source for a (minimal) Go package that demonstrates the problem. Feel free to CC me on the issue. - elias On Tuesday, November 1, 2016 at 1:33:07 PM UTC+1, Danilo Luiz Rheinheimer Danilo wrote: > > Hi, > > I have a gomobile li

[go-nuts] Re: gopkg.in updated: snap, Let's Encrypt, etc

Okay, it's back up and working properly with older git clients. The problem was that git from very recent distributions linked against gnutls and did not support elliptic curve certificates. Hacking the library to ask Let's Encrypt for RSA certificates instead fixed the problem. On Wed, Nov 2, 2

Re: [go-nuts] Re: type assertion: Can I DRY this up?

On 2 November 2016 at 14:44, Bill Warner wrote: > Same thing, but keys can be ints. https://play.golang.org/p/2YssTy0dY5 I considered that, but I think that in practice []string is easier to deal with than []interface{} for a set of indexes, and you'll need to deal with an error in both cases. In

[go-nuts] ActiveState seeking Go community feedback

Hi all, At ActiveState we see Go as one of the languages of the future and we want to help advocate for the language, help the community, and spur enterprise adoption of it. As part of that effort, in 2017 we will be providing a community- and enterprise-ready Go distribution on a variety of

Re: [go-nuts] How to create a reflect.Type for a primitve type?

On Wed, Nov 2, 2016 at 7:08 AM, wrote: > > This seems like it should be simple but I can't find it. How can I create a > reflect.Type for a built-in type *without* starting from an instance? > Something like a set of Type constants, reflect.IntType, reflect.StringType > etc. for all bulit-in typ

Re: [go-nuts] Oxymoron: language spec: ``untyped boolean value''

Thanks. I may have been imprecise using ``implementation specific''. I did not mean it in the C-like manner that the ``meaning'' of some (typed) value depends on the platform (length of some words) or the choice of the compiler writer for a given platform. I meant more: the _terminology_ of

Re: [go-nuts] Re: type assertion: Can I DRY this up?

Same thing, but keys can be ints. https://play.golang.org/p/2YssTy0dY5 On 11/2/16 4:33 AM, roger peppe wrote: I'd suggest something like this: https://play.golang.org/p/w1Vxg6b2Ey Not too much repeated code there, and no need for the reflect package either. cheers, rog. On 1 November

Re: [go-nuts] Re: type assertion: Can I DRY this up?

That's an embarrassingly huge improvement. thx On 11/2/16 4:33 AM, roger peppe wrote: I'd suggest something like this: https://play.golang.org/p/w1Vxg6b2Ey Not too much repeated code there, and no need for the reflect package either. cheers, rog. On 1 November 2016 at 17:13, wrote:

[go-nuts] How to create a reflect.Type for a primitve type?

This seems like it should be simple but I can't find it. How can I create a reflect.Type for a built-in type *without* starting from an instance? Something like a set of Type constants, reflect.IntType, reflect.StringType etc. for all bulit-in types. I'd like to do this: func myChanT(t reflect

Re: [go-nuts] Oxymoron: language spec: ``untyped boolean value''

On Wed, Nov 2, 2016 at 4:27 AM, Martin Steffen wrote: > > So calling the use of "ok" an ``untyped boolean'' it seems a bit > Go-specific (and/or go-implementation-centric) > terminology. Indeed the section about "constants" (mentioned in an earlier > reply) sheds some light, in > that it's a spe

Re: [go-nuts] Context cancellation

On Wed, Nov 2, 2016, at 12:56 PM, 'Axel Wagner' via golang-nuts wrote: > AIUI: A child or grandchild function is not supposed to signal that. > They can return an error and let the parent cancel, or they can create > their own child context WithCancel and cancel that. Context doesn't > replace exce

Re: [go-nuts] Context cancellation

AIUI: A child or grandchild function is not supposed to signal that. They can return an error and let the parent cancel, or they can create their own child context WithCancel and cancel that. Context doesn't replace exceptions. You should consider context a way to implement dynamic scoping

Re: [go-nuts] Context cancellation

On Wed, Nov 2, 2016, at 12:12 PM, Axel Wagner wrote: > From https://godoc.org/context > >> Failing to call the CancelFunc leaks the child and its children until >> the parent is canceled or the timer fires. The go vet tool checks >> that CancelFuncs are used on all control-flow paths. > > I'm not s

Re: [go-nuts] Context cancellation

>From https://godoc.org/context Failing to call the CancelFunc leaks the child and its children until the > parent is canceled or the timer fires. The go vet tool checks that > CancelFuncs are used on all control-flow paths. I'm not sure how it's *meant* to be used, but a way to do it, while adh

[go-nuts] Context cancellation

Hi all, I'm trying to understand the idioms around cancellation of contexts. I've read the godoc and the relevant blog (https://blog.golang.org/context). Should you always call the cancelFunc of a cancellable context? Or should it only be called if the operation is terminated before successful co

Re: [go-nuts] Oxymoron: language spec: ``untyped boolean value''

On Wed, Nov 2, 2016 at 12:27 PM Martin Steffen wrote: > "An untyped constant has a default type" (*) > > sounds ``oxymoronic'' to the unsuspecting: something is called "untyped" > _but_ at the same time ``has a type''. It has no type. It acquires one when 1) being assigned to something that has

Re: [go-nuts] Oxymoron: language spec: ``untyped boolean value''

Thanks for all the replies. Basically it is more like a puzzlement over choice of terminology, not so much what the meaning resp. purpose of the ``special form'' of assignments (with ``ok'') is. So calling the use of "ok" an ``untyped boolean'' it seems a bit Go-specific (and/or go-implement

[go-nuts] Re: gopkg.in updated: snap, Let's Encrypt, etc

I've reverted it temporarily as I'm observing a large number of these messages, certainly from old git clients: tls: no cipher suite supported by both client and server Will investigate and redeploy soon. On Wed, Nov 2, 2016 at 8:32 AM, Gustavo Niemeyer wrote: > Hello all, > > After compla

Re: [go-nuts] Oxymoron: language spec: ``untyped boolean value''

It means there is no specific type name, but the resultant type must either be bool or convertible to bool: type A bool var n int var ok A n, ok = x.(int) Using bool here is not common, but you see this with int and float, etc. Untyped constants is one of the most prominent Go features. > On N

[go-nuts] gopkg.in updated: snap, Let's Encrypt, etc

Hello all, After complaints about the previous StartCom TLS certificate, it was moved over to Let's Encrypt's dynamic generation of certificates using the autocert package [1]. It's also been updated to be deployed as a snap [2], which means it's better confined inside its system and a bit easier

Re: [go-nuts] Re: type assertion: Can I DRY this up?

I'd suggest something like this: https://play.golang.org/p/w1Vxg6b2Ey Not too much repeated code there, and no need for the reflect package either. cheers, rog. On 1 November 2016 at 17:13, wrote: > Basically, the idea is: given a json structure, and a list of strings or > integers, tre

Re: [go-nuts] Oxymoron: language spec: ``untyped boolean value''

On Wed, Nov 2, 2016 at 9:09 AM Martin Steffen wrote: > How should one interpret that? If ok behaves like a boolean, why is it considered as untyped? Because, in this special case, it really is untyped. It works the same way as untyped {int,float,...} constants, ie. an untyped bool value is assig

Re: [go-nuts] Oxymoron: language spec: ``untyped boolean value''

It's a constant literal until it's used in a typed context. This section explains it in detail: https://golang.org/ref/spec#Constants On Wed, Nov 2, 2016 at 6:09 AM, Martin Steffen wrote: > Hi, in the language spec, e.g. in connection with ``type assertions'' and > ``special forms'', like > >

[go-nuts] Oxymoron: language spec: ``untyped boolean value''

Hi, in the language spec, e.g. in connection with ``type assertions'' and ``special forms'', like v, ok = x.(T) it's stated that it yield (in ok) an additional value which is both untyped and boolean (an ``untyped boolean value''). How should one interpret that? If ok behaves like a boolean,