Re: [go-nuts] rin: return if nil syntactic sugar

[Zakaria]

If the objections on the too magical handle part, why not cut that part and
retain the check part?

Most of the time the we just forward the error on to the next level anyway.
Handling error is rarely done and should be explicit.

I got better keyword for this: reterr
A portmanteau of return error.

Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor 
menulis:

> On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris 
> wrote:
> >
> > Idk if this has been proposed or discussed before.
> >
> > Given the last error handling abbreviation proposal is rejected. How
> about some simple syntactic sugar like this:
> >
> >   rin Something()
> >
> > Which is just a sugar for:
> >
> >   if err := Something(); err != nil {
> > return err
> >   }
> >
> > To make it worth the new keyword make it so that:
> >
> >   rin v := Something()
> >
> > equals to:
> >
> >   v, err := Something()
> >   if err != nil {
> > return err
> >   }
>
> This is similar to the check/handle design draft, without the handle.
> You may want to take a look at https://golang.org/issue/40432.
> Thanks.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com.

Re: [go-nuts] Failing to build goanalyzer

[Siddhesh Divekar]

That's right, I had modules enabled.
After moving the repo under go path src directory it worked fine.

echo $GOPATH
/Users/sidhesh/Development/gocode
~/Development/gocode/src/github.com/robaho/goanalyzer/cmd/goanalyzer$ go
build
~/Development/gocode/src/github.com/robaho/goanalyzer/cmd/goanalyzer$

On Sun, Aug 30, 2020 at 4:57 PM robert engels  wrote:

> Tonight, I rebuilt and ran using Go 1.15 and it was fine (I cleared the
> entire build cache using -a). Maybe you have modules enabled?
>
> Here is the output:
>
> GOROOT=/usr/local/Cellar/go/1.15/libexec #gosetup
> GOPATH=/Users/robertengels/go #gosetup
> /usr/local/Cellar/go/1.15/libexec/bin/go build -a -o
> /private/var/folders/bb/dk8qf0zx6zg7kw3m6dgmj40hgn/T/___go_build_github_com_robaho_goanalyzer_cmd_goanalyzer_user
> . #gosetup
> /private/var/folders/bb/dk8qf0zx6zg7kw3m6dgmj40hgn/T/___go_build_github_com_robaho_goanalyzer_cmd_goanalyzer_user
> /Users/robertengels/go/src/
> github.com/robaho/goanalyzer/user_task_span_1_11_good #gosetup
> 2020/08/30 18:54:19 Parsing trace...
> 2020/08/30 18:54:19 Splitting trace...
> 2020/08/30 18:54:19 Opening browser. Trace viewer is listening on
> http://127.0.0.1:57135
>
>
> On Aug 29, 2020, at 7:43 PM, Robert Engels  wrote:
>
> I have not tried building it in a while. I assume some internals have
> changed. I’ll look into it.
>
> On Aug 29, 2020, at 7:08 PM, Siddhesh Divekar 
> wrote:
>
> Hi,
>
> Has anyone tried building goanalyzer recently?
> Am I missing something very basic here.
>
> goanalyzer/cmd/goanalyzer$ ls
> annotations.go doc.go goroutines.go main.go pprof.go trace_test.go
> annotations_test.go goanalyzer.iml internal mmu.go trace.go
> trace_unix_test.go
>
> goanalyzer/cmd/goanalyzer$ go build
> annotations.go:10:2: use of internal package
> github.com/robaho/goanalyzer/cmd/goanalyzer/internal/trace not allowed
>
> --
> -Siddhesh.
>
> --
> 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/CAMjfk%2Bi%3DL%3Dg8t5%3DWayYuShN0mHQ-0DRhWh6G-wEDp%3D_pbJE8jA%40mail.gmail.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3C3C5C76-16FD-4F8C-88F0-037C3E04DC6D%40ix.netcom.com
> 
> .
>
>
>

-- 
-Siddhesh.

-- 
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/CAMjfk%2Bj2KNwAJ5QxYyf7a6swBsmN5-xovp_dsjAPbRJLP_m_Qg%40mail.gmail.com.

Re: [go-nuts] Failing to build goanalyzer

[Siddhesh Divekar]

Thanks !

On Sun, Aug 30, 2020 at 9:35 PM Siddhesh Divekar 
wrote:

> That's right, I had modules enabled.
> After moving the repo under go path src directory it worked fine.
>
> echo $GOPATH
> /Users/sidhesh/Development/gocode
> ~/Development/gocode/src/github.com/robaho/goanalyzer/cmd/goanalyzer$ go
> build
> ~/Development/gocode/src/github.com/robaho/goanalyzer/cmd/goanalyzer$
>
> On Sun, Aug 30, 2020 at 4:57 PM robert engels 
> wrote:
>
>> Tonight, I rebuilt and ran using Go 1.15 and it was fine (I cleared the
>> entire build cache using -a). Maybe you have modules enabled?
>>
>> Here is the output:
>>
>> GOROOT=/usr/local/Cellar/go/1.15/libexec #gosetup
>> GOPATH=/Users/robertengels/go #gosetup
>> /usr/local/Cellar/go/1.15/libexec/bin/go build -a -o
>> /private/var/folders/bb/dk8qf0zx6zg7kw3m6dgmj40hgn/T/___go_build_github_com_robaho_goanalyzer_cmd_goanalyzer_user
>> . #gosetup
>> /private/var/folders/bb/dk8qf0zx6zg7kw3m6dgmj40hgn/T/___go_build_github_com_robaho_goanalyzer_cmd_goanalyzer_user
>> /Users/robertengels/go/src/
>> github.com/robaho/goanalyzer/user_task_span_1_11_good #gosetup
>> 2020/08/30 18:54:19 Parsing trace...
>> 2020/08/30 18:54:19 Splitting trace...
>> 2020/08/30 18:54:19 Opening browser. Trace viewer is listening on
>> http://127.0.0.1:57135
>>
>>
>> On Aug 29, 2020, at 7:43 PM, Robert Engels  wrote:
>>
>> I have not tried building it in a while. I assume some internals have
>> changed. I’ll look into it.
>>
>> On Aug 29, 2020, at 7:08 PM, Siddhesh Divekar 
>> wrote:
>>
>> Hi,
>>
>> Has anyone tried building goanalyzer recently?
>> Am I missing something very basic here.
>>
>> goanalyzer/cmd/goanalyzer$ ls
>> annotations.go doc.go goroutines.go main.go pprof.go trace_test.go
>> annotations_test.go goanalyzer.iml internal mmu.go trace.go
>> trace_unix_test.go
>>
>> goanalyzer/cmd/goanalyzer$ go build
>> annotations.go:10:2: use of internal package
>> github.com/robaho/goanalyzer/cmd/goanalyzer/internal/trace not allowed
>>
>> --
>> -Siddhesh.
>>
>> --
>> 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/CAMjfk%2Bi%3DL%3Dg8t5%3DWayYuShN0mHQ-0DRhWh6G-wEDp%3D_pbJE8jA%40mail.gmail.com
>> 
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/3C3C5C76-16FD-4F8C-88F0-037C3E04DC6D%40ix.netcom.com
>> 
>> .
>>
>>
>>
>
> --
> -Siddhesh.
>


-- 
-Siddhesh.

-- 
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/CAMjfk%2BiJ%2BZK54t86cKAgSFNG13iguE5DOFnQ0TC-YGgPPC0SkQ%40mail.gmail.com.

Re: [go-nuts] rin: return if nil syntactic sugar

[Ian Lance Taylor]

On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris  wrote:
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handling abbreviation proposal is rejected. How about 
> some simple syntactic sugar like this:
>
>   rin Something()
>
> Which is just a sugar for:
>
>   if err := Something(); err != nil {
> return err
>   }
>
> To make it worth the new keyword make it so that:
>
>   rin v := Something()
>
> equals to:
>
>   v, err := Something()
>   if err != nil {
> return err
>   }

This is similar to the check/handle design draft, without the handle.
You may want to take a look at https://golang.org/issue/40432.
Thanks.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU5C4F-m_YPsPtxuPmt5TQrJnXN2QK4dGBONkYD1iKyww%40mail.gmail.com.

[go-nuts] Re: rinn: return if not nil syntactic sugar

[Zakaria bin Haris]

Cause the objection for previous error handling is code coverage, the 
solution is for code coverage tools to desugarize *rinn* syntax.

The objective to minimize error handling "noise" from human eyes.

On Monday, August 31, 2020 at 9:29:44 AM UTC+7 Zakaria bin Haris wrote:

> For completeness if the function is something like:
>
>   func x() (data *Data, err error) {
>   }
>
> then *rinn* should be smart enough to assign error to err variable and 
> just do return instead return err
>
> On Monday, August 31, 2020 at 9:19:48 AM UTC+7 Zakaria bin Haris wrote:
>
>> Sorry, I mean return if not nil, so it should be *rinn* or please find 
>> some better keyword for this :^).
>>
>> On Monday, August 31, 2020 at 9:15:31 AM UTC+7 Zakaria bin Haris wrote:
>>
>>> Hi, gophers!
>>>
>>> Idk if this has been proposed or discussed before.
>>>
>>> Given the last error handling abbreviation proposal is rejected. How 
>>> about some simple syntactic sugar like this:
>>>
>>>   *rin* Something()
>>>
>>> Which is just a sugar for:
>>>
>>>   if err := Something(); err != nil {
>>> return err
>>>   }
>>>
>>> To make it worth the new keyword make it so that:
>>>
>>>   *rin* v := Something()
>>>
>>> equals to:
>>>
>>>   v, err := Something()
>>>   if err != nil {
>>> return err
>>>   }
>>>
>>

-- 
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/5a4471ca-adec-42b2-8af4-d9453f84247fn%40googlegroups.com.

[go-nuts] Re: rinn: return if not nil syntactic sugar

[Zakaria bin Haris]

For completeness if the function is something like:

  func x() (data *Data, err error) {
  }

then *rinn* should be smart enough to assign error to err variable and just 
do return instead return err

On Monday, August 31, 2020 at 9:19:48 AM UTC+7 Zakaria bin Haris wrote:

> Sorry, I mean return if not nil, so it should be *rinn* or please find 
> some better keyword for this :^).
>
> On Monday, August 31, 2020 at 9:15:31 AM UTC+7 Zakaria bin Haris wrote:
>
>> Hi, gophers!
>>
>> Idk if this has been proposed or discussed before.
>>
>> Given the last error handling abbreviation proposal is rejected. How 
>> about some simple syntactic sugar like this:
>>
>>   *rin* Something()
>>
>> Which is just a sugar for:
>>
>>   if err := Something(); err != nil {
>> return err
>>   }
>>
>> To make it worth the new keyword make it so that:
>>
>>   *rin* v := Something()
>>
>> equals to:
>>
>>   v, err := Something()
>>   if err != nil {
>> return err
>>   }
>>
>

-- 
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/b5ad3bb6-74e7-45df-b82a-ef199b058a4en%40googlegroups.com.

[go-nuts] Re: rin: return if nil syntactic sugar

[Zakaria bin Haris]

Sorry, I mean return if not nil, so it should be *rinn* or please find some 
better keyword for this :^).

On Monday, August 31, 2020 at 9:15:31 AM UTC+7 Zakaria bin Haris wrote:

> Hi, gophers!
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handling abbreviation proposal is rejected. How about 
> some simple syntactic sugar like this:
>
>   *rin* Something()
>
> Which is just a sugar for:
>
>   if err := Something(); err != nil {
> return err
>   }
>
> To make it worth the new keyword make it so that:
>
>   *rin* v := Something()
>
> equals to:
>
>   v, err := Something()
>   if err != nil {
> return err
>   }
>

-- 
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/c8683351-b51a-4a6d-bc3a-27a3c1b73ffcn%40googlegroups.com.

[go-nuts] rin: return if nil syntactic sugar

[Zakaria bin Haris]

Hi, gophers!

Idk if this has been proposed or discussed before.

Given the last error handling abbreviation proposal is rejected. How about 
some simple syntactic sugar like this:

  *rin* Something()

Which is just a sugar for:

  if err := Something(); err != nil {
return err
  }

To make it worth the new keyword make it so that:

  *rin* v := Something()

equals to:

  v, err := Something()
  if err != nil {
return err
  }

-- 
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/955d78f2-67cb-4940-845c-034fb45e816an%40googlegroups.com.

Re: [go-nuts] Failing to build goanalyzer

[robert engels]

Tonight, I rebuilt and ran using Go 1.15 and it was fine (I cleared the entire 
build cache using -a). Maybe you have modules enabled?

Here is the output:

GOROOT=/usr/local/Cellar/go/1.15/libexec #gosetup
GOPATH=/Users/robertengels/go #gosetup
/usr/local/Cellar/go/1.15/libexec/bin/go build -a -o 
/private/var/folders/bb/dk8qf0zx6zg7kw3m6dgmj40hgn/T/___go_build_github_com_robaho_goanalyzer_cmd_goanalyzer_user
 . #gosetup
/private/var/folders/bb/dk8qf0zx6zg7kw3m6dgmj40hgn/T/___go_build_github_com_robaho_goanalyzer_cmd_goanalyzer_user
 
/Users/robertengels/go/src/github.com/robaho/goanalyzer/user_task_span_1_11_good
 #gosetup
2020/08/30 18:54:19 Parsing trace...
2020/08/30 18:54:19 Splitting trace...
2020/08/30 18:54:19 Opening browser. Trace viewer is listening on 
http://127.0.0.1:57135


> On Aug 29, 2020, at 7:43 PM, Robert Engels  wrote:
> 
> I have not tried building it in a while. I assume some internals have 
> changed. I’ll look into it. 
> 
> On Aug 29, 2020, at 7:08 PM, Siddhesh Divekar  > wrote:
> 
>> Hi,
>> 
>> Has anyone tried building goanalyzer recently?
>> Am I missing something very basic here.
>> 
>> goanalyzer/cmd/goanalyzer$ ls
>> annotations.go doc.go goroutines.go main.go pprof.go trace_test.go
>> annotations_test.go goanalyzer.iml internal mmu.go trace.go 
>> trace_unix_test.go
>> 
>> goanalyzer/cmd/goanalyzer$ go build
>> annotations.go:10:2: use of internal package 
>> github.com/robaho/goanalyzer/cmd/goanalyzer/internal/trace 
>>  not 
>> allowed
>> 
>> -- 
>> -Siddhesh.
>> 
>> -- 
>> 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/CAMjfk%2Bi%3DL%3Dg8t5%3DWayYuShN0mHQ-0DRhWh6G-wEDp%3D_pbJE8jA%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/3C3C5C76-16FD-4F8C-88F0-037C3E04DC6D%40ix.netcom.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/A28FF204-B7A8-442E-8E6A-164228D12E82%40ix.netcom.com.

Re: [go-nuts] Re: Using go build to cross compile a kernel file and link it to the loader

[saurav deshpande]

i watched a video of gopher-os and looked through it's github repository 
for ways to extract the object files needed and tried his command as 
follows, but i'm getting these errors which i can't resolve:

GOARCH=386 GOOS=linux go build -n 2>&1 | sed -e "1s|^|set -e\n|" -e 
"1s|^|export GOOS=linux\n|" -e "1s|^|export GOARCH=386\n|" -e "1s|^|export 
CGO_ENABLED=0\n|" -e "1s|^|WORK='./build'\n|" -e "1s|^|alias pack='go tool 
pack'\n|" -e "/^mv/d" -e "s|-extld|-tmpdir='./build' -linkmode=external 
-extldflags='-nostdlib' -extld|g" | sh 2>&1 | sed -e "s/^/ | /g"

Errors/Warnings:

 | loadinternal: cannot find runtime/cgo
 | /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 
08049000

The above command is able to produce an object file in the ./build 
directory i specified, i can link it without any errors, but when i try to 
run the executable it doesn't work.

i know there is nothing wrong with the linker script because i have created 
object files using the gccgo cross-compiler, and they work.
i wish to use the extra set of features the 'go build' cross-compiler is 
able to provide that gccgo cross-compiler cannot.


On Sunday, August 30, 2020 at 1:31:58 AM UTC+5:30 nasirhu...@gmail.com 
wrote:

> I would like to +1 Amnon here, 
>
> Although, If you're looking forward to implementing a Kernel in Go, there 
> is a project called GopherOS (https://github.com/gopher-os/gopher-os/) 
> that can be of help to you.
>
> In order to generate the .o file, you can refer to the make file here: 
> https://github.com/gopher-os/gopher-os/blob/master/Makefile#L56 and 
> additionally use the make file for building and loading your Kernel too.
>
> Best,
>
> --
> Nasir Hussain 
>
> On Sat, Aug 29, 2020 at 8:34 PM Amnon  wrote:
>
>> Go is not the best language to write a kernel on. But some people have 
>> done it as an intellectual exercise.
>> Look at https://github.com/ycoroneos/G.E.R.T
>> Or https://github.com/f-secure-foundry/tamago
>> Or read 
>> https://speakerdeck.com/achilleasa/bare-metal-gophers-can-you-write-an-os-kernel-in-go
>>
>> It is quite a bit of work. But you will learn a fair bit along the way.
>>
>>
>> On Saturday, 29 August 2020 14:32:08 UTC+1, saurav deshpande wrote:
>>>
>>> Hello, I was trying to write a basic kernel in golang. Before actually 
>>> implementing anything in the kernel.go file I wanted to see how go build 
>>> cross compiler can be used.
>>> I am currently using :
>>> *go version go1.15*  *linux/amd64*
>>>
>>> I wrote 3 files: a *loader* (*boot.asm*)file, a *linker(linker.ld) *file 
>>> and an *kernel(kernel.go)* file.
>>> I want to run the kernel on virtual machine, arch: linux-32bit.
>>> I need step wise help to successfully running this kernel. 
>>> how to compile it with go build and generate a ".o" file,then using 
>>> linker.ld to link boot.s and kernel.o.
>>> I tired the makefile format of gopher os but didnt get anywhere, so 
>>> thought if someone could help me from scratch.
>>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7d6979b3-d9ed-481b-b47f-fcf83eae4092o%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/46d1c819-f359-4ad0-aee8-c3732b63332cn%40googlegroups.com.

[go-nuts] Re: Memory Leak in bytes.Buffer String() method

[Jake Montgomery]

Sorry if this is a bit obvious. I did not dive into your code. But I did 
notice that replacePositionalPlaceholders returns buf.String(). If you are 
certain that this is where the memory 'leak' is originating, then the most 
likely scenario is that the returned string is never being collected. Is it 
possible that somehow there is a reference being kept to the string, or an 
object containing the string?

On Sunday, August 30, 2020 at 11:25:15 AM UTC-4, Sarath Prabath Redlapalli 
Jaya wrote:
>
> Hi, we've been observing high memory usage in the following code
> https://github.com/Masterminds/squirrel/blob/master/placeholder.go#L113
>
> We measured from pprof of heap
>
> (pprof) top20
>
> Showing nodes accounting for 360.07MB, 91.31% of 394.32MB total
>
> Dropped 142 nodes (cum <= 1.97MB)
>
> Showing top 20 nodes out of 139
>
>   flat  flat%   sum%cum   cum%
>
>   101.21MB 25.67% 25.67%   101.21MB 25.67%  bytes.(*Buffer).String
>
>48.01MB 12.18% 37.84%48.01MB 12.18%  
> github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).add
>
>42.61MB 10.81% 48.65%43.11MB 10.93%  
> github.com/newrelic/go-agent/v3/newrelic.(*txnTrace).witnessNode
>
>38.54MB  9.77% 58.42%38.54MB  9.77%  
> go.uber.org/zap/buffer.NewPool.func1
>
>   19MB  4.82% 63.24%   19MB  4.82%  
> github.com/newrelic/go-agent/v3/newrelic.segmentEnd.spanEvent
>
>16.51MB  4.19% 67.43%91.04MB 23.09%  
> github.com/newrelic/go-agent/v3/newrelic.endDatastoreSegment
>
>14.01MB  3.55% 70.98%18.01MB  4.57%  
> github.com/newrelic/go-agent/v3/newrelic.newTxn
>
>13.51MB  3.43% 74.41%93.13MB 23.62%  
> github.com/newrelic/go-agent/v3/newrelic.endExternalSegment
>
>12.01MB  3.05% 77.45%12.01MB  3.05%  
> github.com/newrelic/go-agent/v3/newrelic.getStackTrace
>
>10.51MB  2.66% 80.12%10.51MB  2.66%  
> github.com/newrelic/go-agent/v3/newrelic.(*slowQueries).insertAtIndex
>
>8MB  2.03% 82.15%8MB  2.03%  
> github.com/newrelic/go-agent/v3/newrelic.newSlowQueries
>
> 6.51MB  1.65% 85.73% 6.51MB  1.65%  
> github.com/DataDog/datadog-go/statsd.newStatsdBuffer
>
>4MB  1.01% 86.75%52.01MB 13.19%  
> github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).addString
>
> 3.50MB  0.89% 87.64% 3.50MB  0.89%  
> go.uber.org/zap.(*Logger).clone
>
> 3.50MB  0.89% 88.52% 3.50MB  0.89%  
> github.com/newrelic/go-agent/v3/newrelic.externalMetricKey.scopedMetric
>
>3MB  0.76% 89.28%3MB  0.76%  
> github.com/newrelic/go-agent/v3/newrelic.addUserAttribute
>
>3MB  0.76% 90.05%3MB  0.76%  strings.(*Builder).WriteString
>
> 2.50MB  0.63% 90.68% 6.06MB  1.54%  encoding/json.Unmarshal
>
> 2.50MB  0.63% 91.31% 2.50MB  0.63%  context.(*cancelCtx).Done
>
> =
>
> Resetting the buffer by defer didn't help either. So moved to string 
> builder like this
>
> func replacePositionalPlaceholders(sql, prefix string) (string, error) {
> buf := {}
> defer buf.Reset()
>
> i := 0
> for {
> p := strings.Index(sql, "?")
> if p == -1 {
> break
> }
>
> if len(sql[p:]) > 1 && sql[p:p+2] == "??" { // escape ?? => ?
> buf.WriteString(sql[:p])
> buf.WriteString("?")
> if len(sql[p:]) == 1 {
> break
> }
> sql = sql[p+2:]
> } else {
> i++
> buf.WriteString(sql[:p])
> fmt.Fprintf(buf, "%s%d", prefix, i)
> sql = sql[p+1:]
> }
> }
>
> buf.WriteString(sql)
> return buf.String(), nil
> }
>
> ==
>
> This didn't help either, from the results below
>
> (pprof) top20
>
> Showing nodes accounting for 220.09MB, 90.37% of 243.55MB total
>
> Dropped 126 nodes (cum <= 1.22MB)
>
> Showing top 20 nodes out of 135
>
>   flat  flat%   sum%cum   cum%
>
>33.97MB 13.95% 13.95%33.97MB 13.95%  strings.(*Builder).Write
>
>29.07MB 11.94% 25.89%29.57MB 12.14%  
> github.com/newrelic/go-agent/v3/newrelic.(*txnTrace).witnessNode
>
>28.01MB 11.50% 37.39%28.01MB 11.50%  
> github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).add
>
>24.34MB  9.99% 47.38%24.34MB  9.99%  strings.(*Builder).WriteString
>
>18.52MB  7.60% 54.98%18.52MB  7.60%  
> go.uber.org/zap/buffer.NewPool.func1
>
>11.01MB  4.52% 59.50%60.59MB 24.88%  
> github.com/newrelic/go-agent/v3/newrelic.endExternalSegment
>
>10.01MB  4.11% 63.61%13.51MB  5.55%  
> github.com/newrelic/go-agent/v3/newrelic.newTxn
>
>   10MB  4.11% 67.72%   10MB  4.11%  
> github.com/newrelic/go-agent/v3/newrelic.segmentEnd.spanEvent
>
>7MB  2.88% 73.73%7MB  2.88%  
> github.com/newrelic/go-agent/v3/newrelic.(*slowQueries).insertAtIndex
>
>7MB  2.88% 76.60%50.02MB 20.54%  
> github.com/newrelic/go-agent/v3/newrelic.endDatastoreSegment
>
> 6.51MB  2.67% 79.28% 6.51MB  2.67%  
> github.com/DataDog/datadog-go/statsd.newStatsdBuffer
>
>6MB  2.46% 81.74% 6.50MB  2.67%  
> github.com/newrelic/go-agent/v3/newrelic.addUserAttribute
>
> 5.50MB  2.26% 84.00% 5.50MB  2.26%  
> 

Re: [go-nuts] Memory Leak in bytes.Buffer String() method

[Ian Lance Taylor]

On Sun, Aug 30, 2020 at 8:25 AM Sarath Prabath Redlapalli Jaya
 wrote:
>
> Hi, we've been observing high memory usage in the following code
> https://github.com/Masterminds/squirrel/blob/master/placeholder.go#L113
>
> We measured from pprof of heap
>
> (pprof) top20
>
> Showing nodes accounting for 360.07MB, 91.31% of 394.32MB total
>
> Dropped 142 nodes (cum <= 1.97MB)
>
> Showing top 20 nodes out of 139
>
>   flat  flat%   sum%cum   cum%
>
>   101.21MB 25.67% 25.67%   101.21MB 25.67%  bytes.(*Buffer).String

This tells you where the memory was allocated.  If you are trying to
track down a memory leak, you need to look into what is keeping this
memory live in the heap.  The fact that it was allocated here is a
start.  But your next step is to look at what calls to this function
are allocating memory, and what is happening to that memory to keep it
alive.  The pprof program can help tell you where the calls are coming
from, but then you'll have to look at what happens to those strings
and why they are being kept live.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUc2fK50YyBJRSuirvR%3DOioTtg%3DC6fL2ovHKNKAVCwB8g%40mail.gmail.com.

Re: [go-nuts] Re: Memory Leak in bytes.Buffer String() method

[Ian Lance Taylor]

On Sun, Aug 30, 2020 at 8:28 AM Sarath Prabath Redlapalli Jaya
 wrote:
>
> The memory usage of containers are ever increasing and has grown from 100 MB 
> to ~ 1 GB in couple of hours. Not able to understand where the gap is, even 
> though the the builder is being reset. Would keeping a sync.Pool of builders 
> help here?

No, because the problem is not the builders.  It's what is happening
to the strings after they have been built.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWfivhCZj1MmAfSg_JBZVxr_hE9K%2Bj%3Dr-NvZrr3nUHeSw%40mail.gmail.com.

Re: [go-nuts] about go tool link, where link get code(text segment) from *.o files and write it to executable files?

[Ian Lance Taylor]

On Sun, Aug 30, 2020 at 7:32 AM xie cui  wrote:
>
> i am trying to understand code of cmd/link,  i need to know where linker get 
> instructions(text segment in executable file) from *o file, and where linker 
> write the binary data (.text segment) to excutable file(in linux it 's a elf 
> file).

The linker was recently rewritten, so I'm describing tip and to some
extent Go 1.15, not earlier releases.

Object files are read by the cmd/link/internal/loader package.  The Go
object file format is read by code in cmd/internal/goobj.

All the loadable segments are written out by the asmb function in
cmd/link/internal/asmb.go.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUpTwG8PPCeENXcdTHG-G0DS%3DDbq2RdQJNWzQFiFpVVag%40mail.gmail.com.

[go-nuts] Re: Memory Leak in bytes.Buffer String() method

[Sarath Prabath Redlapalli Jaya]

The memory usage of containers are ever increasing and has grown from 100 
MB to ~ 1 GB in couple of hours. Not able to understand where the gap is, 
even though the the builder is being reset. Would keeping a sync.Pool of 
builders help here?

Regards

On Sunday, August 30, 2020 at 8:55:15 PM UTC+5:30 Sarath Prabath Redlapalli 
Jaya wrote:

> Hi, we've been observing high memory usage in the following code
> https://github.com/Masterminds/squirrel/blob/master/placeholder.go#L113
>
> We measured from pprof of heap
>
> (pprof) top20
>
> Showing nodes accounting for 360.07MB, 91.31% of 394.32MB total
>
> Dropped 142 nodes (cum <= 1.97MB)
>
> Showing top 20 nodes out of 139
>
>   flat  flat%   sum%cum   cum%
>
>   101.21MB 25.67% 25.67%   101.21MB 25.67%  bytes.(*Buffer).String
>
>48.01MB 12.18% 37.84%48.01MB 12.18%  
> github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).add
>
>42.61MB 10.81% 48.65%43.11MB 10.93%  
> github.com/newrelic/go-agent/v3/newrelic.(*txnTrace).witnessNode
>
>38.54MB  9.77% 58.42%38.54MB  9.77%  
> go.uber.org/zap/buffer.NewPool.func1
>
>   19MB  4.82% 63.24%   19MB  4.82%  
> github.com/newrelic/go-agent/v3/newrelic.segmentEnd.spanEvent
>
>16.51MB  4.19% 67.43%91.04MB 23.09%  
> github.com/newrelic/go-agent/v3/newrelic.endDatastoreSegment
>
>14.01MB  3.55% 70.98%18.01MB  4.57%  
> github.com/newrelic/go-agent/v3/newrelic.newTxn
>
>13.51MB  3.43% 74.41%93.13MB 23.62%  
> github.com/newrelic/go-agent/v3/newrelic.endExternalSegment
>
>12.01MB  3.05% 77.45%12.01MB  3.05%  
> github.com/newrelic/go-agent/v3/newrelic.getStackTrace
>
>10.51MB  2.66% 80.12%10.51MB  2.66%  
> github.com/newrelic/go-agent/v3/newrelic.(*slowQueries).insertAtIndex
>
>8MB  2.03% 82.15%8MB  2.03%  
> github.com/newrelic/go-agent/v3/newrelic.newSlowQueries
>
> 6.51MB  1.65% 85.73% 6.51MB  1.65%  
> github.com/DataDog/datadog-go/statsd.newStatsdBuffer
>
>4MB  1.01% 86.75%52.01MB 13.19%  
> github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).addString
>
> 3.50MB  0.89% 87.64% 3.50MB  0.89%  
> go.uber.org/zap.(*Logger).clone
>
> 3.50MB  0.89% 88.52% 3.50MB  0.89%  
> github.com/newrelic/go-agent/v3/newrelic.externalMetricKey.scopedMetric
>
>3MB  0.76% 89.28%3MB  0.76%  
> github.com/newrelic/go-agent/v3/newrelic.addUserAttribute
>
>3MB  0.76% 90.05%3MB  0.76%  strings.(*Builder).WriteString
>
> 2.50MB  0.63% 90.68% 6.06MB  1.54%  encoding/json.Unmarshal
>
> 2.50MB  0.63% 91.31% 2.50MB  0.63%  context.(*cancelCtx).Done
>
> =
>
> Resetting the buffer by defer didn't help either. So moved to string 
> builder like this
>
> func replacePositionalPlaceholders(sql, prefix string) (string, error) {
> buf := {}
> defer buf.Reset()
>
> i := 0
> for {
> p := strings.Index(sql, "?")
> if p == -1 {
> break
> }
>
> if len(sql[p:]) > 1 && sql[p:p+2] == "??" { // escape ?? => ?
> buf.WriteString(sql[:p])
> buf.WriteString("?")
> if len(sql[p:]) == 1 {
> break
> }
> sql = sql[p+2:]
> } else {
> i++
> buf.WriteString(sql[:p])
> fmt.Fprintf(buf, "%s%d", prefix, i)
> sql = sql[p+1:]
> }
> }
>
> buf.WriteString(sql)
> return buf.String(), nil
> }
>
> ==
>
> This didn't help either, from the results below
>
> (pprof) top20
>
> Showing nodes accounting for 220.09MB, 90.37% of 243.55MB total
>
> Dropped 126 nodes (cum <= 1.22MB)
>
> Showing top 20 nodes out of 135
>
>   flat  flat%   sum%cum   cum%
>
>33.97MB 13.95% 13.95%33.97MB 13.95%  strings.(*Builder).Write
>
>29.07MB 11.94% 25.89%29.57MB 12.14%  
> github.com/newrelic/go-agent/v3/newrelic.(*txnTrace).witnessNode
>
>28.01MB 11.50% 37.39%28.01MB 11.50%  
> github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).add
>
>24.34MB  9.99% 47.38%24.34MB  9.99%  strings.(*Builder).WriteString
>
>18.52MB  7.60% 54.98%18.52MB  7.60%  
> go.uber.org/zap/buffer.NewPool.func1
>
>11.01MB  4.52% 59.50%60.59MB 24.88%  
> github.com/newrelic/go-agent/v3/newrelic.endExternalSegment
>
>10.01MB  4.11% 63.61%13.51MB  5.55%  
> github.com/newrelic/go-agent/v3/newrelic.newTxn
>
>   10MB  4.11% 67.72%   10MB  4.11%  
> github.com/newrelic/go-agent/v3/newrelic.segmentEnd.spanEvent
>
>7MB  2.88% 73.73%7MB  2.88%  
> github.com/newrelic/go-agent/v3/newrelic.(*slowQueries).insertAtIndex
>
>7MB  2.88% 76.60%50.02MB 20.54%  
> github.com/newrelic/go-agent/v3/newrelic.endDatastoreSegment
>
> 6.51MB  2.67% 79.28% 6.51MB  2.67%  
> github.com/DataDog/datadog-go/statsd.newStatsdBuffer
>
>6MB  2.46% 81.74% 6.50MB  2.67%  
> github.com/newrelic/go-agent/v3/newrelic.addUserAttribute
>
> 5.50MB  2.26% 84.00% 5.50MB  2.26%  
> github.com/newrelic/go-agent/v3/newrelic.getStackTrace
>
>3MB  1.23% 85.23%3MB  1.23%  
> 

[go-nuts] Memory Leak in bytes.Buffer String() method

[Sarath Prabath Redlapalli Jaya]

Hi, we've been observing high memory usage in the following code
https://github.com/Masterminds/squirrel/blob/master/placeholder.go#L113

We measured from pprof of heap

(pprof) top20

Showing nodes accounting for 360.07MB, 91.31% of 394.32MB total

Dropped 142 nodes (cum <= 1.97MB)

Showing top 20 nodes out of 139

  flat  flat%   sum%cum   cum%

  101.21MB 25.67% 25.67%   101.21MB 25.67%  bytes.(*Buffer).String

   48.01MB 12.18% 37.84%48.01MB 12.18%  
github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).add

   42.61MB 10.81% 48.65%43.11MB 10.93%  
github.com/newrelic/go-agent/v3/newrelic.(*txnTrace).witnessNode

   38.54MB  9.77% 58.42%38.54MB  9.77%  
go.uber.org/zap/buffer.NewPool.func1

  19MB  4.82% 63.24%   19MB  4.82%  
github.com/newrelic/go-agent/v3/newrelic.segmentEnd.spanEvent

   16.51MB  4.19% 67.43%91.04MB 23.09%  
github.com/newrelic/go-agent/v3/newrelic.endDatastoreSegment

   14.01MB  3.55% 70.98%18.01MB  4.57%  
github.com/newrelic/go-agent/v3/newrelic.newTxn

   13.51MB  3.43% 74.41%93.13MB 23.62%  
github.com/newrelic/go-agent/v3/newrelic.endExternalSegment

   12.01MB  3.05% 77.45%12.01MB  3.05%  
github.com/newrelic/go-agent/v3/newrelic.getStackTrace

   10.51MB  2.66% 80.12%10.51MB  2.66%  
github.com/newrelic/go-agent/v3/newrelic.(*slowQueries).insertAtIndex

   8MB  2.03% 82.15%8MB  2.03%  
github.com/newrelic/go-agent/v3/newrelic.newSlowQueries

6.51MB  1.65% 85.73% 6.51MB  1.65%  
github.com/DataDog/datadog-go/statsd.newStatsdBuffer

   4MB  1.01% 86.75%52.01MB 13.19%  
github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).addString

3.50MB  0.89% 87.64% 3.50MB  0.89%  go.uber.org/zap.(*Logger).clone

3.50MB  0.89% 88.52% 3.50MB  0.89%  
github.com/newrelic/go-agent/v3/newrelic.externalMetricKey.scopedMetric

   3MB  0.76% 89.28%3MB  0.76%  
github.com/newrelic/go-agent/v3/newrelic.addUserAttribute

   3MB  0.76% 90.05%3MB  0.76%  strings.(*Builder).WriteString

2.50MB  0.63% 90.68% 6.06MB  1.54%  encoding/json.Unmarshal

2.50MB  0.63% 91.31% 2.50MB  0.63%  context.(*cancelCtx).Done

=

Resetting the buffer by defer didn't help either. So moved to string 
builder like this

func replacePositionalPlaceholders(sql, prefix string) (string, error) {
buf := {}
defer buf.Reset()

i := 0
for {
p := strings.Index(sql, "?")
if p == -1 {
break
}

if len(sql[p:]) > 1 && sql[p:p+2] == "??" { // escape ?? => ?
buf.WriteString(sql[:p])
buf.WriteString("?")
if len(sql[p:]) == 1 {
break
}
sql = sql[p+2:]
} else {
i++
buf.WriteString(sql[:p])
fmt.Fprintf(buf, "%s%d", prefix, i)
sql = sql[p+1:]
}
}

buf.WriteString(sql)
return buf.String(), nil
}

==

This didn't help either, from the results below

(pprof) top20

Showing nodes accounting for 220.09MB, 90.37% of 243.55MB total

Dropped 126 nodes (cum <= 1.22MB)

Showing top 20 nodes out of 135

  flat  flat%   sum%cum   cum%

   33.97MB 13.95% 13.95%33.97MB 13.95%  strings.(*Builder).Write

   29.07MB 11.94% 25.89%29.57MB 12.14%  
github.com/newrelic/go-agent/v3/newrelic.(*txnTrace).witnessNode

   28.01MB 11.50% 37.39%28.01MB 11.50%  
github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).add

   24.34MB  9.99% 47.38%24.34MB  9.99%  strings.(*Builder).WriteString

   18.52MB  7.60% 54.98%18.52MB  7.60%  
go.uber.org/zap/buffer.NewPool.func1

   11.01MB  4.52% 59.50%60.59MB 24.88%  
github.com/newrelic/go-agent/v3/newrelic.endExternalSegment

   10.01MB  4.11% 63.61%13.51MB  5.55%  
github.com/newrelic/go-agent/v3/newrelic.newTxn

  10MB  4.11% 67.72%   10MB  4.11%  
github.com/newrelic/go-agent/v3/newrelic.segmentEnd.spanEvent

   7MB  2.88% 73.73%7MB  2.88%  
github.com/newrelic/go-agent/v3/newrelic.(*slowQueries).insertAtIndex

   7MB  2.88% 76.60%50.02MB 20.54%  
github.com/newrelic/go-agent/v3/newrelic.endDatastoreSegment

6.51MB  2.67% 79.28% 6.51MB  2.67%  
github.com/DataDog/datadog-go/statsd.newStatsdBuffer

   6MB  2.46% 81.74% 6.50MB  2.67%  
github.com/newrelic/go-agent/v3/newrelic.addUserAttribute

5.50MB  2.26% 84.00% 5.50MB  2.26%  
github.com/newrelic/go-agent/v3/newrelic.getStackTrace

   3MB  1.23% 85.23%3MB  1.23%  
github.com/newrelic/go-agent/v3/newrelic.newSlowQueries

   3MB  1.23% 86.47%3MB  1.23%  go.uber.org/zap.(*Logger).clone

   3MB  1.23% 87.70%3MB  1.23%  
github.com/newrelic/go-agent/v3/newrelic.externalMetricKey.scopedMetric

2.50MB  1.03% 88.72%30.51MB 12.53%  
github.com/newrelic/go-agent/v3/newrelic.(*spanAttributeMap).addString

   2MB  0.82% 90.37%2MB  0.82%  encoding/hex.EncodeToString

(pprof) peek Write

Showing nodes accounting for 243.55MB, 100% of 243.55MB total

--+-

  flat  flat%   sum%cum   cum%   calls calls% 

[go-nuts] about go tool link, where link get code(text segment) from *.o files and write it to executable files?

[xie cui]

i am trying to understand code of cmd/link,  i need to know where linker 
get instructions(text segment in executable file) from *o file, and where 
linker write the binary data (.text segment) to excutable file(in linux it 
's a elf file).

-- 
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/d7f80c72-e25e-42c3-bd33-24e355975dbdn%40googlegroups.com.

Re: [go-nuts] List inside struct

[Shyaka Rene]

Thank you, it worked, everything is automatic in Go when you come from Rust
and Java, Thank you again

On Sun, Aug 30, 2020 at 2:59 AM Bakul Shah  wrote:

> Unless there is a very strong reason to use a doubly linked list, you
> should just use a slice:
>
> type Persons struct { name string; Names []string }
>
> I redid your program using the above here:
> https://play.golang.org/p/x5I1wYiCNGA
>
> Sounds like you are coming from some object oriented language background.
> Suggest reading "Effective Go": https://golang.org/doc/effective_go.html
>
> On Aug 29, 2020, at 9:35 AM, Shyaka  wrote:
>
> Hello, I need help, I have a struct Person wiith list inside, I add 5
> string on list at the end I found that the list is nil, I don't know whre
> is the error, any help is appreciated.
>
> package main
>
> import (
> "container/list"
> "fmt"
> )
>
> type Persons struct {
> name  string
> Names list.List
> }
>
> func main() {
>
> p := {
> name:  "",
> Names: *list.New(),
> }
> p.setName("John Peter")
> p.add("one")
> p.add("two")
> p.add("three")
> p.add("four")
> p.add("five")
> p.display()
>
> }
>
> func (p *Persons) setName(name string) {
> p.name = name
> }
> func (p *Persons) add(name string) {
> p.Names.PushBack(name)
> }
> func (p *Persons) display() {
> fmt.Println(p.name)
> for e := p.Names.Front(); e != nil; e = e.Next() {
> fmt.Println(e.Value)
> }
> }
>
> --
> 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/e8975da6-9af2-4660-8dbb-1a7e7e9b67cfn%40googlegroups.com
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOix%2Bb4R13dQFJvfSXKERaWKaUQe8u-e1WMojVg2kKh6fuJFDg%40mail.gmail.com.