Re: [go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread 'Axel Wagner' via golang-nuts
Okay, *now* I get what you are trying to say. I agree that it seems inefficient to call it more than once, which is why the code tries to optimize for that. I don't know why that optimization doesn't trigger in your case - you might want to try and investigate that. There might be a good reason why

Re: [go-nuts] Go on Windows 10 ARM

2021-06-30 Thread Amit Saha
On Thu, Jul 1, 2021 at 12:52 PM Kurtis Rader wrote: > > On Wed, Jun 30, 2021 at 7:14 PM Amit Saha wrote: >> >> Hi all - I am curious if anybody has installed the Go toolchain on >> Windows 10 ARM 64? > > > You might need to clarify your question. Go is officially supported onWindows > 10 ARM64 a

Re: [go-nuts] Go on Windows 10 ARM

2021-06-30 Thread Kurtis Rader
On Wed, Jun 30, 2021 at 7:14 PM Amit Saha wrote: > Hi all - I am curious if anybody has installed the Go toolchain on > Windows 10 ARM 64? > You might need to clarify your question. Go is officially supported onWindows 10 ARM64 and you can see the current build status at https://build.golang.org

[go-nuts] Go on Windows 10 ARM

2021-06-30 Thread Amit Saha
Hi all - I am curious if anybody has installed the Go toolchain on Windows 10 ARM 64? Thanks, Amit. -- 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+u

Re: [go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread tapi...@gmail.com
On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com wrote: > On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com > wrote: > >> >> >> On Wednesday, June 30, 2021 at 11:56:45 AM UTC-4 Brian Candler wrote: >> >>> So I think what you're asking is, "under what scenario does the

Re: [go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread 'Axel Wagner' via golang-nuts
On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com wrote: > > > On Wednesday, June 30, 2021 at 11:56:45 AM UTC-4 Brian Candler wrote: > >> So I think what you're asking is, "under what scenario does the code in >> L1066-1069 >>

[go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread tapi...@gmail.com
On Wednesday, June 30, 2021 at 11:56:45 AM UTC-4 Brian Candler wrote: > So I think what you're asking is, "under what scenario does the code in > L1066-1069 > > > get run?" - is that

Re: [go-nuts] how to purge invalid tags from GOPROXY?

2021-06-30 Thread 'Dan Kortschak' via golang-nuts
On Wed, 2021-06-30 at 15:45 -0700, 'Jay Conrod' via golang-nuts wrote: > Hi Sebastien, once a version is in proxy.golang.org, it usually can't > be removed. This is important to ensure that builds continue working > when a repository disappears upstream. > > You may want to publish a new version wi

Re: [go-nuts] how to purge invalid tags from GOPROXY?

2021-06-30 Thread 'Jay Conrod' via golang-nuts
Hi Sebastien, once a version is in proxy.golang.org, it usually can't be removed. This is important to ensure that builds continue working when a repository disappears upstream. You may want to publish a new version with a retract directive in go.mod, marking the earlier versions as invalid. In Go

Re: [go-nuts] PtrGuard: a new package to break the Cgo pointer passing rules

2021-06-30 Thread Ian Lance Taylor
On Wed, Jun 30, 2021 at 9:18 AM Sven Anderson wrote: > > because we needed to use iovec APIs like the readv/writev system calls and > wanted to avoid an additional memory copy, we needed to store Go pointers in > C memory, or pass a Go pointer to memory that contains other Go pointers. In > oth

[go-nuts] PtrGuard: a new package to break the Cgo pointer passing rules

2021-06-30 Thread Sven Anderson
Dear nuts, because we needed to use iovec APIs like the readv/writev system calls and wanted to avoid an additional memory copy, we needed to store Go pointers in C memory, or pass a Go pointer to memory that contains other Go pointers. In other words we needed to break the Cgo pointer passing rul

[go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread Brian Candler
So I think what you're asking is, "under what scenario does the code in L1066-1069 get run?" - is that right? On Wednesday, 30 June 2021 at 14:21:21 UTC+1 tapi...@gmail.com wrote: > S

[go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread tapi...@gmail.com
Sorry, I post the wrong anchor. It is line 1068: https://github.com/golang/go/blob/d19a53338fa6272b4fe9c39d66812a79e1464cd2/src/runtime/stack.go#L1068 On Wednesday, June 30, 2021 at 5:08:30 AM UTC-4 Brian Candler wrote: > On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wrote: > >>

Re: [go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread 'Axel Wagner' via golang-nuts
and/or link to a specific commit (press y in the github UI to get redirected to the specific commit you are looking at). On Wed, Jun 30, 2021 at 11:08 AM Brian Candler wrote: > On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wrote: > >> >> It looks this line >> https://github.com/

[go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread Brian Candler
On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wrote: > > It looks this line > https://github.com/golang/go/blob/master/src/runtime/stack.go#L1078 never > gets executed. > > Can you quote the line you're referring to? Line numbers can shift up and down as commits are made to th

[go-nuts] Re: Stack growing is inefficient

2021-06-30 Thread tapi...@gmail.com
It looks all stacks start from 2048 bytes, even if gc has estimated the start function of a goroutine will use much larger stack. Why not initialize the stack with a large size as needed? For example: package main const N = 300 * 1024 * 1024 var v byte = 123 func f(c chan struct{}) { var s

[go-nuts] Stack growing is inefficient

2021-06-30 Thread tapi...@gmail.com
It looks this line https://github.com/golang/go/blob/master/src/runtime/stack.go#L1078 never gets executed. An example: package main const N = 512 * 1024 * 1024 // 500M var v byte = 123 func main() { var s = []byte{N: 0} for i := range s { s[i] = v } println(s[v]) } I added a p