Re: [go-nuts] Library for printing a struct as a compiler recognized version

[John]

Thank you everyone who responded.  Gave utter a look and its pretty 
decent.  I found litter a bit more developed around the circular reference 
area.  But both were great suggestions and just what I was looking for.

Again, thank you for helping me find these!

On Monday, August 15, 2022 at 3:59:05 PM UTC-7 kortschak wrote:

> On Mon, 2022-08-15 at 07:26 -0700, John wrote:
> > I know we have plenty of pretty printing out there, but i'm looking
> > for a package that can print the Go representation of a Struct out to
> > screen.
> >
> > So given:
> >
> > var x := {
> >   A: "hello"
> > }
> >
> > someLib.Print(x)
> >
> > I get:
> >
> > {
> >   A: "hello"
> > }
> >
> > I'm sure someone has used reflection to do this and figured out how
> > they want to deal with recursive pointers, so don't want to go
> > recreate the wheel here.
> >
> > Thanks.
>
> github.com/kortschak/utter will do this for most values (there are
> cases that are not possible due to requiring programmatic construction
> — pointers to strings, ints etc, and filled channels being examples).
>
> Dan
>
>

-- 
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/666011b3-d5ed-4528-9a41-e626ac84ab8bn%40googlegroups.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

['Dan Kortschak' via golang-nuts]

On Mon, 2022-08-15 at 07:26 -0700, John wrote:
> I know we have plenty of pretty printing out there, but i'm looking
> for a package that can print the Go representation of a Struct out to
> screen.
>
> So given:
>
> var x := {
>   A: "hello"
> }
>
> someLib.Print(x)
>
> I get:
>
> {
>   A: "hello"
> }
>
> I'm sure someone has used reflection to do this and figured out how
> they want to deal with recursive pointers, so don't want to go
> recreate the wheel here.
>
> Thanks.

github.com/kortschak/utter will do this for most values (there are
cases that are not possible due to requiring programmatic construction
— pointers to strings, ints etc, and filled channels being examples).

Dan

-- 
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/ed0ddac2db3db8fdccfedb252bdc66ef29685c80.camel%40kortschak.io.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

[jake...@gmail.com]

On Monday, August 15, 2022 at 5:20:58 AM UTC-4 ma...@changkun.de wrote:

> > Any other reading, to me, is trying to find an ambiguity for the sole 
> sake of finding an ambiguity. 
>
> A reader does not have to be motivated to find ambiguity. If the 
> sentence can be interpreted with different meanings, other readers may 
> perceive it differently. To me, the first read of this sentence is 
> perceived to be ambiguous regarding a single location or multiple 
> locations. The posted example discusses a and b as two memory 
> locations. 
>
> Atomic operations on a and b are two different statements. It remains 
> unclear where exactly is the sentence that tries to say this: atomic 
> operations on different memory locations obey the program statements 
> order within a goroutine. 
>

Doesn't the Section on Atomics  statement 
say just that:

The APIs in the sync/atomic  package are 
collectively “atomic operations” that can be used to synchronize the 
execution of different goroutines. If the effect of an atomic operation *A* 
is observed by atomic operation *B*, then *A* is synchronized before *B*. 
All the atomic operations executed in a program behave as though executed 
in some sequentially consistent order.  

Is your confusion about the term "observed"?
 

-- 
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/3a266d04-db5c-4e16-bf1e-3ea6c7a98168n%40googlegroups.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

[Ian Davis]

Perhaps https://github.com/kortschak/utter might suit your needs?

On Mon, 15 Aug 2022, at 4:07 PM, John wrote:
> Hey axel,
> 
> I recognize the problem space you are discussing. There are a couple 
> strategies I could implement to try and solve the problems.  And I'm not 100% 
> sure you can solve all of them.  But I certainly don't want to jump down the 
> rabbit hole of reflection myself if I don't have to.  So I'm looking for a 
> package that has attempted to do this.  I'd certainly take something that 
> can't handle every case.
> 
> So far my googlefoo hasn't found the key words that differentiate this from 
> pretty printing, or this type of package doesn't exist.
> 
> Thanks for your response axel.
> 
> 
> 
> On Monday, August 15, 2022 at 7:53:16 AM UTC-7 axel.wa...@googlemail.com 
> wrote:
>> I don't believe this is possible, in general. For example, consider
>> 
>> type S struct {
>> A *int
>> B *int
>> }
>> var x S
>> x.A = new(int)
>> x.B = x.A
>> 
>> There is no single expression for the value of x. Or
>> 
>> type P *P
>> x := new(P)
>> *x = x
>> 
>> Then you have values which represent more than just their plain memory 
>> resources. For example, an *os.File - restoring that would not give you the 
>> same thing.
>> 
>> There's lots of design space here and I don't think you can solve it in full 
>> generality. So, at the very least, you have to be very deliberate about what 
>> you want and what you are willing to give up.
>> 
>> But. Maybe someone else has suggestions for a library doing an approximation 
>> of this you'd like better.
>> 
>> 
>> 
>> On Mon, Aug 15, 2022 at 4:42 PM John  wrote:
>>> Hey axel,
>>> 
>>> Thanks for the reply, but unfortunately not. Because that is going to 
>>> simply print pointer values out.  I want it to unwind all of that (and 
>>> handle the difficulty of recursive references).  I want to be able to take 
>>> what is printed and simply paste it into a file assigned to a variable, add 
>>> the needed imports and have it compile.
>>> On Monday, August 15, 2022 at 7:34:08 AM UTC-7 axel.wa...@googlemail.com 
>>> wrote:
 Does fmt.Printf("%#v", v) do what you want?
 
 
 On Mon, Aug 15, 2022 at 4:27 PM John  wrote:
> I know we have plenty of pretty printing out there, but i'm looking for a 
> package that can print the Go representation of a Struct out to screen.
> 
> So given:
> 
> var x := {
>   A: "hello"
> }
> 
> someLib.Print(x)
> 
> I get:
> 
> {
>   A: "hello"
> }
> 
> I'm sure someone has used reflection to do this and figured out how they 
> want to deal with recursive pointers, so don't want to go recreate the 
> wheel here.
> 
> Thanks.
> 
> 
> 
> 
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/f4fa3f7b-318e-407b-96ef-16102db1e037n%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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/2029ba81-dbf5-44c2-ac9f-228dcb7837f4n%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/0e2af167-4bad-49a1-8a12-e5218204b47fn%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/bf70fe87-7d83-4b28-9401-3ef846def9be%40www.fastmail.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

[John]

Hey axel,

I recognize the problem space you are discussing. There are a couple 
strategies I could implement to try and solve the problems.  And I'm not 
100% sure you can solve all of them.  But I certainly don't want to jump 
down the rabbit hole of reflection myself if I don't have to.  So I'm 
looking for a package that has attempted to do this.  I'd certainly take 
something that can't handle every case.

So far my googlefoo hasn't found the key words that differentiate this from 
pretty printing, or this type of package doesn't exist.

Thanks for your response axel.



On Monday, August 15, 2022 at 7:53:16 AM UTC-7 axel.wa...@googlemail.com 
wrote:

> I don't believe this is possible, in general. For example, consider
>
> type S struct {
> A *int
> B *int
> }
> var x S
> x.A = new(int)
> x.B = x.A
>
> There is no single expression for the value of x. Or
>
> type P *P
> x := new(P)
> *x = x
>
> Then you have values which represent more than just their plain memory 
> resources. For example, an *os.File - restoring that would not give you the 
> same thing.
>
> There's lots of design space here and I don't think you can solve it in 
> full generality. So, at the very least, you have to be very deliberate 
> about what you want and what you are willing to give up.
>
> But. Maybe someone else has suggestions for a library doing an 
> approximation of this you'd like better.
>
>
> On Mon, Aug 15, 2022 at 4:42 PM John  wrote:
>
>> Hey axel,
>>
>> Thanks for the reply, but unfortunately not. Because that is going to 
>> simply print pointer values out.  I want it to unwind all of that (and 
>> handle the difficulty of recursive references).  I want to be able to take 
>> what is printed and simply paste it into a file assigned to a variable, add 
>> the needed imports and have it compile.
>>
>> On Monday, August 15, 2022 at 7:34:08 AM UTC-7 axel.wa...@googlemail.com 
>> wrote:
>>
>>> Does fmt.Printf("%#v", v) do what you want?
>>>
>>> On Mon, Aug 15, 2022 at 4:27 PM John  wrote:
>>>
 I know we have plenty of pretty printing out there, but i'm looking for 
 a package that can print the Go representation of a Struct out to screen.

 So given:

 var x := {
   A: "hello"
 }

 someLib.Print(x)

 I get:

 {
   A: "hello"
 }

 I'm sure someone has used reflection to do this and figured out how 
 they want to deal with recursive pointers, so don't want to go recreate 
 the 
 wheel here.

 Thanks.


 -- 
 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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/f4fa3f7b-318e-407b-96ef-16102db1e037n%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/2029ba81-dbf5-44c2-ac9f-228dcb7837f4n%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/0e2af167-4bad-49a1-8a12-e5218204b47fn%40googlegroups.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

[John]

Hey axel,

Thanks for the reply, but unfortunately not. Because that is going to 
simply print pointer values out.  I want it to unwind all of that (and 
handle the difficulty of recursive references).  I want to be able to take 
what is printed and simply paste it into a file assigned to a variable, add 
the needed imports and have it compile.

On Monday, August 15, 2022 at 7:34:08 AM UTC-7 axel.wa...@googlemail.com 
wrote:

> Does fmt.Printf("%#v", v) do what you want?
>
> On Mon, Aug 15, 2022 at 4:27 PM John  wrote:
>
>> I know we have plenty of pretty printing out there, but i'm looking for a 
>> package that can print the Go representation of a Struct out to screen.
>>
>> So given:
>>
>> var x := {
>>   A: "hello"
>> }
>>
>> someLib.Print(x)
>>
>> I get:
>>
>> {
>>   A: "hello"
>> }
>>
>> I'm sure someone has used reflection to do this and figured out how they 
>> want to deal with recursive pointers, so don't want to go recreate the 
>> wheel here.
>>
>> Thanks.
>>
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f4fa3f7b-318e-407b-96ef-16102db1e037n%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/2029ba81-dbf5-44c2-ac9f-228dcb7837f4n%40googlegroups.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

['Axel Wagner' via golang-nuts]

Does fmt.Printf("%#v", v) do what you want?

On Mon, Aug 15, 2022 at 4:27 PM John  wrote:

> I know we have plenty of pretty printing out there, but i'm looking for a
> package that can print the Go representation of a Struct out to screen.
>
> So given:
>
> var x := {
>   A: "hello"
> }
>
> someLib.Print(x)
>
> I get:
>
> {
>   A: "hello"
> }
>
> I'm sure someone has used reflection to do this and figured out how they
> want to deal with recursive pointers, so don't want to go recreate the
> wheel here.
>
> Thanks.
>
>
> --
> 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/f4fa3f7b-318e-407b-96ef-16102db1e037n%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/CAEkBMfHnEbgaGEqh7_k-p%3DO%3D_PA8gVtQpV9TQCO%3D0zTP4%3DUhmQ%40mail.gmail.com.

[go-nuts] Library for printing a struct as a compiler recognized version

[John]

I know we have plenty of pretty printing out there, but i'm looking for a 
package that can print the Go representation of a Struct out to screen.

So given:

var x := {
  A: "hello"
}

someLib.Print(x)

I get:

{
  A: "hello"
}

I'm sure someone has used reflection to do this and figured out how they 
want to deal with recursive pointers, so don't want to go recreate the 
wheel here.

Thanks.


-- 
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/f4fa3f7b-318e-407b-96ef-16102db1e037n%40googlegroups.com.

[go-nuts] Application Monitoring

[Rich]

My company relies heavily on Java., Java apps we run require Introscope or 
Glowroot to monitor them and many outages have been solved using those 
tools.  If we were to write our apps in Go -- would we need an application 
monitoring tool, or would standard Linux tools suffice?

Thanks-- Rich

-- 
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/f65a5920-3dde-495b-bc87-0e14f2512e86n%40googlegroups.com.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

['Axel Wagner' via golang-nuts]

If you *want* to read the Memory model that way and write your programs
accordingly, you are free to do so.
I think you'll find that consistently applying that logic will make it
impossible to write correct concurrent programs sharing memory though.

For example, the section about locks . In
that snippet, `l` and `a` are in different memory locations, so under your
reading of the memory model, it would be valid to arbitrarily reorder those
operations. However

The first call to l.Unlock() (in f) is synchronized before the second call
> to l.Lock() (in main) returns, *which is sequenced before the print.*


(emphasis mine).

It is unambiguously clear that the memory model makes the assumption that
within a single goroutine, execution must be consistent with source-order
of statements. Every single section demonstrating synchronization
primitives contains at least one occurrence of such an assumption.

I refuse to believe that you even actually believe your supposed
interpretation of the memory model yourself. But if you do, fine. You are
unnecessarily hamstringing yourself, in my opinion. But that's your
prerogative.

On Mon, Aug 15, 2022 at 11:20 AM Changkun Ou  wrote:

> > Any other reading, to me, is trying to find an ambiguity for the sole
> sake of finding an ambiguity.
>
> A reader does not have to be motivated to find ambiguity. If the
> sentence can be interpreted with different meanings, other readers may
> perceive it differently. To me, the first read of this sentence is
> perceived to be ambiguous regarding a single location or multiple
> locations. The posted example discusses a and b as two memory
> locations.
>
> Atomic operations on a and b are two different statements. It remains
> unclear where exactly is the sentence that tries to say this: atomic
> operations on different memory locations obey the program statements
> order within a goroutine.


> On Mon, Aug 15, 2022 at 10:16 AM Axel Wagner
>
>
>
>
>
>  wrote:
> >
> > On Mon, Aug 15, 2022 at 10:02 AM Changkun Ou  wrote:
> >>
> >> > The memory operations in each goroutine must correspond to a correct
> sequential execution of that goroutine, given the values read from and
> written to memory. That execution must be consistent with the sequenced
> before relation, defined as the partial order requirements set out by the
> Go language specification for Go's control flow constructs as well as the
> order of evaluation for expressions.
> >>
> >> This rule seems a bit unclear in its wording to me. These questions may
> occur:
> >> 1. What does it mean by "a correct sequential execution"? What defines
> >> correct in this case? Is it implied by the variables' written order?
> >>
> >> 2. Is the rule applicable to multiple variables by written order or
> >> only on different variables separately?
> >
> >
> > I think this is trying to pick nits. The rule seems very clear in its
> intended outcome: A single goroutine should behave as if executing each
> statement sequentially, and obeying the spec about order of evaluation
> within a statement.
> >
> > Any other reading, to me, is trying to find an ambiguity for the sole
> sake of finding an ambiguity. Generally, the Go spec and the memory model
> as well doesn't try to be tricky just to be tricky. It expects the reader
> to apply a certain amount of common sense and biasing themselves towards
> the most sensible reading.
> >
> >> In lines 13 and 14's goroutine, it seems there is no control flow or
> >> any given language spec required order of execution. The most relaxing
> >> requirement: permit the compiler to switch the statement.
> >>
> >>
> >> On Mon, Aug 15, 2022 at 9:32 AM Axel Wagner
> >>  wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Aug 15, 2022 at 9:06 AM Changkun Ou  wrote:
> >> >>
> >> >> I think the new memory model does not guarantee this program always
> prints 1:
> >> >>
> >> >> 1. There is no synchronization guarantee between line 13 and line 14
> >> >> as these atomic operations are manipulated on the different memory
> >> >> locations.
> >> >
> >> >
> >> > Yes, there is:
> >> >>
> >> >> The memory operations in each goroutine must correspond to a correct
> sequential execution of that goroutine, given the values read from and
> written to memory. That execution must be consistent with the sequenced
> before relation, defined as the partial order requirements set out by the
> Go language specification for Go's control flow constructs as well as the
> order of evaluation for expressions.
> >> >
> >> >
> >> >> 2. It is *not* prohibited for the compiler to switch line 13 and line
> >> >> 14 (as I read from section https://go.dev/ref/mem#badcompiler)
> because
> >> >> of the above reason, and also, there is no order between line 13 and
> >> >> line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
> >> >> 3. Depending on the memory layout of a and b, if they are on the same
> >> >> cache line, then the program will always print 1.
> >> >>
> 

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

[Changkun Ou]

> Any other reading, to me, is trying to find an ambiguity for the sole sake of 
> finding an ambiguity.

A reader does not have to be motivated to find ambiguity. If the
sentence can be interpreted with different meanings, other readers may
perceive it differently. To me, the first read of this sentence is
perceived to be ambiguous regarding a single location or multiple
locations. The posted example discusses a and b as two memory
locations.

Atomic operations on a and b are two different statements. It remains
unclear where exactly is the sentence that tries to say this: atomic
operations on different memory locations obey the program statements
order within a goroutine.

On Mon, Aug 15, 2022 at 10:16 AM Axel Wagner





 wrote:
>
> On Mon, Aug 15, 2022 at 10:02 AM Changkun Ou  wrote:
>>
>> > The memory operations in each goroutine must correspond to a correct 
>> > sequential execution of that goroutine, given the values read from and 
>> > written to memory. That execution must be consistent with the sequenced 
>> > before relation, defined as the partial order requirements set out by the 
>> > Go language specification for Go's control flow constructs as well as the 
>> > order of evaluation for expressions.
>>
>> This rule seems a bit unclear in its wording to me. These questions may 
>> occur:
>> 1. What does it mean by "a correct sequential execution"? What defines
>> correct in this case? Is it implied by the variables' written order?
>>
>> 2. Is the rule applicable to multiple variables by written order or
>> only on different variables separately?
>
>
> I think this is trying to pick nits. The rule seems very clear in its 
> intended outcome: A single goroutine should behave as if executing each 
> statement sequentially, and obeying the spec about order of evaluation within 
> a statement.
>
> Any other reading, to me, is trying to find an ambiguity for the sole sake of 
> finding an ambiguity. Generally, the Go spec and the memory model as well 
> doesn't try to be tricky just to be tricky. It expects the reader to apply a 
> certain amount of common sense and biasing themselves towards the most 
> sensible reading.
>
>> In lines 13 and 14's goroutine, it seems there is no control flow or
>> any given language spec required order of execution. The most relaxing
>> requirement: permit the compiler to switch the statement.
>>
>>
>> On Mon, Aug 15, 2022 at 9:32 AM Axel Wagner
>>  wrote:
>> >
>> >
>> >
>> > On Mon, Aug 15, 2022 at 9:06 AM Changkun Ou  wrote:
>> >>
>> >> I think the new memory model does not guarantee this program always 
>> >> prints 1:
>> >>
>> >> 1. There is no synchronization guarantee between line 13 and line 14
>> >> as these atomic operations are manipulated on the different memory
>> >> locations.
>> >
>> >
>> > Yes, there is:
>> >>
>> >> The memory operations in each goroutine must correspond to a correct 
>> >> sequential execution of that goroutine, given the values read from and 
>> >> written to memory. That execution must be consistent with the sequenced 
>> >> before relation, defined as the partial order requirements set out by the 
>> >> Go language specification for Go's control flow constructs as well as the 
>> >> order of evaluation for expressions.
>> >
>> >
>> >> 2. It is *not* prohibited for the compiler to switch line 13 and line
>> >> 14 (as I read from section https://go.dev/ref/mem#badcompiler) because
>> >> of the above reason, and also, there is no order between line 13 and
>> >> line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
>> >> 3. Depending on the memory layout of a and b, if they are on the same
>> >> cache line, then the program will always print 1.
>> >>
>> >>
>> >> On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts
>> >>  wrote:
>> >> >
>> >> > Why wouldn't it?
>> >> >>
>> >> >> If the effect of an atomic operation A is observed by atomic operation 
>> >> >> B, then A is synchronized before B.
>> >> >
>> >> > To me, it seems pretty clear that it will. Line 13 is synchronized 
>> >> > before line 14, which is synchronized before any load observing its 
>> >> > effects (i.e. any execution of line 18 which runs into the branch) - 
>> >> > and such a load is synchronized before the load in line 20.
>> >> >
>> >> > Therefore, the store in Line 13 is synchronized before the load in line 
>> >> > 20.
>> >> >
>> >> >
>> >> > On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com  
>> >> > wrote:
>> >> >>
>> >> >> By the latest version of Go Memory Model article: 
>> >> >> https://go.dev/ref/mem, will the following program always print 1?
>> >> >>
>> >> >> https://go.dev/play/p/RICYGip5y8M
>> >> >>
>> >> >> --
>> >> >> 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 
>> >> >> 

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

['Axel Wagner' via golang-nuts]

On Mon, Aug 15, 2022 at 10:02 AM Changkun Ou  wrote:

> > The memory operations in each goroutine must correspond to a correct
> sequential execution of that goroutine, given the values read from and
> written to memory. That execution must be consistent with the sequenced
> before relation, defined as the partial order requirements set out by the
> Go language specification for Go's control flow constructs as well as the
> order of evaluation for expressions.
>
> This rule seems a bit unclear in its wording to me. These questions may
> occur:
> 1. What does it mean by "a correct sequential execution"? What defines
> correct in this case? Is it implied by the variables' written order?

2. Is the rule applicable to multiple variables by written order or
> only on different variables separately?
>

I think this is trying to pick nits. The rule seems very clear in its
intended outcome: A single goroutine should behave as if executing each
statement sequentially, and obeying the spec about order of evaluation
within a statement .

Any other reading, to me, is trying to find an ambiguity for the sole sake
of finding an ambiguity. Generally, the Go spec and the memory model as
well doesn't try to be tricky just to be tricky. It expects the reader to
apply a certain amount of common sense and biasing themselves towards the
most sensible reading.

In lines 13 and 14's goroutine, it seems there is no control flow or
> any given language spec required order of execution. The most relaxing
> requirement: permit the compiler to switch the statement.
>
>
> On Mon, Aug 15, 2022 at 9:32 AM Axel Wagner
>  wrote:
> >
> >
> >
> > On Mon, Aug 15, 2022 at 9:06 AM Changkun Ou  wrote:
> >>
> >> I think the new memory model does not guarantee this program always
> prints 1:
> >>
> >> 1. There is no synchronization guarantee between line 13 and line 14
> >> as these atomic operations are manipulated on the different memory
> >> locations.
> >
> >
> > Yes, there is:
> >>
> >> The memory operations in each goroutine must correspond to a correct
> sequential execution of that goroutine, given the values read from and
> written to memory. That execution must be consistent with the sequenced
> before relation, defined as the partial order requirements set out by the
> Go language specification for Go's control flow constructs as well as the
> order of evaluation for expressions.
> >
> >
> >> 2. It is *not* prohibited for the compiler to switch line 13 and line
> >> 14 (as I read from section https://go.dev/ref/mem#badcompiler) because
> >> of the above reason, and also, there is no order between line 13 and
> >> line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
> >> 3. Depending on the memory layout of a and b, if they are on the same
> >> cache line, then the program will always print 1.
> >>
> >>
> >> On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts
> >>  wrote:
> >> >
> >> > Why wouldn't it?
> >> >>
> >> >> If the effect of an atomic operation A is observed by atomic
> operation B, then A is synchronized before B.
> >> >
> >> > To me, it seems pretty clear that it will. Line 13 is synchronized
> before line 14, which is synchronized before any load observing its effects
> (i.e. any execution of line 18 which runs into the branch) - and such a
> load is synchronized before the load in line 20.
> >> >
> >> > Therefore, the store in Line 13 is synchronized before the load in
> line 20.
> >> >
> >> >
> >> > On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com <
> tapir@gmail.com> wrote:
> >> >>
> >> >> By the latest version of Go Memory Model article:
> https://go.dev/ref/mem, will the following program always print 1?
> >> >>
> >> >> https://go.dev/play/p/RICYGip5y8M
> >> >>
> >> >> --
> >> >> 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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%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/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%40mail.gmail.com
> .
>
>
>
> --
> Changkun Ou (he/him/his)
> München, Deutschland
> https://changkun.de/
>

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

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

[tapi...@gmail.com]

I tend to think it should print 1, as well this one: 
https://go.dev/play/p/bax7CoaSV1d


On Monday, August 15, 2022 at 3:34:35 PM UTC+8 tapi...@gmail.com wrote:

> It would be good if the Memory Model article shows some atomic examples.
>
> On Monday, August 15, 2022 at 3:06:58 PM UTC+8 ma...@changkun.de wrote:
>
>> I think the new memory model does not guarantee this program always 
>> prints 1:
>>
>> 1. There is no synchronization guarantee between line 13 and line 14
>> as these atomic operations are manipulated on the different memory
>> locations.
>> 2. It is *not* prohibited for the compiler to switch line 13 and line
>> 14 (as I read from section https://go.dev/ref/mem#badcompiler) because
>> of the above reason, and also, there is no order between line 13 and
>> line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
>> 3. Depending on the memory layout of a and b, if they are on the same
>> cache line, then the program will always print 1.
>>
>>
>> On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts
>>  wrote:
>> >
>> > Why wouldn't it?
>> >>
>> >> If the effect of an atomic operation A is observed by atomic operation 
>> B, then A is synchronized before B.
>> >
>> > To me, it seems pretty clear that it will. Line 13 is synchronized 
>> before line 14, which is synchronized before any load observing its effects 
>> (i.e. any execution of line 18 which runs into the branch) - and such a 
>> load is synchronized before the load in line 20.
>> >
>> > Therefore, the store in Line 13 is synchronized before the load in line 
>> 20.
>> >
>> >
>> > On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com  
>> wrote:
>> >>
>> >> By the latest version of Go Memory Model article: 
>> https://go.dev/ref/mem, will the following program always print 1?
>> >>
>> >> https://go.dev/play/p/RICYGip5y8M
>> >>
>> >> --
>> >> 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...@googlegroups.com.
>> >> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/4d9b8130-d06c-4519-9b99-d161e922d8f6n%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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%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/0ea1f1a1-fee3-4c2a-8dcb-f7bbbc946812n%40googlegroups.com.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

[Changkun Ou]

> The memory operations in each goroutine must correspond to a correct 
> sequential execution of that goroutine, given the values read from and 
> written to memory. That execution must be consistent with the sequenced 
> before relation, defined as the partial order requirements set out by the Go 
> language specification for Go's control flow constructs as well as the order 
> of evaluation for expressions.

This rule seems a bit unclear in its wording to me. These questions may occur:
1. What does it mean by "a correct sequential execution"? What defines
correct in this case? Is it implied by the variables' written order?
2. Is the rule applicable to multiple variables by written order or
only on different variables separately?

In lines 13 and 14's goroutine, it seems there is no control flow or
any given language spec required order of execution. The most relaxing
requirement: permit the compiler to switch the statement.


On Mon, Aug 15, 2022 at 9:32 AM Axel Wagner
 wrote:
>
>
>
> On Mon, Aug 15, 2022 at 9:06 AM Changkun Ou  wrote:
>>
>> I think the new memory model does not guarantee this program always prints 1:
>>
>> 1. There is no synchronization guarantee between line 13 and line 14
>> as these atomic operations are manipulated on the different memory
>> locations.
>
>
> Yes, there is:
>>
>> The memory operations in each goroutine must correspond to a correct 
>> sequential execution of that goroutine, given the values read from and 
>> written to memory. That execution must be consistent with the sequenced 
>> before relation, defined as the partial order requirements set out by the Go 
>> language specification for Go's control flow constructs as well as the order 
>> of evaluation for expressions.
>
>
>> 2. It is *not* prohibited for the compiler to switch line 13 and line
>> 14 (as I read from section https://go.dev/ref/mem#badcompiler) because
>> of the above reason, and also, there is no order between line 13 and
>> line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
>> 3. Depending on the memory layout of a and b, if they are on the same
>> cache line, then the program will always print 1.
>>
>>
>> On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts
>>  wrote:
>> >
>> > Why wouldn't it?
>> >>
>> >> If the effect of an atomic operation A is observed by atomic operation B, 
>> >> then A is synchronized before B.
>> >
>> > To me, it seems pretty clear that it will. Line 13 is synchronized before 
>> > line 14, which is synchronized before any load observing its effects (i.e. 
>> > any execution of line 18 which runs into the branch) - and such a load is 
>> > synchronized before the load in line 20.
>> >
>> > Therefore, the store in Line 13 is synchronized before the load in line 20.
>> >
>> >
>> > On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com  
>> > wrote:
>> >>
>> >> By the latest version of Go Memory Model article: https://go.dev/ref/mem, 
>> >> will the following program always print 1?
>> >>
>> >> https://go.dev/play/p/RICYGip5y8M
>> >>
>> >> --
>> >> 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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%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/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%40mail.gmail.com.



--
Changkun Ou (he/him/his)
München, Deutschland
https://changkun.de/

-- 
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/CAGrj7%2BKqOk2s6EB%3Dd%2B-xocGFcmyuK95o-TuG%3DAo7-cPf%3D02Mcg%40mail.gmail.com.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

['Axel Wagner' via golang-nuts]

On Mon, Aug 15, 2022 at 9:06 AM Changkun Ou  wrote:

> I think the new memory model does not guarantee this program always prints
> 1:
>
> 1. There is no synchronization guarantee between line 13 and line 14
> as these atomic operations are manipulated on the different memory
> locations.
>

Yes, there is:

> The memory operations in each goroutine must correspond to a correct
> sequential execution of that goroutine, given the values read from and
> written to memory. That execution must be consistent with the sequenced
> before relation, defined as the partial order requirements set out by the
> Go language specification for Go's control flow constructs as well as the
> order of evaluation for expressions.


2. It is *not* prohibited for the compiler to switch line 13 and line
> 14 (as I read from section https://go.dev/ref/mem#badcompiler) because
> of the above reason, and also, there is no order between line 13 and
> line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
> 3. Depending on the memory layout of a and b, if they are on the same
> cache line, then the program will always print 1.
>
>
> On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts
>  wrote:
> >
> > Why wouldn't it?
> >>
> >> If the effect of an atomic operation A is observed by atomic operation
> B, then A is synchronized before B.
> >
> > To me, it seems pretty clear that it will. Line 13 is synchronized
> before line 14, which is synchronized before any load observing its effects
> (i.e. any execution of line 18 which runs into the branch) - and such a
> load is synchronized before the load in line 20.
> >
> > Therefore, the store in Line 13 is synchronized before the load in line
> 20.
> >
> >
> > On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com 
> wrote:
> >>
> >> By the latest version of Go Memory Model article:
> https://go.dev/ref/mem, will the following program always print 1?
> >>
> >> https://go.dev/play/p/RICYGip5y8M
> >>
> >> --
> >> 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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%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/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%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/CAEkBMfFn%2BtDgWi_YAMf5gD1Jtc0sBqJKXWidfYQSuTLUd9RUJg%40mail.gmail.com.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

[Changkun Ou]

I think the new memory model does not guarantee this program always prints 1:

1. There is no synchronization guarantee between line 13 and line 14
as these atomic operations are manipulated on the different memory
locations.
2. It is *not* prohibited for the compiler to switch line 13 and line
14 (as I read from section https://go.dev/ref/mem#badcompiler) because
of the above reason, and also, there is no order between line 13 and
line 20. So this is possible: line 14 < line 18 < line 20 < line 13.
3. Depending on the memory layout of a and b, if they are on the same
cache line, then the program will always print 1.


On Mon, Aug 15, 2022 at 8:48 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> Why wouldn't it?
>>
>> If the effect of an atomic operation A is observed by atomic operation B, 
>> then A is synchronized before B.
>
> To me, it seems pretty clear that it will. Line 13 is synchronized before 
> line 14, which is synchronized before any load observing its effects (i.e. 
> any execution of line 18 which runs into the branch) - and such a load is 
> synchronized before the load in line 20.
>
> Therefore, the store in Line 13 is synchronized before the load in line 20.
>
>
> On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com  wrote:
>>
>> By the latest version of Go Memory Model article: https://go.dev/ref/mem, 
>> will the following program always print 1?
>>
>> https://go.dev/play/p/RICYGip5y8M
>>
>> --
>> 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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%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/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%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/CAGrj7%2B%2BRZeMdnspKHK4yOKJ9eHka-B6jk_bhM5M95XbyamVC%3Dg%40mail.gmail.com.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

['Axel Wagner' via golang-nuts]

Why wouldn't it?

> If the effect of an atomic operation A is observed by atomic operation B,
> then A is synchronized before B.

To me, it seems pretty clear that it will. Line 13 is synchronized before
line 14, which is synchronized before any load observing its effects (i.e.
any execution of line 18 which runs into the branch) - and such a load is
synchronized before the load in line 20.

Therefore, the store in Line 13 is synchronized before the load in line 20.


On Mon, Aug 15, 2022 at 8:37 AM tapi...@gmail.com 
wrote:

> By the latest version of Go Memory Model article: https://go.dev/ref/mem,
> will the following program always print 1?
>
> https://go.dev/play/p/RICYGip5y8M
>
> --
> 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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%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/CAEkBMfHpwchwjAMtXNtpVmhb42Ncw9ENKhz5xH9Sv1z_-DMrRA%40mail.gmail.com.

[go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

[tapi...@gmail.com]

By the latest version of Go Memory Model article: https://go.dev/ref/mem, 
will the following program always print 1?

https://go.dev/play/p/RICYGip5y8M

-- 
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/4d9b8130-d06c-4519-9b99-d161e922d8f6n%40googlegroups.com.