[go-nuts] Re: godoc (golang.org/x/tools/cmd/godoc) has become module-aware

It would have been nice, if there were installation instructions on the page are redirected to when you click that link, so people know how to get a newer version. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

Re: [go-nuts] strict type assignability to prevent arbitrary values

Hi Mohamed, The memory layout of "string" is the same as that of "struct { string }", so there is no extra allocation or indirection involved on creation and access, hence no runtime overhead. Peter On Fri, Nov 8, 2019 at 2:01 AM Mohamed Yousif wrote: > Hi Speter, > > Can you elaborate more

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

On Fri, Nov 8, 2019 at 1:38 PM André Eriksson wrote: > > On Friday, November 8, 2019 at 10:27:32 PM UTC+1, Ian Lance Taylor wrote: >> >> On Fri, Nov 8, 2019 at 11:40 AM André Eriksson wrote: >> > >> > On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote: >> >> >> >> On Fri,

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

On Friday, November 8, 2019 at 10:27:32 PM UTC+1, Ian Lance Taylor wrote: > > On Fri, Nov 8, 2019 at 11:40 AM André Eriksson > wrote: > > > > On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote: > >> > >> On Fri, Nov 8, 2019 at 10:06 AM André Eriksson > wrote: > >> > >

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

On Fri, Nov 8, 2019 at 11:40 AM André Eriksson wrote: > > On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote: >> >> On Fri, Nov 8, 2019 at 10:06 AM André Eriksson wrote: >> > >> > Interesting. Do you have a reference to where that happens? >> >> The method

[go-nuts] Re: godoc (golang.org/x/tools/cmd/godoc) has become module-aware

On Friday, November 8, 2019 at 8:52:07 PM UTC+2, Dmitri Shuralyov wrote: > > Hello gophers, > > godoc , the local web server that > displays documentation for Go packages (not to be confused with > https://godoc.org, the website), has been updated with

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

On Friday, November 8, 2019 at 7:16:42 PM UTC+1, Ian Lance Taylor wrote: > > On Fri, Nov 8, 2019 at 10:06 AM André Eriksson > wrote: > > > > Interesting. Do you have a reference to where that happens? > > The method (*Package).rewriteCall in cmd/cgo/gcc.go. But more useful > might be to

[go-nuts] godoc (golang.org/x/tools/cmd/godoc) has become module-aware

Hello gophers, godoc , the local web server that displays documentation for Go packages (not to be confused with https://godoc.org, the website), has been updated with support for Go modules. (This was issue 33655 .)

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

There is Massimiliano Ghilardi’s gomacro Github.com/cosmos72/gomacro Note that in case of untyped constants, there is no need to use temps so your idea can still work. >> On Nov 8, 2019, at 9:30 AM, Michael Jones wrote: >  > Alas. Thus the need for and glory of macros, hold/uneval, and

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

On Fri, Nov 8, 2019 at 10:06 AM André Eriksson wrote: > > Interesting. Do you have a reference to where that happens? The method (*Package).rewriteCall in cmd/cgo/gcc.go. But more useful might be to experiment with some cgo code and build with `go build -work` and look in the $WORK directory to

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

Interesting. Do you have a reference to where that happens? If i understand you correctly, however, it doesn't appear to solve the case where the called function fn lives in a different package, and takes an argument which is a private type. That is: -- a/a.go -- package a type myString

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

On Fri, Nov 8, 2019 at 9:08 AM André Eriksson wrote: > > That works in simple cases, but does not work when the expression is an > untyped constant, like 1 or nil. In the case of 1 the variable will get a > concrete type of int, while fn may accept a float32, or even a private type > that

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

I tried to explain why that does not work in the general case. Specifically, that coerces expr to take a concrete type. The constant 1 would become int, while fn might take a float32 or even a private type that cannot be named in the package being rewritten. It would similarly fail if expr is

Re: [go-nuts] strict type assignability to prevent arbitrary values

...job for a getter function. On Fri, Nov 8, 2019 at 9:31 AM Jake Montgomery wrote: > The inability to have a type safe enum in Go has bothered me as well. > > While using a struct, as Peter suggests, does prevent accidental use of > literals, it also prevents you from making your enum items

Re: [go-nuts] strict type assignability to prevent arbitrary values

The inability to have a type safe enum in Go has bothered me as well. While using a struct, as Peter suggests, does prevent accidental use of literals, it also prevents you from making your enum items constant.This means that the values can be changed, accidentally, or intentionally, in

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

Alas. Thus the need for and glory of macros, hold/uneval, and backtick in LISP. (Problems solved in the 1970s) On Fri, Nov 8, 2019 at 9:08 AM André Eriksson wrote: > That works in simple cases, but does not work when the expression is an > untyped constant, like 1 or nil. In the case of 1 the

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

That works in simple cases, but does not work when the expression is an untyped constant, like 1 or nil. In the case of 1 the variable will get a concrete type of int, while fn may accept a float32, or even a private type that cannot be named in the current package. On Friday, November 8, 2019

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

If expr was evaluable in the original code then why not rewrite in place after assigning temporaries? go fn(e1,e2) { t1,t2 := e1,e2 go func() { defer instrument() fn(t1,t2) } On Fri, Nov 8, 2019 at 8:38 AM André Eriksson wrote: > I am working on a type of Go preprocessor that rewrites

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

-Original Message- >From: burak serdar >Sent: Nov 8, 2019 9:19 AM >To: golang-nuts >Subject: Re: [go-nuts] What is the correct way to access/modify slice elements >concurrently > >On Fri, Nov 8, 2019 at 7:55 AM Marvin Renich wrote: >> >> * burak serdar [191108 08:42]: >> > I

[go-nuts] Preprocessing "go" statements with preserved semantics

I am working on a type of Go preprocessor that rewrites source code to add additional instrumentation to certain types of statements. One such statement is the go statement. I would like to instrument the newly created goroutine, injecting some instrumentation code at the start and finish of

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

On Fri, Nov 8, 2019 at 7:55 AM Marvin Renich wrote: > > * burak serdar [191108 08:42]: > > I was thinking about this. In general, it should be safe to replace > > > > Lock() > > read/write one value > > Unlock() > > > > with > > > > AtomicRead/Write > > > > Is that correct? The go memory model

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

* burak serdar [191108 08:42]: > I was thinking about this. In general, it should be safe to replace > > Lock() > read/write one value > Unlock() > > with > > AtomicRead/Write > > Is that correct? The go memory model does not say anything about this. Yes. While others have argued that the

[go-nuts] Help Women Who Go and GoBridge and get GoLand IDE on a 30% discount in the process

Hello Gophers! This weekend, on the 10th of November, the Go language turns 10 years old. Congratulations to all the gophers worldwide! As a gift back to the Go community, JetBrains , the creators of GoLand IDE , are launching a fundraising

[go-nuts] Missing embeded function in docs

Hi, I have an exported struct in my code, which has an embedded interface. For public (exported) interfaces I can see the interface in the struct, but if the interface is not public, but has some exported method, you can not find any sign of these methods in the go documents, this is an

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

Almost always, but it is very difficult as most times you are not really working with a single value (there are implied dependencies). These sort of solutions fall under “lock free” structures/algorithms - and they are fascinating to learn about. > On Nov 8, 2019, at 7:42 AM, burak serdar

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

On Fri, Nov 8, 2019 at 6:25 AM Marvin Renich wrote: > > * Kasun Vithanage [191107 23:47]: > > type Foo struct { > > Alive bool > > } > > > > type Bar struct { > > Foos []*Foo > > } > > > > func (b *Bar) CheckFoosAlive() { > > for i := 0; i < len(b.Foos); i++ { > > if b.Foos[i].Alive {

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

* Kasun Vithanage [191107 23:47]: > type Foo struct { > Alive bool > } > > type Bar struct { > Foos []*Foo > } > > func (b *Bar) CheckFoosAlive() { > for i := 0; i < len(b.Foos); i++ { > if b.Foos[i].Alive { > fmt.Println("Alive") > } > } > } > > func (b* Bar)

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

I think that is a bit unclear - even if they access different elements, if they ever access the same element even at different times , you need synchronization- it’s not only if the access the same element “concurrently”. >> On Nov 8, 2019, at 2:54 AM, Volker Dobler wrote: >  >> On Friday, 8

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

On Friday, 8 November 2019 05:47:03 UTC+1, Kasun Vithanage wrote: > > What is the best approach? > There is no single "best approach". If two goroutines A and B access two different indices iA and iB you do not need any synchronisation between them. If iA==iB you need to protect reads from