Re: [go-nuts] golang paths

[Dumitru Ungureanu]

I decided to place them all in one place for containment.
I used the names from envvars to get a simple answer to a simple question: 
*where 
is GOROOT?*, *in go/root*.

GOMODCACHE picks up GOPATH.
GOTOOLDIR picks up GOROOT.
GOTMPDIR defaults to system's tmp dir, I'm fine with that.
On Wednesday, December 9, 2020 at 9:02:46 AM UTC+2 Gergely Födémesi wrote:

> To clarify the go compiler toolchain is a trivial tree. Compared to
> most other mainstream languages and compilers, it's not scattered to
> different subtrees. I believe quite some effort went into that to stay
> that way.
> When using the go compiler toolchain some directories are used for
> caching compiler artifacts. (You could easily delete all of these
> files between compiling sessions, you'll still be able to compile
> everything again. Though only a very space constrained environment
> would require such a peculiar workflow.)
>
> If you are a go programmer the subtrees you set explicitly are 100%
> managed by the toolchain, there is no _need_ to ever look at them.
> Please note, that if you set them explicitly and with that you
> inadvertently mix and match different versions of go toolchain
> binaries and cached artifacts you'll most probably run into issues you
> don't want to have.
>
> Sure the environment variables can be set differently, if you have
> special requirements (maybe you don't have enough space on the same
> device). Sorry I wasn't clear: I tried to ask for these special
> requirements.
> To rephrase and clarify my original question: besides "Paths in
> symmetry with the environmental variables" why is it valuable to
> rearrange the subtrees for your use case? What are your
> requirements/issues you came up with a solution for?
>
> To help with your original question, assuming your only goal is to
> manage all subtrees exposed by environment variables "go env" shows at
> least 3 more trees you might want to set (GOMODCACHE, GOTOOLDIR,
> GOTMPDIR.)
>
>
>
> On 12/9/20, Dumitru Ungureanu  wrote:
> > Yes, there is no requirement to manage the envvars. I personally believe
> > there is a requirement to know about them, though.
> > I read the installation doc, I think there's a hang up on your part on 
> this
> >
> > one.
> > The default go tree is scattered different places, beside the obvious
> > trivial tree you're mentioning.
> > I'm arranging all the paths in a single place and I harmonize the paths
> > with the envvars.
> > Maybe you're missing the whole point I'm making in this blog post?
> > https://mitflit.ro/blog/golang-paths-of-mitflit/
> >
> > On Tuesday, December 8, 2020 at 10:47:27 PM UTC+2 Gergely Födémesi wrote:
> >
> >> There is no requirement to manage these variables or to know about them,
> >> even if you don't use the installer.
> >>
> >> I never use the installer and I've never needed to check on those
> >> environment variables.
> >>
> >> (The installation documentation is short and complete, maybe you should
> >> check it out again.)
> >>
> >> The installed go compiler is really just a trivial tree.
> >>
> >> On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu  wrote:
> >>
> >>> I don't use an installer. I set GOROOT/bin manually. And the rest
> >>> follows. Easy to remember, nothing to forget.
> >>>
> >>> On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi 
> wrote:
> >>>
>  On 12/8/20, Dumitru Ungureanu  wrote:
>  > Paths in symmetry with the environmental
>  > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin.
>  GOCACHE is
>  > go/cache, GOENV is go/env.
>  > Bonus points: modules in go/modules.
> 
>  Why do you need to manage them explicitly? When do you need to look at
>  GOROOT, GOBIN, GOCACHE or GOENV?
> 
>  (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
>  After modules became the default, I've never set GOPATH either.)
> 
>  >
>  > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi
>  wrote:
>  >
>  >> On 12/7/20, Dumitru Ungureanu  wrote:
>  >> ...
>  >> > I'm currently using this directory tree for golang.
>  >> ...
>  >> What do you mean when you write "golang"?
>  >>
>  >> Why is https://golang.org/doc/install not good enough for the go
>  >> compiler?
>  >>
>  >
>  > --
>  > 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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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 

Re: [go-nuts] what is these code line for?

[Ian Lance Taylor]

On Tue, Dec 8, 2020 at 11:11 PM xie cui  wrote:
>
> https://github.com/golang/go/blob/master/src/runtime/proc.go#L248-L251
> why these codes, it seem is unnecessary?

Those lines are there to help new ports.  If the `exit` function isn't
working right, it might return.  If the signal handler isn't working
right, `*x = 0` might not panic.  At least the loop will stop the
program from doing something unexpected.

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/CAOyqgcU%2BQcQ12oBLxT2hfqGApMGhyqS1kZeYeDbuRc_o1A-jwQ%40mail.gmail.com.

[go-nuts] what is these code line for?

[xie cui]

https://github.com/golang/go/blob/master/src/runtime/proc.go#L248-L251
why these codes, it seem is unnecessary?

-- 
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/a123b57c-df8b-4edf-9906-cf047799148cn%40googlegroups.com.

Re: [go-nuts] golang paths

[fgergo]

To clarify the go compiler toolchain is a trivial tree. Compared to
most other mainstream languages and compilers, it's not scattered to
different subtrees. I believe quite some effort went into that to stay
that way.
When using the go compiler toolchain some directories are used for
caching compiler artifacts. (You could easily delete all of these
files between compiling sessions, you'll still be able to compile
everything again. Though only a very space constrained environment
would require such a peculiar workflow.)

If you are a go programmer the subtrees you set explicitly are 100%
managed by the toolchain, there is no _need_ to ever look at them.
Please note, that if you set them explicitly and with that you
inadvertently mix and match different versions of go toolchain
binaries and cached artifacts you'll most probably run into issues you
don't want to have.

Sure the environment variables can be set differently, if you have
special requirements (maybe you don't have enough space on the same
device). Sorry I wasn't clear: I tried to ask for these special
requirements.
To rephrase and clarify my original question: besides "Paths in
symmetry with the environmental variables" why is it valuable to
rearrange the subtrees for your use case? What are your
requirements/issues you came up with a solution for?

To help with your original question, assuming your only goal is to
manage all subtrees exposed by environment variables "go env" shows at
least 3 more trees you might want to set (GOMODCACHE, GOTOOLDIR,
GOTMPDIR.)



On 12/9/20, Dumitru Ungureanu  wrote:
> Yes, there is no requirement to manage the envvars. I personally believe
> there is a requirement to know about them, though.
> I read the installation doc, I think there's a hang up on your part on this
>
> one.
> The default go tree is scattered different places, beside the obvious
> trivial tree you're mentioning.
> I'm arranging all the paths in a single place and I harmonize the paths
> with the envvars.
> Maybe you're missing the whole point I'm making in this blog post?
> https://mitflit.ro/blog/golang-paths-of-mitflit/
>
> On Tuesday, December 8, 2020 at 10:47:27 PM UTC+2 Gergely Födémesi wrote:
>
>> There is no requirement to manage these variables or to know about them,
>> even if you don't use the installer.
>>
>> I never use the installer and I've never needed to check on those
>> environment variables.
>>
>> (The installation documentation is short and complete, maybe you should
>> check it out again.)
>>
>> The installed go compiler is really just a trivial tree.
>>
>> On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu  wrote:
>>
>>> I don't use an installer. I set GOROOT/bin manually. And the rest
>>> follows. Easy to remember, nothing to forget.
>>>
>>> On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:
>>>
 On 12/8/20, Dumitru Ungureanu  wrote:
 > Paths in symmetry with the environmental
 > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin.
 GOCACHE is
 > go/cache, GOENV is go/env.
 > Bonus points: modules in go/modules.

 Why do you need to manage them explicitly? When do you need to look at
 GOROOT, GOBIN, GOCACHE or GOENV?

 (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
 After modules became the default, I've never set GOPATH either.)

 >
 > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi
 wrote:
 >
 >> On 12/7/20, Dumitru Ungureanu  wrote:
 >> ...
 >> > I'm currently using this directory tree for golang.
 >> ...
 >> What do you mean when you write "golang"?
 >>
 >> Why is https://golang.org/doc/install not good enough for the go
 >> compiler?
 >>
 >
 > --
 > 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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%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 

[go-nuts] Web Application Development

[AWS CloudExperts]

Hello Friends 
I am trying to build an WebApp, and this is my first one. do we need to use 
external router like gorilla/mux for routing ? 

-- 
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/d0a93df0-2d76-4e95-9c60-e96b32dc07e9n%40googlegroups.com.

Re: [go-nuts] Linter for checking 'MVS' of go module

[xiangdong...@gmail.com]

Thanks a lot, Shulhan.

On Wednesday, December 9, 2020 at 1:03:01 PM UTC+8 Shulhan wrote:

>
>
> On Wed, 9 Dec 2020, 11:42 xiangd...@gmail.com,  
> wrote:
>
>> Hi all,
>>
>> I'm wondering if any linter, or is it practical to make one, checks 
>> whether a go module's code change conforms the minimal version selection 
>> rules, say linter warns a v2 is needed if incompatible changes to APIs are 
>> introduced in the current change under linting?
>>
>
> There is an experiment on tooling called gorelease [1]. I believe its in 
> working-in-progress [2].
>
> [1] golang.org/x/exp/cmd/gorelease
> [2] https://github.com/golang/go/issues/26420
>
>

-- 
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/25a1ca42-c910-45f4-91d7-14f6866e6538n%40googlegroups.com.

Re: [go-nuts] golang paths

[Dumitru Ungureanu]

Yes, there is no requirement to manage the envvars. I personally believe 
there is a requirement to know about them, though.
I read the installation doc, I think there's a hang up on your part on this 
one.
The default go tree is scattered different places, beside the obvious 
trivial tree you're mentioning.
I'm arranging all the paths in a single place and I harmonize the paths 
with the envvars.
Maybe you're missing the whole point I'm making in this blog post? 
https://mitflit.ro/blog/golang-paths-of-mitflit/

On Tuesday, December 8, 2020 at 10:47:27 PM UTC+2 Gergely Födémesi wrote:

> There is no requirement to manage these variables or to know about them, 
> even if you don't use the installer.
>
> I never use the installer and I've never needed to check on those 
> environment variables.
>
> (The installation documentation is short and complete, maybe you should 
> check it out again.)
>
> The installed go compiler is really just a trivial tree.
>
> On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu  wrote:
>
>> I don't use an installer. I set GOROOT/bin manually. And the rest 
>> follows. Easy to remember, nothing to forget.
>>
>> On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:
>>
>>> On 12/8/20, Dumitru Ungureanu  wrote: 
>>> > Paths in symmetry with the environmental 
>>> > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. 
>>> GOCACHE is 
>>> > go/cache, GOENV is go/env. 
>>> > Bonus points: modules in go/modules. 
>>>
>>> Why do you need to manage them explicitly? When do you need to look at 
>>> GOROOT, GOBIN, GOCACHE or GOENV? 
>>>
>>> (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly. 
>>> After modules became the default, I've never set GOPATH either.) 
>>>
>>> > 
>>> > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi 
>>> wrote: 
>>> > 
>>> >> On 12/7/20, Dumitru Ungureanu  wrote: 
>>> >> ... 
>>> >> > I'm currently using this directory tree for golang. 
>>> >> ... 
>>> >> What do you mean when you write "golang"? 
>>> >> 
>>> >> Why is https://golang.org/doc/install not good enough for the go 
>>> >> compiler? 
>>> >> 
>>> > 
>>> > -- 
>>> > 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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%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/c0ed7490-800b-424e-834a-4f928be2a52en%40googlegroups.com.

Re: [go-nuts] Linter for checking 'MVS' of go module

[Mhd Shulhan]

On Wed, 9 Dec 2020, 11:42 xiangdong...@gmail.com, 
wrote:

> Hi all,
>
> I'm wondering if any linter, or is it practical to make one, checks
> whether a go module's code change conforms the minimal version selection
> rules, say linter warns a v2 is needed if incompatible changes to APIs are
> introduced in the current change under linting?
>

There is an experiment on tooling called gorelease [1]. I believe its in
working-in-progress [2].

[1] golang.org/x/exp/cmd/gorelease
[2] https://github.com/golang/go/issues/26420

-- 
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/CAMh9%2BYDnGGRAixmxiddNkpX1gbHPSB7NAwatDKP5qCg6z48aJA%40mail.gmail.com.

[go-nuts] Linter for checking 'MVS' of go module

[xiangdong...@gmail.com]

Hi all,

I'm wondering if any linter, or is it practical to make one, checks whether 
a go module's code change conforms the minimal version selection rules, say 
linter warns a v2 is needed if incompatible changes to APIs are introduced 
in the current change under linting?

-- 
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/a57bad3b-a4bb-4507-ada3-95df46606bf3n%40googlegroups.com.

[go-nuts] How to use packages and modules with git repositories on private servers

[Dean Schulze]

I couldn't get the information I needed when I posted this question on a 
couple of forums, so I've posted a detailed explanation of how to use 
packages and modules with git repositories on private servers 

.

I hope this helps anyone else who finds themselves in this situation.


-- 
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/a058c330-eb22-41a1-88ba-7208d815cac1n%40googlegroups.com.

[go-nuts] Let's trace memory allocated by goroutines

[Kostiantyn Masliuk]

I tried to play with go runtime to seamlessly add memory (bytes, objects, 
allocation calls) tracing into any arbitrary go code. Check it out in the 
repo https://github.com/1pkg/gotcha and in blog post 
https://1pkg.github.io/posts/lets_trace_goroutine_allocated_memory/. 

-- 
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/ad7c156e-f1a5-4a4a-8503-9d3160cb05d4n%40googlegroups.com.

Re: [go-nuts] golang paths

[fgergo]

There is no requirement to manage these variables or to know about them,
even if you don't use the installer.

I never use the installer and I've never needed to check on those
environment variables.

(The installation documentation is short and complete, maybe you should
check it out again.)

The installed go compiler is really just a trivial tree.

On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu  wrote:

> I don't use an installer. I set GOROOT/bin manually. And the rest follows.
> Easy to remember, nothing to forget.
>
> On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:
>
>> On 12/8/20, Dumitru Ungureanu  wrote:
>> > Paths in symmetry with the environmental
>> > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin.
>> GOCACHE is
>> > go/cache, GOENV is go/env.
>> > Bonus points: modules in go/modules.
>>
>> Why do you need to manage them explicitly? When do you need to look at
>> GOROOT, GOBIN, GOCACHE or GOENV?
>>
>> (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
>> After modules became the default, I've never set GOPATH either.)
>>
>> >
>> > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi
>> wrote:
>> >
>> >> On 12/7/20, Dumitru Ungureanu  wrote:
>> >> ...
>> >> > I'm currently using this directory tree for golang.
>> >> ...
>> >> What do you mean when you write "golang"?
>> >>
>> >> Why is https://golang.org/doc/install not good enough for the go
>> >> compiler?
>> >>
>> >
>> > --
>> > 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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%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/CA%2BctqroS22ktu%3DWMkMtFHmwjJ0dBk_fa_vmVQXGAXT1bQFFe9Q%40mail.gmail.com.

Re: [go-nuts] golang paths

[Dumitru Ungureanu]

I don't use an installer. I set GOROOT/bin manually. And the rest follows. 
Easy to remember, nothing to forget.

On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:

> On 12/8/20, Dumitru Ungureanu  wrote:
> > Paths in symmetry with the environmental
> > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. 
> GOCACHE is
> > go/cache, GOENV is go/env.
> > Bonus points: modules in go/modules.
>
> Why do you need to manage them explicitly? When do you need to look at
> GOROOT, GOBIN, GOCACHE or GOENV?
>
> (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
> After modules became the default, I've never set GOPATH either.)
>
> >
> > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi wrote:
> >
> >> On 12/7/20, Dumitru Ungureanu  wrote:
> >> ...
> >> > I'm currently using this directory tree for golang.
> >> ...
> >> What do you mean when you write "golang"?
> >>
> >> Why is https://golang.org/doc/install not good enough for the go
> >> compiler?
> >>
> >
> > --
> > 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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%40googlegroups.com.

Re: [go-nuts] golang paths

[fgergo]

On 12/8/20, Dumitru Ungureanu  wrote:
> Paths in symmetry with the environmental
> variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is
> go/cache, GOENV is go/env.
> Bonus points: modules in go/modules.

Why do you need to manage them explicitly? When do you need to look at
GOROOT, GOBIN, GOCACHE or GOENV?

(I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
After modules became the default, I've never set GOPATH either.)

>
> On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi wrote:
>
>> On 12/7/20, Dumitru Ungureanu  wrote:
>> ...
>> > I'm currently using this directory tree for golang.
>> ...
>> What do you mean when you write "golang"?
>>
>> Why is https://golang.org/doc/install not good enough for the go
>> compiler?
>>
>
> --
> 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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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/CA%2BctqrqbJVbJn%2Bg%2B2b4VPvOmMB8iBdtrjW7hQz%2B08gRE4cUtRg%40mail.gmail.com.

Re: [go-nuts] golang paths

[Dumitru Ungureanu]

Paths in symmetry with the environmental 
variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is 
go/cache, GOENV is go/env. 
Bonus points: modules in go/modules.

On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi wrote:

> On 12/7/20, Dumitru Ungureanu  wrote:
> ...
> > I'm currently using this directory tree for golang.
> ...
> What do you mean when you write "golang"?
>
> Why is https://golang.org/doc/install not good enough for the go compiler?
>

-- 
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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%40googlegroups.com.

[go-nuts] [Macos/Apple M1] some fork/exec … operation not permitted error

[Denis Cheremisov]

Hi! I installed Go via sources

$ go version
go version devel +9c91cab0da Tue Dec 8 01:46:45 2020 + darwin/arm64

got better performance than I had with my aging Core i5 4670k, etc, this 
was expectable, no surprises here.

But, there's an issue. When I call `go get`, `go install`, etc via 
`exec.Command` I get this error:

self check: update pedro-miguel: run go get 
gitlab.stageoffice.ru/UCS-TOOLS/pedro-miguel: fork/exec 
/usr/local/go/bin/go: operation not permitted

What may cause this? Launching other utilities works fine:

package main

import (
"os"
"os/exec"
)

func main() {
cmd := exec.Command("echo", "hello!")
cmd.Stdout = os.Stdout
if err := cmd.Run(); err != nil {
panic(err)
}
}

PS pedro-miguel named after a cascade of locks in Panama channel.

-- 
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/21d6e61d-0f01-4e4a-b44d-60a3b4878603n%40googlegroups.com.

Re: [go-nuts] golang paths

[fgergo]

On 12/7/20, Dumitru Ungureanu  wrote:
...
> I'm currently using this directory tree for golang.
...
What do you mean when you write "golang"?

Why is https://golang.org/doc/install not good enough for the go compiler?

-- 
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/CA%2Bctqrq67shAz8ao_XsfO6%2B1xkk76BGJh7vzGeiGXerXJaNoUQ%40mail.gmail.com.

Re: [go-nuts] gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

['Than McIntosh' via golang-nuts]

Hello,

Thanks for the note.

I am still not completely sure what the problem is.

You wrote:

 | I found
 |
 | // triple: i686-pc-linux-gnu
 | static const CpuAttrs attrs1[] = {
 | // first entry is default cpu
 | { "i686", "+cx8,+x87"},
 |
 | and (inside the hashmap)
 |
 | { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
 | , which is not what I have supported (for Intel Celeron M440).

What makes you say that this is not what you have supported? Are you
saying that the cpu clang calls "yonah" doesn't actually have one of these
features (ex: sse3)?

 | Clang reports "unsupported CPU features" on any non-provided one.
 | So that is one big problem.

Not sure what you mean here. Can you please post the complete clang
invocation and error message you are getting?


 | const TripleCpus triples[] = {
 | { "x86_64-unknown-linux-gnu", [0] },
 | { "i686-pc-linux-gnu", [0] },
 | { "aarch64-unknown-linux-gnu", [0] },
 | { "", nullptr } // sentinel
 | };
 | is not targeting to yonah, while llc is targeting it.
 | It is always some "default" CPU model and, in fact, your code never
provided extraction of the CPU model (from llc).
 |

When llc emits the line

  Host CPU: yonah

this does not mean that clang/llc will automatically target 'yonah' when
compiling, it just means that the program has detected the host CPU.

Generally speaking if you want clang to produce code targeted specifically
to the host CPU, you have to use -march=native or -mtune-native.

Thanks, Than

On Fri, Dec 4, 2020 at 8:08 PM Ivan Serdyuk 
wrote:

> Hello.
>
> This issue is related to
> https://go-review.googlesource.com/c/gollvm/+/274574
> .
>
> I think I have some misunderstanding on how you used to deal with CPU
> models, for LLVM.
>
> First things first - I had success with using
>
> #include "llvm/ADT/StringRef.h"
> #include "llvm/ADT/StringMap.h"
> #include "llvm/MC/SubtargetFeature.h"
> #include "llvm/Support/Host.h"
>
> using namespace llvm;
> SubtargetFeatures Features1;
>
> int main (int argc, char **argv)
> {
> sys::getHostCPUName();
> StringMap HostFeatures;
> if (sys::getHostCPUFeatures(HostFeatures))
> for (auto  : HostFeatures)
> Features1.AddFeature(F.first(), F.second);
>
> printf("test %s", Features1.getString().c_str());
> printf("\nsomething else\n");
> return 0;
> }
> . It gives me such a set of CPU features:
>
>
> +sse2,-tsxldtrk,-cx16,-sahf,-tbm,-avx512ifma,-sha,-gfni,-fma4,-vpclmulqdq,-prfchw,-bmi2,-cldemote,-fsgsbase,-ptwrite,-amx-tile,-avx512bf16,-popcnt,-aes,-avx512bitalg,-movdiri,-xsaves,-avx512er,-xsavec,-avx512vnni,-amx-bf16,-avx512vpopcntdq,-pconfig,-clwb,-avx512f,-clzero,-pku,+mmx,-lwp,-rdpid,-xop,-rdseed,-waitpkg,-movdir64b,-sse4a,-avx512bw,-clflushopt,-xsave,-avx512vbmi2,-64bit,-avx512vl,-serialize,-invpcid,-avx512cd,-avx,-vaes,+cx8,-fma,-rtm,-bmi,-enqcmd,-rdrnd,-mwaitx,-sse4.1,-sse4.2,-avx2,+fxsr,-wbnoinvd,+sse,-lzcnt,-pclmul,-prefetchwt1,-f16c,-ssse3,-sgx,-shstk,+cmov,-avx512vbmi,-amx-int8,-movbe,-avx512vp2intersect,-xsaveopt,-avx512dq,-adx,-avx512pf,+sse3
>
> $ llc --version
> provides
> Default target: i686-pc-linux-gnu
> Host CPU: yonah
> .
>
> I tried to update the capture-fcn-attributes.go file, like this:
>
> var supportedTriples []string = []string{
> "x86_64-unknown-linux-gnu",
> "i686-pc-linux-gnu",
> "aarch64-unknown-linux-gnu",
> }
> .
>
> When I tried the generator
>
> capture-fcn-attributes -o /tmp/cpu_feature_list
> it generated me a broad list.
> The header contained
>
> Ubuntu clang version 11.0.0-++20200721055954+cebd637c886-1exp1
> 20200721161335.13
> .
> I found
>
> // triple: i686-pc-linux-gnu
> static const CpuAttrs attrs1[] = {
> // first entry is default cpu
> { "i686", "+cx8,+x87"},
>
> and (inside the hashmap)
>
> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
> , which is not what I have supported (for Intel Celeron M440).
> Clang reports "unsupported CPU features" on any non-provided one.
> So that is one big problem.
> Next problem is that
>
> const TripleCpus triples[] = {
> { "x86_64-unknown-linux-gnu", [0] },
> { "i686-pc-linux-gnu", [0] },
> { "aarch64-unknown-linux-gnu", [0] },
> { "", nullptr } // sentinel
> };
> is not targeting to yonah, while llc is targeting it.
> It is always some "default" CPU model and, in fact, your code never
> provided extraction of the CPU model (from llc).
>
> To make my observation complete - I am providing what is generated via
>
> capture-fcn-attributes -cpu yonah
> :
>
> // triple: x86_64-unknown-linux-gnu
> static const CpuAttrs attrs0[] = {
> // first entry is default cpu
> { "x86-64", "+cx8,+fxsr,+mmx,+sse,+sse2,+x87"},
> { "", "" } // sentinel
> };
>
> // triple: i686-pc-linux-gnu
> static const CpuAttrs attrs1[] = {
> // first entry is default cpu
> { "i686", "+cx8,+x87"},
> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
> { "", "" } // sentinel
> };
>
> // triple: aarch64-unknown-linux-gnu
> static const CpuAttrs attrs2[] = {
> // first entry is default cpu
> { "generic", "+neon"},
> { "", "" } // sentinel
> };
>
> 

Re: [go-nuts] Code coverage in error cases when compared to other languages

['Axel Wagner' via golang-nuts]

Hi,

On Tue, Dec 8, 2020 at 1:19 AM 'Charles Hathaway' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi all,
>
> I'm looking for a good study/quantitative measure of how well-written Go
> code looks compared to other languages, such as Java, when it comes to test
> coverage. In particular, how handling errors may reduce the percentage of
> code covered by tests in Go relative to other languages.
>
> For example, in this code snippet:
>
> func Foo() error {
>   // do some stuff that actually adds value
>   if err := somelib.Bar(); err != nil {
> // triggering the error case in Bar is hard, i.e. requires simulating
> network troubles
> // or causing a file write to fail, but we don't do anything with
> result besides
> // return it. Testing it by adding an interface or wrapper isn't worth
> the effort
> // and the only impact is really reported test coverage.
> return err
>   }
>   // do more stuff
>   return nil
> }
>
> In Java, you would just add 'throws SomeException' to your method
> declaration. The effect is that we have one line in the Go code which is
> not easily covered by a test, whereas Java does not report that untested
> case because the return path is not visible in the code.
>
> The result is that otherwise equivalent code, we will report different
> code coverage values, with Go being slightly lower. I'm just looking for
> something written on that topic that can give us a notion of how much of a
> difference we might expect.
>

I don't think there is as much of a difference as you think.

You seem to be considering the `throws SomeException` to not impact
coverage - but that's not true. It's code you add for error handling and
that code is not hit, unless your test actually triggers that exception -
just as the code you add for error handling in Go isn't hit. So if you
don't count `throws SomeException` as code to be covered in java, you also
shouldn't count `if err i= nil { return err }` as code to be covered in Go.
So the semantic difference really comes down to a single `throws
SomeException` line being able to cover *multiple* branches with the same
exception type. It's a difference, but it should be small in practice.

But really, I think what this comes down to is that line-coverage - or,
what's actually measured and then projected down to lines,
"instruction-coverage" - just isn't a super meaningful measure in this
context. More interesting would be branch- or path-coverage - and that
would be exactly the same in both cases. Every point where a
`SomeException` *could* be thrown would branch off a separate path, just as
every `if err != nil` in your Go code. And in both languages they are
covered iff you write a test-case that triggers that error condition.

So… I'm sorry that I can't really provide a quantitative, meaningful answer
to your question. I don't know what relative difference there would be in
line-coverage for Go vs. Java in a case like that. But your question sounds
as if you would like to use line-coverage as a metric (maybe even in CI
*shudder*) to determine whether you tested enough. And the point I'm trying
to make is that I think that goal is fallacious :) If you need a
coverage-metric, use branch- or path-coverage, which won't have that
difference. But really, coverage reports are IMO most useful if inspected
manually, to choose where to invest further tests. As a metric, it just is
too unreliable.

https://en.wikipedia.org/wiki/Goodhart%27s_law


>
> Thanks,
>   Charles
>
> --
> 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/6b48ed73-1963-482e-aff0-b91f3aa6a2aen%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/CAEkBMfHdUq_N07ccwcHyf_aHyPfoFGcsHYt4JvdA_TobzoFVhQ%40mail.gmail.com.