Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

On Fri, Jul 5, 2019 at 9:16 PM Mohit Verma wrote: > Thanks Keith. > > Yes, the function call takes a variadic interface argument, so it would > cause the variables to escape if it existed before. To take care of this, I > allocate space for the interface during buildSSA & then call >

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

Thanks Keith. Yes, the function call takes a variadic interface argument, so it would cause the variables to escape if it existed before. To take care of this, I allocate space for the interface during buildSSA & then call *runtime.convT2E** functions. *1. How do I turn off escape analysis with

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

- Other: [ ] On Fri, Jul 5, 2019 at 5:12 PM Jakub Labath wrote: > > But it's not a binary question. > > If you ask me > > Would like go to have Maybe/Option type instead of val, err - then I can say > yes. > Would you like to have something such as Rust's Result instead of

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

But it's not a binary question. If you ask me Would like go to have Maybe/Option type instead of val, err - then I can say yes. Would you like to have something such as Rust's Result instead of val, err - then I can say yes (even though I understand this may not be possible due to generics

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

If you’ve suffered through bad code due to exceptions, you would just be trading one ill for another. Exception handling when properly done is beautiful. Yes, a lot of people get it wrong, but they would probably get a lot of other things wrong as well. At least with exceptions, you have a

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

> So I was quiet on the topic then - I am not now. i guess you missed the point where I advocated for a new survey, well advertised, where all the people who are fervent Go programmers but somehow neglected to fill out the Go surveys for three years running can cast their voice. "does go error

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

On Fri, Jul 5, 2019 at 2:05 PM Mohit Verma wrote: > Thanks Keith, Ian. > > Specifically, I am trying to catch all the memory stores/moves during the > build SSA phase, and instead call a function that can do things like record > the old/new values in a journal. > So I changed the methods like

[go-nuts] Re: Does this code safe?

In theory, the non-atomic store could tear with respect to the atomic load. On Friday, 5 July 2019 10:53:05 UTC-4, Cholerae Hu wrote: > > package main > > import ( > "sync/atomic" > "sync" > ) > > func main() { > var n int32 > var m sync.Mutex > var wg sync.WaitGroup > wg.Add(2) > go func() { >

Re: [go-nuts] Does this code safe?

Use the same method for both Load and Set, also your example will never complete as your for loops will run forever. On 05/07/2019 15:53, Cholerae Hu wrote: | package main import ( "sync/atomic" "sync" ) func main() { var n int32 var m sync.Mutex var wg sync.WaitGroup wg.Add(2) go func() {

[go-nuts] Does this code safe?

package main import ( "sync/atomic" "sync" ) func main() { var n int32 var m sync.Mutex var wg sync.WaitGroup wg.Add(2) go func() { for { atomic.LoadInt32() } wg.Done() }() go func() { for { m.Lock() n = 1 m.Unlock() } wg.Done() }() wg.Wait() } Does it safe to use atomic read an int and write

[go-nuts] Re: General thoughts about new proposals

Oh gosh, i'd rather call it a disaster :D You written something bigger in C++ or Java? If yes you really want to go back to all this mess, where you're not even sure what the "=" or ">" operator is doing? IMO this is totally unfit for code people are writing nowdays. You can no longer afford a

[go-nuts] Re: readonly []byte required

This came up about 5 or so years ago. Brad proposed it, it was deliberated for a while, and Russ articulated why it was no doable at the time. There may be a chance to resurrect it, but it will be good to see what was written before. See Prior discussion:

Re: [go-nuts] Re: Does the code have any concurrent problem?

Interesting point because output would be random but still n could be accessed by only one thread at a time, after the change ... so technically it's different kind of a race (race due to the order in which operations are scheduled because they can not be safely serialized, not due to

Re: [go-nuts] Does the code have any concurrent problem?

Besides what others already suggested, you'll find the reason in the Go memory model specification: https://golang.org/ref/mem This part is relevant here: "If the effects of a goroutine must be observed by another goroutine, use a synchronization mechanism such as a lock or channel communication

Re: [go-nuts] Re: readonly []byte required

In the case of high performance IO, where probably most strings are converted, you use a ByteBuffer to avoid many small kernel calls anyway, and these can copy the string data (WriteString) to the buffer directly without an intermediate allocation. > On Jul 5, 2019, at 7:00 AM, Slawomir

[go-nuts] Re: readonly []byte required

Not sure if that's a good idea. Strings are immutable so you can pass string to function by reference, in thread safe manner. So if you pass same string to 2 threads and one of them modify it - you'll really have allocate+copy+modify so you're never touching the original thing so you can't

Re: [go-nuts] Re: Does the code have any concurrent problem?

Even if you do this, the code still has a “race” as there is no way to logically reason as to the eventual outcome or purpose. You can take out all of the concurrent controls and you’ll have the same program/result (although the race detector will report an issue) - no claims can be made about

[go-nuts] Re: readonly []byte required

I think it could be a useful optimization. There are at least in two different (and much more general) proposals that, if accepted, would include readonly slices as a special case. The the compiler could recognize that a readonly slice created from a string can reuse string's underlying data:

[go-nuts] Re: General thoughts about new proposals

is there a hope for generics like this? gen[A]ToStringer gen[string].ToString() Noong Huwebes, Hulyo 4, 2019 ng 6:02:45 PM UTC+8, si Slawomir Pryczek ay sumulat: > > Following this group for couple years and I think that from some time the > community is in some kind of crisis, because it

[go-nuts] Re: Does the code have any concurrent problem?

Sure it has a race issue, because in this example you're mixing atomic operations with mutex, when you want your code to be thread safe you need to do access to the variable using mutex or using atomic in all cases. Because both ways work differently and are not "interchargable" so you can't

Re: [go-nuts] Does the code have any concurrent problem?

Thanks for your reply. I've tried before and it reported race. But I don't understand why this code has race, and what's the possible bug? Here's the output: $ go run -race main.go == WARNING: DATA RACE Write at 0x00c96000 by goroutine 7: main.main.func3()

Re: [go-nuts] Does the code have any concurrent problem?

Have you tried building with the -race flag? go build - race This should help you figure out any data race conditions that may occur. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

[go-nuts] Re: Does the code have any concurrent problem?

Sorry for miss some code, the code should be like this: package main import ( "sync" "sync/atomic" ) func main() { var n int32 var m sync.RWMutex go func() { for { atomic.LoadInt32() } }() go func() { for { m.RLock() atomic.AddInt32(, 1) m.RUnlock() } }() go func() { for { m.Lock() n = 0

[go-nuts] Does the code have any concurrent problem?

Hi, I wrote some code like below these days, and my colleagues and me are not sure if the code has any concurrent problem. Can someone help to figure out if the code has any race problem? Thanks very much! Code: > package main > import ( "sync" "sync/atomic" ) > func

Re: [go-nuts] Re: gofmt: one line if statement

On Fri, Jul 5, 2019 at 11:55 AM Malcolm Gorman wrote: > If these single-statement if statements could be: > > if err != nil { return , err } > > the visual appearance of code would become far more compact and easier to > read, and we wouldn't need any special new syntax. I prefer the opposite.

[go-nuts] Re: gofmt: one line if statement

Excellent idea! Occasionally an error message needs to be created or elaborated, requiring a multi-line if statement body. But the common situation is where the error is simply returned to the calling function using a single-statement if statement. If these single-statement if statements

[go-nuts] GOPROXY="https://proxy.golang.org,direct" behaviour

Hi all, I am a little bit confused at what is the expected behaviour for GOPROXY="https://proxy.golang.org,direct;. On my system when using Go 1.13 beta 1, go env reports that GOPROXY="https://proxy.golang.org,direct;. When `go build .` tries to access a package hosted on github.com,

Re: [go-nuts] Announcing gg ("gigi") your new friend

On Thu, 4 Jul 2019 09:10:09 -0700 Michael Jones wrote: Great work, thank you :) > Recently I shared my Survey > program, saying that it was a sidestep from what I was working on but > interesting and hopefully useful to others. Here is the real thing,

[go-nuts] try? how about try {} curious if anyone thinks this might be better.

Problems with try: 1 - hiding the return 2 - error decoration The motivation behind this "issue" seems somewhat suspect. I get the consensus the idea that people think the current state of the art `if err != nil { .. }` its verbose. I'd argue that isn't the issue with it. If we want