Re: [go-nuts] Can't range over iter.Seq in text/template (go 1.22/dev)

On Sat, Jul 6, 2024 at 2:21 PM Rory Campbell-Lange wrote: > > I don't seem to be able to range over an iter.Seq in a template. ... > ...is an iter.Seq or iter.Seq2 not intended to be added there? Yes, this is https://go.dev/issue/66107. Ian -- You received this message because you are subsc

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

The way I read the section about programs with memory races (https://go.dev/ref/mem#restrictions), that program should always print 1. "A read r of a memory location x holding a value that is not larger than a machine word must observe some write w such that r does not happen before w and there is

[go-nuts] Can't range over iter.Seq in text/template (go 1.22/dev)

I don't seem to be able to range over an iter.Seq in a template. error: executing "test" at <.>: range can't iterate over 0x5103c0 resulter := func(yield func(int) bool) { for _, v := range []int{1, 2, 3} { if !yield(v) {

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

On Sat, Jul 6, 2024 at 7:34 AM 'qiu laidongfeng2' via golang-nuts wrote: > > I know not to write code with data races? > The problem is that I find that this code always outputs 1 on the amd64 > machine, > I am not sure what effect this data competition has on the execution result, > whether it i

Re: [go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows

go compiler is not signed. It might be interesting to see if signing the executable has an impact on the antivirus scan. Le mercredi 20 mars 2024 à 20:23:46 UTC+1, Larry Clapp a écrit : > I found this webpage from MS which talks about configuring Windows > Defender. > > > https://support.micro

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

I corrected myself. On Jul 6, 2024, at 10:34 AM, peterGo wrote:On Saturday, July 6, 2024 at 11:21:46 AM UTC-4 Robert Engels wrote:That is not a data race. The wait group is a synchronization barrier. ==WARNING: DATA RACEWrite at 0x00c14158 by goroutine 8:  main.main.func1()   

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

On Saturday, July 6, 2024 at 11:21:46 AM UTC-4 Robert Engels wrote: That is not a data race. The wait group is a synchronization barrier. == WARNING: DATA RACE Write at 0x00c14158 by goroutine 8: main.main.func1() /home/peter/racer.go:12 +0x84 Previous write at 0x00

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

On Sat, Jul 6, 2024 at 5:21 PM Robert Engels wrote: > That is not a data race. The wait group is a synchronization barrier. Multiple concurrent, uncoordinated writers are a perfect data race. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

Sorry and the outer loop is the only reader. It probably reports it as a race though since there are multiple writers - but they all write the same value. Technically still a data race depending on if the word splits when writing. On Jul 6, 2024, at 10:20 AM, Robert Engels wrote:That is not a dat

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

That is not a data race. The wait group is a synchronization barrier. On Jul 6, 2024, at 9:34 AM, 'qiu laidongfeng2' via golang-nuts wrote:I know not to write code with data races?The problem is that I find that this code always outputs 1 on the amd64 machine,I am not sure what effect this data c

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

I know not to write code with data races? The problem is that I find that this code always outputs 1 on the amd64 machine, I am not sure what effect this data competition has on the execution result, whether it is an inevitable result of the amd64 machine to always output 1 or I am lucky to encou

Re: [go-nuts] errors.Join to return a single error if possible

On Sat, Jul 6, 2024 at 7:04 AM Andrei Rusakov wrote: > > So, what do you think it makes sense for the function to return a wrapped > error even if it contains only one error? Wouldn't it be more rational in > such cases for Join to return that single error? Perhaps that would have made sense, b

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

On Sat, Jul 6, 2024 at 7:04 AM 'qiu laidongfeng2' via golang-nuts wrote: > > Does data race in this program affect execution results? > In amd64, it always output1. If you want to write code like this, use the sync/atomic package. Don't write code with data races. Ian -- You received this mess

[go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

Does data race in this program affect execution results? In amd64, it always output1. ```go package main import "sync" func main() { i := 0 var wg sync.WaitGroup for range 100 { wg.Add(1) go func() { defer wg.Done() i = 1 }() } wg.Wait() println(i) } ``` -- You received this message becaus

[go-nuts] errors.Join to return a single error if possible

Hey gophers, I would like to know your opinion on the following topic. In my experience, the most popular case for errors.Join is to handle deferred potential errors such as closing os.File, sql.Rows or http.Response.Body. Might be a bit of a contrived example,