Re: [go-nuts] interactive debugger for go ??

[Florin Pățan]

As a small note, you need only the plugin, we ship delve with it so you don't 
need to install it.

Also gdb is known to be unsupported and i would not recommend it. Delve is the 
Go debugger.

-- 
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] interactive debugger for go ??

[Jan Mercl]

On Thu, Sep 8, 2016 at 10:37 AM Florin Pățan  wrote:

> Delve is the Go debugger.

fmt.Printf is the Go debugger.  /ducks

-- 

-j

-- 
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] interactive debugger for go ??

[Rob Pike]

I use fmt.Println more than fmt.Printf when debugging, but I admit I used
dlv yesterday, briefly, to look at a zillion thread stacks and within its
limitations it was helpful.

-rob


On Thu, Sep 8, 2016 at 7:19 PM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Thu, Sep 8, 2016 at 10:37 AM Florin Pățan 
> wrote:
>
> > Delve is the Go debugger.
>
> fmt.Printf is the Go debugger.  /ducks
>
> --
>
> -j
>
> --
> 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.
>

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Sep 7, 2016 at 8:16 AM, T L > 
> wrote: 
> > 
> > On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote: 
> >> 
> >> On Wed, Sep 7, 2016 at 4:54 PM T L  wrote: 
> >> 
> >> https://golang.org/doc/go1compat 
> >> 
> > 
> > Then how to write compatibility safe atomic pointer reads/writes code? 
> Do I 
> > must use atomic.Value for pointers? 
>
> Perhaps you could explain what kind of compatibility risk you are 
> concerned about that is not covered by the Go 1 compatibility 
> guarantee.  Please give an example of code that will work today but 
> that you think may stop working in future releases.  Thanks. 
>

As the go1compat  says unsafe package is 
not promised to keep compatibility, 
so I think atomic.Load/Store/SwapPointer functions are also not promised to 
keep compatibility, am I right?
 

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

Re: [go-nuts] Why don't the embedded T1 and T2 clash?

[T L]

Thank all for the explanation.

On Thursday, September 8, 2016 at 7:07:14 AM UTC+8, xiio...@gmail.com wrote:
>
>
>
> On Wednesday, 7 September 2016 15:59:50 UTC+1, Jan Mercl wrote:
>>
>> On Wed, Sep 7, 2016 at 4:42 PM T L  wrote:
>>
>> See https://golang.org/ref/spec#Selectors and explain why do you think a 
>> clash should happen.
>> -- 
>>
>> -j
>>
>
> More specifically this (in the spec)
>
> "For a value x of type T or *T where T is not a pointer or interface type, 
> x.f denotes the field or method at the shallowest depth in T where there is 
> such an f."
>
>
> Covers the above behaviour 
>
> and (from the same section)
>
> " If there is not exactly one f with shallowest depth, the selector 
> expression is illegal."
>
>
> is not the case here - so works..
>
> Thanks for bringing this up - is actually quite an obscure point. 
>

-- 
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: How to get Network speed in linux using golang

[kumargv]

I am using CGO to get network speed.
package main

/*
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int get_interface_speed(char *ifname){
int sock;
struct ifreq ifr;
struct ethtool_cmd edata;
int rc;
sock = socket(AF_INET, SOCK_STREAM, 0);
// string copy first argument into struct
strncpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
ifr.ifr_data = &edata;
// set some global options from ethtool API
edata.cmd = ETHTOOL_GSET;
// issue ioctl
rc = ioctl(sock, SIOCETHTOOL, &ifr);

close(sock);

if (rc < 0) {
perror("ioctl");// lets not error out here
// make sure to zero out speed
return 0;
}

return edata.speed;
}
*/
import "C"

import (
"fmt"
"unsafe"
)

func main() {
ifname := []byte("eth0\x00")// interface name eth0,eth1,wlan0 etc.
sp := C.get_interface_speed((*C.char)(unsafe.Pointer(&ifname[0])))
fmt.Println(sp)
}

Please give some suggestion .


On Monday, March 28, 2016 at 5:21:59 PM UTC+5:30, kumargv wrote:
>
> i am able to get new_inbytes,prev_inbytes,new_outbytes,prev_outbytes  From 
> /proc/net/dev file . 
>
>
>  inbytes means recived
>
>  outbyte means transmite 
>
>  fmt.Println("new_inbytes : ",new_inbytes," prev_inbytes : ",prev_inbytes)
>
> if new_inbytes >= prev_inbytes{
>
> in_traffic = ( ( (new_inbytes - prev_inbytes) * 8 ) /  (delta_time) )
>
> fmt.Println("in_traffic : ",in_traffic)
>
> }
>
> fmt.Println("new_outbytes : ",new_outbytes," prev_outbytes : 
> ",prev_outbytes)
>
> if new_outbytes >= prev_outbytes{
>
> out_traffic = ( ( (new_outbytes -  prev_outbytes) * 8) / (delta_time))
>
> fmt.Println("out_traffic : ",out_traffic)
>
> }
>
>  if speed > 0{
>
> in_utilization = (in_traffic / (speed * 1))
>
> out_utilization = (out_traffic / (speed * 1))
>
> }
>
>
>
> The Speed variable i am not able to find .
>
> please help.
>
> 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.

Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[Jakob Borg]

tors 8 sep. 2016 kl 12:46 skrev T L :

>
> On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor
> wrote:
>
>> Perhaps you could explain what kind of compatibility risk you are
>> concerned about that is not covered by the Go 1 compatibility
>> guarantee.  Please give an example of code that will work today but
>> that you think may stop working in future releases.  Thanks.
>>
>
> As the go1compat  says unsafe package
> is not promised to keep compatibility,
> so I think atomic.Load/Store/SwapPointer functions are also not promised
> to keep compatibility, am I right?
>

But package sync/atomic is not package unsafe,  so why would you think that?

//jb

-- 
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] Re: Ideas for a Go interpeter, feedback requested

[HWJ]

I have semi-concrete plans for such a port after I am done with
sparc64 and arm64 SSA.

That's really interesting!


PS: perhaps, instead of "vm" or "varch", the GOARCH should be named "dis" :)

I'd suggest GOARCH=n32k.

--
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] Re: Ideas for a Go interpeter, feedback requested

[Seb Binet]

On Thu, Sep 8, 2016 at 1:29 PM, HWJ  wrote:

> I have semi-concrete plans for such a port after I am done with
>> sparc64 and arm64 SSA.
>>
> That's really interesting!


FYI, these semi-concrete plans were exposed here:
 https://github.com/go-interpreter/proposal/issues/1#issuecomment-242975215


>
> PS: perhaps, instead of "vm" or "varch", the GOARCH should be named "dis"
>> :)
>>
> I'd suggest GOARCH=n32k.

that's indeed a better suited arch-y name :)

-s

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

On Thursday, September 8, 2016 at 7:00:33 PM UTC+8, Jakob Borg wrote:
>
> tors 8 sep. 2016 kl 12:46 skrev T L >:
>
>>
>> On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor 
>> wrote:
>>
>>> Perhaps you could explain what kind of compatibility risk you are 
>>> concerned about that is not covered by the Go 1 compatibility 
>>> guarantee.  Please give an example of code that will work today but 
>>> that you think may stop working in future releases.  Thanks. 
>>>
>>
>> As the go1compat  says unsafe package 
>> is not promised to keep compatibility, 
>> so I think atomic.Load/Store/SwapPointer functions are also not promised 
>> to keep compatibility, am I right?
>>
>  
> But package sync/atomic is not package unsafe,  so why would you think 
> that?
>

Aren't the parameters of atomic.Load/Store/SwapPointer functions 
(*)unsafe.Pointer?
 

>
> //jb
>

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[Jan Mercl]

On Thu, Sep 8, 2016 at 2:51 PM T L  wrote:

> Aren't the parameters of atomic.Load/Store/SwapPointer functions
(*)unsafe.Pointer?

Yes, they are. Using any package API that involves unsafe.Pointer implies
your program must "import unsafe" to use it. And that means your program is
not covered by the Go compatibility promise. TBH, I did not realize that
before. But don't panic yet! Backward incompatible changes to package
unsafe are not common, nor very likely in the future, even though
recently-ish the rules for messing with unsafe.Pointer actually were
changed, IIRC.

-- 

-j

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[Henrik Johansson]

Or maybe it works the other way? Because sync/atomic is covered then by
accidental extension so is unsafe.

tors 8 sep. 2016 kl 15:00 skrev Jan Mercl <0xj...@gmail.com>:

> On Thu, Sep 8, 2016 at 2:51 PM T L  wrote:
>
> > Aren't the parameters of atomic.Load/Store/SwapPointer functions
> (*)unsafe.Pointer?
>
> Yes, they are. Using any package API that involves unsafe.Pointer implies
> your program must "import unsafe" to use it. And that means your program is
> not covered by the Go compatibility promise. TBH, I did not realize that
> before. But don't panic yet! Backward incompatible changes to package
> unsafe are not common, nor very likely in the future, even though
> recently-ish the rules for messing with unsafe.Pointer actually were
> changed, IIRC.
>
> --
>
> -j
>
> --
> 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.
>

-- 
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] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

[T L]

With the enough initial size, the underlying hashtable of the new map will 
never need to be realloced in the whole copy process.

-- 
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] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

[Jan Mercl]

On Thu, Sep 8, 2016 at 3:32 PM T L  wrote:

> With the enough initial size, the underlying hashtable of the new map
will never need to be realloced in the whole copy process.

For example

dst := make(map[T]U, len(src))

See also https://golang.org/ref/spec#Making_slices_maps_and_channels

BTW: The whole "never need to be realloced in the whole copy process" thing
depends on unspecified implementation details and to me it feels like
premature optimization. Especially if not supported by first doing some
benchmarks that proved the/any/substantial difference.
-- 

-j

-- 
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] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

[T L]

On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote:
>
> On Thu, Sep 8, 2016 at 3:32 PM T L > 
> wrote:
>
> > With the enough initial size, the underlying hashtable of the new map 
> will never need to be realloced in the whole copy process.
>
> For example
>
> dst := make(map[T]U, len(src))
>

Will setting the second parameter as len(src) make sure the length of the 
underlying hashtable is large enough?
It looks the official docs doesn't confirm this.
 

>
> See also https://golang.org/ref/spec#Making_slices_maps_and_channels
>
> BTW: The whole "never need to be realloced in the whole copy process" 
> thing depends on unspecified implementation details and to me it feels like 
> premature optimization. Especially if not supported by first doing some 
> benchmarks that proved the/any/substantial difference.
> -- 
>
> -j
>

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[Ian Lance Taylor]

On Thu, Sep 8, 2016 at 3:46 AM, T L  wrote:
>
> On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Wed, Sep 7, 2016 at 8:16 AM, T L  wrote:
>> >
>> > On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote:
>> >>
>> >> On Wed, Sep 7, 2016 at 4:54 PM T L  wrote:
>> >>
>> >> https://golang.org/doc/go1compat
>> >>
>> >
>> > Then how to write compatibility safe atomic pointer reads/writes code?
>> > Do I
>> > must use atomic.Value for pointers?
>>
>> Perhaps you could explain what kind of compatibility risk you are
>> concerned about that is not covered by the Go 1 compatibility
>> guarantee.  Please give an example of code that will work today but
>> that you think may stop working in future releases.  Thanks.
>
>
> As the go1compat says unsafe package is not promised to keep compatibility,
> so I think atomic.Load/Store/SwapPointer functions are also not promised to
> keep compatibility, am I right?

No.  The Go 1 compatibility document doesn't say that anything about
the unsafe package can change.  It says that packages that use unsafe
"may depend on internal properties of the Go implementation."  That is
not intended to mean that such packages depend on internal properties
merely because they import unsafe.  It is intended to mean that
packages that import unsafe may then (perhaps accidentally) use the
unsafe values in ways that depend on internal properties.  The
atomic.Load/Store/SwapPointer functions don't use the unsafe values in
any way at all.  They just move the values around.  That is always
going to be OK.

Even if it somehow wasn't, the Go 1 compatibility guarantee does cover
the sync/atomic package.  That package is guaranteed to remain
compatible, so atomic.Load/Store/SwapPointer will continue to work as
they do today, even if the unsafe package somehow, unimaginably,
changes so that they don't.

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

Re: [go-nuts] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

[Ian Lance Taylor]

On Thu, Sep 8, 2016 at 7:21 AM, T L  wrote:
>
> On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote:
>>
>> On Thu, Sep 8, 2016 at 3:32 PM T L  wrote:
>>
>> > With the enough initial size, the underlying hashtable of the new map
>> > will never need to be realloced in the whole copy process.
>>
>> For example
>>
>> dst := make(map[T]U, len(src))
>
>
> Will setting the second parameter as len(src) make sure the length of the
> underlying hashtable is large enough?

Yes.

> It looks the official docs doesn't confirm this.

The docs say "map of type T with initial space for n elements"
(https://golang.org/ref/spec#Making_slices_maps_and_channels).  What
else would you want them to say?

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

Re: [go-nuts] JPEG to RGB issues

[Joshua Barone]

Thanks Nigel.

That explains what I'm seeing.

On Wednesday, September 7, 2016 at 8:41:17 PM UTC-5, Nigel Tao wrote:
>
> JPEG is not a pixel-exact format, even in YCbCr color space. Different 
> Discrete Cosine Transformation implementations may produce slightly 
> different YCbCr and hence RGB values, and still be considered valid 
> JPEG implementations. 
>
> For example, libjpeg is just one software implementation, in one 
> programming language, but it has multiple FDCT / IDCT implementations 
> (e.g. 4 different jidct???.c files). Some use floating point math. 
> Some use fixed point (integer) math, especially useful if your CPU 
> doesn't support floating point in hardware. Some implementations are 
> "fast", which are indeed as advertised, but have worse quality on some 
> measures. They're all valid, spec-compliant implementations, but they 
> have different rounding errors, and won't give identical RGB results 
> on all inputs. 
>
> Newer image formats like WebP have tightened up the variety in valid 
> decodings, but JPEG is what it is. 
>
> I'm therefore unsurprised that Go's decoding can differ slightly from 
> whatever OpenCV uses. 
>

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Sep 8, 2016 at 3:46 AM, T L > 
> wrote: 
> > 
> > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Wed, Sep 7, 2016 at 8:16 AM, T L  wrote: 
> >> > 
> >> > On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl 
> wrote: 
> >> >> 
> >> >> On Wed, Sep 7, 2016 at 4:54 PM T L  wrote: 
> >> >> 
> >> >> https://golang.org/doc/go1compat 
> >> >> 
> >> > 
> >> > Then how to write compatibility safe atomic pointer reads/writes 
> code? 
> >> > Do I 
> >> > must use atomic.Value for pointers? 
> >> 
> >> Perhaps you could explain what kind of compatibility risk you are 
> >> concerned about that is not covered by the Go 1 compatibility 
> >> guarantee.  Please give an example of code that will work today but 
> >> that you think may stop working in future releases.  Thanks. 
> > 
> > 
> > As the go1compat says unsafe package is not promised to keep 
> compatibility, 
> > so I think atomic.Load/Store/SwapPointer functions are also not promised 
> to 
> > keep compatibility, am I right? 
>
> No.  The Go 1 compatibility document doesn't say that anything about 
> the unsafe package can change.  It says that packages that use unsafe 
> "may depend on internal properties of the Go implementation."  That is 
> not intended to mean that such packages depend on internal properties 
> merely because they import unsafe.  It is intended to mean that 
> packages that import unsafe may then (perhaps accidentally) use the 
> unsafe values in ways that depend on internal properties.  The 
> atomic.Load/Store/SwapPointer functions don't use the unsafe values in 
> any way at all.  They just move the values around.  That is always 
> going to be OK. 
>
> Even if it somehow wasn't, the Go 1 compatibility guarantee does cover 
> the sync/atomic package.  That package is guaranteed to remain 
> compatible, so atomic.Load/Store/SwapPointer will continue to work as 
> they do today, even if the unsafe package somehow, unimaginably, 
> changes so that they don't. 
>
> Ian 
>

Thanks for the confirmation. 

It would be clearer to write down "unsafe package and unsafe.Pointer will 
be there for ever" in docs.
 

-- 
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] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

[T L]

On Thursday, September 8, 2016 at 10:57:10 PM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Sep 8, 2016 at 7:21 AM, T L > 
> wrote: 
> > 
> > On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote: 
> >> 
> >> On Thu, Sep 8, 2016 at 3:32 PM T L  wrote: 
> >> 
> >> > With the enough initial size, the underlying hashtable of the new map 
> >> > will never need to be realloced in the whole copy process. 
> >> 
> >> For example 
> >> 
> >> dst := make(map[T]U, len(src)) 
> > 
> > 
> > Will setting the second parameter as len(src) make sure the length of 
> the 
> > underlying hashtable is large enough? 
>
> Yes. 
>
> > It looks the official docs doesn't confirm this. 
>
> The docs say "map of type T with initial space for n elements" 
> (https://golang.org/ref/spec#Making_slices_maps_and_channels).  What 
> else would you want them to say? 
>
> Ian 
>

Thanks for the confirmation.
It would be better to also put "map of type T with initial space for n 
elements"  in the docs for https://golang.org/pkg/builtin/#make.

-- 
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] Can't understand untyped constant behavior

[Ilya Kostarev]

package main

import "fmt"

func main() {
const x, y = 5, 3
var f float32 = x / y
fmt.Println(f)
}

output
1
https://play.golang.org/p/FH1f793gWI
How this doesn't produce 1.6
Would be thankful for explanation.
__
Ilya Kostarev

--
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] Can't understand untyped constant behavior

[Jan Mercl]

On Thu, Sep 8, 2016 at 5:31 PM Ilya Kostarev  wrote:

> How this doesn't produce 1.6

x and y are untyped integer constants, so x/y is an untyped integer
constant 1. var f is float32, so the untyped integer constant 1 is
converted to float32.


-- 

-j

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[Ian Lance Taylor]

On Thu, Sep 8, 2016 at 8:16 AM, T L  wrote:
>
> On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Thu, Sep 8, 2016 at 3:46 AM, T L  wrote:
>> >
>> > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor
>> > wrote:
>> >>
>> >> On Wed, Sep 7, 2016 at 8:16 AM, T L  wrote:
>> >> >
>> >> > On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl
>> >> > wrote:
>> >> >>
>> >> >> On Wed, Sep 7, 2016 at 4:54 PM T L  wrote:
>> >> >>
>> >> >> https://golang.org/doc/go1compat
>> >> >>
>> >> >
>> >> > Then how to write compatibility safe atomic pointer reads/writes
>> >> > code?
>> >> > Do I
>> >> > must use atomic.Value for pointers?
>> >>
>> >> Perhaps you could explain what kind of compatibility risk you are
>> >> concerned about that is not covered by the Go 1 compatibility
>> >> guarantee.  Please give an example of code that will work today but
>> >> that you think may stop working in future releases.  Thanks.
>> >
>> >
>> > As the go1compat says unsafe package is not promised to keep
>> > compatibility,
>> > so I think atomic.Load/Store/SwapPointer functions are also not promised
>> > to
>> > keep compatibility, am I right?
>>
>> No.  The Go 1 compatibility document doesn't say that anything about
>> the unsafe package can change.  It says that packages that use unsafe
>> "may depend on internal properties of the Go implementation."  That is
>> not intended to mean that such packages depend on internal properties
>> merely because they import unsafe.  It is intended to mean that
>> packages that import unsafe may then (perhaps accidentally) use the
>> unsafe values in ways that depend on internal properties.  The
>> atomic.Load/Store/SwapPointer functions don't use the unsafe values in
>> any way at all.  They just move the values around.  That is always
>> going to be OK.
>>
>> Even if it somehow wasn't, the Go 1 compatibility guarantee does cover
>> the sync/atomic package.  That package is guaranteed to remain
>> compatible, so atomic.Load/Store/SwapPointer will continue to work as
>> they do today, even if the unsafe package somehow, unimaginably,
>> changes so that they don't.
>>
>> Ian
>
>
> Thanks for the confirmation.
>
> It would be clearer to write down "unsafe package and unsafe.Pointer will be
> there for ever" in docs.

Which docs?

I think the Go 1 compatibility doc is currently accurate.  We reserve
the right to make changes to the implementation of the unsafe package.
Not to the API, but to the implementation.  That is, the unsafe
package and unsafe.Pointer are guaranteed to remain, but it is
possible that certain aspects of their implementation will change.
That said, for the 1.6 release we clarified when unsafe.Pointer may be
used safely, and there are no current plans for, or expectations of,
further changes.

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

[go-nuts] Can't understand untyped constant behavior

[morozoandrei]

Because the infered type is a int so you're doing integer math.. So 5/2 = 2.5 
but if you int 2.5 you get 2. As an example. For the infere to work correctly I 
believe you need to write const x,y := 5.0,2.0 the decimal place will force it 
to use float64 instead.

-- 
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] I want to deep copy a map, how to get an enough initial size for the second parameter of make function?

[Ian Lance Taylor]

On Thu, Sep 8, 2016 at 8:19 AM, T L  wrote:
>
> On Thursday, September 8, 2016 at 10:57:10 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Thu, Sep 8, 2016 at 7:21 AM, T L  wrote:
>> >
>> > On Thursday, September 8, 2016 at 9:48:34 PM UTC+8, Jan Mercl wrote:
>> >>
>> >> On Thu, Sep 8, 2016 at 3:32 PM T L  wrote:
>> >>
>> >> > With the enough initial size, the underlying hashtable of the new map
>> >> > will never need to be realloced in the whole copy process.
>> >>
>> >> For example
>> >>
>> >> dst := make(map[T]U, len(src))
>> >
>> >
>> > Will setting the second parameter as len(src) make sure the length of
>> > the
>> > underlying hashtable is large enough?
>>
>> Yes.
>>
>> > It looks the official docs doesn't confirm this.
>>
>> The docs say "map of type T with initial space for n elements"
>> (https://golang.org/ref/spec#Making_slices_maps_and_channels).  What
>> else would you want them to say?
>
> Thanks for the confirmation.
> It would be better to also put "map of type T with initial space for n
> elements"  in the docs for https://golang.org/pkg/builtin/#make.

Thanks for the suggestion.  https://golang.org/cl/28815 .

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

[go-nuts] Re: Can't understand untyped constant behavior

[T L]

Although x and y's possible types include float32, there are two steps in 
"var f float32 = x / y".
The first one is "x / y", for both default type of x and y is int, so the 
result is 1.
The second step is "var f float32 = 1". 
This is it.

If you change 5 to 5.0, or change 3 to 3.0,
then the first step will operate on two Float values, the intersection 
possible types of 5.0 and 3 (or 5 and 3.0) are float types.

On Thursday, September 8, 2016 at 11:31:55 PM UTC+8, Uvelichitel wrote:
>
> package main 
>
>  import "fmt" 
>
>  func main() { 
>  const x, y = 5, 3 
>  var f float32 = x / y 
>  fmt.Println(f) 
>  } 
>
> output 
> 1 
> https://play.golang.org/p/FH1f793gWI 
> How this doesn't produce 1.6 
> Would be thankful for explanation. 
> __ 
> Ilya Kostarev 
>
>

-- 
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: Can't understand untyped constant behavior

[T L]

On Friday, September 9, 2016 at 12:15:53 AM UTC+8, T L wrote:
>
> Although x and y's possible types include float32, there are two steps in 
> "var f float32 = x / y".
> The first one is "x / y", for both default type of x and y is int, so the 
> result is 1.
> The second step is "var f float32 = 1". 
> This is it.
>
> If you change 5 to 5.0, or change 3 to 3.0,
> then the first step will operate on two Float values, the intersection 
> possible types of 5.0 and 3 (or 5 and 3.0) are float types.
>
sorry, the possible types of 3.0 and 5.0 also include int.
So here should be "the preferred possible types of 5.0 and 3 (or 5 and 3.0) 
are float types".
 

>
> On Thursday, September 8, 2016 at 11:31:55 PM UTC+8, Uvelichitel wrote:
>>
>> package main 
>>
>>  import "fmt" 
>>
>>  func main() { 
>>  const x, y = 5, 3 
>>  var f float32 = x / y 
>>  fmt.Println(f) 
>>  } 
>>
>> output 
>> 1 
>> https://play.golang.org/p/FH1f793gWI 
>> How this doesn't produce 1.6 
>> Would be thankful for explanation. 
>> __ 
>> Ilya Kostarev 
>>
>>

-- 
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] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

On Friday, September 9, 2016 at 12:10:50 AM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Sep 8, 2016 at 8:16 AM, T L > 
> wrote: 
> > 
> > On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Thu, Sep 8, 2016 at 3:46 AM, T L  wrote: 
> >> > 
> >> > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor 
> >> > wrote: 
> >> >> 
> >> >> On Wed, Sep 7, 2016 at 8:16 AM, T L  wrote: 
> >> >> > 
> >> >> > On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl 
> >> >> > wrote: 
> >> >> >> 
> >> >> >> On Wed, Sep 7, 2016 at 4:54 PM T L  wrote: 
> >> >> >> 
> >> >> >> https://golang.org/doc/go1compat 
> >> >> >> 
> >> >> > 
> >> >> > Then how to write compatibility safe atomic pointer reads/writes 
> >> >> > code? 
> >> >> > Do I 
> >> >> > must use atomic.Value for pointers? 
> >> >> 
> >> >> Perhaps you could explain what kind of compatibility risk you are 
> >> >> concerned about that is not covered by the Go 1 compatibility 
> >> >> guarantee.  Please give an example of code that will work today but 
> >> >> that you think may stop working in future releases.  Thanks. 
> >> > 
> >> > 
> >> > As the go1compat says unsafe package is not promised to keep 
> >> > compatibility, 
> >> > so I think atomic.Load/Store/SwapPointer functions are also not 
> promised 
> >> > to 
> >> > keep compatibility, am I right? 
> >> 
> >> No.  The Go 1 compatibility document doesn't say that anything about 
> >> the unsafe package can change.  It says that packages that use unsafe 
> >> "may depend on internal properties of the Go implementation."  That is 
> >> not intended to mean that such packages depend on internal properties 
> >> merely because they import unsafe.  It is intended to mean that 
> >> packages that import unsafe may then (perhaps accidentally) use the 
> >> unsafe values in ways that depend on internal properties.  The 
> >> atomic.Load/Store/SwapPointer functions don't use the unsafe values in 
> >> any way at all.  They just move the values around.  That is always 
> >> going to be OK. 
> >> 
> >> Even if it somehow wasn't, the Go 1 compatibility guarantee does cover 
> >> the sync/atomic package.  That package is guaranteed to remain 
> >> compatible, so atomic.Load/Store/SwapPointer will continue to work as 
> >> they do today, even if the unsafe package somehow, unimaginably, 
> >> changes so that they don't. 
> >> 
> >> Ian 
> > 
> > 
> > Thanks for the confirmation. 
> > 
> > It would be clearer to write down "unsafe package and unsafe.Pointer 
> will be 
> > there for ever" in docs. 
>
> Which docs? 
>
> I think the Go 1 compatibility doc is currently accurate.  We reserve 
> the right to make changes to the implementation of the unsafe package. 
> Not to the API, but to the implementation.  That is, the unsafe 
> package and unsafe.Pointer are guaranteed to remain, but it is 
> possible that certain aspects of their implementation will change. 
> That said, for the 1.6 release we clarified when unsafe.Pointer may be 
> used safely, and there are no current plans for, or expectations of, 
> further changes. 
>
> Ian 
>

Ok, got it. 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.

Re: [go-nuts] Pointer literal

[chai2010]

https://github.com/golang/go/issues/9097

2016-09-07 23:42 GMT+08:00 'Mihai B' via golang-nuts <
golang-nuts@googlegroups.com>:

> Hi there,
>
> Any HTTP API with PATCH support needs to use pointers on basic types.
> Therefore I'm wondering if there is any will/proposal to make pointer
> initialisation easier to work with basic types. The `standard` way is quite
> verbose so it seems that most APIs use functions for every possible type[1].
>   I think these kind of functions should be provided in the standard
> library or preferably the syntax should be extended to support pointer
> literals < i.e. something like x := &("hello") ; x := &T("hello") x :=
> &(30)  >;  .
>   Some real world examples of APIs that reinvent the pointer
> initialisation google[2], amazon aws[3], github[4].
>
>
> Mihai.
>
>
> [0]
> d := "new description"
> r := T{Description:&d}
> [1]
> func NewInt32(i int32)*int32{}
>
> [2] https://github.com/google/google-api-go-client/issues/54
> [3] https://godoc.org/github.com/aws/aws-sdk-go/aws
> [4] https://godoc.org/github.com/google/go-github/github
>
> --
> 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.
>



-- 
https://github.com/golang-china/gopl-zh
https://github.com/golang-china
https://github.com/chai2010

-- 
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] What was the rationale behind using braces for scoping?

[Michael Jones]

There is ample evidence that “typographic block structure” via indenting is 
fragile in terms of potential error in the reality of cut-and-paste. This is 
not a comment on like/dislike in abstract, just on dislike when designing for 
high programmer productivity.


-- 
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] Problems to create the JSON structure dynamically

[Jens Ramhorst]

Hello,

I'm unable o create dynamically the given JSON structure.
I need the following JSON structure for a linechart with two  timeseries:
[
[{
"time": 141004800,
"val": 2182257289.448362
}, {
"time": 141013440,
"val": 1693164286.4698827
}, {
"time": 141022080,
"val": 0
}],
[{
"time": 141004800,
"val": 1600071082.4768825
}, {
"time": 141013440,
"val": 1243405427.1394928
}, {
"time": 141022080,
"val": 0
}]
]




 I'm new to golang and I tried many things. But nothing works. My last 
trial:
type tChartValue struct {
Time  string  `json:"time"`
Value float32 `json:"value"`
}

type tChartSerie struct {
Values []tChartValue
}

var timeSeries tChartSerie

for j := 1; j < 3; j++ {

var chartValues []tChartValue

for i := 1; i < 4; i++ {

chartValues = append(chartValues, tChartValue{Time: "2016090815" + 
strconv.Itoa(15+i), Value: float32(i * j)})

}

timeSeries.Values = append(timeSeries.Values, chartValues...)

}

Can anyone help

-- 
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] Problems to create the JSON structure dynamically

[Shawn Milochik]

 Hi Jens. I hope this helps. Let me know if you have any questions.

https://play.golang.org/p/Z39q1BAFFb

-- 
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: Problems to create the JSON structure dynamically

[Jens Ramhorst]

Thank you,

after a meal i found the same solution :-)

-- 
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] Dynamic json unmarshaling map[string]int and errors

[Viacheslav Biriukov]

Hi all, 

Help me please write an idiomatic golang code for api client for json rest 
api. 


In normal case api send just map[string]int and it's easy to unmarshal in 
map.
{
  "string": 1,
  "string": 2
}

But in error case it becomes: 

{
  "error": "error_string"
}

What is the best way to handle this situation?

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

[go-nuts] memory leak with websocket

[aiden0xz]

We have a websocket service based on go-socket.io( the socket.io golang 
implementation), but seems have a memory leak problem. I also have opened a 
same topic ,but the problem is not be resolved.  I also enable the 
debug.FreeOSMemory, the idle heap now will be released back to OS, but the 
heap alloc always increase. I collect the new pprof data, and also found 
something interesting.

1. heap in-use space callgraph





2. heap alloc space callgraph




3. goroutine callgraph




I also attach the pprof pdf file.


Problem:
1.  When the request hijack to the websocket conn, the 
*net/http.(*conn).serve *goroutine will return immediately， but why the 
*net/textproto.(*Reader).ReadMIMEHeader 
*(contains in net/http.readRequest which located in net/http.(*conn).serve) 
take 
so much memory in the heap in-use callgraph?
2. Is there any other tool can inspect the memory leak problem?

-- 
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.


comet_goroutine.pdf
Description: Adobe PDF document


comet_alloc_space.pdf
Description: Adobe PDF document


comet_inuse_space.pdf
Description: Adobe PDF document


comet_inuse_objects.pdf
Description: Adobe PDF document

[go-nuts] Is SizedReaderAt coming back in 1.8?

[Carl Mastrangelo]

It seems that io.SizedReaderAt was added temporarily during the 1.7 cycle, 
but promptly removed.  I see an standing github issue for it (15822) but it 
doesn't seem to have much activity.  

I would like to express my hope that it comes back (and hopefully others 
will to).  A use case that I am interested in is turning a ReaderAt into a 
Reader, which is currently non-trivial to convert.  The io package has a 
SectionReader, but to create one of those you need to know the size, which 
a plain ReaderAt won't provide.

There are some other places in the API that would benefit from such a 
class, such as the archive/zip package.  Currently, it is not possible to 
read from an in memory Zip file, because the only method to open zips is 
OpenReader(name string) !?  I understand that the index is at the back of 
the file, so a plain reader can't be passed in.  However, a SizedReaderAt 
would conveniently fit as a zip Reader, since it know the size 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] Is SizedReaderAt coming back in 1.8?

[Dan Kortschak]

The problem is that some Size methods return (int64, error) and others
return int64, so the interface was removed, since it can't match all the
types in the stdlib that it might be useful for.

You can easily define it yourself for your own use though, and provide a
shim for the types that don't quite fit (the ugliness that follows is
why it's not there) https://play.golang.org/p/j0PednO__i


On Thu, 2016-09-08 at 21:40 -0700, Carl Mastrangelo wrote:
> It seems that io.SizedReaderAt was added temporarily during the 1.7
> cycle, but promptly removed.  I see an standing github issue for it
> (15822) but it doesn't seem to have much activity.  
> 
> I would like to express my hope that it comes back (and hopefully
> others will to).  A use case that I am interested in is turning a
> ReaderAt into a Reader, which is currently non-trivial to convert.
> The io package has a SectionReader, but to create one of those you
> need to know the size, which a plain ReaderAt won't provide.
> 
> There are some other places in the API that would benefit from such a
> class, such as the archive/zip package.  Currently, it is not possible
> to read from an in memory Zip file, because the only method to open
> zips is OpenReader(name string) !?  I understand that the index is at
> the back of the file, so a plain reader can't be passed in.  However,
> a SizedReaderAt would conveniently fit as a zip Reader, since it know
> the size 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] Is SizedReaderAt coming back in 1.8?

['Axel Wagner' via golang-nuts]

On Fri, Sep 9, 2016 at 6:40 AM, Carl Mastrangelo  wrote:

> A use case that I am interested in is turning a ReaderAt into a Reader,
> which is currently non-trivial to convert.
>

Out of curiosity, what's wrong with this
? There might be some subtlety that
I'm overlooking (thus proving your point), but otherwise that seems rather
trivial to me.

-- 
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] Is SizedReaderAt coming back in 1.8?

['Ingo Oeser' via golang-nuts]

The missing inclusion stems from a misunderstanding of the intended api.

The Size method should return the upper bound for the offset passed to ReadAt 
known ahead of time. 

If the upper bound cannot be detected, the SizedReaderAt will simply fail 
creation. 

When the Size changes, ReadAt will return any errors related to that. 

So there really is no need for Size to return an error.

The misunderstanding happened while trying to make os.File satisfy this 
interface, while it actually needs a small helper function doing File.Stat 
ahead of time and a small intermediate type to convert between them.

-- 
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.