[go-nuts] Re: Client certificate not sent to server
Elaborating on the previous answer, which led me to the source of the issue
I'm facing but did not quite solve the problem.
In case you have no control over the server, you are using private CA, and
the server does not include Certificate Authorities
<https://tools.ietf.org/html/rfc8446#section-4.2.4> extension in TLS
Handshake Certificate Request, in this case golang will not include
certificates from private CAs even if they are included in the tls
configuration. This can be solved by implementing
tls.Config.GetClientCertificate and doing the cert, err :=
tls.LoadX509KeyPair(certFile, keyFile) part there.
Hope that helps.
On Wednesday, May 20, 2020 at 2:27:58 AM UTC+3 mspet...@gmail.com wrote:
> I know this is an old thread, but I found it, so others might, too.
>
> I struggled with a similar problem of the Go HTTP client not sending
> client certs when challenged by the server. Yet, curl worked fine when
> given the same client certs, calling the same server endpoint. The cert
> chains I was dealing with look like
>
> leaf + intermediate + root
>
>
> The solution for me was to provide the server (Envoy proxy) with a the
> root cert AND intermediate cert, the latter of which signed my Go client
> cert. When the server challenges the client for its cert, the server will
> send a TLS Certificate Request with, among other things, the certificate
> authority that must have signed the client cert. Without including the
> intermediate cert with the root cert on the server side, the client cannot
> not build a complete path from its client cert to the root and therefore
> cannot determine which cert to send in response. The client will not use
> tls.Config.RootCAs in this analysis (RootCAs is for validating the server
> cert chain). Moreover, when the client parses its cert with
>
> cert, err := tls.LoadX509KeyPair(*certFile, *keyFile)
>
>
> only the leaf is returned even if the certFile contains the concatenated
> intermediate.
>
> Including the full cert bundle on the server side solves this for me.
>
> Hope that helps.
>
>
>
> On Tuesday, March 17, 2015 at 10:19:01 AM UTC-7, Dots Connected wrote:
>>
>> Hello!
>>
>> I am trying to access an API served by nginx (with a self-signed SSL
>> cert) that requires client certificate authentication, and while I can
>> successfully auth with curl, I unable to accomplish the same with golang.
>>
>> Example using curl:
>>
>> # Will not work
>> curl -k https://127.0.0.1/api
>>
>> # Works
>> curl -k -E example_key+cert.pem https://127.0.0.1/api
>>
>>
>> I found an example from this list that I've tried to adapt:
>>
>> https://groups.google.com/forum/#!topic/golang-nuts/dEfqPOSccIchttps://groups.google.com/forum/#!topic/golang-nuts/dEfqPOSccIc
>>
>> <https://groups.google.com/forum/#!topic/golang-nuts/dEfqPOSccIc>
>> And another from github:
>> https://gist.github.com/michaljemala/d6f4e01c4834bf47a9c4
>>
>> Despite this, golang gets the same result as the first curl with no
>> client cert.
>> Am I missing something, or is this a regression in go?
>>
>> I'm on go version go1.4.2 linux/amd64. My code (or via
>> http://pastebin.com/LGiXZpgx):
>>
>> package main
>>
>> import (
>> "crypto/tls"
>> "io/ioutil"
>> "log"
>> "net/http"
>> )
>>
>> func main() {
>>
>> certFile := "example_cert.pem"
>> keyFile := "example_key.pem"
>>
>> // Load client cert
>> cert, err := tls.LoadX509KeyPair(certFile, keyFile)
>> if err != nil {
>> log.Fatal(err)
>> }
>>
>> // Setup HTTPS client
>> tlsConfig := &tls.Config{
>> Certificates: []tls.Certificate{cert},
>> ClientAuth: tls.RequireAndVerifyClientCert,
>> InsecureSkipVerify: true,
>> }
>> tlsConfig.BuildNameToCertificate()
>>
>> transport := &http.Transport{
>> TLSClientConfig: tlsConfig,
>> }
>> client := &http.Client{
>> Transport: transport,
>> }
>>
>> // Do GET something
>> resp, err := client.Get("https://localhost/api/";)
>> if err != nil {
>> log.Fatal(err)
>> }
>> defer resp.Body.Close()
>>
>> // Dump response
>> data, err := ioutil.ReadAll(resp.Body)
>> if err != nil {
>> log.Fatal(err)
>> }
>> log.Println(string(data))
>> }
>>
>>
--
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/dc66f3b0-36bb-4970-90e6-588282b4fbben%40googlegroups.com.
[go-nuts] Why does this struct escape to the heap?
I'm trying to reduce allocations (and improve performance) in some Go code.
There's a recurring pattern in the code where a struct is passed to a
function, and the function passes one of the struct's methods to
strings.IndexFunc. For some reason, this causes the entire struct to escape
to the heap. If I wrap the method call in an anonymous function, the struct
does not escape and the benchmarks run about 30% faster.
Here is a minimal example. In the actual code, the struct has more
fields/methods and the function in question actually does something. But
this sample code illustrates the problem. Why does the opts argument escape
to the heap in index1 but not in the functionally equivalent index2? And is
there a robust way to ensure that it stays on the stack?
type options struct {
zero rune
}
func (opts *options) isDigit(r rune) bool {
r -= opts.zero
return r >= 0 && r <= 9
}
// opts escapes to heap
func index1(s string, opts options) int {
return strings.IndexFunc(s, opts.isDigit)
}
// opts does not escape to heap
func index2(s string, opts options) int {
return strings.IndexFunc(s, func(r rune) bool {
return opts.isDigit(r)
})
}
FYI I'm running Go 1.10.3 on Linux. Thanks...
--
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 more options, visit https://groups.google.com/d/optout.
[go-nuts] Importing local package
Hello all,
Super new to Golang, loving the hell out of it, but I am running into a
small issue. I have a small application that I am working through. I can
import my models using `import ("/dojo/pkg/models")` in main.go just fine.
Now I am trying to build a `cli` package and I cannot import it. Every
time I do, I cannot use the function `QueryESXi()` that is in my esxi.go
Attached is my layout. I have tried "./cmd/cli" and "dojo/cmd/cli"... but
none are working. What am I missing? Thanks in advance.
--
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 more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Importing local package
Yes, my GOPATH and GOROOT are working fine in fact other local imports work
as intended. I made a idiotic mistake and wasted so much time googling
when I shouldve seen what I was doing wrong. I was calling `QueryESXi()`
and adding the import line. I left off the `cli.QueryESXi()`. Once I did
that importing `dojo/cmd/cli` worked like a champ. Thank you so much for
reaching out!
On Tuesday, October 9, 2018 at 1:23:22 PM UTC-5, Justin Israel wrote:
>
>
>
> On Wed, Oct 10, 2018, 5:49 AM D Whelp >
> wrote:
>
>> Hello all,
>>
>> Super new to Golang, loving the hell out of it, but I am running into a
>> small issue. I have a small application that I am working through. I can
>> import my models using `import ("/dojo/pkg/models")` in main.go just fine.
>> Now I am trying to build a `cli` package and I cannot import it. Every
>> time I do, I cannot use the function `QueryESXi()` that is in my esxi.go
>> Attached is my layout. I have tried "./cmd/cli" and "dojo/cmd/cli"... but
>> none are working. What am I missing? Thanks in advance.
>>
>
> There is a bit of missing info here. Assuming you are using a GOPATH like
> $GOPATH/src/dojo or you have a go.mod properly configured and are outside
> your GOPATH, then an import like "dojo/cmd/cli" could work. I would
> recommend sticking to absolute import paths and not using relative dot
> imports. What is the package name in your esxi.go file? The fact that it is
> in a cmd location implies that it would be a "main" package and thus not
> intended to be imported by another package.
>
>
>>
>> --
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
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 more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Importing local package
Forgive my ignorance, I am working from MacOS but realized my mistake about
20 min after I had submitted the issue I was having. The import wasnt
really the issue, it was my usage of the QueryESXi function. I was trying
to call it directly but figured out after a few hours of frustration and
googling that `cli.QueryESXi()` fixed my issue. Super noob mistake on my
part. I apologize for wasting the communities time on something so trivial
and appreciate the responses. Thanks!
On Tuesday, October 9, 2018 at 1:21:38 PM UTC-5, Constantin Konstantinidis
wrote:
>
> I don't see clearly which OS you run on, but "../cli" should work if you
> run locally.
>
> On Tuesday, October 9, 2018 at 6:49:20 PM UTC+2, D Whelp wrote:
>>
>> Hello all,
>>
>> Super new to Golang, loving the hell out of it, but I am running into a
>> small issue. I have a small application that I am working through. I can
>> import my models using `import ("/dojo/pkg/models")` in main.go just fine.
>> Now I am trying to build a `cli` package and I cannot import it. Every
>> time I do, I cannot use the function `QueryESXi()` that is in my esxi.go
>> Attached is my layout. I have tried "./cmd/cli" and "dojo/cmd/cli"... but
>> none are working. What am I missing? Thanks in advance.
>>
>>
>>
--
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 more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Load dylib without using cgo on macOS?
> > Is it possible to load a dylib without using cgo on macOS? > > Not to my knowledge. > Does anyone know the technical reason behind this? -- 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 more options, visit https://groups.google.com/d/optout.
[go-nuts] Appending to a slice of an array on the stack
Hello everyone.
I'm learning the go language and I have some questions regarding the
implementation of slices.
*$ cat slice_stack.go *
package main
import "fmt"
func main() {
stack_array := [4]int{1,2,3,4}
// !- I assume this is on the stack, like a local int[4] would be in C.
slice := stack_array[:] // Does this copy the data to the heap?
// or just get a slice to the mem on the stack?
for i := 0; i<25; i++ {
slice = append(slice, 99) // Does this copy the data to the heap on
first append?
}
fmt.Println(stack_array)
fmt.Println(slice)
}
*$ go run slice_stack.go *
[1 2 3 4]
[1 2 3 4 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99
99 99 99]
Is it common to get slices to arrays on the stack? Am I wrong when I say
*stack_array* is on the stack?
Thank you.
--
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/221259d6-8cd2-4f51-b67d-757a0f802e7b%40googlegroups.com.
[go-nuts] Re: Fuzz Testing in Go 1.18
It looks great, thanks. Probably edit out the last 2 minute end screen ;) On Tuesday, February 22, 2022 at 11:39:17 PM UTC+3 corin@gmail.com wrote: > Great job, a nice and gentle introduction. > > But what's with the 2 minute end screen? > > On Tuesday, 22 February 2022 at 3:53:07 am UTC+11 a.pl...@gmail.com wrote: > >> Hi, >> >> I recently made a video on fuzzing support in Go 1.18. I'd like to hear >> your feedback if that's possible - https://youtu.be/w8STTZWdG9Y >> >> Best, >> Alex >> > -- 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/1d6aa086-1d3d-4d42-b07a-53452bc9ed5bn%40googlegroups.com.
Re: [go-nuts] Re: Windows Binaries and stdout
It should be doable with just go code and the windows package.. CreateFile can do the same work that freopen is doing. The *CreateFile* <https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea> function enables a process to get a handle to its console's input buffer and active screen buffer, even if STDIN and STDOUT have been redirected. To open a handle to a console's input buffer, specify the CONIN$ value in a call to *CreateFile*. Specify the CONOUT$ value in a call to *CreateFile* to open a handle to a console's active screen buffer. *CreateFile* enables you to specify the read/write access of the handle that it return. On Thursday, May 5, 2022 at 1:56:43 AM UTC-4 stephen.t@gmail.com wrote: > The blog is very interesting. However, I can't see how to re-implement > this in Go with only the syscall package or the golang.org/x/sys/windows > package. It needs the functionality of C++ freopen(), which as far as I can > tell is not possible with the WinAPI - From what I can gather, ReOpen() > only works with file handles and not console handles returned by > GetStdHandle(). > > On Monday, May 2, 2022 at 2:34:03 PM UTC+1: > >> >> https://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/ >> >> -- 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/a32a24f0-fa45-44e9-b364-ac5fdc73620cn%40googlegroups.com.
[go-nuts] pure function on golang
Hi, I don't know if this kind of idea is already discussed before.
I have an idea of adding pure function marker/type on golang, it is just
like "constexpr" on C++ or "const fn" on Rust, whether this function is
evaluated at compile time if the input is known at compile time is another
discussion,
I don't think this idea is hard to implement
to my understanding, a pure function is a function that doesn't have a side
effect, so we can limit pure function to:
- unable to call non-pure function
- unable to modify a variable that is not declared on current function
(like a global variable)
for this purpose, we can think receiver as input to the function
for example:
normal pure function
purefunc Sum(data []int) int {
// any modification to data is compile error, like
// data[0] = 20
// or call to non pure function is also compile error
// data = append(data, 12)
total := 0
for _, x := range data {
total += x
}
return total
}
pure function with a receiver
type mylist struct {
data []int
}
func (l *mylist) print() {
fmt.Println(l.data)
}
purefunc (l *mylist) print2() {
// this will compile error, because fmt.Println is not purefunc
// fmt.Println(l.data)
}
purefunc (l *mylist) sum() int {
// updating l will compile error, like
// l.data[0] = 12
// l.data = []int{1, 2, 3}
// calling to non-pure function also compile error
// l.print()
total := 0
for _, x := range l.data {
total += x
}
return total
}
accepting and returning pure function
func lala(f purefunc() int) {
fmt.Println(f())
}
func doLala() {
x := &mylist{data: []int{1, 2, 3}}
lala(x.sum)
}
purefunc createAdder(x int) purefunc(int) int {
return purefunc(y int) int {
// updating x here will compile error, because x is not declared in
this function
// x += 1
return x + y
}
}
func doCreateAdder() {
var addFive purefunc(int) int = createAdder(5)
// pure function is convertible to non pure function
var addFive2 func(int) int = addFive
fmt.Println(addFive(5))
fmt.Println(addFive2(10))
}
interaction pure function with interface (we need to add keyword "pure" in
function list)
type myStruct struct {}
func (myStruct) () {}
purefunc (myStruct) () {}
func lala() {
a := myStruct{}
// this compile error, non-pure function is not convertible to pure one
// var x interface { pure () } = a
// but pure function is convertible to non-pure function
var x interface { () } = a
}
what do you guys think about this idea?
--
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/36fbf41b-0a69-4852-a9e3-09dc65edddc7o%40googlegroups.com.
[go-nuts] Why runtime force gc every 2 minutes?
Why runtime force gc every 2 minutes?, https://github.com/golang/go/blob/016e6ebb4264f4b46e505bb404953cdb410f63f2/src/runtime/proc.go#L5226 AFAIK gc will be triggered when user try to allocate memory (the mallocgc func) and if user want to force gc every 2 minutes, they can create their own goroutine to call runtime.GC() every 2 minute -- 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/0c330217-579e-442d-be4d-888b8890ccb9n%40googlegroups.com.
Re: [go-nuts] Why runtime force gc every 2 minutes?
> It's a heuristic. The Go developers probably observed that starting a GC approximately every two minutes was a reasonable trade-off between the overhead of a GC cycle and memory used. is there any stat/data on this decision? and what will happen if you make it 1 minute or 5 minutes, average CPU usage will go up? or average memory usage will go up? > Not true. Nope, it's true, but yes, not every malloc will trigger GC, https://github.com/golang/go/blob/1afa432ab93aa9adb2e0f04b6c15eb654762d652/src/runtime/malloc.go#L1203 > Requiring that level of control is generally anathema to a GC language. The language runtime should provide reasonable behavior for the vast majority of its users without requiring them to manually jump through such hoops. What you're suggesting is equivalent to saying that Go should require its users to manually manage its memory; such as with `C`. the problem with it, when you have a large live heap but with efficient code (most of the hot code is zero alloc), the runtime will be wasting CPU time every 2 minutes just to find out that there is no garbage to collect I think without forcing GC every 2 minutes the app will work fine, that is why I'm curious what kind of trade-off we make here? On Wednesday, December 8, 2021 at 9:32:39 AM UTC+7 kra...@skepticism.us wrote: > On Tue, Dec 7, 2021 at 6:20 PM Kurnia D Win wrote: > >> Why runtime force gc every 2 minutes?, >> https://github.com/golang/go/blob/016e6ebb4264f4b46e505bb404953cdb410f63f2/src/runtime/proc.go#L5226 >> > > It's a heuristic. The Go developers probably observed that starting a GC > approximately every two minutes was a reasonable trade-off between the > overhead of a GC cycle and memory used. > > >> AFAIK gc will be triggered when user try to allocate memory (the mallocgc >> func) >> > > Not true. > > >> and if user want to force gc every 2 minutes, they can create their own >> goroutine to call runtime.GC() every 2 minute >> >> Requiring that level of control is generally anathema to a GC language. > The language runtime should provide reasonable behavior for the vast > majority of its users without requiring them to manually jump through such > hoops. What you're suggesting is equivalent to saying that Go should > require its users to manually manage its memory; such as with `C`. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- 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/635b94bb-35a1-4ece-bfa9-a7de9146765cn%40googlegroups.com.
Re: [go-nuts] Why runtime force gc every 2 minutes?
okay, thanks for the explanation, suggesting me to change language to rust/c is not answering my curiosity I ask it because I'm trying to learn the runtime, and the "why" behind some decision that already made for now, I will just follow it blindly, because the go developers already made that decision thank you On Tuesday, December 14, 2021 at 3:27:18 PM UTC+7 Brian Candler wrote: > On Tuesday, 14 December 2021 at 03:28:26 UTC kurnia...@gmail.com wrote: > >> the problem with it, when you have a large live heap but with efficient >> code (most of the hot code is zero alloc), the runtime will be wasting CPU >> time every 2 minutes just to find out that there is no garbage to collect >> > > Let's say it wastes, say, 10 milliseconds every 2 minutes - and it doesn't > even stop the program for that time but runs GC in a separate thread. Is > that a big deal, in order to give reasonable behaviour across a wide range > of programs? > > If you need such fine low-level control, then maybe a different language > like Rust (or even C) might be better for your application. > >> -- 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/d3e22652-749e-49da-912f-ac344bdb2f78n%40googlegroups.com.
Re: [go-nuts] Why runtime force gc every 2 minutes?
oh, maybe they just trying random configuration (1min, 5min, or something else) and 2min is the best result On Tuesday, December 14, 2021 at 4:13:05 PM UTC+7 Kurnia D Win wrote: > okay, thanks for the explanation, > suggesting me to change language to rust/c is not answering my curiosity > I ask it because I'm trying to learn the runtime, and the "why" behind > some decision that already made > for now, I will just follow it blindly, because the go developers already > made that decision > > thank you > > On Tuesday, December 14, 2021 at 3:27:18 PM UTC+7 Brian Candler wrote: > >> On Tuesday, 14 December 2021 at 03:28:26 UTC kurnia...@gmail.com wrote: >> >>> the problem with it, when you have a large live heap but with efficient >>> code (most of the hot code is zero alloc), the runtime will be wasting CPU >>> time every 2 minutes just to find out that there is no garbage to collect >>> >> >> Let's say it wastes, say, 10 milliseconds every 2 minutes - and it >> doesn't even stop the program for that time but runs GC in a separate >> thread. Is that a big deal, in order to give reasonable behaviour across a >> wide range of programs? >> >> If you need such fine low-level control, then maybe a different language >> like Rust (or even C) might be better for your application. >> >>> -- 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/d052caa3-d339-402f-8455-114087993eb7n%40googlegroups.com.
[go-nuts] Question regarding Golang Interfaces and composite struct
Consider the following piece of code
type Dog struct {
}
type Walker interface {
Walks()
}
func (d *Dog) Walks() {
}
func CheckWalker(w Walker) {
}
func main() {
dog := Dog{}
CheckWalker(dog) -> cannot use dog (variable of type Dog) as Walker
value in argument to CheckWalker: Dog does not implement Walker (method
Walks has pointer receiver)compilerInvalidIfaceAssign
<https://pkg.go.dev/golang.org/x/tools/internal/typesinternal?utm_source%3Dgopls#InvalidIfaceAssign>
}
When I run this code I get the error as show in the red above
Now consider this piece of code
type Dog struct {
}
func (d *Dog) Walks() {
}
type Bird struct {
}
func (b *Bird) Flys() {
}
type Flyer interface {
Flys()
}
type Walker interface {
Walks()
}
type Combined interface {
Walker
Flyer
}
type Animal struct {
Dog
Bird
}
func CheckCombined(c Combined) {
}
func Check(w Walker) {
}
func main() {
animal := &Animal{}
CheckCombined(animal)
}
This code runs without any error!
Since Animal struct is compose of Dog and Bird (not pointer to them), why
this code is working where as only pointer to Dog and Bird implement the
necessary methods to satisfy the interface Combined ?
--
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/80a3498b-b1e9-4a30-a55c-ef93a53e89e4n%40googlegroups.com.
