[go-nuts] Re: What is the relationship between go community and goproxy.io

[Brian Candler]

> By the go module cache system design, if you trust the server set in your 
GOSUMDB env var,
> which is defaulted to sum.golang.org, then it is not a matter whatever 
proxy server your are using.

>From the point of view of downloaded package integrity, yes.

But there are other things an untrustworthy proxy might do - such as 
tracking what packages and versions you use, identifying which clients are 
using packages with known security vulnerabilities, selling that data on to 
third parties etc.

-- 
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/30d2e0ff-2700-43bc-8cd6-0ead64baed7bn%40googlegroups.com.

Re: [go-nuts] Practical use cases of recover in golang

[Brian Candler]

On Monday, 10 October 2022 at 06:21:48 UTC+1 Henry wrote:

> You may want to make your app more robust by handling panic in the topmost 
> layer of your application. With many people working on the code and various 
> external dependencies, it is often impractical to ensure none of the code 
> panics. This is where recover comes in.


I'd say that's a very poor reason to use recover.

To clarify, there are two types of panic:
1. Those where the code author has invoked panic(...) explicitly (there are 
various reasons for doing this)
2. Those where the integrity of the runtime has been violated - e.g. a race 
has caused a data structure corruption. This can be as simple as two 
goroutines concurrently accessing the same map or slice.

In case (2), the entire go runtime is in an indeterminate state. Attempting 
to recover and continue is futile at best, downright dangerous at worst.

Therefore, if you want to handle panics caused by code bugs, you should run 
your process under an external supervisor (like systemd or kubernetes) 
which logs the stderr output and restarts the program if it crashes.

-- 
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/9e2100f3-c1dd-4adc-b536-cfd5c6e71f61n%40googlegroups.com.

[go-nuts] Re: Practical use cases of recover in golang

[Vladimir Varankin]

One particular example is if you use std's net/http server, you 
(indirectly) use recover. The std's documentation for the Handler interface 
has a section, where they outline how the server recovers from a panic, 
that fired in the context of a request https://pkg.go.dev/net/http#Handler

On Sunday, October 9, 2022 at 11:16:52 PM UTC+2 cg-guy wrote:

> Hi Team,
>
> Whatever I have been worked so far with golang,I did not use recover() 
> function . 
> Curious to know if anyone using recover in production code and can you 
> please 
> the scenarios where it is used. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/da146c8e-2275-4163-b43e-879f52d139d8n%40googlegroups.com.

[go-nuts] Does Go team have a preference on codegen over reflect style?

[ag9920]

There're many reflect-based mock and inject tools, and they are quite 
helpful.

But I noticed that the famous official mock tool mockgen and dependency 
injection tool wire both follow codegen style.

So just out of curiosity, I want to know the underlying reason for that, is 
codegen better than reflect? 

-- 
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/3e8f7f35-2b19-48e5-b006-550a2a42b548n%40googlegroups.com.

[go-nuts] Re: Issue with go-git API

[peterGo]

Follow the instructions in the error messages: see `go help modules`.

On Monday, October 10, 2022 at 1:35:38 AM UTC-4 princ...@gmail.com wrote:

> I am trying to use this git api(*https://github.com/go-git/go-git 
> *), but before that I tried to run the 
> provided example (i.e. cloning the repo by golang). So I run the program 
> *https://github.com/go-git/go-git/blob/master/_examples/clone/main.go 
> *
>
> So when I run this program I used to get this error:
> sample.go:7:2: no required module provides package 
> github.com/go-git/go-git/v5: go.mod file not found in current directory 
> or any parent directory; see 'go help modules'
>
> sample.go:8:2: no required module provides package 
> github.com/go-git/go-git/v5/_examples: go.mod file not found in current 
> directory or any parent directory; see 'go help modules'
>
> *Please help me, how I can execute this?*
>
> I am using the following:
> Go version: go version go1.18.1 linux/amd64
> Platform:  Ubuntu 22.04.1 LTS

-- 
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/390f1b49-22d4-44ec-ab6a-79cb6aec83efn%40googlegroups.com.

Re: [go-nuts] Issue with go-git API

[Martin Schnabel]

Hi PK,

most of the time examples are single file programs to be used with go 
run. if you are inside the module root that covers all the dependencies 
(or decend into the relevant example folder) you can use `go run 
main.go` to run the example file.


I just tired it with the same repository and it works as expected and 
described.


have fun!

On 10/10/22 07:35, PK wrote:
I am trying to use this git api(*https://github.com/go-git/go-git*), but 
before that I tried to run the provided example (i.e. cloning the repo 
by golang). So I run the program

*https://github.com/go-git/go-git/blob/master/_examples/clone/main.go*

So when I run this program I used to get this error:
sample.go:7:2: no required module provides package 
github.com/go-git/go-git/v5: go.mod file not found in current directory 
or any parent directory; see 'go help modules'


sample.go:8:2: no required module provides package 
github.com/go-git/go-git/v5/_examples: go.mod file not found in current 
directory or any parent directory; see 'go help modules'


*Please help me, how I can execute this?*

I am using the following:
Go version: go version go1.18.1 linux/amd64
Platform:  Ubuntu 22.04.1 LTS

--
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/353c43c7-99bc-4e85-bf94-a5daff749640n%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/037ea98b-6cab-66cf-cb31-e67a10f603ac%40mb0.org.

[go-nuts] Re: Issue with go-git API

[Brian Candler]

Basically, every program now needs a "go.mod" file.  Even a "hello world" 
program should be made like this:

mkdir hello
cd hello
go mod init example.com/hello# this creates "go.mod"
vi hello.go   # create your program here
go run .

Whilst it still does work to say "go run hello.go" for a simple 
hello-world-and-nothing-else, as soon as it depends on any third-party 
libraries, it will fail.  You *must* include a go.mod file.  Then when you 
import external libraries, "go mod tidy" will fetch them for you, including 
their dependencies, and update go.mod

On Monday, 10 October 2022 at 06:35:38 UTC+1 princ...@gmail.com wrote:

> I am trying to use this git api(*https://github.com/go-git/go-git 
> *), but before that I tried to run the 
> provided example (i.e. cloning the repo by golang). So I run the program 
> *https://github.com/go-git/go-git/blob/master/_examples/clone/main.go 
> *
>
> So when I run this program I used to get this error:
> sample.go:7:2: no required module provides package 
> github.com/go-git/go-git/v5: go.mod file not found in current directory 
> or any parent directory; see 'go help modules'
>
> sample.go:8:2: no required module provides package 
> github.com/go-git/go-git/v5/_examples: go.mod file not found in current 
> directory or any parent directory; see 'go help modules'
>
> *Please help me, how I can execute this?*
>
> I am using the following:
> Go version: go version go1.18.1 linux/amd64
> Platform:  Ubuntu 22.04.1 LTS

-- 
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/39c1bc4d-cf78-4799-8a69-40d6f9134afdn%40googlegroups.com.

[go-nuts] Detecting JSON changes

[Slawomir Pryczek]

Hi Guys,
I have 2 json files, A, B. Now i want to detect changes on the root level.

File A: {"a":{"b":1, "c":2}, "x":false,  ... }
File B: {"a":{"b":1, "c":2}, "x":true,  ... }

I want to be able to see that x is different between A and B and a stayed 
the same. What would be the easiest approach?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7e88ac99-b6ff-49af-95a9-c1c5d7cf9236n%40googlegroups.com.

Re: [go-nuts] Detecting JSON changes

[burak serdar]

On Mon, Oct 10, 2022 at 8:50 AM Slawomir Pryczek 
wrote:

> Hi Guys,
> I have 2 json files, A, B. Now i want to detect changes on the root level.
>
> File A: {"a":{"b":1, "c":2}, "x":false,  ... }
> File B: {"a":{"b":1, "c":2}, "x":true,  ... }
>
> I want to be able to see that x is different between A and B and a stayed
> the same. What would be the easiest approach?
>

This is not easy in general. Try using an available package, like:
github.com/wI2L/jsondiff


>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7e88ac99-b6ff-49af-95a9-c1c5d7cf9236n%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/CAMV2RqohB%3DrtvNLWwtL0MOrNHf%3Deu0j%2BYm0NsQJi14nfc_W--A%40mail.gmail.com.

Re: [go-nuts] Detecting JSON changes

[Shulhan]

On Mon, 10 Oct 2022 07:50:20 -0700 (PDT)
Slawomir Pryczek  wrote:

> Hi Guys,
> I have 2 json files, A, B. Now i want to detect changes on the root
> level.
> 
> File A: {"a":{"b":1, "c":2}, "x":false,  ... }
> File B: {"a":{"b":1, "c":2}, "x":true,  ... }
> 
> I want to be able to see that x is different between A and B and a
> stayed the same. What would be the easiest approach?
> 
> Thanks
> 

I can think three options here.

One, create a type T that unmarshal the JSON into T and add method that
compare each fields.

Two, create a type T and unmarshal the JSON into T and use third party
library that do struct comparison.

Three, diff the text as is using third party library.

For option two and three, I have some example here:

https://go.dev/play/p/bknJBK4m4CW

-- ms

-- 
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/20221010221608.0518b78f%40inspiro.localdomain.


pgpybFhctz21m.pgp
Description: OpenPGP digital signature

[go-nuts] golang.org/x/exp/jsonrpc2 bugs

[Maxime Soulé]

Hi Gophers!

Does anyone know if the jsonrpc2 sub-directory of golang.org/x/exp is still 
maintained?

If yes, perhaps could you point me to the right person? as there are 2 
pending bug fixes that do not seem to arouse somebody curiosity :)

https://go-review.googlesource.com/c/exp/+/412334
https://go-review.googlesource.com/c/exp/+/436888

As I am here, I also proposed a slight improvement to expose errors content 
to the caller:

https://go-review.googlesource.com/c/exp/+/415615

Thanks for your help.

Regards,

Max.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6cd447cb-fe57-4aaf-9c42-7cce9154bb56n%40googlegroups.com.

[go-nuts] behavior of %f

[Dante Castagnoli]

Hi,

I'm wondering what folks think about the behavior of %f and precision.

The go fmt documentation states:
> For floating-point values, width sets the minimum width of the field and 
precision sets the number of places after the decimal, 

What I discovered is there is rounding going on in %f as shown below.

https://go.dev/play/p/23AfRtwOqcD

I found this behavior as I'm converting floats to integers, and was testing 
fine regions between digits, and experienced the behavior.   I didn't 
expect it.

I expected the behavior of printing "n" characters of a string.  However, I 
note that "c" behaves the same way:

$ cat math.c
#include
int main(int argc, char *argv[]) {
printf("%0.3f\n", 0.99);
}
$ ./math
1.000
$ 

-- 
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/732843d6-2a65-4bed-b199-8b0260a1e82bn%40googlegroups.com.

[go-nuts] Internationalized webpage depending on the user's web browser locale

[Christoph]

Hello,

I am running a git-server, powered by gitea, an open-source git server 
project written in Go. In gitea, it is possible to customize the home page, 
what I did. My customized home page, among other things, contains:

{{if eq .Lang "de-DE"}} 
  Willkommen auf dem Git-Server der Fakultät für Informatik der TU 
Dortmund 
 {{else}} 
   Welcome to the GIT server of the Faculty of Computer Science of 
the TU Dortmund 
 {{end}}

This worked with gitea 1.14.5, compiled with some older version of golang, 
but unfortunately, it does not work in gitea 1.17.2, compiled with golang 
1.19.1; the language of the displayed webpage is English, though my browser 
locale is German.

As far as I found on the internet, the if-else-clause and the .LANG 
variable come from Go, so I ask here if anyone has an idea of how to make 
the above work again.

Regards
  Christoph 


 

-- 
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/ace1198c-d4c4-4208-9bc8-c5db0ae0cb48n%40googlegroups.com.

[go-nuts] Re: golang.org/x/exp/jsonrpc2 bugs

[Jason Phillips]

Are these existing known bugs or did you open a ticket on the Go bug 
tracker? If there are already tickets for these known bugs, you should 
mention the ticket number in your code review. If there aren't tickets, you 
should probably start by opening a ticket and then linking to your changes.

As for your feature/improvement, it's also generally best to discuss such 
things as an issue or on the go-dev mailing list before digging in, if only 
so you don't waste time working on things that may not be accepted.

Here's a link to Go's contribution guide if you haven't seen 
it: https://go.dev/doc/contribute

On Monday, October 10, 2022 at 11:32:15 AM UTC-4 zept...@gmail.com wrote:

> Hi Gophers!
>
> Does anyone know if the jsonrpc2 sub-directory of golang.org/x/exp is 
> still maintained?
>
> If yes, perhaps could you point me to the right person? as there are 2 
> pending bug fixes that do not seem to arouse somebody curiosity :)
>
> https://go-review.googlesource.com/c/exp/+/412334
> https://go-review.googlesource.com/c/exp/+/436888
>
> As I am here, I also proposed a slight improvement to expose errors 
> content to the caller:
>
> https://go-review.googlesource.com/c/exp/+/415615
>
> Thanks for your help.
>
> Regards,
>
> Max.
>

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

[go-nuts] Re: behavior of %f

[Brian Candler]

Whilst Go handles constants with arbitrary precision AFAIK, precision is 
lost once values are assigned to a float64 variable (or passed as an 
argument to a function).  There are only 53 bits of precision in the 
"mantissa".

For more info, you might find this helpful:
https://0.30004.com/

On Monday, 10 October 2022 at 17:48:56 UTC+1 dante.ca...@gmail.com wrote:

> Hi,
>
> I'm wondering what folks think about the behavior of %f and precision.
>
> The go fmt documentation states:
> > For floating-point values, width sets the minimum width of the field and 
> precision sets the number of places after the decimal, 
>
> What I discovered is there is rounding going on in %f as shown below.
>
> https://go.dev/play/p/23AfRtwOqcD
>
> I found this behavior as I'm converting floats to integers, and was 
> testing fine regions between digits, and experienced the behavior.   I 
> didn't expect it.
>
> I expected the behavior of printing "n" characters of a string.  However, 
> I note that "c" behaves the same way:
>
> $ cat math.c
> #include
> int main(int argc, char *argv[]) {
> printf("%0.3f\n", 0.99);
> }
> $ ./math
> 1.000
> $ 
>

-- 
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/e3dfb9d8-285f-486c-a487-04a2a4410c77n%40googlegroups.com.

[go-nuts] Write heap dump in a forked process - could that be even possible?

[Konstantin Khomoutov]

More than once at my $dayjob we experienced the need to grab the heap dump or
a running process implementing some critical functionality.
The problem is that saving of the dump file requires freezing of the process,
and if its memory consumption is relatively high (in our case it clocked
around 50 GiB), saving of the dump freezes the process for too long to have
negative impact (the service processes "real-time" data).

I were thinking of an approach similar to what Redis uses for one of its
backup modes on Unix (I'm mainly interested in Linux): it periodically forks
itself and the child then saves away the memory it "inherited" from its parent
while the parent continues working. This feature takes advantage of the memory
CoW mechanism implemented on Linux (and I think on most if not all popular
platforms which have fork) to have total memory consumption resonably low, and
allows the main process to have relatively brief pauses - required only to
fork a child copy and be done with it.

Could something like this at leat theoretically be implemented for Go's
runtime/debug.WriteHeapDump?

Well, in order to not create an XY Problem, I should stress that my end goal
would be to have a way to "dump core" of a running Go process with big memory
footprint in a way to not freeze the process for too long (under, say, 2
seconds).  Being able to somehow collect the "classic" core file (using
something what `gcore` does with the help of GDB) would be fine as well, but
`gcore` freezes the process as well.

-- 
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/20221010183320.rdm4dyijfcl6hj6n%40carbon.

Re: [go-nuts] Internationalized webpage depending on the user's web browser locale

['Sean Liao' via golang-nuts]

.Lang comes from something gitea provided to the template, it's not an
intrinsic part of go

- sean

On Mon, Oct 10, 2022, 19:48 Christoph  wrote:

> Hello,
>
> I am running a git-server, powered by gitea, an open-source git server
> project written in Go. In gitea, it is possible to customize the home page,
> what I did. My customized home page, among other things, contains:
>
> {{if eq .Lang "de-DE"}}
>   Willkommen auf dem Git-Server der Fakultät für Informatik der TU
> Dortmund
>  {{else}}
>Welcome to the GIT server of the Faculty of Computer Science of
> the TU Dortmund
>  {{end}}
>
> This worked with gitea 1.14.5, compiled with some older version of golang,
> but unfortunately, it does not work in gitea 1.17.2, compiled with golang
> 1.19.1; the language of the displayed webpage is English, though my browser
> locale is German.
>
> As far as I found on the internet, the if-else-clause and the .LANG
> variable come from Go, so I ask here if anyone has an idea of how to make
> the above work again.
>
> Regards
>   Christoph
>
>
>
>
> --
> 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/ace1198c-d4c4-4208-9bc8-c5db0ae0cb48n%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/CAGabyPq1uCpi69N%2BhXK_bN578n4qN4ke1SFMU_AHpgPm4mEzmA%40mail.gmail.com.

[go-nuts] Re: golang.org/x/exp/jsonrpc2 bugs

[Maxime Soulé]

Hi Jason,

I didn't realized this repo followed the same rules as golang/go.

Thank for your help and sorry for the noise.

Regards,

Max.

Le lundi 10 octobre 2022 à 18:53:43 UTC+2, Jason Phillips a écrit :

> Are these existing known bugs or did you open a ticket on the Go bug 
> tracker? If there are already tickets for these known bugs, you should 
> mention the ticket number in your code review. If there aren't tickets, you 
> should probably start by opening a ticket and then linking to your changes.
>
> As for your feature/improvement, it's also generally best to discuss such 
> things as an issue or on the go-dev mailing list before digging in, if only 
> so you don't waste time working on things that may not be accepted.
>
> Here's a link to Go's contribution guide if you haven't seen it: 
> https://go.dev/doc/contribute
>
> On Monday, October 10, 2022 at 11:32:15 AM UTC-4 zept...@gmail.com wrote:
>
>> Hi Gophers!
>>
>> Does anyone know if the jsonrpc2 sub-directory of golang.org/x/exp is 
>> still maintained?
>>
>> If yes, perhaps could you point me to the right person? as there are 2 
>> pending bug fixes that do not seem to arouse somebody curiosity :)
>>
>> https://go-review.googlesource.com/c/exp/+/412334
>> https://go-review.googlesource.com/c/exp/+/436888
>>
>> As I am here, I also proposed a slight improvement to expose errors 
>> content to the caller:
>>
>> https://go-review.googlesource.com/c/exp/+/415615
>>
>> Thanks for your help.
>>
>> Regards,
>>
>> Max.
>>
>

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

[go-nuts] I need help with this project

[Kazuya Nomura]

Hello,
The project is about building a decentralized P2P network (platform) based 
on the IPFS or libp2p network framework. The project has 7 main phases:
1) Build a P2P network, where each node/peer participating in this network 
must be capable of discovering, routing, messaging, file sharing, and 
pinging other nodes/peers. This can be done through the IPFS or LİBP2P. 
This step is very easy you just need to install one of the above-mentioned 
protocols and then deploy it as a private (isolated) network via "Swarm / 
DHT".
2) Setup a VPN based on hyperspace to enable Master and Worker nodes be 
accessible in RAY (if you can manage it through libp2p then this task can 
be skipped).
3) Resource management: each node/peer must be able to manage its resources 
(i.e. RAM, CPU, and storage).
4) Deploy RAY over this P2P network: RAY must be deployed, run, and tested 
in this platform when steps 1-2 are accomplished. It means that the 
platform must support an external application like RAY.
5) An API must be written to interconnect the P2P network and RAY.
6) The project must be delivered as a single executive file too.
7) Design and create a GUI (interface) for the platform to allow users to 
manage resources via the GUI, see other peers, etc. More detail will be 
given in the chat.
Important notes:
The P2P network must perform over the internet. It means nodes from 
different geographical locations can connect to this network.
 - security is a concern: for this, a Sandbox security mechanism can be 
used to create an isolated environment on the network (if you have another 
solution please propose it).
 -The platform should be run in a Windows environment (windows 10 and 
beyond): The priority is to deploy it in Windows but if there is a 
restriction, we can deploy it in Ubuntu (this needs to be negotiated at the 
beginning of the project).
 - My preference is to use IPFS (python) or LibP2P based on GoLang, but 
other languages are welcome if you can convince me.


-
I need help with this project, 
Please DM me via mail.
Thank you && Regards.
Kazuya Nomura

-- 
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/87f1ae99-c4ce-469e-b36e-cdbb9de28ab5n%40googlegroups.com.

[go-nuts] Re: behavior of %f

[Dante Castagnoli]

Thanks!

It's not lost, though.  It shows up with the %g form.

Knowing about %g, my issue is not extant, but others might hit it.  I'm 
relatively new to floating point issues, and I saw numbers showing up as 
integers, and it took a while to sort out what was going on, is all.

As the behavior matches "c", I would suggest at minimum making the 
documentation clearer.

https://go.dev/play/p/WBlf3jltimr

On Monday, October 10, 2022 at 10:27:00 AM UTC-7 Brian Candler wrote:

> Whilst Go handles constants with arbitrary precision AFAIK, precision is 
> lost once values are assigned to a float64 variable (or passed as an 
> argument to a function).  There are only 53 bits of precision in the 
> "mantissa".
>
> For more info, you might find this helpful:
> https://0.30004.com/
>
> On Monday, 10 October 2022 at 17:48:56 UTC+1 dante.ca...@gmail.com wrote:
>
>> Hi,
>>
>> I'm wondering what folks think about the behavior of %f and precision.
>>
>> The go fmt documentation states:
>> > For floating-point values, width sets the minimum width of the field 
>> and precision sets the number of places after the decimal, 
>>
>> What I discovered is there is rounding going on in %f as shown below.
>>
>> https://go.dev/play/p/23AfRtwOqcD
>>
>> I found this behavior as I'm converting floats to integers, and was 
>> testing fine regions between digits, and experienced the behavior.   I 
>> didn't expect it.
>>
>> I expected the behavior of printing "n" characters of a string.  However, 
>> I note that "c" behaves the same way:
>>
>> $ cat math.c
>> #include
>> int main(int argc, char *argv[]) {
>> printf("%0.3f\n", 0.99);
>> }
>> $ ./math
>> 1.000
>> $ 
>>
>

-- 
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/4a15ac2c-e30d-4d6e-be8f-251996fb01cen%40googlegroups.com.

Re: [go-nuts] get function body comments using ast

['wagner riffel' via golang-nuts]

On 10/9/22 11:09, Dmitry Belyaev wrote:

For a function like below I'd get only *example // doc comment*,

// doc comment
func example() {
   // body comment   < looking to extract this comment
}

but I am looking also to extract *// body comment*.

Please advise on how to extract function name, doc comment AND body 
comment altogether. Thank you!




I don't think go/parser adds comments to functions body []Stmt list, 
though if go through all comments in ast.File and filter by those that 
are in range with function's block statement, maybe that's enough.


https://go.dev/play/p/S4Iz504K8Gm

-w


--
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/3758c4a4-bff7-3c15-91ac-8b5cb3d550d3%40104d.net.

Re: [go-nuts] Re: behavior of %f

[Rob Pike]

This behavior is how floating-point math works, which is not best addressed
in the documentation for the formatted I/O library. We see may comments
from people new to floating point who argue that there are bugs in Go's
arithmetic, but it's invariably a lack of familiarity with the—admittedly
rather tricky—properties of imprecise arithmetic.

-rob


On Tue, Oct 11, 2022 at 9:01 AM Dante Castagnoli 
wrote:

> Thanks!
>
> It's not lost, though.  It shows up with the %g form.
>
> Knowing about %g, my issue is not extant, but others might hit it.  I'm
> relatively new to floating point issues, and I saw numbers showing up as
> integers, and it took a while to sort out what was going on, is all.
>
> As the behavior matches "c", I would suggest at minimum making the
> documentation clearer.
>
> https://go.dev/play/p/WBlf3jltimr
>
> On Monday, October 10, 2022 at 10:27:00 AM UTC-7 Brian Candler wrote:
>
>> Whilst Go handles constants with arbitrary precision AFAIK, precision is
>> lost once values are assigned to a float64 variable (or passed as an
>> argument to a function).  There are only 53 bits of precision in the
>> "mantissa".
>>
>> For more info, you might find this helpful:
>> https://0.30004.com/
>>
>> On Monday, 10 October 2022 at 17:48:56 UTC+1 dante.ca...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> I'm wondering what folks think about the behavior of %f and precision.
>>>
>>> The go fmt documentation states:
>>> > For floating-point values, width sets the minimum width of the field
>>> and precision sets the number of places after the decimal,
>>>
>>> What I discovered is there is rounding going on in %f as shown below.
>>>
>>> https://go.dev/play/p/23AfRtwOqcD
>>>
>>> I found this behavior as I'm converting floats to integers, and was
>>> testing fine regions between digits, and experienced the behavior.   I
>>> didn't expect it.
>>>
>>> I expected the behavior of printing "n" characters of a string.
>>> However, I note that "c" behaves the same way:
>>>
>>> $ cat math.c
>>> #include
>>> int main(int argc, char *argv[]) {
>>> printf("%0.3f\n", 0.99);
>>> }
>>> $ ./math
>>> 1.000
>>> $
>>>
>> --
> 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/4a15ac2c-e30d-4d6e-be8f-251996fb01cen%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/CAOXNBZRq9U4O-cCFxugZSFmJf-z0rR10HAE5Do2HGDPB30nuXQ%40mail.gmail.com.

Re: [go-nuts] Re: behavior of %f

[Dante Castagnoli]

Thanks, Rob,

As the behavior is as in "C", the behavior is as it should be.  I also
understand that "1" is a closer representation than 0. should the
number be 0.9, though it's a choice as it diverges from string-type
formats.  Regardless of whether the choice was right or wrong, it is
immaterial in my view, as any change would confuse those familiar with the
current behavior.

I do think the documentation I cited above could be clearer, and without
difficulty.  The documentation of "precision" leads one to believe that
additional digits will be printed, leaving one with the impression those
digits will be as they are in the float, and not rounded.

Thanks for the response.  My view of the issue hasn't really changed given
the responses.  I'm simply considering how this might be easier for others,
as I now understand the behavior.  That's all.

D.



On Mon, Oct 10, 2022 at 4:23 PM Rob Pike  wrote:

> This behavior is how floating-point math works, which is not best
> addressed in the documentation for the formatted I/O library. We see may
> comments from people new to floating point who argue that there are bugs in
> Go's arithmetic, but it's invariably a lack of familiarity with
> the—admittedly rather tricky—properties of imprecise arithmetic.
>
> -rob
>
>
> On Tue, Oct 11, 2022 at 9:01 AM Dante Castagnoli <
> dante.castagn...@gmail.com> wrote:
>
>> Thanks!
>>
>> It's not lost, though.  It shows up with the %g form.
>>
>> Knowing about %g, my issue is not extant, but others might hit it.  I'm
>> relatively new to floating point issues, and I saw numbers showing up as
>> integers, and it took a while to sort out what was going on, is all.
>>
>> As the behavior matches "c", I would suggest at minimum making the
>> documentation clearer.
>>
>> https://go.dev/play/p/WBlf3jltimr
>>
>> On Monday, October 10, 2022 at 10:27:00 AM UTC-7 Brian Candler wrote:
>>
>>> Whilst Go handles constants with arbitrary precision AFAIK, precision is
>>> lost once values are assigned to a float64 variable (or passed as an
>>> argument to a function).  There are only 53 bits of precision in the
>>> "mantissa".
>>>
>>> For more info, you might find this helpful:
>>> https://0.30004.com/
>>>
>>> On Monday, 10 October 2022 at 17:48:56 UTC+1 dante.ca...@gmail.com
>>> wrote:
>>>
 Hi,

 I'm wondering what folks think about the behavior of %f and precision.

 The go fmt documentation states:
 > For floating-point values, width sets the minimum width of the field
 and precision sets the number of places after the decimal,

 What I discovered is there is rounding going on in %f as shown below.

 https://go.dev/play/p/23AfRtwOqcD

 I found this behavior as I'm converting floats to integers, and was
 testing fine regions between digits, and experienced the behavior.   I
 didn't expect it.

 I expected the behavior of printing "n" characters of a string.
 However, I note that "c" behaves the same way:

 $ cat math.c
 #include
 int main(int argc, char *argv[]) {
 printf("%0.3f\n", 0.99);
 }
 $ ./math
 1.000
 $

>>> --
>> 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/4a15ac2c-e30d-4d6e-be8f-251996fb01cen%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/CAEaSmXcfd3MO3eRjHkshi%3DMg3G9RrN9rH1B%3DSoJVth3BDG5-dg%40mail.gmail.com.

Re: [go-nuts] behavior of %f

[robert engels]

I will add that this is why most financial applications using “fixed place” or 
“integer math” libraries - to have control over these sorts of issues.

An example is robaho/fixed 

> On Oct 10, 2022, at 6:35 PM, Dante Castagnoli  
> wrote:
> 
> Thanks, Rob,
> 
> As the behavior is as in "C", the behavior is as it should be.  I also 
> understand that "1" is a closer representation than 0. should the number 
> be 0.9, though it's a choice as it diverges from string-type formats.  
> Regardless of whether the choice was right or wrong, it is immaterial in my 
> view, as any change would confuse those familiar with the current behavior.
> 
> I do think the documentation I cited above could be clearer, and without 
> difficulty.  The documentation of "precision" leads one to believe that 
> additional digits will be printed, leaving one with the impression those 
> digits will be as they are in the float, and not rounded.
> 
> Thanks for the response.  My view of the issue hasn't really changed given 
> the responses.  I'm simply considering how this might be easier for others, 
> as I now understand the behavior.  That's all.
> 
> D.
> 
> 
> 
> On Mon, Oct 10, 2022 at 4:23 PM Rob Pike  > wrote:
> This behavior is how floating-point math works, which is not best addressed 
> in the documentation for the formatted I/O library. We see may comments from 
> people new to floating point who argue that there are bugs in Go's 
> arithmetic, but it's invariably a lack of familiarity with the—admittedly 
> rather tricky—properties of imprecise arithmetic.
> 
> -rob
> 
> 
> On Tue, Oct 11, 2022 at 9:01 AM Dante Castagnoli  > wrote:
> Thanks!
> 
> It's not lost, though.  It shows up with the %g form.
> 
> Knowing about %g, my issue is not extant, but others might hit it.  I'm 
> relatively new to floating point issues, and I saw numbers showing up as 
> integers, and it took a while to sort out what was going on, is all.
> 
> As the behavior matches "c", I would suggest at minimum making the 
> documentation clearer.
> 
> https://go.dev/play/p/WBlf3jltimr 
> 
> On Monday, October 10, 2022 at 10:27:00 AM UTC-7 Brian Candler wrote:
> Whilst Go handles constants with arbitrary precision AFAIK, precision is lost 
> once values are assigned to a float64 variable (or passed as an argument to a 
> function).  There are only 53 bits of precision in the "mantissa".
> 
> For more info, you might find this helpful:
> https://0.30004.com/ 
> 
> On Monday, 10 October 2022 at 17:48:56 UTC+1 dante.ca...@gmail.com <> wrote:
> Hi,
> 
> I'm wondering what folks think about the behavior of %f and precision.
> 
> The go fmt documentation states:
> > For floating-point values, width sets the minimum width of the field and 
> > precision sets the number of places after the decimal, 
> 
> What I discovered is there is rounding going on in %f as shown below.
> 
> https://go.dev/play/p/23AfRtwOqcD 
> 
> I found this behavior as I'm converting floats to integers, and was testing 
> fine regions between digits, and experienced the behavior.   I didn't expect 
> it.
> 
> I expected the behavior of printing "n" characters of a string.  However, I 
> note that "c" behaves the same way:
> 
> $ cat math.c
> #include
> int main(int argc, char *argv[]) {
> printf("%0.3f\n", 0.99);
> }
> $ ./math
> 1.000
> $ 
> 
> -- 
> 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/4a15ac2c-e30d-4d6e-be8f-251996fb01cen%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/CAEaSmXcfd3MO3eRjHkshi%3DMg3G9RrN9rH1B%3DSoJVth3BDG5-dg%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

Re: [go-nuts] Re: behavior of %f

['Sean Liao' via golang-nuts]

> leaving one with the impression those digits will be as they are in the
float, and not rounded.

This is a fundamental misunderstanding of what a float is. The rounding
happens the moment a value is stored in a float. The printed value is
exactly what is stored.

- sean

-- 
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/CAGabyPoZdWMjYUiq_LS44tvyCzxmUYRbQs4%2BY_8s0uSmO_%2BdNw%40mail.gmail.com.

Re: [go-nuts] Re: behavior of %f

[Dante Castagnoli]

Sean,

Your comment is not correct.  You can take the original program I wrote and
increase the digits and will notice they are printed as they are meant to
be.

Also, if you were to take an int(f), you will note that it returns "0", and
not "1".

Sorry!  Incorrect information ought to be corrected.  Run some tests to
convince yourself.

D

On Mon, Oct 10, 2022 at 5:34 PM Sean Liao  wrote:

> > leaving one with the impression those digits will be as they are in the
> float, and not rounded.
>
> This is a fundamental misunderstanding of what a float is. The rounding
> happens the moment a value is stored in a float. The printed value is
> exactly what is stored.
>
> - sean
>

-- 
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/CAEaSmXdenhQHEL-Pkd0mLg%2B0SKR6zdBYxvnV6P3kNQvVyOjn1A%40mail.gmail.com.

Re: [go-nuts] behavior of %f

[Bakul Shah]

On Oct 10, 2022, at 5:40 PM, Dante Castagnoli  
wrote:
> 
> Also, if you were to take an int(f), you will note that it returns "0", and 
> not "1".

%0.3f does *rounding*, while int(f) does *truncation*.
1.0 is closer to 0.... than 0.999 is to 0....

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

Re: [go-nuts] behavior of %f

[robert engels]

He was using that as an example to show that the value contained in the float 
is not 1, but less than 1, even though the print shows it as 1.

> On Oct 10, 2022, at 8:07 PM, Bakul Shah  wrote:
> 
> On Oct 10, 2022, at 5:40 PM, Dante Castagnoli  
> wrote:
>> 
>> Also, if you were to take an int(f), you will note that it returns "0", and 
>> not "1".
> 
> %0.3f does *rounding*, while int(f) does *truncation*.
> 1.0 is closer to 0.... than 0.999 is to 0....
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/B51E4191-D268-4F17-BD50-1FEB59B94379%40bitblocks.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/2A273781-F8A7-425C-8F08-12A49CBB0863%40ix.netcom.com.

Re: [go-nuts] Re: behavior of %f

[Patrick Smith]

This program (https://go.dev/play/p/w-QE790dGcs)

func main() {
f := 0.999
fmt.Printf("%0.2f %0.3f %0.4f\n", f, f, f)
fmt.Println(f)
fmt.Printf("%0.64f\n", f)
}

prints

1.00 0.999 0.9990
0.999
0.99899911182158029987476766109466552734375000


The last line prints enough places so that it can show the actual value
stored in f. Note that this is _not_ 0.999; it is the closest approximation
that can be stored in a float64.

The first line prints the best possible approximation to this value (not to
0.999) that can be done with 2, 3, or 4 decimal places.

The middle line prints a value that, when converted to float64, will yield
the actual value stored in f. Of course, by construction of this program,
0.999 will do and is shorter than printing the actual value.

On Mon, Oct 10, 2022 at 5:40 PM Dante Castagnoli 
wrote:

> Sean,
>
> Your comment is not correct.  You can take the original program I wrote
> and increase the digits and will notice they are printed as they are meant
> to be.
>
> Also, if you were to take an int(f), you will note that it returns "0",
> and not "1".
>
> Sorry!  Incorrect information ought to be corrected.  Run some tests to
> convince yourself.
>
> D
>
> On Mon, Oct 10, 2022 at 5:34 PM Sean Liao  wrote:
>
>> > leaving one with the impression those digits will be as they are in the
>> float, and not rounded.
>>
>> This is a fundamental misunderstanding of what a float is. The rounding
>> happens the moment a value is stored in a float. The printed value is
>> exactly what is stored.
>>
>> - sean
>>
> --
> 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/CAEaSmXdenhQHEL-Pkd0mLg%2B0SKR6zdBYxvnV6P3kNQvVyOjn1A%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/CAADvV_sLc-CUtOJbXDjbEi5Cv8Hai9q8XnYvnimaDPLDju_S1A%40mail.gmail.com.

[go-nuts] Re: What is the relationship between go community and goproxy.io

[tapi...@gmail.com]

On Monday, October 10, 2022 at 3:11:06 PM UTC+8 Brian Candler wrote:

> > By the go module cache system design, if you trust the server set in 
> your GOSUMDB env var,
> > which is defaulted to sum.golang.org, then it is not a matter whatever 
> proxy server your are using.
>
> From the point of view of downloaded package integrity, yes.
>
> But there are other things an untrustworthy proxy might do - such as 
> tracking what packages and versions you use, identifying which clients are 
> using packages with known security vulnerabilities, selling that data on to 
> third parties etc.
>

This is true for any website we visit daily. :D 

-- 
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/6bcbf0bf-1988-446b-ba80-1093786113b9n%40googlegroups.com.

Re: [go-nuts] Re: behavior of %f

[Patrick Smith]

On Mon, Oct 10, 2022 at 6:10 PM Patrick Smith  wrote:

>  %g differs from %f when printing large or small values.
> https://go.dev/play/p/lxj9fn19kOO
>

For the sake of completeness, I should add that they can also differ for
"normal" sized values: https://go.dev/play/p/xiFwOrK8Tv6
With %f, one specifies the number of fractional decimal places to appear;
with %g, the number of significant figures.

-- 
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/CAADvV_t%3DmR3W080zsCOH%3DQ-r5PX-rrbH%3DdhytObuMxB52x%3DUhA%40mail.gmail.com.