Is the Category "Games" gaining attention in the go community?
Are the Developers writing for production level?
Do we have an examples?
[image: image.png]
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop rec
I've expanded the proposal to address feedback from the Go team. It now
offers a more special purpose construct than the generic if-variant 'on'.
See the Critiques section in
https://github.com/golang/go/issues/32611
On Tue, Jul 2, 2019, 12:57 PM Liam wrote:
> This proposal has attracted modes
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
> *runtime.con
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 c
- 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 va
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 etc
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 stack
> 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 han
Sorry but how do you know we are a minority? I dislike the try proposal for
all the reasons already mentioned by others.
I did fill out the survey but I do not remember there being an option to
say this simple thing.
While I dislike the verbose error handling it's many times better than
intro
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 (*s
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 (*state).assign, (*state).storeType in
gc/ssa.go and injected equi
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() {
>
The race detector detects races, like smoke detectors detect smoke and
water detectors detect water. Are you asking if the race detector is
broken? If its judgement is just a guess? Not a guess. A scientific
observation. Your code is not safe.
On Fri, Jul 5, 2019 at 7:53 AM Cholerae Hu wrote:
>
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() {
fo
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(&n)
}
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
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
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:
https://groups.google.com/forum/?from
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
simultane
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 to
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 Prycze
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 have
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 a
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:
*
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 s
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 co
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()
/Users/purewh
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 fro
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(&n)
}
}()
go func() {
for {
m.RLock()
atomic.AddInt32(&n, 1)
m.RUnlock()
}
}()
go func() {
for {
m.Lock()
n = 0
m.U
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 main
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.
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 could
31 matches
Mail list logo