FAQ
I have built a cli tool for retrieving HN stories and while i don't want
EOF errors in stdout, they get printed.

resp, err := http.Get(url)
if err != nil {
if err != io.EOF {
fmt.Println(err)
}
return nil, err
}
Might it be that HTTP GET EOF errors do not correspond to io.EOF?
Here
<https://github.com/kargakis/whatabout/blob/5d1524543f0e019fac4160c4792362f2ab392784/whatabout.go#L215>
is all the code in debug branch.
Can anyone else reproduce this? Just run the tool a couple of times and you
should see an EOF error.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Dave Cheney at Nov 25, 2014 at 2:50 pm
    Try printing the type of the error with %T,that might give some clues.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Edward Muller at Nov 25, 2014 at 5:41 pm

    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.

    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }

    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
       fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Nov 25, 2014 at 10:19 pm
    Someone is feeding your program bad data. There is no http client action as the URLs is garbage. You can create the client more explicitly rather than using the Get helper which will give you more opportunities to handle errors at the appropriate place.


    On 26 Nov 2014, at 04:41, Edward Muller wrote:

    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.
    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }
    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
    fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sdq1jy8Mfso/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Edward Muller at Nov 26, 2014 at 4:07 am

    On Nov 25, 2014, at 2:19 PM, Dave Cheney wrote:

    Someone is feeding your program bad data. There is no http client action as the URLs is garbage. You can create the client more explicitly rather than using the Get helper which will give you more opportunities to handle errors at the appropriate place.
    May, but I see this *all* the time talking to services that we control through a HTTPS ELB on Amazon.

    I even have a test case to re-produce it (because I couldn’t figure out why `if err == io.EOF` wasn’t working)….
    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L37

    If I stick a `fmt.Printf(“%+T\n”, err)` right before this line (https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L100), I get a `*url.Error` when I execute the test case. This is exactly what happens in production (we run thousands of these).

    I've seen it in other code bases as well where people where like “but I have an `if err == io.EOF` and it’s not catching EOFs.
    On 26 Nov 2014, at 04:41, Edward Muller wrote:

    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.

    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }

    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
    fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sdq1jy8Mfso/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Edward Muller at Nov 26, 2014 at 4:12 am
    Also, looking through my splunk logs I see it wrapping the following:

    : i/o timeout" errtype="*url.Error”
    : net/http: timeout awaiting response headers" errtype="*url.Error”
    : EOF" errtype="*url.Error”
    : lookup …………….: Temporary failure in name resolution" errtype="*url.Error”

    PS: If I’m doing something wrong I’d love to learn why and change it.
    On Nov 25, 2014, at 8:07 PM, Edward Muller wrote:

    On Nov 25, 2014, at 2:19 PM, Dave Cheney wrote:

    Someone is feeding your program bad data. There is no http client action as the URLs is garbage. You can create the client more explicitly rather than using the Get helper which will give you more opportunities to handle errors at the appropriate place.
    May, but I see this *all* the time talking to services that we control through a HTTPS ELB on Amazon.

    I even have a test case to re-produce it (because I couldn’t figure out why `if err == io.EOF` wasn’t working)….
    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L37

    If I stick a `fmt.Printf(“%+T\n”, err)` right before this line (https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L100), I get a `*url.Error` when I execute the test case. This is exactly what happens in production (we run thousands of these).

    I've seen it in other code bases as well where people where like “but I have an `if err == io.EOF` and it’s not catching EOFs.
    On 26 Nov 2014, at 04:41, Edward Muller wrote:

    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.

    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }

    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
    fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sdq1jy8Mfso/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Nov 26, 2014 at 4:31 am
    I recommend using http.NewRequest to separate creating the request from issuing it.


    On 26 Nov 2014, at 15:12, Edward Muller wrote:

    Also, looking through my splunk logs I see it wrapping the following:

    : i/o timeout" errtype="*url.Error”
    : net/http: timeout awaiting response headers" errtype="*url.Error”
    : EOF" errtype="*url.Error”
    : lookup …………….: Temporary failure in name resolution" errtype="*url.Error”

    PS: If I’m doing something wrong I’d love to learn why and change it.
    On Nov 25, 2014, at 8:07 PM, Edward Muller wrote:

    On Nov 25, 2014, at 2:19 PM, Dave Cheney wrote:

    Someone is feeding your program bad data. There is no http client action as the URLs is garbage. You can create the client more explicitly rather than using the Get helper which will give you more opportunities to handle errors at the appropriate place.
    May, but I see this *all* the time talking to services that we control through a HTTPS ELB on Amazon.

    I even have a test case to re-produce it (because I couldn’t figure out why `if err == io.EOF` wasn’t working)….
    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L37

    If I stick a `fmt.Printf(“%+T\n”, err)` right before this line (https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L100), I get a `*url.Error` when I execute the test case. This is exactly what happens in production (we run thousands of these).

    I've seen it in other code bases as well where people where like “but I have an `if err == io.EOF` and it’s not catching EOFs.
    On 26 Nov 2014, at 04:41, Edward Muller wrote:

    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.

    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }

    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
    fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sdq1jy8Mfso/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Edward Muller at Nov 26, 2014 at 4:37 am

    On Nov 25, 2014, at 8:31 PM, Dave Cheney wrote:

    I recommend using http.NewRequest to separate creating the request from issuing it.
    We do.

    https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L124

    On 26 Nov 2014, at 15:12, Edward Muller wrote:

    Also, looking through my splunk logs I see it wrapping the following:

    : i/o timeout" errtype="*url.Error”
    : net/http: timeout awaiting response headers" errtype="*url.Error”
    : EOF" errtype="*url.Error”
    : lookup …………….: Temporary failure in name resolution" errtype="*url.Error”

    PS: If I’m doing something wrong I’d love to learn why and change it.
    On Nov 25, 2014, at 8:07 PM, Edward Muller wrote:

    On Nov 25, 2014, at 2:19 PM, Dave Cheney wrote:

    Someone is feeding your program bad data. There is no http client action as the URLs is garbage. You can create the client more explicitly rather than using the Get helper which will give you more opportunities to handle errors at the appropriate place.
    May, but I see this *all* the time talking to services that we control through a HTTPS ELB on Amazon.

    I even have a test case to re-produce it (because I couldn’t figure out why `if err == io.EOF` wasn’t working)….
    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L37

    If I stick a `fmt.Printf(“%+T\n”, err)` right before this line (https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L100), I get a `*url.Error` when I execute the test case. This is exactly what happens in production (we run thousands of these).

    I've seen it in other code bases as well where people where like “but I have an `if err == io.EOF` and it’s not catching EOFs.
    On 26 Nov 2014, at 04:41, Edward Muller wrote:

    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.

    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }

    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
    fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sdq1jy8Mfso/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Nov 26, 2014 at 4:54 am
    Right, but it's all mixed up in that post method. Somehow a dud url is getting into that method and its bailing early. Can you put more verification in to prevent that bad url?


    On 26 Nov 2014, at 15:37, Edward Muller wrote:

    On Nov 25, 2014, at 8:31 PM, Dave Cheney wrote:

    I recommend using http.NewRequest to separate creating the request from issuing it.
    We do.

    https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L124

    On 26 Nov 2014, at 15:12, Edward Muller wrote:

    Also, looking through my splunk logs I see it wrapping the following:

    : i/o timeout" errtype="*url.Error”
    : net/http: timeout awaiting response headers" errtype="*url.Error”
    : EOF" errtype="*url.Error”
    : lookup …………….: Temporary failure in name resolution" errtype="*url.Error”

    PS: If I’m doing something wrong I’d love to learn why and change it.
    On Nov 25, 2014, at 8:07 PM, Edward Muller wrote:


    On Nov 25, 2014, at 2:19 PM, Dave Cheney wrote:

    Someone is feeding your program bad data. There is no http client action as the URLs is garbage. You can create the client more explicitly rather than using the Get helper which will give you more opportunities to handle errors at the appropriate place.
    May, but I see this *all* the time talking to services that we control through a HTTPS ELB on Amazon.

    I even have a test case to re-produce it (because I couldn’t figure out why `if err == io.EOF` wasn’t working)….
    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L37

    If I stick a `fmt.Printf(“%+T\n”, err)` right before this line (https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L100), I get a `*url.Error` when I execute the test case. This is exactly what happens in production (we run thousands of these).

    I've seen it in other code bases as well where people where like “but I have an `if err == io.EOF` and it’s not catching EOFs.
    On 26 Nov 2014, at 04:41, Edward Muller wrote:


    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.

    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }

    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
    fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sdq1jy8Mfso/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Edward Muller at Nov 26, 2014 at 5:13 am

    On Nov 25, 2014, at 8:54 PM, Dave Cheney wrote:

    Right, but it's all mixed up in that post method. Somehow a dud url is getting into that method and its bailing early. Can you put more verification in to prevent that bad url?
    It’s not a bad URL. Really. It’s not.

    The URLs are valid. We parse them on startup using url.Parse() and the program aborts if they’re not parseable.

    We have thousands of log shuttle’s in production sending data all the time.

    The errors we’re seeing are transient errors (yay distributed systems).

    My point is that http.Client.Do(req) is returning these errors wrapped in *url.Error.

    See the test case.

    The url that uses is the url from net/http/httptest’s NewTLSServer()

    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L40

    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L42

    AFAICT if net/http’s doFollowingRedirects, which is what Do() calls, breaks out of the redirect tracking loop if c.send(req) returns an error, which it most likely the case here. Then it wraps err in a *url.Error and returns that, which comes back to us from Do().

    Maybe this has something to do with the custom client we construct?

    https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L56

    We can’t use the default client’s timeouts they’re not strict enough and when this code was written you couldn’t just set a Timeout on a http client and have it do the right thing (TBH: I’m not 100% sure it does 100% the right thing now, but I haven’t read through all the net/http code in a while and what we have was *working*).
    On 26 Nov 2014, at 15:37, Edward Muller wrote:
    On Nov 25, 2014, at 8:31 PM, Dave Cheney wrote:

    I recommend using http.NewRequest to separate creating the request from issuing it.
    We do.

    https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L124

    On 26 Nov 2014, at 15:12, Edward Muller wrote:

    Also, looking through my splunk logs I see it wrapping the following:

    : i/o timeout" errtype="*url.Error”
    : net/http: timeout awaiting response headers" errtype="*url.Error”
    : EOF" errtype="*url.Error”
    : lookup …………….: Temporary failure in name resolution" errtype="*url.Error”

    PS: If I’m doing something wrong I’d love to learn why and change it.
    On Nov 25, 2014, at 8:07 PM, Edward Muller wrote:

    On Nov 25, 2014, at 2:19 PM, Dave Cheney wrote:

    Someone is feeding your program bad data. There is no http client action as the URLs is garbage. You can create the client more explicitly rather than using the Get helper which will give you more opportunities to handle errors at the appropriate place.
    May, but I see this *all* the time talking to services that we control through a HTTPS ELB on Amazon.

    I even have a test case to re-produce it (because I couldn’t figure out why `if err == io.EOF` wasn’t working)….
    https://github.com/heroku/log-shuttle/blob/master/shuttle/outlet_test.go#L37

    If I stick a `fmt.Printf(“%+T\n”, err)` right before this line (https://github.com/heroku/log-shuttle/blob/master/shuttle/http_outlet.go#L100), I get a `*url.Error` when I execute the test case. This is exactly what happens in production (we run thousands of these).

    I've seen it in other code bases as well where people where like “but I have an `if err == io.EOF` and it’s not catching EOFs.
    On 26 Nov 2014, at 04:41, Edward Muller wrote:

    On Nov 25, 2014, at 6:33 AM, Michalis Kargakis wrote:

    I have built a cli tool for retrieving HN stories and while i don't want EOF errors in stdout, they get printed.

    resp, err := http.Get(url)
    if err != nil {
    if err != io.EOF {
    fmt.Println(err)
    }
    return nil, err
    }

    Might it be that HTTP GET EOF errors do not correspond to io.EOF?
    Here is all the code in debug branch.
    Can anyone else reproduce this? Just run the tool a couple of times and you should see an EOF error.
    The errors end up being wrapped in a net/url.Error

    I’ve ended up handling it something like this in the past….

    if err, ok := err.(*url.Error); ok && err.Err != io.EOF {
    fmt.Println(err)
    }

    There may be a better way and if so I’m interested too.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sdq1jy8Mfso/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 25, '14 at 2:33p
activeNov 26, '14 at 5:13a
posts10
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase