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

[marcelloh]

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 and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6cbd28ce-fff1-4609-b9a3-5e6fa79c8bc1%40googlegroups.com.

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

[speter]

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 on this point please?
> > there is no memory or runtime overhead due to encapsulating the string
> within a struct.
>
>
> On Thu, 7 Nov 2019 at 3:15 PM, speter  wrote:
>
>> Hi bsr,
>>
>> I'd suggest to use a struct type with a single string field. It will
>> prevent conversion from untyped string constant "by mistake".
>> Moreover, if you make the string field unexported, you can limit new
>> instance creation to the declaring package, allowing to enforce predefined
>> values.
>> Unlike with some other languages, there is no memory or runtime overhead
>> due to encapsulating the string within a struct.
>>
>> HTH,
>> Peter
>>
>> On Thu, Nov 7, 2019 at 7:58 PM bsr  wrote:
>>
>>> Hello,
>>>
>>> I am a long time user of go, but I always had the impression that below
>>> code would not work as string and Status are different type.
>>> I thought I need to explicitly convert as ```exec(Status("abc"))``` it
>>> to work.
>>>
>>> I think, this part of the spec may be the reason
>>> https://golang.org/ref/spec#Assignability
>>>
>>>- x is an untyped constant 
>>>representable  by a
>>>value of type T.
>>>
>>> Is there a way I can prevent this behavior.
>>> I am using Status like an enum, and only predefined status values should
>>> be allowed.
>>>
>>>
>>>
>>>
>>> https://play.golang.org/p/4zsb7KtPBC6
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> )
>>>
>>> type Status string
>>>
>>> func main() {
>>> exec("abc")
>>> }
>>>
>>> func exec(s Status) {
>>> fmt.Printf("Hello, %s", s)
>>> }
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/a20a7034-19c3-410a-bc86-25deff38534f%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAK_MaNuSTSGGummC5cOyh%2BbR9VCovrX3xHamDLixDUWbk010Dw%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK_MaNsozfO1_emE4LzkuRYxF9TyBQA1S%2B%2BJh2rN%2B310iv0T%2Bg%40mail.gmail.com.

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

[Ian Lance Taylor]

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, 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 see the generated files.
>> >>
>> >>
>> >> > 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 string
>> >> >
>> >> > func Fn(str myString) { }
>> >> >
>> >> > -- b/b.go --
>> >> > package b
>> >> >
>> >> > import "a"
>> >> >
>> >> > func rewrite() {
>> >> > go a.Fn("some string")
>> >> > }
>> >> >
>> >> > In this example knowing the desired type from the function signature 
>> >> > does not help, I would think?
>> >>
>> >> That is correct.
>> >>
>> >> Fortunately for a case like that you don't need to use a temporary
>> >> variable at all, since the argument is a constant.
>> >>
>> >> Ian
>> >
>> >
>> > That makes sense. I did some more research and came across another case 
>> > where even this might not work.
>> > It appears that there is a distinction between an untyped value and an 
>> > untyped constant. I hadn't appreciated this distinction until now.
>> >
>> > According to the spec (https://golang.org/ref/spec#Comparison_operators), 
>> > "Comparison operators compare two operands and yield an untyped boolean 
>> > value."
>> > As a result, it's possible to get untyped, non-constant values from 
>> > non-constant expressions.
>> >
>> > So we could have fn(a() == b()) passed to fn(b myBool) with no ability to 
>> > store this argument in a temporary variable without coercing the type to a 
>> > regular typed bool.
>>
>> Technically true but essentially never happens in practice.
>>
>> Ian
>
>
> I suppose that's fair, but it's hard to come up with concrete rules for what 
> is permissible given a particular implementation of the rewrite, which makes 
> it hard to explain to potential users of the tool.

The case where you have trouble is code that uses an unexported type
set as bool, functions that take parameters of that type that are
invoked by the go statement, and arguments passed as comparisons.  I
would be mildly surprised if any such code exists anywhere.  And even
then you could still make it work by using temporaries for the
operands of the comparison, and keeping the comparison unchanged in
the actual call to the function.

> Switching gears a bit, I guess this might be easier to implement as a 
> modification to the compiler? Or can you think of another way of making the 
> general case more tractable?

This could be done by modifying the compiler but it's unlikely that
the compiler change would be accepted in the master sources.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWATo%3Dt7GpVB8AiN_X2XXP9XkUWUV7c_51FzJ3LUC9N-Q%40mail.gmail.com.

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

[André Eriksson]

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: 
> >> > 
> >> > 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 see the generated files. 
> >> 
> >> 
> >> > 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 string 
> >> > 
> >> > func Fn(str myString) { } 
> >> > 
> >> > -- b/b.go -- 
> >> > package b 
> >> > 
> >> > import "a" 
> >> > 
> >> > func rewrite() { 
> >> > go a.Fn("some string") 
> >> > } 
> >> > 
> >> > In this example knowing the desired type from the function signature 
> does not help, I would think? 
> >> 
> >> That is correct. 
> >> 
> >> Fortunately for a case like that you don't need to use a temporary 
> >> variable at all, since the argument is a constant. 
> >> 
> >> Ian 
> > 
> > 
> > That makes sense. I did some more research and came across another case 
> where even this might not work. 
> > It appears that there is a distinction between an untyped value and an 
> untyped constant. I hadn't appreciated this distinction until now. 
> > 
> > According to the spec (https://golang.org/ref/spec#Comparison_operators), 
> "Comparison operators compare two operands and yield an untyped boolean 
> value." 
> > As a result, it's possible to get untyped, non-constant values from 
> non-constant expressions. 
> > 
> > So we could have fn(a() == b()) passed to fn(b myBool) with no ability 
> to store this argument in a temporary variable without coercing the type to 
> a regular typed bool. 
>
> Technically true but essentially never happens in practice. 
>
> Ian 
>

I suppose that's fair, but it's hard to come up with concrete rules for 
what is permissible given a particular implementation of the rewrite, which 
makes it hard to explain to potential users of the tool.

Switching gears a bit, I guess this might be easier to implement as a 
modification to the compiler? Or can you think of another way of making the 
general case more tractable?

Thanks,
André 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2817e2e4-cc78-472e-bb06-7b0aa0322bdd%40googlegroups.com.

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

[Ian Lance Taylor]

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 (*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 see the generated files.
>>
>>
>> > 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 string
>> >
>> > func Fn(str myString) { }
>> >
>> > -- b/b.go --
>> > package b
>> >
>> > import "a"
>> >
>> > func rewrite() {
>> > go a.Fn("some string")
>> > }
>> >
>> > In this example knowing the desired type from the function signature does 
>> > not help, I would think?
>>
>> That is correct.
>>
>> Fortunately for a case like that you don't need to use a temporary
>> variable at all, since the argument is a constant.
>>
>> Ian
>
>
> That makes sense. I did some more research and came across another case where 
> even this might not work.
> It appears that there is a distinction between an untyped value and an 
> untyped constant. I hadn't appreciated this distinction until now.
>
> According to the spec (https://golang.org/ref/spec#Comparison_operators), 
> "Comparison operators compare two operands and yield an untyped boolean 
> value."
> As a result, it's possible to get untyped, non-constant values from 
> non-constant expressions.
>
> So we could have fn(a() == b()) passed to fn(b myBool) with no ability to 
> store this argument in a temporary variable without coercing the type to a 
> regular typed bool.

Technically true but essentially never happens in practice.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXbp8RNJQ%3DnbOEVkXd4vbuK8HC%3Dd9BfYso9yz35DEyEoA%40mail.gmail.com.

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

[Ain]

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 support for Go 
> modules. (This was issue 33655 .)
>

Great news, thank you! 

Ain

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ce9e20ff-9388-4e7e-bbcd-b2a088c8d5e8%40googlegroups.com.

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

[André Eriksson]

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 experiment with some cgo code and build with `go build 
> -work` and look in the $WORK directory to see the generated files. 
>
>
> > 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 string 
> > 
> > func Fn(str myString) { } 
> > 
> > -- b/b.go -- 
> > package b 
> > 
> > import "a" 
> > 
> > func rewrite() { 
> > go a.Fn("some string") 
> > } 
> > 
> > In this example knowing the desired type from the function signature 
> does not help, I would think? 
>
> That is correct. 
>
> Fortunately for a case like that you don't need to use a temporary 
> variable at all, since the argument is a constant. 
>
> Ian 
>

That makes sense. I did some more research and came across another case 
where even this might not work.
It appears that there is a distinction between an untyped value and an 
untyped constant. I hadn't appreciated this distinction until now.

According to the spec (https://golang.org/ref/spec#Comparison_operators), 
"Comparison operators compare two operands and yield an untyped boolean 
value."
As a result, it's possible to get untyped, non-constant values from 
non-constant expressions.

So we could have fn(a() == b()) passed to fn(b myBool) with no ability to 
store this argument in a temporary variable without coercing the type to a 
regular typed bool.


>
> > On Friday, November 8, 2019 at 6:58:02 PM UTC+1, Ian Lance Taylor wrote: 
> >> 
> >> 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 cannot be named in the current package. 
> >> 
> >> You might want to look at the rewriting that cmd/cgo does, as it 
> >> handles this exact kind of case.  Basically, for untyped constants, 
> >> you know the desired type, because it's in the function signature.  So 
> >> use that. 
> >> 
> >> It does get kind of complicated, though. 
> >> 
> >> Ian 
> >> 
> >> 
> >> > On Friday, November 8, 2019 at 5:51:10 PM UTC+1, Michael Jones wrote: 
> >> >> 
> >> >> 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 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 the goroutine. 
> >> >>> 
> >> >>> In the simple case, the rewrite is straightforward: 
> >> >>> 
> >> >>> go fn() 
> >> >>> 
> >> >>> becomes 
> >> >>> 
> >> >>> go func() { 
> >> >>> defer instrument()() 
> >> >>> fn() 
> >> >>> }() 
> >> >>> 
> >> >>> However this approach does not work when fn takes parameters. 
> >> >>> If we were to rewrite go fn(expr) into the equivalent form above: 
> >> >>> 
> >> >>> go func() { 
> >> >>> defer instrument()() 
> >> >>> fn(expr) 
> >> >>> }() 
> >> >>> 
> >> >>> 
> >> >>> the semantics change, since in the rewrite expr gets evaluated 
> inside the newly created goroutine, which can change the behavior and 
> introduce data races. 
> >> >>> 
> >> >>> My attempts to address this have not been particularly fruitful. 
> >> >>> 
> >> >>> One cannot pass in expr as an argument to the closure, because the 
> type of the expression may not have a valid name in the current package 
> (for example if expr evaluates to a private type in some other package). 
> >> >>> 
> >> >>> Similarly, if expr is a constant expression (like 1 or nil) the 
> type may depend on the corresponding parameter in fn’s signature. 
> >> >>> 
> >> >>> The only semantics-preserving rewrite I can think of revolves 
> around using package reflect, and rewriting like so: 
> >> >>> 
> >> >>> go func(fn reflect.Value, vals …reflect.Value) { 
> >> >>> defer instrument() 
> >> >>> fn.Call(vals) 
> >> >>> }(reflect.ValueOf(fn), reflect.ValueOf(expr)) 
> >> >>> 
> >> >>> As far as I understand, this should be semantics-preserving, 
> although with a slight performance cost. (Though I imagine the cost of a 
> reflection-based 

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

[Dmitri Shuralyov]

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 .)

Module-aware mode is enabled whenever it would be enabled for the go
command. That is, module mode is enabled when a go.mod file
 is found in, or in a
parent of, the directory where you run the godoc command. Documentation is
displayed for packages in the build list
, which
includes the main module and its dependencies. Environment variables
 such as GO111MODULE,
GOPRIVATE, GOPROXY that control the behavior of the go command also affect
godoc.

As a reminder, the godoc command is no longer included in the binary
distribution as of Go 1.13 . You can
install the latest version from its source at golang.org/x/tools/cmd/godoc.

If you run into unexpected problems, please let us know by leaving a
comment on issue 33655 , filing a new issue
, or
replying to this thread.

Thanks,
Dmitri

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BON-PFnPJiuAkO0eNruWwu0-atG2%2B-VqQ%3DyXSR%2BO5bV2FdXFQ%40mail.gmail.com.

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

[Bakul Shah]

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 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 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 at 5:51:10 PM UTC+1, Michael Jones wrote:
>>> 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 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 the goroutine.
 
 In the simple case, the rewrite is straightforward:
 
 go fn()
 
 becomes
 
 go func() {
defer instrument()()
fn()
 }()
 
 However this approach does not work when fn takes parameters.
 If we were to rewrite go fn(expr) into the equivalent form above:
 
 go func() {
defer instrument()()
fn(expr)
 }()
 
 
 the semantics change, since in the rewrite expr gets evaluated inside the 
 newly created goroutine, which can change the behavior and introduce data 
 races.
 
 My attempts to address this have not been particularly fruitful.
 
 One cannot pass in expr as an argument to the closure, because the type of 
 the expression may not have a valid name in the current package (for 
 example if expr evaluates to a private type in some other package). 
 
 Similarly, if expr is a constant expression (like 1 or nil) the type may 
 depend on the corresponding parameter in fn’s signature.
 
 The only semantics-preserving rewrite I can think of revolves around using 
 package reflect, and rewriting like so:
 
 go func(fn reflect.Value, vals …reflect.Value) {
defer instrument()
fn.Call(vals)
 }(reflect.ValueOf(fn), reflect.ValueOf(expr))
 
 As far as I understand, this should be semantics-preserving, although with 
 a slight performance cost. (Though I imagine the cost of a 
 reflection-based call is dwarfed by the cost of spawning a goroutine.)
 
 Unfortunately this also comes with a major downside: the rewritten code 
 does not typecheck identically to the original code. Ideally I would like 
 the rewritten form to cause identical typechecking failures to the old 
 code, so that these errors are caught at compile time without requiring a 
 separate typechecking pass for the original code.
 
 Am I correct in the above reasoning? Can anyone think of a way to do this 
 sort of rewrite in a semantics-preserving and typechecking-preserving way? 
  
 -- 
 You received this message because you are subscribed to the Google Groups 
 "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com.
>>> 
>>> 
>>> -- 
>>> Michael T. Jones
>>> michae...@gmail.com
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/ec41a345-163f-4a8a-a24f-b868def081a0%40googlegroups.com.
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@gmail.com
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQxe--frSeHfKo822bKhWStJoQdJpkNdAYM6zTPLUuZ%2BAg%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an 

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

[Ian Lance Taylor]

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 see the generated files.


> 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 string
>
> func Fn(str myString) { }
>
> -- b/b.go --
> package b
>
> import "a"
>
> func rewrite() {
> go a.Fn("some string")
> }
>
> In this example knowing the desired type from the function signature does not 
> help, I would think?

That is correct.

Fortunately for a case like that you don't need to use a temporary
variable at all, since the argument is a constant.

Ian


> On Friday, November 8, 2019 at 6:58:02 PM UTC+1, Ian Lance Taylor wrote:
>>
>> 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 cannot be named in the current package.
>>
>> You might want to look at the rewriting that cmd/cgo does, as it
>> handles this exact kind of case.  Basically, for untyped constants,
>> you know the desired type, because it's in the function signature.  So
>> use that.
>>
>> It does get kind of complicated, though.
>>
>> Ian
>>
>>
>> > On Friday, November 8, 2019 at 5:51:10 PM UTC+1, Michael Jones wrote:
>> >>
>> >> 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 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 the goroutine.
>> >>>
>> >>> In the simple case, the rewrite is straightforward:
>> >>>
>> >>> go fn()
>> >>>
>> >>> becomes
>> >>>
>> >>> go func() {
>> >>> defer instrument()()
>> >>> fn()
>> >>> }()
>> >>>
>> >>> However this approach does not work when fn takes parameters.
>> >>> If we were to rewrite go fn(expr) into the equivalent form above:
>> >>>
>> >>> go func() {
>> >>> defer instrument()()
>> >>> fn(expr)
>> >>> }()
>> >>>
>> >>>
>> >>> the semantics change, since in the rewrite expr gets evaluated inside 
>> >>> the newly created goroutine, which can change the behavior and introduce 
>> >>> data races.
>> >>>
>> >>> My attempts to address this have not been particularly fruitful.
>> >>>
>> >>> One cannot pass in expr as an argument to the closure, because the type 
>> >>> of the expression may not have a valid name in the current package (for 
>> >>> example if expr evaluates to a private type in some other package).
>> >>>
>> >>> Similarly, if expr is a constant expression (like 1 or nil) the type may 
>> >>> depend on the corresponding parameter in fn’s signature.
>> >>>
>> >>> The only semantics-preserving rewrite I can think of revolves around 
>> >>> using package reflect, and rewriting like so:
>> >>>
>> >>> go func(fn reflect.Value, vals …reflect.Value) {
>> >>> defer instrument()
>> >>> fn.Call(vals)
>> >>> }(reflect.ValueOf(fn), reflect.ValueOf(expr))
>> >>>
>> >>> As far as I understand, this should be semantics-preserving, although 
>> >>> with a slight performance cost. (Though I imagine the cost of a 
>> >>> reflection-based call is dwarfed by the cost of spawning a goroutine.)
>> >>>
>> >>> Unfortunately this also comes with a major downside: the rewritten code 
>> >>> does not typecheck identically to the original code. Ideally I would 
>> >>> like the rewritten form to cause identical typechecking failures to the 
>> >>> old code, so that these errors are caught at compile time without 
>> >>> requiring a separate typechecking pass for the original code.
>> >>>
>> >>> Am I correct in the above reasoning? Can anyone think of a way to do 
>> >>> this sort of rewrite in a semantics-preserving and 
>> >>> typechecking-preserving way?
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google 
>> >>> Groups "golang-nuts" group.
>> >>> To unsubscribe from this group and stop receiving emails from it, send 
>> >>> an email to golan...@googlegroups.com.
>> >>> To view this discussion on the web visit 
>> >>> 

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

[André Eriksson]

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 string

func Fn(str myString) { }

-- b/b.go --
package b

import "a"

func rewrite() {
go a.Fn("some string")
}

In this example knowing the desired type from the function signature does 
not help, I would think?

On Friday, November 8, 2019 at 6:58:02 PM UTC+1, Ian Lance Taylor wrote:
>
> 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 cannot be named in the current package. 
>
> You might want to look at the rewriting that cmd/cgo does, as it 
> handles this exact kind of case.  Basically, for untyped constants, 
> you know the desired type, because it's in the function signature.  So 
> use that. 
>
> It does get kind of complicated, though. 
>
> Ian 
>
>
> > On Friday, November 8, 2019 at 5:51:10 PM UTC+1, Michael Jones wrote: 
> >> 
> >> 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 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 the goroutine. 
> >>> 
> >>> In the simple case, the rewrite is straightforward: 
> >>> 
> >>> go fn() 
> >>> 
> >>> becomes 
> >>> 
> >>> go func() { 
> >>> defer instrument()() 
> >>> fn() 
> >>> }() 
> >>> 
> >>> However this approach does not work when fn takes parameters. 
> >>> If we were to rewrite go fn(expr) into the equivalent form above: 
> >>> 
> >>> go func() { 
> >>> defer instrument()() 
> >>> fn(expr) 
> >>> }() 
> >>> 
> >>> 
> >>> the semantics change, since in the rewrite expr gets evaluated inside 
> the newly created goroutine, which can change the behavior and introduce 
> data races. 
> >>> 
> >>> My attempts to address this have not been particularly fruitful. 
> >>> 
> >>> One cannot pass in expr as an argument to the closure, because the 
> type of the expression may not have a valid name in the current package 
> (for example if expr evaluates to a private type in some other package). 
> >>> 
> >>> Similarly, if expr is a constant expression (like 1 or nil) the type 
> may depend on the corresponding parameter in fn’s signature. 
> >>> 
> >>> The only semantics-preserving rewrite I can think of revolves around 
> using package reflect, and rewriting like so: 
> >>> 
> >>> go func(fn reflect.Value, vals …reflect.Value) { 
> >>> defer instrument() 
> >>> fn.Call(vals) 
> >>> }(reflect.ValueOf(fn), reflect.ValueOf(expr)) 
> >>> 
> >>> As far as I understand, this should be semantics-preserving, although 
> with a slight performance cost. (Though I imagine the cost of a 
> reflection-based call is dwarfed by the cost of spawning a goroutine.) 
> >>> 
> >>> Unfortunately this also comes with a major downside: the rewritten 
> code does not typecheck identically to the original code. Ideally I would 
> like the rewritten form to cause identical typechecking failures to the old 
> code, so that these errors are caught at compile time without requiring a 
> separate typechecking pass for the original code. 
> >>> 
> >>> Am I correct in the above reasoning? Can anyone think of a way to do 
> this sort of rewrite in a semantics-preserving and typechecking-preserving 
> way? 
> >>> 
> >>> -- 
> >>> You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> >>> To unsubscribe from this group and stop receiving emails from it, send 
> an email to golan...@googlegroups.com. 
> >>> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com.
>  
>
> >> 
> >> 
> >> 
> >> -- 
> >> Michael T. Jones 
> >> michae...@gmail.com 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/ec41a345-163f-4a8a-a24f-b868def081a0%40googlegroups.com.
>  
>
>

-- 
You received this message because you are 

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

[Ian Lance Taylor]

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 cannot be named in the current package.

You might want to look at the rewriting that cmd/cgo does, as it
handles this exact kind of case.  Basically, for untyped constants,
you know the desired type, because it's in the function signature.  So
use that.

It does get kind of complicated, though.

Ian


> On Friday, November 8, 2019 at 5:51:10 PM UTC+1, Michael Jones wrote:
>>
>> 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 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 the goroutine.
>>>
>>> In the simple case, the rewrite is straightforward:
>>>
>>> go fn()
>>>
>>> becomes
>>>
>>> go func() {
>>> defer instrument()()
>>> fn()
>>> }()
>>>
>>> However this approach does not work when fn takes parameters.
>>> If we were to rewrite go fn(expr) into the equivalent form above:
>>>
>>> go func() {
>>> defer instrument()()
>>> fn(expr)
>>> }()
>>>
>>>
>>> the semantics change, since in the rewrite expr gets evaluated inside the 
>>> newly created goroutine, which can change the behavior and introduce data 
>>> races.
>>>
>>> My attempts to address this have not been particularly fruitful.
>>>
>>> One cannot pass in expr as an argument to the closure, because the type of 
>>> the expression may not have a valid name in the current package (for 
>>> example if expr evaluates to a private type in some other package).
>>>
>>> Similarly, if expr is a constant expression (like 1 or nil) the type may 
>>> depend on the corresponding parameter in fn’s signature.
>>>
>>> The only semantics-preserving rewrite I can think of revolves around using 
>>> package reflect, and rewriting like so:
>>>
>>> go func(fn reflect.Value, vals …reflect.Value) {
>>> defer instrument()
>>> fn.Call(vals)
>>> }(reflect.ValueOf(fn), reflect.ValueOf(expr))
>>>
>>> As far as I understand, this should be semantics-preserving, although with 
>>> a slight performance cost. (Though I imagine the cost of a reflection-based 
>>> call is dwarfed by the cost of spawning a goroutine.)
>>>
>>> Unfortunately this also comes with a major downside: the rewritten code 
>>> does not typecheck identically to the original code. Ideally I would like 
>>> the rewritten form to cause identical typechecking failures to the old 
>>> code, so that these errors are caught at compile time without requiring a 
>>> separate typechecking pass for the original code.
>>>
>>> Am I correct in the above reasoning? Can anyone think of a way to do this 
>>> sort of rewrite in a semantics-preserving and typechecking-preserving way?
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com.
>>
>>
>>
>> --
>> Michael T. Jones
>> michae...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/ec41a345-163f-4a8a-a24f-b868def081a0%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWAjqU8dFfkNpMKyzTvUAcEkc0DjRnLJesWN9TsWjCs0A%40mail.gmail.com.

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

[eandre via golang-nuts]

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 untyped nil.

On Friday, November 8, 2019 at 5:51:10 PM UTC+1, Michael Jones wrote:
>
> 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 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 the goroutine.
>>
>> In the simple case, the rewrite is straightforward:
>>
>> go fn()
>>
>> becomes
>>
>> go func() {
>> defer instrument()()
>> fn()
>> }()
>>
>> However this approach does not work when fn takes parameters.
>> If we were to rewrite go fn(expr) into the equivalent form above:
>>
>> go func() {
>> defer instrument()()
>> fn(expr)
>> }()
>>
>>
>> the semantics change, since in the rewrite expr gets evaluated inside 
>> the newly created goroutine, which can change the behavior and introduce 
>> data races.
>>
>> My attempts to address this have not been particularly fruitful.
>>
>> One cannot pass in expr as an argument to the closure, because the type 
>> of the expression may not have a valid name in the current package (for 
>> example if expr evaluates to a private type in some other package). 
>>
>> Similarly, if expr is a constant expression (like 1 or nil) the type may 
>> depend on the corresponding parameter in fn’s signature.
>>
>> The only semantics-preserving rewrite I can think of revolves around 
>> using package reflect, and rewriting like so:
>>
>> go func(fn reflect.Value, vals …reflect.Value) {
>> defer instrument()
>> fn.Call(vals)
>> }(reflect.ValueOf(fn), reflect.ValueOf(expr))
>>
>> As far as I understand, this should be semantics-preserving, although 
>> with a slight performance cost. (Though I imagine the cost of a 
>> reflection-based call is dwarfed by the cost of spawning a goroutine.)
>>
>> Unfortunately this also comes with a major downside: the rewritten code 
>> does not typecheck identically to the original code. Ideally I would like 
>> the rewritten form to cause identical typechecking failures to the old 
>> code, so that these errors are caught at compile time without requiring a 
>> separate typechecking pass for the original code.
>>
>> Am I correct in the above reasoning? Can anyone think of a way to do this 
>> sort of rewrite in a semantics-preserving and typechecking-preserving way?  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/67118711-d7c7-4ea0-9260-1ff50f38cf43%40googlegroups.com.

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

[Michael Jones]

...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 constant.This
> means that the values can be changed, accidentally, or intentionally, in
> another package. For example:
>
> package enum
>
> import "fmt"
>
> type Status struct {
> s string
> }
>
> var One = Status{"one"}
> var Two = Status{"two"}
>
> func PrintIt(stat Status) {
> fmt.Println("Status is", stat.s)
> }
>
> But a client of your package can then do:
>
> func Foo() {
>
> enum.One = enum.Two
> enum.PrintIt(enum.One)
>
> }
>
> Which will print "two", and perminantly alter the meaning of enum.One.
>
>
> On Thursday, November 7, 2019 at 8:15:20 AM UTC-5, speter wrote:
>>
>> Hi bsr,
>>
>> I'd suggest to use a struct type with a single string field. It will
>> prevent conversion from untyped string constant "by mistake".
>> Moreover, if you make the string field unexported, you can limit new
>> instance creation to the declaring package, allowing to enforce predefined
>> values.
>> Unlike with some other languages, there is no memory or runtime overhead
>> due to encapsulating the string within a struct.
>>
>> HTH,
>> Peter
>>
>> On Thu, Nov 7, 2019 at 7:58 PM bsr  wrote:
>>
>>> Hello,
>>>
>>> I am a long time user of go, but I always had the impression that below
>>> code would not work as string and Status are different type.
>>> I thought I need to explicitly convert as ```exec(Status("abc"))``` it
>>> to work.
>>>
>>> I think, this part of the spec may be the reason
>>> https://golang.org/ref/spec#Assignability
>>>
>>>- x is an untyped constant 
>>>representable  by a
>>>value of type T.
>>>
>>> Is there a way I can prevent this behavior.
>>> I am using Status like an enum, and only predefined status values should
>>> be allowed.
>>>
>>>
>>>
>>>
>>> https://play.golang.org/p/4zsb7KtPBC6
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> )
>>>
>>> type Status string
>>>
>>> func main() {
>>> exec("abc")
>>> }
>>>
>>> func exec(s Status) {
>>> fmt.Printf("Hello, %s", s)
>>> }
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/a20a7034-19c3-410a-bc86-25deff38534f%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9df8504c-4309-43ab-86ee-518b52eb2e2f%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQw2WZQjcmpRzue8xpX4JKOc3PsR_5TAcoWnaaS%3DxkR5CQ%40mail.gmail.com.

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

[Jake Montgomery]

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 
another package. For example:

package enum

import "fmt"

type Status struct {
s string
}

var One = Status{"one"}
var Two = Status{"two"}

func PrintIt(stat Status) {
fmt.Println("Status is", stat.s)
}

But a client of your package can then do:

func Foo() {

enum.One = enum.Two
enum.PrintIt(enum.One)

}

Which will print "two", and perminantly alter the meaning of enum.One.


On Thursday, November 7, 2019 at 8:15:20 AM UTC-5, speter wrote:
>
> Hi bsr,
>
> I'd suggest to use a struct type with a single string field. It will 
> prevent conversion from untyped string constant "by mistake".
> Moreover, if you make the string field unexported, you can limit new 
> instance creation to the declaring package, allowing to enforce predefined 
> values.
> Unlike with some other languages, there is no memory or runtime overhead 
> due to encapsulating the string within a struct.
>
> HTH,
> Peter
>
> On Thu, Nov 7, 2019 at 7:58 PM bsr > wrote:
>
>> Hello,
>>
>> I am a long time user of go, but I always had the impression that below 
>> code would not work as string and Status are different type.
>> I thought I need to explicitly convert as ```exec(Status("abc"))``` it to 
>> work.
>>
>> I think, this part of the spec may be the reason 
>> https://golang.org/ref/spec#Assignability
>>
>>- x is an untyped constant  
>>representable  by a 
>>value of type T. 
>>
>> Is there a way I can prevent this behavior.
>> I am using Status like an enum, and only predefined status values should 
>> be allowed.
>>
>>
>>
>>
>> https://play.golang.org/p/4zsb7KtPBC6
>>
>> package main
>>
>> import (
>> "fmt"
>> )
>>
>> type Status string
>>
>> func main() {
>> exec("abc")
>> }
>>
>> func exec(s Status) {
>> fmt.Printf("Hello, %s", s)
>> }
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a20a7034-19c3-410a-bc86-25deff38534f%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9df8504c-4309-43ab-86ee-518b52eb2e2f%40googlegroups.com.

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

[Michael Jones]

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 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 at 5:51:10 PM UTC+1, Michael Jones wrote:
>>
>> 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 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 the goroutine.
>>>
>>> In the simple case, the rewrite is straightforward:
>>>
>>> go fn()
>>>
>>> becomes
>>>
>>> go func() {
>>> defer instrument()()
>>> fn()
>>> }()
>>>
>>> However this approach does not work when fn takes parameters.
>>> If we were to rewrite go fn(expr) into the equivalent form above:
>>>
>>> go func() {
>>> defer instrument()()
>>> fn(expr)
>>> }()
>>>
>>>
>>> the semantics change, since in the rewrite expr gets evaluated inside
>>> the newly created goroutine, which can change the behavior and introduce
>>> data races.
>>>
>>> My attempts to address this have not been particularly fruitful.
>>>
>>> One cannot pass in expr as an argument to the closure, because the type
>>> of the expression may not have a valid name in the current package (for
>>> example if expr evaluates to a private type in some other package).
>>>
>>> Similarly, if expr is a constant expression (like 1 or nil) the type
>>> may depend on the corresponding parameter in fn’s signature.
>>>
>>> The only semantics-preserving rewrite I can think of revolves around
>>> using package reflect, and rewriting like so:
>>>
>>> go func(fn reflect.Value, vals …reflect.Value) {
>>> defer instrument()
>>> fn.Call(vals)
>>> }(reflect.ValueOf(fn), reflect.ValueOf(expr))
>>>
>>> As far as I understand, this should be semantics-preserving, although
>>> with a slight performance cost. (Though I imagine the cost of a
>>> reflection-based call is dwarfed by the cost of spawning a goroutine.)
>>>
>>> Unfortunately this also comes with a major downside: the rewritten code
>>> does not typecheck identically to the original code. Ideally I would like
>>> the rewritten form to cause identical typechecking failures to the old
>>> code, so that these errors are caught at compile time without requiring a
>>> separate typechecking pass for the original code.
>>>
>>> Am I correct in the above reasoning? Can anyone think of a way to do
>>> this sort of rewrite in a semantics-preserving and typechecking-preserving
>>> way?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>>
>> *Michael T. jonesmichae...@gmail.com*
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ec41a345-163f-4a8a-a24f-b868def081a0%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQxe--frSeHfKo822bKhWStJoQdJpkNdAYM6zTPLUuZ%2BAg%40mail.gmail.com.

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

[André Eriksson]

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 at 5:51:10 PM UTC+1, Michael Jones wrote:
>
> 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 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 the goroutine.
>>
>> In the simple case, the rewrite is straightforward:
>>
>> go fn()
>>
>> becomes
>>
>> go func() {
>> defer instrument()()
>> fn()
>> }()
>>
>> However this approach does not work when fn takes parameters.
>> If we were to rewrite go fn(expr) into the equivalent form above:
>>
>> go func() {
>> defer instrument()()
>> fn(expr)
>> }()
>>
>>
>> the semantics change, since in the rewrite expr gets evaluated inside 
>> the newly created goroutine, which can change the behavior and introduce 
>> data races.
>>
>> My attempts to address this have not been particularly fruitful.
>>
>> One cannot pass in expr as an argument to the closure, because the type 
>> of the expression may not have a valid name in the current package (for 
>> example if expr evaluates to a private type in some other package). 
>>
>> Similarly, if expr is a constant expression (like 1 or nil) the type may 
>> depend on the corresponding parameter in fn’s signature.
>>
>> The only semantics-preserving rewrite I can think of revolves around 
>> using package reflect, and rewriting like so:
>>
>> go func(fn reflect.Value, vals …reflect.Value) {
>> defer instrument()
>> fn.Call(vals)
>> }(reflect.ValueOf(fn), reflect.ValueOf(expr))
>>
>> As far as I understand, this should be semantics-preserving, although 
>> with a slight performance cost. (Though I imagine the cost of a 
>> reflection-based call is dwarfed by the cost of spawning a goroutine.)
>>
>> Unfortunately this also comes with a major downside: the rewritten code 
>> does not typecheck identically to the original code. Ideally I would like 
>> the rewritten form to cause identical typechecking failures to the old 
>> code, so that these errors are caught at compile time without requiring a 
>> separate typechecking pass for the original code.
>>
>> Am I correct in the above reasoning? Can anyone think of a way to do this 
>> sort of rewrite in a semantics-preserving and typechecking-preserving way?  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ec41a345-163f-4a8a-a24f-b868def081a0%40googlegroups.com.

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

[Michael Jones]

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 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 the goroutine.
>
> In the simple case, the rewrite is straightforward:
>
> go fn()
>
> becomes
>
> go func() {
> defer instrument()()
> fn()
> }()
>
> However this approach does not work when fn takes parameters.
> If we were to rewrite go fn(expr) into the equivalent form above:
>
> go func() {
> defer instrument()()
> fn(expr)
> }()
>
>
> the semantics change, since in the rewrite expr gets evaluated inside the
> newly created goroutine, which can change the behavior and introduce data
> races.
>
> My attempts to address this have not been particularly fruitful.
>
> One cannot pass in expr as an argument to the closure, because the type
> of the expression may not have a valid name in the current package (for
> example if expr evaluates to a private type in some other package).
>
> Similarly, if expr is a constant expression (like 1 or nil) the type may
> depend on the corresponding parameter in fn’s signature.
>
> The only semantics-preserving rewrite I can think of revolves around using
> package reflect, and rewriting like so:
>
> go func(fn reflect.Value, vals …reflect.Value) {
> defer instrument()
> fn.Call(vals)
> }(reflect.ValueOf(fn), reflect.ValueOf(expr))
>
> As far as I understand, this should be semantics-preserving, although with
> a slight performance cost. (Though I imagine the cost of a reflection-based
> call is dwarfed by the cost of spawning a goroutine.)
>
> Unfortunately this also comes with a major downside: the rewritten code
> does not typecheck identically to the original code. Ideally I would like
> the rewritten form to cause identical typechecking failures to the old
> code, so that these errors are caught at compile time without requiring a
> separate typechecking pass for the original code.
>
> Am I correct in the above reasoning? Can anyone think of a way to do this
> sort of rewrite in a semantics-preserving and typechecking-preserving way?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQx4n-PLJ_scPHfcqNtTnyCo2y1RG_enpV-Rqe4FtxwaQg%40mail.gmail.com.

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

[Robert Engels]

-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 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 GMM is not specific enough about this
>> case, I disagree.  The atomic package says it is "useful for
>> implementing synchronization algorithms".  This wording is, in my
>> opinion, sufficient to make two guarantees:
>>
>>   1.  Values read and written with the atomic package will read and
>>   write whole values without corruption.
>>   2.  If a memory write from one goroutine is observed by another
>>   goroutine, this establishes a "happens before" relationship.
>>
>> If these are not true, than the documentation in the atomic package is a
>> blatant lie.  Thus, the memory model does not need any additional
>> verbiage to clarify this.
>>
>> And while the next paragraph in the atomic documentation discourages
>> using it for synchronization, I think the doc'n is overly pessimistic.
>> Certainly for the simple case of avoiding races due to concurrent
>> write/read of a single value, the atomic operations are a very good
>> solution.  If you can guarantee that all writes to a particular value
>> are done on a single goroutine, and all reads and writes are done using
>> the atomic package, than it is safe to have many other goroutines
>> reading that value, and using a mutex is overkill.
>>
>> I do agree that channels and the sync package should be preferred over
>> implementing something similar with atomic, but don't shy away from
>> atomic for the simple cases that it does well.
>
>
>That's what I figured as well. Atomic read/writes have memory
>barriers, so this should work. Afaik, an atomic read/write does not
>yield, so busy-waiting using an atomic will probably not work. Maybe
>some of these guarantees (and non-guarantees) can be explicitly stated
>in the docs.
>
>
>
>>
>> ...Marvin
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/20191108145435.3tdii3v3zgx3jv22%40basil.wdw.
>
>-- 
>You received this message because you are subscribed to the Google Groups 
>"golang-nuts" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to golang-nuts+unsubscr...@googlegroups.com.
>To view this discussion on the web visit 
>https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoyJMC3XXTBKdcAitKUyvyzbykvrfZPgQcLw5%3D%2BY%2B0%2BCQ%40mail.gmail.com.

See https://github.com/golang/go/issues/10958 for using atomics in 
tight/busy-wait loops.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1843585103.1669.1573231278267%40wamui-cheeto.atl.sa.earthlink.net.

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

[André Eriksson]

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 the goroutine.

In the simple case, the rewrite is straightforward:

go fn()

becomes

go func() {
defer instrument()()
fn()
}()

However this approach does not work when fn takes parameters.
If we were to rewrite go fn(expr) into the equivalent form above:

go func() {
defer instrument()()
fn(expr)
}()


the semantics change, since in the rewrite expr gets evaluated inside the 
newly created goroutine, which can change the behavior and introduce data 
races.

My attempts to address this have not been particularly fruitful.

One cannot pass in expr as an argument to the closure, because the type of 
the expression may not have a valid name in the current package (for 
example if expr evaluates to a private type in some other package). 

Similarly, if expr is a constant expression (like 1 or nil) the type may 
depend on the corresponding parameter in fn’s signature.

The only semantics-preserving rewrite I can think of revolves around using 
package reflect, and rewriting like so:

go func(fn reflect.Value, vals …reflect.Value) {
defer instrument()
fn.Call(vals)
}(reflect.ValueOf(fn), reflect.ValueOf(expr))

As far as I understand, this should be semantics-preserving, although with 
a slight performance cost. (Though I imagine the cost of a reflection-based 
call is dwarfed by the cost of spawning a goroutine.)

Unfortunately this also comes with a major downside: the rewritten code 
does not typecheck identically to the original code. Ideally I would like 
the rewritten form to cause identical typechecking failures to the old 
code, so that these errors are caught at compile time without requiring a 
separate typechecking pass for the original code.

Am I correct in the above reasoning? Can anyone think of a way to do this 
sort of rewrite in a semantics-preserving and typechecking-preserving way?  

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com.

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

[burak serdar]

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 does not say anything about this.
>
> Yes.
>
> While others have argued that the GMM is not specific enough about this
> case, I disagree.  The atomic package says it is "useful for
> implementing synchronization algorithms".  This wording is, in my
> opinion, sufficient to make two guarantees:
>
>   1.  Values read and written with the atomic package will read and
>   write whole values without corruption.
>   2.  If a memory write from one goroutine is observed by another
>   goroutine, this establishes a "happens before" relationship.
>
> If these are not true, than the documentation in the atomic package is a
> blatant lie.  Thus, the memory model does not need any additional
> verbiage to clarify this.
>
> And while the next paragraph in the atomic documentation discourages
> using it for synchronization, I think the doc'n is overly pessimistic.
> Certainly for the simple case of avoiding races due to concurrent
> write/read of a single value, the atomic operations are a very good
> solution.  If you can guarantee that all writes to a particular value
> are done on a single goroutine, and all reads and writes are done using
> the atomic package, than it is safe to have many other goroutines
> reading that value, and using a mutex is overkill.
>
> I do agree that channels and the sync package should be preferred over
> implementing something similar with atomic, but don't shy away from
> atomic for the simple cases that it does well.


That's what I figured as well. Atomic read/writes have memory
barriers, so this should work. Afaik, an atomic read/write does not
yield, so busy-waiting using an atomic will probably not work. Maybe
some of these guarantees (and non-guarantees) can be explicitly stated
in the docs.



>
> ...Marvin
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20191108145435.3tdii3v3zgx3jv22%40basil.wdw.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoyJMC3XXTBKdcAitKUyvyzbykvrfZPgQcLw5%3D%2BY%2B0%2BCQ%40mail.gmail.com.

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

[Marvin Renich]

* 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 GMM is not specific enough about this
case, I disagree.  The atomic package says it is "useful for
implementing synchronization algorithms".  This wording is, in my
opinion, sufficient to make two guarantees:

  1.  Values read and written with the atomic package will read and
  write whole values without corruption.
  2.  If a memory write from one goroutine is observed by another
  goroutine, this establishes a "happens before" relationship.

If these are not true, than the documentation in the atomic package is a
blatant lie.  Thus, the memory model does not need any additional
verbiage to clarify this.

And while the next paragraph in the atomic documentation discourages
using it for synchronization, I think the doc'n is overly pessimistic.
Certainly for the simple case of avoiding races due to concurrent
write/read of a single value, the atomic operations are a very good
solution.  If you can guarantee that all writes to a particular value
are done on a single goroutine, and all reads and writes are done using
the atomic package, than it is safe to have many other goroutines
reading that value, and using a mutex is overkill.

I do agree that channels and the sync package should be preferred over
implementing something similar with atomic, but don't shy away from
atomic for the simple cases that it does well.

...Marvin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191108145435.3tdii3v3zgx3jv22%40basil.wdw.

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

[Florin Pățan]

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 campaign to help support the Women Who Go 
 and GoBridge  
non-profit organizations, which are both dedicated to enabling minorities 
in tech to use Go as a tool to learn and teach programming.

This fundraising campaign is aiming to allow thousands of Women Who Go and 
GoBrige volunteers across the world to teach workshops, run meetups, and 
provide resources to women and other underrepresented groups with limited 
access to technology and tech skills.

During the two-week campaign, which will run until the *22nd of November*, 
every time* a new GoLand individual license* is brought the money will go 
to the Women Who Go and GoBridge non-profit organizations.

You can find more details on this page: 
https://www.jetbrains.com/lp/support-go/

GoLand team, Women Who Go, and GoBridge would really appreciate it if you 
could share this information among your fellow gophers.

Congrats!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/32ae1ab2-2fb1-434e-8e8d-414189124ddc%40googlegroups.com.

[go-nuts] Missing embeded function in docs

[Forud Ghafouri]

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 example : 

https://github.com/fzerorubigd/demo-doc/blob/master/demo.go

and this is the doc: 

https://godoc.org/github.com/fzerorubigd/demo-doc

the `ExportedFunction` is callable from outside, but it is not visible in 
documents. 

I am sure the code is valid, (it might be better to change it, but 
sometimes it's the best option, and also I can not find any advice against 
it) but I am not sure if "no-document" is intended, and if it is, what is 
the reason? 


Best

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cdf996e8-5279-4d8f-8c4d-31aba13eb56d%40googlegroups.com.

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

[Robert Engels]

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  wrote:
> 
>> 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 {
>>>  fmt.Println("Alive")
>>>}
>>>  }
>>> }
>>> 
>>> func (b* Bar) MarkFooStatus(index int, status bool){
>>>  // after bound checking
>>>  b.Foos[index].Alive = status
>>> }
>> 
>> Volker's answer is very good, but for the simple case where Alive is (or
>> can be) a type that is handled by the atomic package, that is almost
>> certainly the best approach.
> 
> 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.
> 
> 
>> 
>> If the Foo struct is complicated, and you have lots of non-overlapping
>> access to b.Foos (with the occasional overlapping access), I strongly
>> suspect that putting a mutex in Foo and using that will give you the
>> best results.
>> 
>> As Volker said, try several different approaches, and measure with loads
>> approximating your real-world scenario.  Alternatively, implement the
>> approach that you think is easiest to maintain (from a source code POV),
>> and test to see if the performance is acceptable under load.  If it is,
>> don't bother trying to optimize.
>> 
>> ...Marvin
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/20191108132521.bkrbxj2lv7wpinuo%40basil.wdw.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoGKG8FAqxn-M_E9hN3%2BzqX1UABWmdHu9w6rneKCu%2BsuA%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/58E8A687-9E28-4F39-9EF2-B095D1D80265%40ix.netcom.com.

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

[burak serdar]

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 {
> >   fmt.Println("Alive")
> > }
> >   }
> > }
> >
> > func (b* Bar) MarkFooStatus(index int, status bool){
> >   // after bound checking
> >   b.Foos[index].Alive = status
> > }
>
> Volker's answer is very good, but for the simple case where Alive is (or
> can be) a type that is handled by the atomic package, that is almost
> certainly the best approach.

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.


>
> If the Foo struct is complicated, and you have lots of non-overlapping
> access to b.Foos (with the occasional overlapping access), I strongly
> suspect that putting a mutex in Foo and using that will give you the
> best results.
>
> As Volker said, try several different approaches, and measure with loads
> approximating your real-world scenario.  Alternatively, implement the
> approach that you think is easiest to maintain (from a source code POV),
> and test to see if the performance is acceptable under load.  If it is,
> don't bother trying to optimize.
>
> ...Marvin
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20191108132521.bkrbxj2lv7wpinuo%40basil.wdw.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoGKG8FAqxn-M_E9hN3%2BzqX1UABWmdHu9w6rneKCu%2BsuA%40mail.gmail.com.

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

[Marvin Renich]

* 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) MarkFooStatus(index int, status bool){
>   // after bound checking
>   b.Foos[index].Alive = status
> }

Volker's answer is very good, but for the simple case where Alive is (or
can be) a type that is handled by the atomic package, that is almost
certainly the best approach.

If the Foo struct is complicated, and you have lots of non-overlapping
access to b.Foos (with the occasional overlapping access), I strongly
suspect that putting a mutex in Foo and using that will give you the
best results.

As Volker said, try several different approaches, and measure with loads
approximating your real-world scenario.  Alternatively, implement the
approach that you think is easiest to maintain (from a source code POV),
and test to see if the performance is acceptable under load.  If it is,
don't bother trying to optimize.

...Marvin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191108132521.bkrbxj2lv7wpinuo%40basil.wdw.

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

[Robert Engels]

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 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 concurrent writes.
> 
> If you have far more reads than writes: Use a RWMutex, otherwise
> a Mutex probably is fine. The trick here: Experiment and measure.
> 
> You can synchronise on the Bar-level or on the level of individual Foos.
> Or you can group lets say N Foos together and synchronise on the
> level of these groups. The trick here: Experiment and measure.
> 
> So it boils down to: What is your access pattern? Make several
> experiments which simulate this pattern and measure. Then decide
> on "the best".
> 
> V.
>  
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e8fd2954-6b46-4337-8564-16e3f771098d%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F3D828C7-8DC4-4887-8BA1-9B8115E7690A%40ix.netcom.com.

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

[Volker Dobler]

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 concurrent writes.

If you have far more reads than writes: Use a RWMutex, otherwise
a Mutex probably is fine. The trick here: Experiment and measure.

You can synchronise on the Bar-level or on the level of individual Foos.
Or you can group lets say N Foos together and synchronise on the
level of these groups. The trick here: Experiment and measure.

So it boils down to: What is your access pattern? Make several
experiments which simulate this pattern and measure. Then decide
on "the best".

V.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e8fd2954-6b46-4337-8564-16e3f771098d%40googlegroups.com.