Re: [go-nuts] Should "go install module@version" interact with ~/.local/bin?

[Randall O'Reilly]

It would be great if there were a universal standard location in the user's 
$HOME directory that is already on the PATH, because that always trips up new 
users when starting to use a CLI.

But that does not appear to be the case on the mac -- this seems to be what a 
default user gets, at least on my system: 
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Apple/usr/bin

I didn't even know about ~/.local until this email, and I was a longtime linux 
user prior to mostly using a mac.  Windows is always different.  

Anyway, given those issues, probably better to stick with the current default 
like you say..

- Randy

> On Jul 13, 2021, at 2:43 PM, Tyler Compton  wrote:
> 
> With recent changes to go install, we now have an official, module-aware way 
> to locally build and install Go tools. This is a great step, but I wonder if 
> some renewed consideration should be made to where the tools are installed.
> 
> As I'm sure you all know, go install puts binaries in $GOPATH/bin or 
> $HOME/go/bin by default. I think that made more sense in a world where the 
> GOPATH was our primary means of Go development. However, with modules, I 
> would argue that GOPATH is becoming less and less a part of the Go 
> development experience. If go install placed binaries in ~/.local/bin by 
> default instead, it would be more in line with the way other local 
> installation tools work and wouldn't require users to update their $PATH at 
> all on some distributions. If we want to keep $GOPATH/bin, perhaps the tool 
> could put a symlink in ~/.local/bin instead.
> 
> I can think of a few reasons why this might not be a good idea:
> 
> What about other platforms, like Windows? I don't know if there's a place in 
> all operating systems where user-installed binaries are supposed to be 
> installed. It could be argued that the current approach is a better 
> cross-platform default.
> 
> Can't this already be achieved by setting $GOBIN? Sure. I still think there's 
> value in having the best possible default, but having $GOBIN as an option 
> makes this discussion less important.
> 
> Is this worth the confusion that changes like this inevitably create? Maybe 
> not. For those of us that use Go daily and already have $GOPATH/bin in our 
> $PATH, this may seem especially frivlious. I think a change like this 
> benefits those who don't develop in Go the most, and non-Go developers will 
> (probably) always outnumber Go developers :)
> 
> I'm curious to hear everyone's thoughts.
> 
> -- 
> 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/CAA%3DXfu0c4x5nW80jVehUs666iv%2B_9xp0frEudZH1u5zBHEm%2BjQ%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/E87DA07A-8E0F-42D1-AF97-5C26F6E55F60%40gmail.com.

[go-nuts] Re: various go-assembler code is generated

['Keith Randall' via golang-nuts]

The Go compiler is not very good at eliminating redundant copies of large 
temporaries (structs with many fields, or arrays with length>1).

On Tuesday, July 13, 2021 at 2:51:32 PM UTC-7 buro...@gmail.com wrote:

> https://go.godbolt.org/z/G8K79K48G - small
> https://go.godbolt.org/z/Yv853E6P3 - long
>
> >go version go1.16 windows/amd64
>
> On the local machine i am executing  go tool compile -S main.go > main.s
>
> in the second case, I see that the compiler sees here a local variable 
> entering the code. Why is this happening ? why is such a different code 
> generated?
>

-- 
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/8e2c63e4-6d90-433c-bf36-b8c84dec5fc9n%40googlegroups.com.

[go-nuts] various go-assembler code is generated

[Паша Бурак]

https://go.godbolt.org/z/G8K79K48G - small
https://go.godbolt.org/z/Yv853E6P3 - long

>go version go1.16 windows/amd64

On the local machine i am executing  go tool compile -S main.go > main.s

in the second case, I see that the compiler sees here a local variable 
entering the code. Why is this happening ? why is such a different code 
generated?

-- 
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/bd6113cd-43f4-4def-8f5a-849273d0f92en%40googlegroups.com.

[go-nuts] Should "go install module@version" interact with ~/.local/bin?

[Tyler Compton]

With recent changes to go install, we now have an official, module-aware
way to locally build and install Go tools. This is a great step, but
I wonder if some renewed consideration should be made to where the tools
are installed.

As I'm sure you all know, go install puts binaries in $GOPATH/bin or
$HOME/go/bin by default. I think that made more sense in a world where the
GOPATH was our primary means of Go development. However, with modules, I
would argue that GOPATH is becoming less and less a part of the Go
development experience. If go install placed binaries in ~/.local/bin by
default instead, it would be more in line with the way other local
installation tools work and wouldn't require users to update their $PATH at
all on some distributions. If we want to keep $GOPATH/bin, perhaps the tool
could put a symlink in ~/.local/bin instead.

I can think of a few reasons why this might not be a good idea:

What about other platforms, like Windows? I don't know if there's a place
in all operating systems where user-installed binaries are supposed to be
installed. It could be argued that the current approach is a better
cross-platform default.

Can't this already be achieved by setting $GOBIN? Sure. I still think
there's value in having the best possible default, but having $GOBIN as an
option makes this discussion less important.

Is this worth the confusion that changes like this inevitably create? Maybe
not. For those of us that use Go daily and already have $GOPATH/bin in our
$PATH, this may seem especially frivlious. I think a change like this
benefits those who don't develop in Go the most, and non-Go developers will
(probably) always outnumber Go developers :)

I'm curious to hear everyone's thoughts.

-- 
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/CAA%3DXfu0c4x5nW80jVehUs666iv%2B_9xp0frEudZH1u5zBHEm%2BjQ%40mail.gmail.com.

Re: [go-nuts] How are interfaces marked by the GC?

[Ian Lance Taylor]

On Tue, Jul 13, 2021 at 1:29 PM Kristoffer Semelka  wrote:
>
> I noticed that word sized datatypes can be stored directly in the data field 
> of an iface/eface, but I'm confused on how marking works with these kinds of 
> inline cases. I checked the mark routines in the runtime/gcmark.go and 
> couldn't find special casing for interfaces. How does the runtime know when 
> not to follow an interface's data pointer? Does it just scan that word 
> conservatively? How does the func's pointer map fit into this?

In the current implementations the data field of an interface value is
always a pointer.  It was once true that small scalar values were
stored directly in interface values, but that is no longer true today.

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/CAOyqgcVwXV8TC9HCw7BqYxhiM%2B%2BuzN1MpEtewC3B-17TkjW57g%40mail.gmail.com.

[go-nuts] How are interfaces marked by the GC?

[Kristoffer Semelka]

I noticed that word sized datatypes can be stored directly in the data
field of an iface/eface, but I'm confused on how marking works with these
kinds of inline cases. I checked the mark routines in the runtime/gcmark.go
and couldn't find special casing for interfaces. How does the runtime know
when not to follow an interface's data pointer? Does it just scan that word
conservatively? How does the func's pointer map fit into this?

Kind regards, Kris

-- 
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/CAEF0weje407%2BsKjjcV3bgmRz4QZGZgzs8yJMriGANui%3DznhnYQ%40mail.gmail.com.

[go-nuts] Go 1.17 Release Candidate 1 is released

[Cherry Mui]

Hello gophers,

We have just released go1.17rc1, a release candidate version of Go 1.17.
It is cut from release-branch.go1.17 at the revision tagged go1.17rc1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.17rc1
is by using the go command:
$ go get golang.org/dl/go1.17rc1
$ go1.17rc1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.17rc1

To find out what has changed in Go 1.17, read the draft release notes:
https://tip.golang.org/doc/go1.17

Cheers,
Cherry and Dmitri for the Go team

-- 
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/CAOW6Qtj2nGnULqsmhD%3D0i4OEbVmZEfJs6VLdD_vNSiibQaFfSg%40mail.gmail.com.

Re: [go-nuts] Re: heap space not released by the end of program ?

[Robert Engels]

I knew I had seen something on that. :)

I guess Go doesn’t need a compacting collector if it can allocate most objects 
on the stack to avoid fragmentation. 

> On Jul 13, 2021, at 4:34 AM, Brian Candler  wrote:
> 
> 
>> On Tuesday, 13 July 2021 at 03:52:24 UTC+1 bai...@gmail.com wrote:
>> Hi, I wrote a test program, which tests when GC starts to return heap space 
>> to OS.
>> Here's the code: https://paste.ubuntu.com/p/jxHqDnsM2T/
>> 
>> But I've waited for a long time and haven't seen the RSS memory reduced. I 
>> can't figured out why, Any help ? (go version 1.14.3)
> 
> There was a change in go 1.16 which could affect this, so I suggest you try 
> the latest go.
> 
> Previously, go just marked the pages as "can be freed when required" - but 
> the OS would not actually free them until under memory pressure. Now it tells 
> the OS to free them immediately.
> -- 
> 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/7c99fe43-376d-4f94-9070-17dafbe6baffn%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/508DA5F7-E15C-4E95-B957-16B469AB0AD6%40ix.netcom.com.

[go-nuts] Re: heap space not released by the end of program ?

[Brian Candler]

On Tuesday, 13 July 2021 at 03:52:24 UTC+1 bai...@gmail.com wrote:

> Hi, I wrote a test program, which tests when GC starts to return heap 
> space to OS.
> Here's the code: https://paste.ubuntu.com/p/jxHqDnsM2T/
>
> But I've waited for a long time and haven't seen the RSS memory reduced. I 
> can't figured out why, Any help ? (go version 1.14.3)
>

There was a change in go 1.16  which 
could affect this, so I suggest you try the latest go.

Previously, go just marked the pages as "can be freed when required" - but 
the OS would not actually free them until under memory pressure. Now it 
tells the OS to free them immediately.

-- 
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/7c99fe43-376d-4f94-9070-17dafbe6baffn%40googlegroups.com.