Re: [go-nuts] Why fmt.Scan doesn't wait input while using in testing?

[Ian Lance Taylor]

On Fri, Mar 27, 2020 at 10:29 PM  wrote:
>
> Hello Evan, where is this `set to /dev/null` operating in the source code of 
> golang? I tried to explore it, but I didn't find it

You are replying to a message from 2012.  Many things have changed since then.

Ian


> 在 2012年2月18日星期六 UTC+8下午12:16:48，Evan Shaw写道：
>>
>> fmt.Scan reads from os.Stdin, which is set to /dev/null when testing.
>> Tests should be automated and self-contained anyway, so you don't want
>> to read from stdin.
>>
>> Either use an external file, a bytes.Buffer, or a strings.Reader and
>> call scan.Fscan if you want to scan something.
>>
>> - Evan
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/fbd04f6d-4c78-4b61-a37b-3c3a10171e36%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV2L%3D8oeD0yj0tm4PGRJW%3D6TLS1C7XpsVn8zisp_mu95Q%40mail.gmail.com.

Re: [go-nuts] Why fmt.Scan doesn't wait input while using in testing?

[ashinminisnake]

Hello Evan, where is this `set to /dev/null` operating in the source code 
of golang? I tried to explore it, but I didn't find it

在 2012年2月18日星期六 UTC+8下午12:16:48，Evan Shaw写道：
>
> fmt.Scan reads from os.Stdin, which is set to /dev/null when testing.
> Tests should be automated and self-contained anyway, so you don't want
> to read from stdin.
>
> Either use an external file, a bytes.Buffer, or a strings.Reader and
> call scan.Fscan if you want to scan something.
>
> - Evan
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fbd04f6d-4c78-4b61-a37b-3c3a10171e36%40googlegroups.com.

Re: [go-nuts] Re: Conversion to Complex numbers

[Ian Lance Taylor]

On Fri, Mar 27, 2020 at 9:27 AM  wrote:
>
>
> On Friday, 27 March 2020 16:16:18 UTC, Stephen Illingworth wrote:
>>
>>
>>
>> On Friday, 27 March 2020 15:58:19 UTC, Brian Candler wrote:
>>>
>>> On Friday, 27 March 2020 15:42:08 UTC, stephen.i...@gmail.com wrote:

 // float -> complex

 const constFloat = 1

>>>
>>> Did you mean const constFloat = 1.0 ?
>>
>>
>> Yes. Results are the same.
>
>
> Corrected test program. Results are the same:
>
> package main
>
> import "testing"
>
> // int -> complex
>
> const constInt = 1
>
> func TestConstInt(t *testing.T) {
> _ = complex64(constInt)
> }
>
> const constIntExplicit = int(1)
>
> func TestConstIntExplicit(t *testing.T) {
> _ = complex64(constIntExplicit)
> }
>
> func TestVarInt(t *testing.T) {
> varInt := 1
> _ = complex64(varInt)
> }
>
> func TestVarIntExplicit(t *testing.T) {
> varIntExplicit := int(1)
> _ = complex64(varIntExplicit)
> }
>
> // float -> complex
>
> const constFloat = 1.0
>
> func TestConstFloat(t *testing.T) {
> _ = complex64(constFloat)
> }
>
> const constFloatExplicit = float64(1.0)
>
> func TestConstFloatExplicit(t *testing.T) {
> _ = complex64(constFloatExplicit)
> }
>
> func TestVarFloat(t *testing.T) {
> varFloat := 1.0
> _ = complex64(varFloat)
> }
>
> func TestVarFloatExplicit(t *testing.T) {
> varFloatExplicit := float64(1.0)
> _ = complex64(varFloatExplicit)
> }


The language spec does not support conversions between ints/floats and
complex numbers.  The exact rules are written down at
https://golang.org/ref/spec#Conversions.

But it's interesting that the behavior of typed constants changed
between 1.13 and 1.14.  I suspect that was changed in
https://golang.org/cl/187657.  The spec is not precisely clear on how
typed constant values should be handled.  Please open a bug report for
that case at https://golang.org/issue.  Thanks.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUo8jgfyJiYnO0PVg8wRZOOejo%3DU9S5c2oRQ0VeFj5Grg%40mail.gmail.com.

Re: [go-nuts] Go course

[Owen Waller]

Hi Dave,
As the original author of the post that Dan has referenced, I can say
that Go does indeed make IMHO a good first programming language. It all
comes down to how you explain things. Thanks Dan for the reference :)
I'm not going to repeat what the original discussion said, but let me
try to pick out a few things.
I was teaching the very young - 10 & 11 year olds. So I had to simplify
things down quite a bit. So I didn't cover things like:
* functions - arguments vs parameters I thought this was just too to
big a step. Yes they used functions, but they didn't write them,
including functions with no parameters and no return values.
* structs - again its just to big a jump. You can do a lot with just
numbers and strings
* Local vs global variables - again too big a jump and doesn't make
sense without functions.
* Anything you might think of as advanced - so concurrency, testing,
packages and modules, file and network IO, even errors etc I left out.
With an older group I'd put all of those back in except concurrency,
starting with functions, then packages, then IO. 
But that still leaves the key things that all programming languages
have in common namely variables, instruction sequencing, selection and
repetition. In the UK this is what they have to cover at this age
group. This is also the order I introduce these in, and over about 15
hours. So I let them work slowly. At least at this age group typing is
still an issue, so they need time just for that.
Static typing I did not find to be a problem at all. The way I
approached it was simple. Kids already have a good grasp of numbers
(whole and fractions and decimals fractions) and words at this age. So
they know that writing "hello+world" in English makes no sense. The "+"
symbol is only used with numbers. So "1+1" does make sense in a
different context. 
All I had to do was ask the kids did they think they needed a number or
a word for a variable type? If they where reading a variable from the
keyboard that they had to use in a sum, they can work out they need a
number not a word. If all they wanted to do was echo the variable back
- say their name - then they work out it's a word. It takes a few
hours, but within 3-4 hours most of the kids have worked it out. After
that its just a syntax and typing problem.
You'll find that having the types helps the kids reason about the
programs. This is something I personally find very difficult with
python and other typeless languages. It's very hard to reason about an
old bit of code because you don't know what the valid operations or
data range is of a type, which especially if it a named well helps you
reason about the logic. So with kids I would say you want to be as
explicit as possible. Static typing helps with this.
The way I introduced numbers was subtle, but matches what they
typically see in maths at that age. So a number is an int type
initially. Only when we need fractions did I introduce float64, and I
only talked about those two numeric types (so no int8 or float32). And
I talk about numbers not int or float64, unless I have to be specific.
Words are simply strings, that's just a new name they have to learn and
associate with a sequence of characters/letters. They get this really
quickly.
The other approach I took was that I gave them partially completed Go
programs, where the level of completion tails off each session. So I
did this for two reasons. Firstly to cover a bit of boiler plate,
things like the import statements and the main() function header. I do
talk about these and the partial programs also explain these in the
comments but I don't expect the kids to type these lines. Secondly I
want them to focus on whatever was key to that session.
The programs are heavily commented to both explain what is there
already and what and where I want them to fill in the blanks.
And since the programs are incomplete they won't compile and run to
begin with. So they kids have to get he correct syntax from the get go.
That's just the same as in English, you have to have the correct
spelling and grammar, so the kids have a similar concept at that age.
If you do this they'll absorb things like main() and import just
because they will be familiar. So they'll spot it if you leave it out
after a few weeks. Or be able to complete an import statement (if you
tell them the package name) just by coping a previous example.
My last trick was as I kept things to keyboard IO, I had a little
wrapper package that hid the complexity of the text scanner class and
converting form strings to ints etc that the programs used.
So to give you an idea of what I had them doing, they where printing
"Hello " after inputting their name, working out how fast the
ISS goes in orbit and the orbital period and comparing that to
geostationary satellites, doing ROT13 encryption (so A becomes  N) (in
the UK they have to learn about Caesar ciphers at this age), getting
them to print hello world in non-Latin languages (again works well with
a 

[go-nuts] Re: Conversion to Complex numbers

[stephen . illingworth]

On Friday, 27 March 2020 16:16:18 UTC, Stephen Illingworth wrote:
>
>
>
> On Friday, 27 March 2020 15:58:19 UTC, Brian Candler wrote:
>>
>> On Friday, 27 March 2020 15:42:08 UTC, stephen.i...@gmail.com wrote:
>>>
>>> // float -> complex
>>>
>>> const constFloat = 1
>>>
>>>
>> Did you mean const constFloat = 1.0 ?
>>
>
> Yes. Results are the same. 
>

Corrected test program. Results are the same:

package main

import "testing"

// int -> complex

const constInt = 1

func TestConstInt(t *testing.T) {
_ = complex64(constInt)
}

const constIntExplicit = int(1)

func TestConstIntExplicit(t *testing.T) {
_ = complex64(constIntExplicit)
}

func TestVarInt(t *testing.T) {
varInt := 1
_ = complex64(varInt)
}

func TestVarIntExplicit(t *testing.T) {
varIntExplicit := int(1)
_ = complex64(varIntExplicit)
}

// float -> complex

const constFloat = 1.0

func TestConstFloat(t *testing.T) {
_ = complex64(constFloat)
}

const constFloatExplicit = float64(1.0)

func TestConstFloatExplicit(t *testing.T) {
_ = complex64(constFloatExplicit)
}

func TestVarFloat(t *testing.T) {
varFloat := 1.0
_ = complex64(varFloat)
}

func TestVarFloatExplicit(t *testing.T) {
varFloatExplicit := float64(1.0)
_ = complex64(varFloatExplicit)
}
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3332e4d4-edb9-4948-9a32-ae035fd110ad%40googlegroups.com.

[go-nuts] Re: Conversion to Complex numbers

[stephen . illingworth]

On Friday, 27 March 2020 15:58:19 UTC, Brian Candler wrote:
>
> On Friday, 27 March 2020 15:42:08 UTC, stephen.i...@gmail.com wrote:
>>
>> // float -> complex
>>
>> const constFloat = 1
>>
>>
> Did you mean const constFloat = 1.0 ?
>

Yes. Results are the same. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5432c674-a237-493d-924c-9337b074156b%40googlegroups.com.

[go-nuts] Re: Conversion to Complex numbers

[Brian Candler]

On Friday, 27 March 2020 15:42:08 UTC, stephen.i...@gmail.com wrote:
>
> // float -> complex
>
> const constFloat = 1
>
>
Did you mean const constFloat = 1.0 ?

>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cadcfeb6-d19c-411d-b1c4-e0e86853b80f%40googlegroups.com.

[go-nuts] Conversion to Complex numbers

[stephen . illingworth]

Hello,

Conversion to complex numbers should be done with the complex builtin 
function, specifying a real and imaginary part. However, is casting to a 
complex type supported or not? Empirically, it seems to me that sometimes 
it is and sometimes it isn't. More confusing is that this behaviour changed 
between version 1.13.6 and 1.14.

Using this test program.

package main

import "testing"

// int -> complex

const constInt = 1

func TestConstInt(t *testing.T) {
_ = complex64(constInt)
}

const constIntExplicit = int(1)

func TestConstIntExplicit(t *testing.T) {
_ = complex64(constIntExplicit)
}

func TestVarInt(t *testing.T) {
varInt := 1
_ = complex64(varInt)
}

func TestVarIntExplicit(t *testing.T) {
varIntExplicit := int(1)
_ = complex64(varIntExplicit)
}

// float -> complex

const constFloat = 1

func TestConstFloat(t *testing.T) {
_ = complex64(constFloat)
}

const constFloatExplicit = float64(1)

func TestConstFloatExplicit(t *testing.T) {
_ = complex64(constFloatExplicit)
}

func TestVarFloat(t *testing.T) {
varFloat := 1
_ = complex64(varFloat)
}

func TestVarFloatExplicit(t *testing.T) {
varFloatExplicit := float64(1)
_ = complex64(varFloatExplicit)
}


Summary of results:


1.13.6  
1.14.1 
const int y y 
const int (explicit type) y n 
variable int n n 
variable int (explicit type) n n 
const float y y 
const float (explicit type) y n 
variable float n n 
variable float (explicit type)   
n n 


I wouldn't want to argue too strongly on this point but for consistency, 
should casting be allowed at all?


Regards

Stephen Illingworth

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e09492c7-bbb0-4ff7-865f-d3d7ea57937f%40googlegroups.com.

Re: [go-nuts] Re: Slice reuse + GC

[Jan Mercl]

On Fri, Mar 27, 2020 at 8:19 AM Leszek Kubik  wrote:

> A fix for the situation of the topic could be implemented by the slice type. 
> Imagine, if a slice value not only shared the pointer to the underlying 
> buffer but also a list with references to all other slices holding on to the 
> underlying buffer then such operation as s = s[x:y] could walk the list, find 
> and free all unreferenced values in the underlying buffer (perhaps even 
> assigning zero value to have consistent behavior regardless of []T or []*T). 
> Such operation would be deterministic. Of course there could be an 
> optimization in place, whenever the slice was derived from a named array, 
> just keep some flag instead of the list of references to all other slices. I 
> don't see how GC could achieve that in a consistent way since the GC may not 
> even do the swipe between calls like s = s[:x]; s = s[:cap(x)]. Unfortunately 
> I'm afraid that this would break some existing code (even if we also trim the 
> cap property) thus keeping in mind the original notion of a slice as a window 
> to some array makes sense to me.

For many, if not most programs the current approach is quite ok. The
suggested solution is non trivial, especially in terms of runtime and
memory consumption costs. Not only _all_ programs will get slower, but
the added memory overhead can sometimes dwarf the memory savings.

If a specific program has the problem of "zombie" slice elements,
which is BTW the same problem as keeping a short string sliced from of
a huge string, then in both the cases the solution is to make a copy
of the part that is needed to keep, thus allowing the GC to take care
of the original backing array.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WVFpUQDmf0oohmCG4tfSstUcszVJcgNnbAHs%2BJxHM%3DXg%40mail.gmail.com.

[go-nuts] Re: Go course

[Miki Tebeka]

I'm curious if you find https://www.353solutions.com/annotated-go helpful?

On Wednesday, March 25, 2020 at 6:57:23 PM UTC+2, Renato Marcandier wrote:
>
> Hello guys,
>
> What's the best course to start with Go?
>
>
>
> Regards
> RG
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/119c3ed7-06ac-460b-9883-3d9d8285713e%40googlegroups.com.

Re: [go-nuts] Re: Golang and the mobile framework

[Wojciech S. Czarnecki]

Dnia 2020-03-26, o godz. 22:18:40
husam alkdary  napisał(a):

> which one react-native or Flutter ? and how ?

https://www.arputer.com/using-go-library-in-flutter

hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20200327092110.7cf340dc%40xmint.

[go-nuts] Re: Golang and the mobile framework

[Brian Candler]

You can write your frontend UI in react-native (using Javascript) or 
flutter (using Dart), and the API backend in Go.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/34b76471-deb3-4683-aad9-f31065b7e53b%40googlegroups.com.

Re: [go-nuts] Re: Slice reuse + GC

[Leszek Kubik]

Wait, by saying it would be nice to have the GC not trace elements between 
len and cap, you mean it would be nice to have GC recognize unreferenced 
elements of a slice between len and cap and free them (presumably if they 
are pointer or interface types)?

OK, I would say Go has quirks but I'm the type of an engineer who doesn't 
expect things to work as I like them but I dig how it actually works and 
live with that. In my opinion Go (or the Go tutorials) advertise slices too 
much, perhaps the problem is that there's no handy builtin list type with 
nice language sugar.

A fix for the situation of the topic could be implemented by the slice 
type. Imagine, if a slice value not only shared the pointer to the 
underlying buffer but also a list with references to all other slices 
holding on to the underlying buffer then such operation as s = s[x:y] could 
walk the list, find and free all unreferenced values in the underlying 
buffer (perhaps even assigning zero value to have consistent behavior 
regardless of []T or []*T). Such operation would be deterministic. Of 
course there could be an optimization in place, whenever the slice was 
derived from a named array, just keep some flag instead of the list of 
references to all other slices. I don't see how GC could achieve that in a 
consistent way since the GC may not even do the swipe between calls like s 
= s[:x]; s = s[:cap(x)]. Unfortunately I'm afraid that this would break 
some existing code (even if we also trim the cap property) thus keeping in 
mind the original notion of a slice as a window to some array makes sense 
to me.

As a side note, I think the append function has quirks too, so it's easy to 
make mistakes until you dig into it. The function signature shows it 
returns a new slice so it's easy to jump to conclusion that you can safely 
modify the new slice without affecting the original one, or on the other 
hand jump to conclusion that writes made to this slice would be seen in 
other slices. It all depends how you initially form the idea of what the 
slice type is.


On Friday, March 27, 2020 at 1:06:16 AM UTC+1, Keith Randall wrote:
>
> It's common practice to *write* to elements between the length and 
> capacity of a slice.  Usually, you use append to do that.
> It's bad practice to *read* elements between the length and capacity. 
> Which you can't do with a simple indexing op, of course. You would have to 
> reslice larger and then index.
> In that sense, it would be nice to have the GC not trace elements between 
> len and cap. They should be dead if you never read them, only write them. 
> It's hard to do in the GC, it requires a language change, etc. But it would 
> be nice.
>
>
> On Thursday, March 26, 2020 at 12:29:04 PM UTC-7 leszek...@gmail.com 
> wrote:
>
>>
>>
>>
>>> I disagree. I do that all the time. It's also how `append` was 
>>> implemented before it existed as a predeclared function. It's also, FWIW, 
>>> used in bytes.Buffer . I 
>>> agree that unless your API is very clear about it, you shouldn't really 
>>> access a slice past the length for one of your arguments. But there *are* 
>>> APIs where it's clear that's happening (e.g. anything having "append" in 
>>> it's doc-string) and there are use-cases where you control the slice for 
>>> its entire lifetime and where it can make code more readable.
>>>
>>
>>  I didn't even know that append wasn't there, but since we have it isn't 
>> it meant to be used in the first place?
>> Of course if we check the capacity, expanding past len is safe, like 
>> s[:cap(s)]. I would check the capacity only in case when I really don't 
>> want to end with a new slice buffer as a result of appending more than the 
>> available space.
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4975efcd-4d31-4be0-9b34-03d125f096a9%40googlegroups.com.

[go-nuts] Re: Print something while read message from server with websocket

[洪嘉鴻]

I'm sorry that I didn't remind that my Client code does not compile.
I've tried your example  with 
SetReadDeadline 
().
It seems like what I want to do.

Thank you very much!
  Max

Jake Montgomery於 2020年3月27日星期五 UTC+8上午1時12分07秒寫道：
>
> Your Client  code does not 
> compile. As a courtesy to those trying to help, it is always good to test 
> your code before posting it. A working example, without your "busy" 
> messages would be something like: https://play.golang.org/p/cvgwd8GDobc . 
> The Read() method documentation 
>  says "Read 
> implements the io.Reader interface." So I suggest you *carefully *read 
> the io.Reader documentation , because 
> it requires very specific handling to be done correctly. 
>
> Also, I did note that golang.org/x/net/websocket documentation 
>  states that: "This package 
> currently lacks some features found in alternative and more actively 
> maintained WebSocket packages." So you may want to consider using one of 
> those. 
>
> I have not actually used golang.org/x/net 
> /websocket myself, but there is a 
> SetReadDeadline 
> () 
> function. Because I have not used the package before, there may be some 
> hidden pitfalls that I am missing, but this code seems to do what you want, 
> using SetReadDeadline 
> (): 
> https://play.golang.org/p/ISUR7c_Mtqb
>
> Good luck
>
> On Wednesday, March 25, 2020 at 8:56:57 PM UTC-4, 洪嘉鴻 wrote:
>>
>> I'm sorry.
>> The followings are the complete codes of server and client:
>> Server 
>> Client 
>>
>> Thank you very much!
>>   Max
>>
>> Jake Montgomery於 2020年3月25日星期三 UTC+8下午9時28分37秒寫道：
>>>
>>> You do not provide enough information to give a really good answer. 
>>> There are a number of ways to achieve this, but they depend on the details. 
>>> A more complete example would help. 
>>>
>>> What is the type of `ws`? If it is something on which you can set a read 
>>> timeout, then one way would be to set a timeout, and loop.
>>>
>>> On Wednesday, March 25, 2020 at 4:10:19 AM UTC-4, 洪嘉鴻 wrote:

 Hello everyone:
   The version of the golang which I am using is 1.12.9 with Win10.
   I want to print something while the client is waiting for server.
   The following are the partial code of server and client.

   Server:
   time.Sleep(time.Second * 100)
   ws.Write([]byte("Hello!"))
   
   Client:
   while(!ws.Read(msg)){
   fmt.Println("Please wait because server is busy.")  
   }

   Can anyone suggest how to fix the code?

   Any help is appreciated.
   Thank you very much!
   Max

>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ac4c3a2d-9305-4775-bc84-a91c8661bc38%40googlegroups.com.