Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[roger peppe]

On Mon, 24 Aug 2020 at 06:35, Denis Cheremisov 
wrote:

> I probably didn't read what you have wrote in the first message carefuly
> enough. Does it mean something like that will work
>
> type SomeTypes interface {
> type int, float32, float64
> }
>
> func Min[T SomeTypes](x, y T) T {
> switch T {
> case int:
> if x < y {
> return x
> }
> return y
> case float32:
> return math.Min(float64(x), float64(y))
> case float64:
> return math.Min(x, y)
> }
> }
>

This was discussed above.

I don't believe you can do that. I didn't see any suggestion that knowing
the type implies the ability
to convert from the generic type to the known underlying type.

>
> Would something like below work as well?
>
> type Compare[T any] interface {
> Compare(x, y T) int
> }
>
> type CompareConstraints[T any] {
> type int, int8, …, float64, string, Compare[T]
> }
>
> func Min[T CompareConstraints]Min(x, y T) bool {
> switch T {
> case int:
> …
> …
> case Compare[T]:
> return x.Compare(y) < 0
> }
> }
>

No. As proposed, the type switch doesn't change anything about the type T.

Also, AIUI that type list wouldn't be very useful in practice, because
using that interface type in the type list would only allow types whose
underlying type is exactly Compare[T], which doesn't include any
non-interface types or interface types that have more methods than just
Compare.

  cheers,
rog.

-- 
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/CAJhgachjLex%3DUNP_trPy55mNcn3iXNePYE8pFOuA1oLa2GJ9Xw%40mail.gmail.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

I probably didn't read what you have wrote in the first message carefuly 
enough. Does it mean something like that will work

type SomeTypes interface {
type int, float32, float64
}

func Min[T SomeTypes](x, y T) T {
switch T {
case int:
if x < y {
return x
}
return y
case float32:
return math.Min(float64(x), float64(y))
case float64:
return math.Min(x, y)
}
}

Would something like below work as well?

type Compare[T any] interface {
Compare(x, y T) int
}

type CompareConstraints[T any] {
type int, int8, …, float64, string, Compare[T]
}

func Min[T CompareConstraints]Min(x, y T) bool {
switch T {
case int:
…
…
case Compare[T]:
return x.Compare(y) < 0
}
}

понедельник, 24 августа 2020 г. в 06:40:52 UTC+3, Ian Lance Taylor: 

> On Sun, Aug 23, 2020 at 3:00 PM Juliusz Chroboczek  wrote:
> >
> > > We’re going to permit type switches on type parameters that have type
> > > lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> > > clarify code like “switch v := x.(type)”.
> >
> > Could you please give an example of the proposed syntax?
>
> func F[T constraints.Integer]() {
> switch T {
> case int:
> case int8:
> }
> }
>
> 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/4e9391f0-f688-4189-8822-39fc8e217b70n%40googlegroups.com.

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

[alex . besogonov]

Can we at least move with the https://github.com/golang/go/issues/22729 , 
please? Anything will help with the current mess.

On Sunday, August 23, 2020 at 8:52:30 PM UTC-7, Ian Lance Taylor wrote:
>
> On Sun, Aug 23, 2020 at 1:16 PM Denis Cheremisov 
> > wrote: 
> > 
> > You may use something like this 
> > 
> > value2 := 
> *(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer(&value)) + 8)) 
> > if value2 == 0 { 
> > return true 
> > } 
> > 
> > on AMD64, should work also for any 64 bit architecture (at least I 
> believe so). Remember though this is hacky and may stop working once. 
>
> You could do that, but please don't. 
>
> Ian 
>
>
> > воскресенье, 23 августа 2020 г. в 22:58:51 UTC+3, Aviv Eyal: 
> >> 
> >> I was trying to show that the current behavior is confusing and that 
> fmt.Print() needing to resort to panic-and-recover is kinda code smell, but 
> I sorts-of convinced myself that the current behavior is right, or at least 
> consistent. 
> >> 
> >> In my code, I got bit because I sometimes use v *Type to denote "I may 
> or may not have a value here" (where Type is a value-type). 
> >> This is probably a bad practice on my behalf, because I break the 
> Liskov substitution principle: there is a value of `*Type` that is not a 
> valid value of `Type`, and I let this value slip by. 
> >> 
> >> In this case, `v Type` implements Stringer (i.e. valid callee for 
> `v.String()`, but `v *Type`, in the strictest sense, does not. 
> >> The only reason we can write: 
> >> 
> >> func (Type) String() string {...} 
> >> v *Type = &Type{...} 
> >> _ = v.String() 
> >> 
> >> and have it compile, is syntactic sugar: `v` gets implicitly 
> de-referenced, and there's an implicit assumption that it's not nil. 
> >> And there's a matching syntactic sugar for converting `Type` to a 
> `*Type`. 
> >> 
> >> So, In the code: 
> >> 
> >> func (Type) String() string {...} 
> >> 
> >> v *Type = nil 
> >> r interface{} = v 
> >> _, ok = r.(Stringer) 
> >> 
> >> What I really want to ask is "Can I, at runtime, call r.String()?", 
> whereas the question Go answers is "Is any of `r`, `*r`, or `&r` defines 
> .String()?" - which matches the static semantics of `r.String()`. 
> >> 
> >> So, while I should probably not use *Type as a replacement for 
> Optional, I think it might make sense to have some operator that can 
> determine, at run-time, if a call `r.String()` is valid (including a 
> nil-check). 
> >> 
> >> 
> >> -- Aviv 
> >> 
> >> On Saturday, April 11, 2020 at 4:48:28 PM UTC+3 ren...@ix.netcom.com 
> wrote: 
> >>> 
> >>> I agree with the OP. The usefulness of nil interfaces is pretty 
> limited. Show me a useful case that cant easily be implemented with non-nil 
> interfaces. 
> >>> 
> >>> I would argue that allowing nil interfaces causes more subtle latent 
> bugs and makes it harder to reason about the correctness of code when 
> reviewing it. 
> >>> 
> >>> It just feels wrong. I realize I’m probably in the minority here but 
> the OP is not alone. 
> >>> 
> >>> On Apr 11, 2020, at 8:20 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote: 
> >>> 
> >>> On Fri, Apr 10, 2020 at 7:17 PM  wrote: 
>  
>  I realize I'm reviving an age-old discussion here and apologize for 
> bringing up the undead. I happend to run into this when my application 
> panicked when some interfaces where initialized with nil mock objects 
> instead of being left uninitialized as in production mode. 
> >>> 
> >>> 
> >>> Let's imagine a world in which `foo == nil` also is true if `foo` is 
> an interface-value containing a nil-pointer. Let's say in this world, 
> someone sends a message to golang-nuts. They wrote a mock for the same 
> code. And since it's just a mock, they just returned static value from its 
> methods and didn't need to care if the pointer was nil or not. They are 
> confused, because the passed in this mock, but the code just assumed the 
> field was uninitialized and never called into their mock. What would you 
> tell them? Why is their confusion less valid? 
> >>> 
>  This would be an example where a nil implementing fooer is never 
> caught: 
>  
>  type fooer interface { 
>   foo() 
>  } 
>  
>  type other struct{} 
>  
>  func (o *other) foo() {} // implement fooer 
>  
>  func main() { 
>   var f fooer 
>  
>   var p *other // nil 
>   f = p // it is a fooer so I can assign it 
>  
>   if f == nil { 
>  // will not get here 
>   } 
>  } 
>  
>  
>  My confusion comes from the point that the nil interface is 
> apparently not "a nil-pointer with the correct method set" while *other is 
> even if nil. 
> >>> 
> >>> 
> >>> In the code you posted, even a nil *other is a perfectly fine 
> implementation of fooer. You can call `(*other)(nil).foo()` without any 
> problems. 
> >>> So, as you illustrated, calling methods on a nil-pointe

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

[Ian Lance Taylor]

On Sun, Aug 23, 2020 at 1:16 PM Denis Cheremisov
 wrote:
>
> You may use something like this
>
> value2 := *(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer(&value)) + 
> 8))
> if value2 == 0 {
> return true
> }
>
> on AMD64, should work also for any 64 bit architecture (at least I believe 
> so). Remember though this is hacky and may stop working once.

You could do that, but please don't.

Ian


> воскресенье, 23 августа 2020 г. в 22:58:51 UTC+3, Aviv Eyal:
>>
>> I was trying to show that the current behavior is confusing and that 
>> fmt.Print() needing to resort to panic-and-recover is kinda code smell, but 
>> I sorts-of convinced myself that the current behavior is right, or at least 
>> consistent.
>>
>> In my code, I got bit because I sometimes use v *Type to denote "I may or 
>> may not have a value here" (where Type is a value-type).
>> This is probably a bad practice on my behalf, because I break the Liskov 
>> substitution principle: there is a value of `*Type` that is not a valid 
>> value of `Type`, and I let this value slip by.
>>
>> In this case, `v Type` implements Stringer (i.e. valid callee for 
>> `v.String()`, but `v *Type`, in the strictest sense, does not.
>> The only reason we can write:
>>
>> func (Type) String() string {...}
>> v *Type = &Type{...}
>> _ = v.String()
>>
>> and have it compile, is syntactic sugar: `v` gets implicitly de-referenced, 
>> and there's an implicit assumption that it's not nil.
>> And there's a matching syntactic sugar for converting `Type` to a `*Type`.
>>
>> So, In the code:
>>
>> func (Type) String() string {...}
>>
>> v *Type = nil
>> r interface{} = v
>> _, ok = r.(Stringer)
>>
>> What I really want to ask is "Can I, at runtime, call r.String()?", whereas 
>> the question Go answers is "Is any of `r`, `*r`, or `&r` defines .String()?" 
>> - which matches the static semantics of `r.String()`.
>>
>> So, while I should probably not use *Type as a replacement for 
>> Optional, I think it might make sense to have some operator that can 
>> determine, at run-time, if a call `r.String()` is valid (including a 
>> nil-check).
>>
>>
>> -- Aviv
>>
>> On Saturday, April 11, 2020 at 4:48:28 PM UTC+3 ren...@ix.netcom.com wrote:
>>>
>>> I agree with the OP. The usefulness of nil interfaces is pretty limited. 
>>> Show me a useful case that cant easily be implemented with non-nil 
>>> interfaces.
>>>
>>> I would argue that allowing nil interfaces causes more subtle latent bugs 
>>> and makes it harder to reason about the correctness of code when reviewing 
>>> it.
>>>
>>> It just feels wrong. I realize I’m probably in the minority here but the OP 
>>> is not alone.
>>>
>>> On Apr 11, 2020, at 8:20 AM, 'Axel Wagner' via golang-nuts 
>>>  wrote:
>>>
>>> On Fri, Apr 10, 2020 at 7:17 PM  wrote:

 I realize I'm reviving an age-old discussion here and apologize for 
 bringing up the undead. I happend to run into this when my application 
 panicked when some interfaces where initialized with nil mock objects 
 instead of being left uninitialized as in production mode.
>>>
>>>
>>> Let's imagine a world in which `foo == nil` also is true if `foo` is an 
>>> interface-value containing a nil-pointer. Let's say in this world, someone 
>>> sends a message to golang-nuts. They wrote a mock for the same code. And 
>>> since it's just a mock, they just returned static value from its methods 
>>> and didn't need to care if the pointer was nil or not. They are confused, 
>>> because the passed in this mock, but the code just assumed the field was 
>>> uninitialized and never called into their mock. What would you tell them? 
>>> Why is their confusion less valid?
>>>
 This would be an example where a nil implementing fooer is never caught:

 type fooer interface {
  foo()
 }

 type other struct{}

 func (o *other) foo() {} // implement fooer

 func main() {
  var f fooer

  var p *other // nil
  f = p // it is a fooer so I can assign it

  if f == nil {
 // will not get here
  }
 }


 My confusion comes from the point that the nil interface is apparently not 
 "a nil-pointer with the correct method set" while *other is even if nil.
>>>
>>>
>>> In the code you posted, even a nil *other is a perfectly fine 
>>> implementation of fooer. You can call `(*other)(nil).foo()` without any 
>>> problems.
>>> So, as you illustrated, calling methods on a nil-pointer can be totally 
>>> fine. A nil-interface, OTOH, doesn't have any methods to call, as it 
>>> doesn't contain a dynamic value. If you write `(*other)(nil).foo()`, it is 
>>> completely clear what code gets called - even if that code *might* panic. 
>>> If you write `fooer(nil).foo()`, what code should be called in your opinion?
>>>
>>> I think it's easy to see that a nil-interface and a nil-pointer stored in 
>>> an interface are very different thin

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Ian Lance Taylor]

On Sun, Aug 23, 2020 at 3:00 PM Juliusz Chroboczek  wrote:
>
> > We’re going to permit type switches on type parameters that have type
> > lists, without the “.(type)” syntax.  The “(.type)” syntax exists to
> > clarify code like “switch v := x.(type)”.
>
> Could you please give an example of the proposed syntax?

func F[T constraints.Integer]() {
switch T {
case int:
case int8:
}
}

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/CAOyqgcU0yWcRd4FwfUnshwLVeZBR7DN1ZBe0rzLBaSRg4UVJpQ%40mail.gmail.com.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Juliusz Chroboczek]

> We’re going to permit type switches on type parameters that have type
> lists, without the “.(type)” syntax.  The “(.type)” syntax exists to
> clarify code like “switch v := x.(type)”.

Could you please give an example of the proposed syntax?

-- 
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/87sgcdowez.fsf%40pirx.irif.fr.

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

[Denis Cheremisov]

You may use something like this

*value2 := 
*(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer(&value)) + 8))*
*if value2 == 0 {*
*return true*
*}*

on AMD64, should work also for any 64 bit architecture (at least I believe 
so). Remember though this is hacky and may stop working once.


воскресенье, 23 августа 2020 г. в 22:58:51 UTC+3, Aviv Eyal: 

> I was trying to show that the current behavior is confusing and that 
> fmt.Print() needing to resort to panic-and-recover is kinda code smell, but 
> I sorts-of convinced myself that the current behavior is right, or at least 
> consistent.
>
> In my code, I got bit because I sometimes use v *Type to denote "I may or 
> may not have a value here" (where Type is a value-type). 
> This is probably a bad practice on my behalf, because I break the Liskov 
> substitution principle: there is a value of `*Type` that is not a valid 
> value of `Type`, and I let this value slip by.
>
> In this case, `v Type` implements Stringer (i.e. valid callee for 
> `v.String()`, but `v *Type`, in the strictest sense, does not.
> The only reason we can write:
>
> func (Type) String() string {...}
> v *Type = &Type{...}
> _ = v.String()
>
> and have it compile, is syntactic sugar: `v` gets implicitly 
> de-referenced, and there's an implicit assumption that it's not nil.
> And there's a matching syntactic sugar for converting `Type` to a `*Type`.
>
> So, In the code:
>
> func (Type) String() string {...}
>
> v *Type = nil
> r interface{} = v
> _, ok = r.(Stringer)
>
> What I really want to ask is "Can I, at runtime, call r.String()?", 
> whereas the question Go answers is "Is any of `r`, `*r`, or `&r` defines 
> .String()?" - which matches the static semantics of `r.String()`.
>
> So, while I should probably not use *Type as a replacement for 
> Optional, I think it might make sense to have some operator that can 
> determine, at run-time, if a call `r.String()` is valid (including a 
> nil-check).
>
>
> -- Aviv
>
> On Saturday, April 11, 2020 at 4:48:28 PM UTC+3 ren...@ix.netcom.com 
> wrote:
>
>> I agree with the OP. The usefulness of nil interfaces is pretty limited. 
>> Show me a useful case that cant easily be implemented with non-nil 
>> interfaces. 
>>
>> I would argue that allowing nil interfaces causes more subtle latent bugs 
>> and makes it harder to reason about the correctness of code when reviewing 
>> it. 
>>
>> It just feels wrong. I realize I’m probably in the minority here but the 
>> OP is not alone. 
>>
>> On Apr 11, 2020, at 8:20 AM, 'Axel Wagner' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>> On Fri, Apr 10, 2020 at 7:17 PM  wrote:
>>
>>> I realize I'm reviving an age-old discussion here and apologize for 
>>> bringing up the undead. I happend to run into this when my application 
>>> panicked when some interfaces where initialized with nil mock objects 
>>> instead of being left uninitialized as in production mode.
>>>
>>
>> Let's imagine a world in which `foo == nil` also is true if `foo` is an 
>> interface-value containing a nil-pointer. Let's say in this world, someone 
>> sends a message to golang-nuts. They wrote a mock for the same code. And 
>> since it's just a mock, they just returned static value from its methods 
>> and didn't need to care if the pointer was nil or not. They are confused, 
>> because the passed in this mock, but the code just assumed the field was 
>> uninitialized and never called into their mock. What would you tell them? 
>> Why is their confusion less valid?
>>
>> This would be an example where a nil implementing fooer is never caught:
>>>
>>> type fooer interface {
>>>  foo()
>>> }
>>>
>>> type other struct{}
>>>
>>> func (o *other) foo() {} // implement fooer
>>>
>>> func main() {
>>>  var f fooer
>>>
>>>  var p *other // nil
>>>  f = p // it is a fooer so I can assign it
>>>
>>>  if f == nil {
>>> // will not get here
>>>  }
>>> }
>>>
>>>
>>> My confusion comes from the point that the nil interface is apparently 
>>> not "a nil-pointer with the correct method set" while *other is even if nil.
>>>
>>
>> In the code you posted, even a nil *other is a perfectly fine 
>> implementation of fooer. You can call `(*other)(nil).foo()` without any 
>> problems.
>> So, as you illustrated, calling methods on a nil-pointer can be totally 
>> fine. A nil-interface, OTOH, doesn't have any methods to call, as it 
>> doesn't contain a dynamic value. If you write `(*other)(nil).foo()`, it is 
>> completely clear what code gets called - even if that code *might* panic. 
>> If you write `fooer(nil).foo()`, what code should be called in your opinion?
>>
>> I think it's easy to see that a nil-interface and a nil-pointer stored in 
>> an interface are very different things. Even from first principles, without 
>> deep knowledge of the language. And if they are obviously different, I 
>> don't understand why you'd find it confusing that they are not the same in 

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

[Aviv Eyal]

I was trying to show that the current behavior is confusing and that 
fmt.Print() needing to resort to panic-and-recover is kinda code smell, but 
I sorts-of convinced myself that the current behavior is right, or at least 
consistent.

In my code, I got bit because I sometimes use v *Type to denote "I may or 
may not have a value here" (where Type is a value-type). 
This is probably a bad practice on my behalf, because I break the Liskov 
substitution principle: there is a value of `*Type` that is not a valid 
value of `Type`, and I let this value slip by.

In this case, `v Type` implements Stringer (i.e. valid callee for 
`v.String()`, but `v *Type`, in the strictest sense, does not.
The only reason we can write:

func (Type) String() string {...}
v *Type = &Type{...}
_ = v.String()

and have it compile, is syntactic sugar: `v` gets implicitly de-referenced, 
and there's an implicit assumption that it's not nil.
And there's a matching syntactic sugar for converting `Type` to a `*Type`.

So, In the code:

func (Type) String() string {...}

v *Type = nil
r interface{} = v
_, ok = r.(Stringer)

What I really want to ask is "Can I, at runtime, call r.String()?", whereas 
the question Go answers is "Is any of `r`, `*r`, or `&r` defines 
.String()?" - which matches the static semantics of `r.String()`.

So, while I should probably not use *Type as a replacement for 
Optional, I think it might make sense to have some operator that can 
determine, at run-time, if a call `r.String()` is valid (including a 
nil-check).


-- Aviv

On Saturday, April 11, 2020 at 4:48:28 PM UTC+3 ren...@ix.netcom.com wrote:

> I agree with the OP. The usefulness of nil interfaces is pretty limited. 
> Show me a useful case that cant easily be implemented with non-nil 
> interfaces. 
>
> I would argue that allowing nil interfaces causes more subtle latent bugs 
> and makes it harder to reason about the correctness of code when reviewing 
> it. 
>
> It just feels wrong. I realize I’m probably in the minority here but the 
> OP is not alone. 
>
> On Apr 11, 2020, at 8:20 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> On Fri, Apr 10, 2020 at 7:17 PM  wrote:
>
>> I realize I'm reviving an age-old discussion here and apologize for 
>> bringing up the undead. I happend to run into this when my application 
>> panicked when some interfaces where initialized with nil mock objects 
>> instead of being left uninitialized as in production mode.
>>
>
> Let's imagine a world in which `foo == nil` also is true if `foo` is an 
> interface-value containing a nil-pointer. Let's say in this world, someone 
> sends a message to golang-nuts. They wrote a mock for the same code. And 
> since it's just a mock, they just returned static value from its methods 
> and didn't need to care if the pointer was nil or not. They are confused, 
> because the passed in this mock, but the code just assumed the field was 
> uninitialized and never called into their mock. What would you tell them? 
> Why is their confusion less valid?
>
> This would be an example where a nil implementing fooer is never caught:
>>
>> type fooer interface {
>>  foo()
>> }
>>
>> type other struct{}
>>
>> func (o *other) foo() {} // implement fooer
>>
>> func main() {
>>  var f fooer
>>
>>  var p *other // nil
>>  f = p // it is a fooer so I can assign it
>>
>>  if f == nil {
>> // will not get here
>>  }
>> }
>>
>>
>> My confusion comes from the point that the nil interface is apparently 
>> not "a nil-pointer with the correct method set" while *other is even if nil.
>>
>
> In the code you posted, even a nil *other is a perfectly fine 
> implementation of fooer. You can call `(*other)(nil).foo()` without any 
> problems.
> So, as you illustrated, calling methods on a nil-pointer can be totally 
> fine. A nil-interface, OTOH, doesn't have any methods to call, as it 
> doesn't contain a dynamic value. If you write `(*other)(nil).foo()`, it is 
> completely clear what code gets called - even if that code *might* panic. 
> If you write `fooer(nil).foo()`, what code should be called in your opinion?
>
> I think it's easy to see that a nil-interface and a nil-pointer stored in 
> an interface are very different things. Even from first principles, without 
> deep knowledge of the language. And if they are obviously different, I 
> don't understand why you'd find it confusing that they are not the same in 
> this particular manner.
>
> The above is a case where that might happen. In can be worked around but 
>> it is unexpected unless the programmer is deeply rooted in the language 
>> definition.
>>
>
> I fully agree with that. What I *don't* agree with, is where you attribute 
> the problem here. You say, the problem is that the nil-check is 
> ill-behaved. I say that - if anything - the original nil-assignment is 
> ill-behaved. Having `(fooer)((*other)(nil)) == nil` be true is semantically 
> wrong, because by checking against `nil`,

[go-nuts] Is this behavior by textproto.Writer.DotWriter correct?

[Jonathan]

When a DotWriter is created and closed without any write being done, the 
buffer contains a CR/LF . CR/LF. When a DotWriter is created and closed 
with a single write of an empty line, the buffer also contains CR/LF . 
CR/LF. See:
https://play.golang.org/p/ScXaRPBH7vI

This seems wrong to me.  If it isn't I think the documentation should note 
this.

Jonathan

-- 
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/689bbe79-e9f4-472e-8391-567c767a6e11n%40googlegroups.com.

Re: [go-nuts] Mysterious RSS memory spike

[Mike Spreitzer]

BTW, how are you measuring RSS?  That is a trick all by itself!  See 
https://groups.google.com/g/golang-nuts/c/LsOYrYc_Occ/m/LbjLAsL6BwAJ

Regards,
Mike

golang-nuts@googlegroups.com wrote on 08/23/2020 11:04:47 AM:

> From: Manish R Jain 
> To: "golang-nuts" 
> Date: 08/23/2020 11:04 AM
> Subject: [EXTERNAL] [go-nuts] Mysterious RSS memory spike
> Sent by: golang-nuts@googlegroups.com
> 
> Hey Gophers,
> 
> I'm puzzled by a mysterious RSS memory spike in my Go program, when 
> all memory allocations are happening via Cgo. I assert that there 
> are no memory leaks in the program. And have written another C 
> program with similar logic which does NOT show RSS memory spiking. 
> So, I suspect this is something to do with Go memory.
> 
> Program:
> 
> https://github.com/dgraph-io/ristretto/pull/186
> 
> This PR creates a Go memtest program, which does this:
> - Uses z.Calloc and z.Free to allocate Go struct (S) and a byte 
> slice inside it. All allocations are happening in Cgo, and being 
> type casted into Go. No allocations are happening in Go (except a 32
> MB fill slice).
> - z.NumAllocBytes is tracking memory allocated and freed by these calls.
> - Increases memory usage to 16 GB (as reported by z.NumAllocBytes).
> - Decreases it back to 1 GB.
> - Repeats this cycle.
> - On Ctrl+C, it deallocates everything and asserts that Cgo memory 
> allocated is zero.
> 
> I was concerned about memory fragmentation, so created a very 
> similar C program which does the same thing (memtestc).
> 
> Please feel free to run either of the Go or C programs. They should 
> compile and run easily.
> 
> Behavior:
> 
> Run the program with: `go build . && ./memtest` . Go pprof heap 
> shows 32 MB used, to account for the fill slice. However, RSS 
> reported keeps roughly increasing every cycle.
> 
> I'm using Go 1.14.4 and on it, RSS jumps to 22GB after a few cycles. 
> memtestc (C equivalent, compiled with gcc) does not show this 
> behavior. The RSS goes down to 1GB-ish every cycle.
> 
> Any clues why the RSS is much higher than expected in Go and keeps 
> climbing in Go?
> 
> ?
> Manish
> Founder, https://dgraph.io
> [image removed] 
> -- 
> 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/a592db0482f1843c694a9486379a47dd%40frontapp.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/OFD256528A.E55B2BFE-ON852585CD.00651CB3-852585CD.0065262F%40notes.na.collabserv.com.

Re: [go-nuts] Re: basics of understanding golang memory usage

[Mike Spreitzer]

BTW, how are you measuring RSS?  That is a trick in and of itself!

https://groups.google.com/g/golang-nuts/c/LsOYrYc_Occ/m/LbjLAsL6BwAJ

Regards,
Mike

golang-nuts@googlegroups.com wrote on 08/18/2020 01:56:30 AM:

> From: Mike Spreitzer 
> To: golang-nuts 
> Date: 08/18/2020 01:56 AM
> Subject: [EXTERNAL] [go-nuts] Re: basics of understanding golang memory 
usage
> Sent by: golang-nuts@googlegroups.com
> 
> I collected data on an example program from four angles.  See 
> https://docs.google.com/document/d/
> 1KUz7IjnD93X2VTVkRAhhNa7rHScCaIH8GLrsoaDIW_g for the raw data and my
> puny attempts to correlate the four views.  There are some exact 
> equalities, some near matches, some gross differences in things that
> seem like they should be the same, and things I wasn't able to match
> in any way.  This begs lots of questions.
> 
> Why is memory.usage_in_bytes from cgroups so much smaller than the 
> other top-line measurements?  What is statm.size counting that the 
> coredump "all" is not?
> 
> I assume that the text part of the connection-agent binary is 
> shared.  Why is the readonly data part of the connection-agent 
> binary _not_ shared?
> 
> What is statm.data counting that MemStats.Sys is not?
> 
> Why is MemStats.HeapIdle so much bigger than the coredump's heap free 
spans?
> Why is MemStats.heapReleased so much bigger than the coredump's 
heapreleased?
> In MemStats, (HeapIdle - HeapReleased) = 1,490,944
> In coredump, (heap free spans) - (heap released) = 1,613,824 --- not
> so very different.  What is making the roughly 52 MB difference 
> between MemStats and the coredump?
> 
> Why is the bss in the coredump so huge?  Does it correspond to 
> anything in any of the other views?
> 
> What do the three big anonymous blocks in the procfs view correpond 
> to in the other views?
> 
> Thanks,
> Mike
> 
> -- 
> 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/7c44fbd8-976a-4bfa-acf4-fa4a0d6bad35o%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/OFA58CB7B7.2124468F-ON852585CD.0064FE8B-852585CD.006514F7%40notes.na.collabserv.com.

RE: [go-nuts] Debug http calls made using go http client

[Mike Spreitzer]

Krishna can put a use of TCPMon or tcpdump inside the Kubernetes Pod. 
Either of these things can be added to the main container, or put in 
another container in the Pod.

Regards,
Mike

golang-nuts@googlegroups.com wrote on 08/23/2020 01:06:20 PM:

> From: "Tamás Gulácsi" 
> To: golang-nuts 
> Date: 08/23/2020 01:06 PM
> Subject: [EXTERNAL] Re: [go-nuts] Debug http calls made using go http 
client
> Sent by: golang-nuts@googlegroups.com
> 
> You can print every step with net/http/httptrace 's ClientTrace.

> krishna...@gmail.com a következőt írta (2020. augusztus 23., 
> vasárnap, 15:55:50 UTC+2):
> Hello Dimas,
> 
> Thank you for your response. My application is running in a 
> kubernetes cluster and I will not be able to run TCPMon or TCPDump 
> separately, as access is restricted. I was looking for something 
> that can be embedded within the go application.
> 
> Regards,
> Krishna
> 
> On Sun, Aug 23, 2020 at 7:13 PM Dimas Prawira  
wrote:
> There are several tools which you can use to help to inspect, 
> 
> 1. TCPmon, is a java-based tool for inspecting http call in between 
> server and client. TCPmon also can be used to simulate slow connection. 
> 
> Work mechanism of TCPmon is as a proxy. So if I describe it as below
> 
> [Your apps] ---> [tcpmon] ---> [server]
> 
> 2. TCPdump, is a linux app which can be use to dump TCP connection 
> in and out. This can be help to inspect HTTP request / HTTP come to 
> the server.
> 
> 3. Traceroute
> You may want to inspect / trace connection from your server to 
> vendor's server using traceroute, maybe the problem is in the 
connection.
> 
> Hope that's helpful
> 
> On Sat, Aug 22, 2020, 01:59 krishna...@gmail.com  
wrote:
> Hello Gophers,
> 
> I am making multiple http calls from my go application to an 
> external vendor's http server using the go standard http client. 
> I've set a 10 second timeout for my context. Everything works fine. 
> 
> However, I get random timeouts in my application due to these HTTP 
> calls. On further investigation, I found that the http calls to the 
> vendor's server take longer than 10 seconds. 
> During this period of timeouts, the vendor says they've not received
> any HTTP requests. How do I verify that the http requests are made 
> from my app? If the requests are made from my app, how can I figure 
> out what's causing the delay?
> 
> I tried debugging using the HTTP client trace, but couldn't find any
> actionable information. Any suggestions on how to debug/fix this issue ?
> 
> Thanks
> - Krishna 
> -- 
> 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/2d454dda-6670-48ef-85a2-0a42216dcd29n%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/72972301-5163-4dfd-8886-1ed2b8efadc4n%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/OFBF44A5F2.6B132B86-ON852585CD.00648478-852585CD.0064AEF2%40notes.na.collabserv.com.

Re: [go-nuts] how golang choose instructions?

[Ian Lance Taylor]

On Sat, Aug 22, 2020 at 10:31 PM xie cui  wrote:
>
> we can find same dynamic programming algorithm(like BURS bottom rewriting 
> system), to choose instructions in book about compiler technique. but as far 
> as i know, it seems that golang just transform ast to ssa IR, then lower to 
> machine instruction. how i find the min cost of instructions?

I believe that instruction cost is implicitly encoded in the rules
that appear in the cmd/compile/internal/ssa/gen directory.  The rules
only list the instruction choices that seem best.  As far as I know
the gc compiler does not trade off between register allocation and
instruction selection, but I don't know everything that it does.

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/CAOyqgcXLda70UR340GWFf3yKn3aZBbv74KR7zhMcbCo7LnfmCA%40mail.gmail.com.

Re: [go-nuts] Debug http calls made using go http client

[Tamás Gulácsi]

You can print every step with net/http/httptrace 's ClientTrace.

krishna...@gmail.com a következőt írta (2020. augusztus 23., vasárnap, 
15:55:50 UTC+2):

> Hello Dimas,
>
> Thank you for your response. My application is running in a kubernetes 
> cluster and I will not be able to run TCPMon or TCPDump separately, as 
> access is restricted. I was looking for something that can be embedded 
> within the go application.
>
> Regards,
> *Krishna*
>
>
>
> On Sun, Aug 23, 2020 at 7:13 PM Dimas Prawira  
> wrote:
>
>> There are several tools which you can use to help to inspect, 
>>
>> 1. TCPmon, is a java-based tool for inspecting http call in between 
>> server and client. TCPmon also can be used to simulate slow connection. 
>>
>> Work mechanism of TCPmon is as a proxy. So if I describe it as below
>>
>> [Your apps] ---> [tcpmon] ---> [server]
>>
>> 2. TCPdump, is a linux app which can be use to dump TCP connection in and 
>> out. This can be help to inspect HTTP request / HTTP come to the server.
>>
>> 3. Traceroute
>> You may want to inspect / trace connection from your server to vendor's 
>> server using traceroute, maybe the problem is in the connection.
>>
>> Hope that's helpful
>>
>> On Sat, Aug 22, 2020, 01:59 krishna...@gmail.com  
>> wrote:
>>
>>> Hello Gophers,
>>>
>>> I am making multiple http calls from my go application to an external 
>>> vendor's http server using the go standard http client. I've set a 10 
>>> second timeout for my context. Everything works fine. 
>>>
>>> However, I get random timeouts in my application due to these HTTP 
>>> calls. On further investigation, I found that the http calls to the 
>>> vendor's server take longer than 10 seconds. 
>>> During this period of timeouts, the vendor says they've not received any 
>>> HTTP requests. How do I verify that the http requests are made from my app? 
>>> If the requests are made from my app, how can I figure out what's causing 
>>> the delay?
>>>
>>> I tried debugging using the HTTP client trace, but couldn't find any 
>>> actionable information. Any suggestions on how to debug/fix this issue ?
>>>
>>> Thanks
>>> - Krishna 
>>>
>>> -- 
>>> 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/2d454dda-6670-48ef-85a2-0a42216dcd29n%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/72972301-5163-4dfd-8886-1ed2b8efadc4n%40googlegroups.com.

[go-nuts] Mysterious RSS memory spike

[Manish R Jain]

Hey Gophers,


I'm puzzled by a mysterious RSS memory spike in my Go program, when all memory 
allocations are happening via Cgo. I assert that there are no memory leaks in 
the program. And have written another C program with similar logic which does 
NOT show RSS memory spiking. So, I suspect this is something to do with Go 
memory.



Program:


https://github.com/dgraph-io/ristretto/pull/186


This PR creates a Go memtest program, which does this:
- Uses z.Calloc and z.Free to allocate Go struct (S) and a byte slice inside 
it. All allocations are happening in Cgo, and being type casted into Go. No 
allocations are happening in Go (except a 32 MB fill slice).
- z.NumAllocBytes is tracking memory allocated and freed by these calls.
- Increases memory usage to 16 GB (as reported by z.NumAllocBytes).
- Decreases it back to 1 GB.
- Repeats this cycle.
- On Ctrl+C, it deallocates everything and asserts that Cgo memory allocated is 
zero.


I was concerned about memory fragmentation, so created a very similar C program 
which does the same thing (memtestc).


Please feel free to run either of the Go or C programs. They should compile and 
run easily.


Behavior:


Run the program with: `go build . && ./memtest` . Go pprof heap shows 32 MB 
used, to account for the fill slice. However, RSS reported keeps roughly 
increasing every cycle.


I'm using Go 1.14.4 and on it, RSS jumps to 22GB after a few cycles. memtestc 
(C equivalent, compiled with gcc) does not show this behavior. The RSS goes 
down to 1GB-ish every cycle.


Any clues why the RSS is much higher than expected in Go and keeps climbing in 
Go?

—
Manish
Founder, https://dgraph.io

-- 
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/a592db0482f1843c694a9486379a47dd%40frontapp.com.

Re: [go-nuts] Debug http calls made using go http client

[Krishna Kowshik]

Hello Dimas,

Thank you for your response. My application is running in a kubernetes
cluster and I will not be able to run TCPMon or TCPDump separately, as
access is restricted. I was looking for something that can be embedded
within the go application.

Regards,
*Krishna*



On Sun, Aug 23, 2020 at 7:13 PM Dimas Prawira 
wrote:

> There are several tools which you can use to help to inspect,
>
> 1. TCPmon, is a java-based tool for inspecting http call in between server
> and client. TCPmon also can be used to simulate slow connection.
>
> Work mechanism of TCPmon is as a proxy. So if I describe it as below
>
> [Your apps] ---> [tcpmon] ---> [server]
>
> 2. TCPdump, is a linux app which can be use to dump TCP connection in and
> out. This can be help to inspect HTTP request / HTTP come to the server.
>
> 3. Traceroute
> You may want to inspect / trace connection from your server to vendor's
> server using traceroute, maybe the problem is in the connection.
>
> Hope that's helpful
>
> On Sat, Aug 22, 2020, 01:59 krishna...@gmail.com <
> krishna.kows...@gmail.com> wrote:
>
>> Hello Gophers,
>>
>> I am making multiple http calls from my go application to an external
>> vendor's http server using the go standard http client. I've set a 10
>> second timeout for my context. Everything works fine.
>>
>> However, I get random timeouts in my application due to these HTTP calls.
>> On further investigation, I found that the http calls to the vendor's
>> server take longer than 10 seconds.
>> During this period of timeouts, the vendor says they've not received any
>> HTTP requests. How do I verify that the http requests are made from my app?
>> If the requests are made from my app, how can I figure out what's causing
>> the delay?
>>
>> I tried debugging using the HTTP client trace, but couldn't find any
>> actionable information. Any suggestions on how to debug/fix this issue ?
>>
>> Thanks
>> - Krishna
>>
>> --
>> 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/2d454dda-6670-48ef-85a2-0a42216dcd29n%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/CABmZoo9RUuFpRZWWjUWbRnS3BK01BQ3a5a_CsKwiB_9kcJg9Mg%40mail.gmail.com.

Re: [go-nuts] Debug http calls made using go http client

[Dimas Prawira]

There are several tools which you can use to help to inspect,

1. TCPmon, is a java-based tool for inspecting http call in between server
and client. TCPmon also can be used to simulate slow connection.

Work mechanism of TCPmon is as a proxy. So if I describe it as below

[Your apps] ---> [tcpmon] ---> [server]

2. TCPdump, is a linux app which can be use to dump TCP connection in and
out. This can be help to inspect HTTP request / HTTP come to the server.

3. Traceroute
You may want to inspect / trace connection from your server to vendor's
server using traceroute, maybe the problem is in the connection.

Hope that's helpful

On Sat, Aug 22, 2020, 01:59 krishna...@gmail.com 
wrote:

> Hello Gophers,
>
> I am making multiple http calls from my go application to an external
> vendor's http server using the go standard http client. I've set a 10
> second timeout for my context. Everything works fine.
>
> However, I get random timeouts in my application due to these HTTP calls.
> On further investigation, I found that the http calls to the vendor's
> server take longer than 10 seconds.
> During this period of timeouts, the vendor says they've not received any
> HTTP requests. How do I verify that the http requests are made from my app?
> If the requests are made from my app, how can I figure out what's causing
> the delay?
>
> I tried debugging using the HTTP client trace, but couldn't find any
> actionable information. Any suggestions on how to debug/fix this issue ?
>
> Thanks
> - Krishna
>
> --
> 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/2d454dda-6670-48ef-85a2-0a42216dcd29n%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/CA%2Bp%2BMUckb_ThhNw4%3Dxbz%3D9v0yJEXAX0CbP4CE5x0VziL5hFDSw%40mail.gmail.com.

[go-nuts] Re: [modules] List available only patch upgrades

[Jérôme LAFORGE]

Hello,
I have just created this issue:
https://github.com/golang/go/issues/40990

Regards,
Jérôme

Le vendredi 14 août 2020 19:21:20 UTC+2, Jérôme LAFORGE a écrit :
>
> Hello Gophers,
>
> I want to list modules available only for available only patch upgrades.
> The given example here 
> https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies
>  is 
> for direct with minor and patch (I just want patch)
>
> I want use this in my CI with https://github.com/psampaz/go-mod-outdated.
>
> Many thx
> Regards,
> Jérôme
>

-- 
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/2d2ababb-25c6-413a-9d82-e47b41f7ebbco%40googlegroups.com.