[go-nuts] Re: Any way to print a 'struct g' within delve/gdb

I just tried with latest delve, and 'p runtime.m0.curg' is enough: (dlv) p runtime.m0.curg *runtime.g nil (dlv) break main.main (dlv) continue [...] (dlv) p runtime.m0.curg *runtime.g { stack: runtime.stack {lo: 824635269120, hi: 824635285504}, stackguard0: 82463527, stackguard1:

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

* Robert Engels [191112 12:59]: > The bug I referenced discusses the current problem with the MM > specification. You are making assumptions that are not supported by > the current MM, but as the bug points out, that is the current > behavior. I can see that point of view, and I don't think it

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

[You keep sending replies that are not connected to the message to which you are replying. RFC 822 (and subsequent RFCs) defines the In-Reply-To header, which has been in use for more than 30 years. Most MUAs will add this automatically. Failure to add the header really messes up MUAs that

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

[I almost missed this post because you did not reply to the thread.] * Robert Engels [191108 11:41]: > See https://github.com/golang/go/issues/10958 for using atomics in > tight/busy-wait loops. This doesn't have anything to do with atomics. Atomic operations are just one of many, many things

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

There are two different viewpoints you can take. Either the Go Memory Model must stand alone, and any concurrency claims made by the language and standard library must be based on the limited set of operations defined in the GMM, or the GMM provides the definitions and provides a substantial, but

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

The bug I referenced discusses the current problem with the MM specification. You are making assumptions that are not supported by the current MM, but as the bug points out, that is the current behavior. Btw, there is no such thing as "concurrent access". There is a concept of "sharing" and

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

Sorry, at work so I need to use the 'web mail' interface and it doesn't appear to be including them when I reply. -Original Message- >From: Marvin Renich >Sent: Nov 12, 2019 12:41 PM >To: golang-nuts >Subject: Re: [go-nuts] What is the correct way to access/modify slice elements

[go-nuts] Re: Any way to print a 'struct g' within delve/gdb

Thank your Derek, that's really helpful. On Tuesday, November 12, 2019 at 10:52:58 PM UTC+8, Derek Parker wrote: > > If you look at the output of your first command you see the result > `(**runtime.g)()`, however you're trying to cast to > `(runtime.g*)()`. The correct syntax you're looking

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

On Tue, Nov 12, 2019 at 10:21 AM Marvin Renich wrote: > > There are two different viewpoints you can take. Either the Go Memory > Model must stand alone, and any concurrency claims made by the language > and standard library must be based on the limited set of operations > defined in the GMM, or

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

This is not the issue I am referring to, I am referring to https://github.com/golang/go/issues/5045 -Original Message- >From: Marvin Renich >Sent: Nov 12, 2019 11:30 AM >To: golang-nuts >Subject: Re: [go-nuts] What is the correct way to access/modify slice elements >concurrently >

Re: [go-nuts] What is the correct way to access/modify slice elements concurrently

* Robert Engels [191112 13:44]: > Sorry, at work so I need to use the 'web mail' interface and it > doesn't appear to be including them when I reply. Understood. I'll just try to follow the threading as best as I can. ...Marvin -- You received this message because you are subscribed to the

[go-nuts] Re: Any way to print a 'struct g' within delve/gdb

If you look at the output of your first command you see the result `(**runtime.g)()`, however you're trying to cast to `(runtime.g*)()`. The correct syntax you're looking for is ` *(*runtime.g)()`. Hope that helps! On Monday, November 11, 2019 at 11:29:42 PM UTC-8, Xiangdong JI wrote: > > Hi

Re: [go-nuts] liteide x36.2 released.

Getting 400 Bad Request when accessing http://liteide.org On Sat, Nov 2, 2019, 9:32 PM visualfc wrote: > Hi, all. > LiteIDE X36.2 released! > This version fix gocode crash bug. Add new image viewer plugins. Folder > view support multi copy, move to trash. Fix windows floating dock > widget

Re: [go-nuts] Why does this program crash on darwin?

On Mon, Nov 11, 2019 at 9:32 PM Saj Goonatilleke wrote: > > Source: > > --- 8< --- > package main > > import ( > "os" > "os/signal" > ) > > func main() { > sigs := make(chan os.Signal) > signal.Notify(sigs, os.Interrupt) > > if f := os.NewFile(3, ""); f !=

[go-nuts] WasmFiddle for Go?

I came across WasmFiddle a couple of days ago which lets you interactively code WebAssembly apps in C++. Is anyone planning a similar capability for Go? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] How to know the deeper go-grpc error's name and detect it? Does Go 1.13 helpful?

I'm use go-grpc as communication between client & server program. When the server killed by manual, the client will get an error, I'm trying to know that situation. Here is some client code, 36 var check = func(err error) { 37 if err != nil { 38 panic(err) 39