Re: [go-nuts] Reading os.Stdin, Unbuffered

That is not Go specific; the OS does the line-buffering. You could use e.g. termbox to disable that. On Tue, Nov 28, 2017 at 6:12 AM, dc0d wrote: > For example I want the program to exit, if any key has been pressed on >

Re: [go-nuts] Reading os.Stdin, Unbuffered

For example I want the program to exit, if any key has been pressed on keyboard. I can not find any way to skip the wait for a necessary split character (like '\n'). On Monday, November 27, 2017 at 6:36:35 PM UTC+3:30, Jan Mercl wrote: > > On Mon, Nov 27, 2017 at 4:00 PM dc0d

Re: [go-nuts] Google Cloud Golang SDK authentication

Hi Salman, There are broadly two types of authorization on GCP: user accounts and service accounts. User account tokens will act on behalf of a particular end-user, and service account tokens will act on behalf of that service account. I'm not exactly sure which one is right for your

[go-nuts] Telegram bot

How to check member join channel by bot? So that the robot does not work until members are join -- 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

[go-nuts] Re: CfP Go Devroom FOSDEM 2018

Hey Francesc, Will there be any lightning talk slots available for the devroom? I've submitted a full length talk proposal elsewhere but would be happy to submit a lightning talk proposal for the Go devroom, if that's an option. Thanks for your time! On Monday, October 9, 2017 at 4:24:31 PM

Re: [go-nuts] Reading os.Stdin, Unbuffered

On Mon, Nov 27, 2017 at 4:00 PM dc0d wrote: > Is there a way to read from `os.Stdin` in an unbuffered way? (Not waiting for a `\n` or anything). n, err := os.Stdin.Read(buf) does not wait for `\n`. Or do you actually mean setting a terminal in raw mode?

[go-nuts] Reading os.Stdin, Unbuffered

Is there a way to read from `os.Stdin` in an unbuffered way? (Not waiting for a `\n` or anything). -- 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] Re: Interface value terminology

On Mon, Nov 27, 2017 at 3:02 PM, Stefan Nilsson < trolleriprofess...@gmail.com> wrote: > Sure, using a type descriptor to implement the dynamic type is an > implementation detail. but the fact that an interface value consists of a > concrete value and a dynamic type is part of the spec. I find it

Re: [go-nuts] Re: Interface value terminology

On Mon, Nov 27, 2017 at 3:18 PM Stefan Nilsson wrote: > I fully understand that this can be implemented in many different ways. That's not my question. Splitting words about "consists of" and "has a" doesn't add much to the discussion. I think the distinction is

Re: [go-nuts] Re: Interface value terminology

I fully understand that this can be implemented in many different ways. That's not my question. Splitting words about "consists of" and "has a" doesn't add much to the discussion. On Monday, November 27, 2017 at 3:12:31 PM UTC+1, Jan Mercl wrote: > > On Mon, Nov 27, 2017 at 3:02 PM Stefan

Re: [go-nuts] Re: Interface value terminology

On Mon, Nov 27, 2017 at 3:02 PM Stefan Nilsson wrote: > Sure, using a type descriptor to implement the dynamic type is an implementation detail. but the fact that an interface value consists of a concrete value and a dynamic type is part of the spec. The value of

Re: [go-nuts] Re: Interface value terminology

Sure, using a type descriptor to implement the dynamic type is an implementation detail. but the fact that an interface value consists of a concrete value and a dynamic type is part of the spec. I find it unfortunate that there is no common agreement on the terminology. That's why I'm asking.

Re: [go-nuts] Re: Interface value terminology

On Mon, Nov 27, 2017 at 2:42 PM, Stefan Nilsson < trolleriprofess...@gmail.com> wrote: > I see the dynamic type, which is part of every interface variable, as more > than an implementation detail. > Yes. But not the type descriptor. Which is why I tried to emphasize the difference :) The

Re: [go-nuts] Re: Interface value terminology

On Mon, Nov 27, 2017 at 2:43 PM Stefan Nilsson wrote: Having a dynamic type does not imply having a/any type descriptor included in the value of an interface variable. That's why it's an implementation detail. -- -j -- You received this message because you

[go-nuts] Re: Interface value terminology

I see the dynamic type, which is part of every interface variable, as more than an implementation detail. The language spec, which is typically very careful to avoid talking about implementation issues, explicitly states that an interface variable has a dynamic type: Variables of interface

[go-nuts] Re: profiling webserver with pprof and router middleware

The go tool pprof command is interactive, so I thought it is enough type 'png' to get the image after the benchmark is run I tested to start go tool pprof now as well during and after the benchmark -> nothing changes Am Montag, 27. November 2017 04:37:48 UTC+1 schrieb Karan Chaudhary: > > From

Re: [go-nuts] Interface value terminology

Just my personal usage/2¢: 1. An interface-value/The value of an interface 2. The dynamic value 3. The dynamic type x. Concrete type, to me, is a static type that is not an interface type. y. Concrete value, to me, might sometimes be used interchangeably with dynamic value. Or it might refer to

Re: [go-nuts] Problems with JSON Marshal/UnmarshalText aand maps

It seems that time.Time as keys exhibit the same issue: https://play.golang.org/p/-_H3ZD6YLG Is this really intended or a bug? mån 27 nov. 2017 kl 11:25 skrev Henrik Johansson : > There is a discussion here >

Re: [go-nuts] Interface value terminology

I’ve adopted terminology from other OO languages and people seem to have understood me. > 1. the value of an interface (both parts), This is the “interface value”. > 2. the concrete value, The “boxed value”. > 3. the type descriptor. No need to talk about it specifically. Worst case, it is

Re: [go-nuts] Problems with JSON Marshal/UnmarshalText aand maps

There is a discussion here https://groups.google.com/forum/#!searchin/golang-dev/json$20map/golang-dev/5gSHNrJQpUI/vZGSGRmUrC0J and an issue here: https://github.com/golang/go/issues/12146 At least the issue has an initial example with a value type key mån 27 nov. 2017 kl 11:21 skrev James

Re: [go-nuts] Problems with JSON Marshal/UnmarshalText aand maps

Think UnmarshalText needs to have a pointer receiver or you'll only be modifying a copy of the struct On 27 November 2017 at 23:13, Henrik Johansson wrote: > Hi, > > https://play.golang.org/p/bLiYSsKL_7 > > I have perhaps missed something simple or misunderstood the

[go-nuts] Problems with JSON Marshal/UnmarshalText aand maps

Hi, https://play.golang.org/p/bLiYSsKL_7 I have perhaps missed something simple or misunderstood the contract for MarshalText/UnmarshalText but it seems to me that it should work it just doesn't... :) If I uncomment the return of the parse error "BOOM" then I just get a new "default" key with 3

Re: [go-nuts] Interface value terminology

On Mon, Nov 27, 2017 at 9:13 AM Stefan Nilsson wrote: > My question. How do you refer to the following three concepts (and why): > > 1. the value of an interface (both parts), The value of/in the interface variable. Why: No alternative comes to my mind. > 2. the

[go-nuts] Interface value terminology

An interface value in Go consists of two parts: a concrete value and a type descriptor. What is the preferred terminology when talking about this? The language specification says "dynamic value" and "dynamic type". However, this doesn't seem to have caught on. The term "concrete value" seems

[go-nuts] Re: Python ⇒ Go Cheatsheet

Oops, I missed that one. On Monday, November 27, 2017 at 7:44:03 AM UTC+1, Miki Tebeka wrote: > > Thanks! I do show sort.Strings there (first one). > > On Saturday, November 25, 2017 at 1:31:31 PM UTC+2, Stefan Nilsson wrote: >> >> Very nice! >> >> Just one comment: you may want to use