Re: [go-nuts] Re: What's the maximum array length?

2022-10-29 Thread T L 
On Sat, Oct 29, 2022 at 12:11 PM Kurtis Rader  wrote:

Did you not see my reply pointing out the same thing? That is, given a
particular platform and executable format the limit is likely to be much
less than math.MaxInt. Alternatively, was my reply not clear about the
practical versus theoretical limit of the size of an array? Which is not to
say that your reply is invalid. I'm just curious how you view your reply as
being more clear than mine. :-)


> On Fri, Oct 28, 2022 at 8:57 PM tapi...@gmail.com 
> wrote:
>
>> The max array length is math.MaxInt. "[math.MaxInt]struct{}" is valid,
>> though the practical size of non-zero-size array is hard limited in some
>> way.
>>
>> On Friday, October 28, 2022 at 9:43:16 AM UTC+8 eric...@arm.com wrote:
>>
>>> The spec says that " The length is part of the array's type; it must
>>> evaluate to a non-negative constant 
>>> representable  by a value of
>>> type int. ", so on a 64-bit environment, I assume that the maximum array
>>> length should be math.MaxInt64, am I right ? But the following code doesn't
>>> compile:
>>>
>>> package main
>>> var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}
>>>
>> --
>> 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/df18462d-4ec1-4287-ad71-ef4aa0d85a5dn%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/CAHbs%3DNbmgsUet1GW4AbbBeOQ9xeUZd92ybb28L-m1O8-Ze3CtQ%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.19 average goroutine stack

2022-08-18 Thread T L 
On Thu, Aug 18, 2022 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Aug 18, 2022 at 10:34 AM T L  wrote:
>
> > When I investigate something, I ask questions in communities firstly, to
> save time.
>
> To save your time at the expense of more time wasted by others. Such
> an approach is rightfully frowned upon.
>
> Doing your own research first, asking about things where you got stuck
> next is fine.
>

It really wastes your time (and others') to make such an unnecessary and
impolite reply.

-- 
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/CAHbs%3DNbRKo5sV3PV_j44fLSmY%3DrifYxoBVD%3DSPo4j8LPAWUEPw%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.19 average goroutine stack

2022-08-18 Thread T L 
On Thu, Aug 18, 2022 at 11:30 AM Kurtis Rader  wrote:

> On Wed, Aug 17, 2022 at 8:18 PM tapi...@gmail.com 
> wrote:
>
>> I'm a bit wondering about how the following case will be affected by the
>> change:
>> 1. Initially, there is one goroutine, which stack size is large at the
>> time of a GC process.
>> 2. After the GC process, a large quantity of goroutines start. They all
>> need small stacks.
>>But now the runtime will allocate a very large stack for each of them.
>>
>> Then is much memory wasted? Will the stacks of the new goroutines shrink
>> at the next GC process?
>>
>
> I can't help but wonder why, if you care so much about this type of issue,
> you did not make any attempt to answer your own question? Why not assume
> the Go team is competent (thus handling your scenario in a reasonable, if
> not optimal, fashion) unless you have evidence to the contrary? Why didn't
> you take a few minutes to write a Go program to test your own hypothesis?
> Questions are great unless you make no attempt to answer your own question.
>
>
So you don't care so much about this type of issue? I wonder why you don't
care?

When I investigate something, I ask questions in communities firstly, to
save time.
For experts who understand the problem, it will spend them no much time to
make an answer.

I never denied the competentness of Go team.

I don't think I'm able to write a Go program to test in a few minutes.
In fact, this will be my last attempt and is why I asked the question here.
If you are able to, could you write one? I will be very appreciate it.


>
>
>> On Saturday, August 13, 2022 at 10:00:58 PM UTC+8 lia...@garena.com
>> wrote:
>>
>>> Hi masters,
>>>
>>> As far as I know, go 1.19 supports self-adaptive stack size when
>>> spawning a goroutine, which intends to decrease the calling times of
>>> morestack that aims to claim more frames from heap.
>>>
>>> After each GC happens, Go runtime will calculate the average stack usage
>>> and the next time, goroutine would created with such a stack size.
>>>
>>> My question is, how do we validate the whole process or check it if
>>> works well or not.
>>> Is there any metric or stack size checking function, or should I use
>>> pprof to peek the alloc part ?
>>>
>>> Kindly thanks for all
>>>
>>> ```
>>> func main() {
>>> go func() {
>>> // spawn a goroutine started from a fixed stack size
>>> }()
>>>
>>> runtime.GC()
>>>
>>> go func() {
>>> // spawn a goroutine started from an avg stack size.
>>> }()
>>> }
>>> ```
>>>
>>>
>>> --
>> 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/e922b755-8205-462b-91ed-b9391b6fa2b2n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

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

Re: [go-nuts] Is this a known problem?

2021-11-12 Thread T L 
On Fri, Nov 12, 2021 at 11:54 PM Axel Wagner 
wrote:

> Oh, sorry, I just re-read. Your example still requires `range` to return
> distinct types, so that probably shouldn't work.
>

Not this reason:

func Bar[T []byte|map[int]byte](s T) {
for i, v := range s { _, _ = i, v} // cannot range over s (variable of
type T constrained by []byte|map[int]byte) (type set has no single
underlying type)
}


>
> On Fri, Nov 12, 2021 at 4:52 PM Axel Wagner 
> wrote:
>
>> The error message gives you a reason - there is no single underlying
>> type. This works:
>>
>> type B []byte
>> func Bar[T []byte|B](s T) {
>> for range s {}
>> }
>>
>> But yes, your example arguably should be made to work eventually. I would
>> suggest filing an issue about that.
>>
>> On Fri, Nov 12, 2021 at 4:47 PM tapi...@gmail.com 
>> wrote:
>>
>>> This one doesn't compile either.
>>> So the range operation doesn't support values of parameter types?
>>>
>>> type MyByte byte
>>>
>>> func Bar[T []byte|[]MyByte](s T) {
>>> for range s {} // cannot range over s (variable of type T
>>> constrained by []byte|[]MyByte) (type set has no single underlying
>>> }
>>>
>>> On Friday, November 12, 2021 at 11:40:53 PM UTC+8
>>> axel.wa...@googlemail.com wrote:
>>>
 On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com 
 wrote:

> On Friday, November 12, 2021 at 11:10:17 PM UTC+8
> axel.wa...@googlemail.com wrote:
>
>> `range s` works differently for string and []byte. In the former case
>> it iterates over utf8-encoded unicode codepoints, in the latter it 
>> iterates
>> over bytes.
>>
>
> It is true, but why it matters here?
>

 Because it makes `range` different operations for the purposes of
 determining the allowed operations on a type-parameter.


>
>
>>
>> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com 
>> wrote:
>>
>>>
>>> func Bar[T []byte|string](s T) bool {
>>> for _, v := range s { // cannot range over s (variable of type T
>>> constrained by []byte|string) (T has no structural type)
>>> if v > 100 {
>>> return true
>>> }
>>> }
>>> return false
>>> }
>>>
>>> The message is quite confusing.
>>>
>>> --
>>> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%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/abd83194-8198-40e8-ad12-82953f85fba5n%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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%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/CAHbs%3DNb133_JRg%2BJCYsdSbZN24OM_pA1S92zY%2BKACEF8MC%3Da6g%40mail.gmail.com.

Re: [go-nuts] How the scopes of type parameters are defined?

2021-11-12 Thread T L 
This one compiles okay:

func Bar2[T any](x T) T {
   {
 var T = x // T redeclared in this block
 return T
   }
}

So the parameter type is declared at the local top block?


On Fri, Nov 12, 2021 at 9:43 PM T L  wrote:

> It is strange that my recent comments are deleted automatically if they
> are posted from the web interface.
> But now from the email interface.
>
> On Fri, Nov 12, 2021 at 9:40 PM T L  wrote:
>
>> Are the followings also intended?
>>
>> func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
>>return T // T (type) is not an expression
>> }
>>
>> func Bar[T any](x T) T {
>>var T = x // T redeclared in this block
>>return T
>> }
>>
>> On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>>
>>>
>>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>>>> axel.wa...@googlemail.com wrote:
>>>>
>>>>> I suspect this issue is hard/impossible to avoid, because it must be
>>>>> possible to self- and mutually reference type-parameters, in a way that
>>>>> it's not for normal parameters, to allow to write something like
>>>>>
>>>>> type Equaler[T any] interface {
>>>>> Equal(T) bool
>>>>> }
>>>>> func Eq[T Equaler[T]](a, b T) bool {
>>>>> return a.Equal(b)
>>>>> }
>>>>>
>>>>
>>>> I don't see the same problem here. "T" and "Equaler" are two different
>>>> identifiers.
>>>>
>>>
>>> But T and T are not.
>>>
>>> The point I was making is that type-parameters must inherently be scoped
>>> in a way that makes them visible in the type-list itself, to make writing
>>> code like this possible. This isn't necessary for regular parameters and
>>> it's what makes type-parameter lists special.
>>>
>>> I *also* said that it's probably possible to devise rules which would
>>> make this possible, while allowing the example you wrote, just that those
>>> rules would have to be complicated.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> or basically any use-case for constraint-type inference.
>>>>>
>>>>> Even if we *could* allow it consistently, the rules for doing that
>>>>> would likely be pretty complex. Better to take the relatively minor hit of
>>>>> disallowing this overloading (you can always use different names for the
>>>>> type-parameters, if they conflict with the constraint you want to use) 
>>>>> than
>>>>> to take the hit of complex scoping rules with lots of exceptions.
>>>>>
>>>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> I expect the following code compilers okay, but it doesn't.
>>>>>> It looks All the three "I" in the Bar function declaration are
>>>>>> viewed as the type parameter, whereas the second one is
>>>>>> expected as the constraint I (at least by me).
>>>>>>
>>>>>> package main
>>>>>>
>>>>>> type I interface { M() }
>>>>>>
>>>>>> func Foo(i I) {
>>>>>>   i.M()
>>>>>> }
>>>>>>
>>>>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>>>>>   i.M()
>>>>>> }
>>>>>>
>>>>>> func main() {}
>>>>>>
>>>>>> --
>>>>>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

-- 
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/CAHbs%3DNZVnhK2fV2R2NbtXvfsyV%3DfP1ToD0SoSBhf9%3Dr0d19gPg%40mail.gmail.com.

Re: [go-nuts] How the scopes of type parameters are defined?

2021-11-12 Thread T L 
It is strange that my recent comments are deleted automatically if they are
posted from the web interface.
But now from the email interface.

On Fri, Nov 12, 2021 at 9:40 PM T L  wrote:

> Are the followings also intended?
>
> func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
>return T // T (type) is not an expression
> }
>
> func Bar[T any](x T) T {
>var T = x // T redeclared in this block
>return T
> }
>
> On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner 
> wrote:
>
>>
>>
>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com 
>> wrote:
>>
>>>
>>>
>>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>>> axel.wa...@googlemail.com wrote:
>>>
>>>> I suspect this issue is hard/impossible to avoid, because it must be
>>>> possible to self- and mutually reference type-parameters, in a way that
>>>> it's not for normal parameters, to allow to write something like
>>>>
>>>> type Equaler[T any] interface {
>>>> Equal(T) bool
>>>> }
>>>> func Eq[T Equaler[T]](a, b T) bool {
>>>> return a.Equal(b)
>>>> }
>>>>
>>>
>>> I don't see the same problem here. "T" and "Equaler" are two different
>>> identifiers.
>>>
>>
>> But T and T are not.
>>
>> The point I was making is that type-parameters must inherently be scoped
>> in a way that makes them visible in the type-list itself, to make writing
>> code like this possible. This isn't necessary for regular parameters and
>> it's what makes type-parameter lists special.
>>
>> I *also* said that it's probably possible to devise rules which would
>> make this possible, while allowing the example you wrote, just that those
>> rules would have to be complicated.
>>
>>
>>>
>>>
>>>>
>>>> or basically any use-case for constraint-type inference.
>>>>
>>>> Even if we *could* allow it consistently, the rules for doing that
>>>> would likely be pretty complex. Better to take the relatively minor hit of
>>>> disallowing this overloading (you can always use different names for the
>>>> type-parameters, if they conflict with the constraint you want to use) than
>>>> to take the hit of complex scoping rules with lots of exceptions.
>>>>
>>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com 
>>>> wrote:
>>>>
>>>>> I expect the following code compilers okay, but it doesn't.
>>>>> It looks All the three "I" in the Bar function declaration are
>>>>> viewed as the type parameter, whereas the second one is
>>>>> expected as the constraint I (at least by me).
>>>>>
>>>>> package main
>>>>>
>>>>> type I interface { M() }
>>>>>
>>>>> func Foo(i I) {
>>>>>   i.M()
>>>>> }
>>>>>
>>>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>>>>   i.M()
>>>>> }
>>>>>
>>>>> func main() {}
>>>>>
>>>>> --
>>>>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/golang-nuts/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/CAHbs%3DNYm6EmC3G2fV77zUh7%3D6xUDj2fhuMAYO7iV2bTD6bkOfw%40mail.gmail.com.

Re: [go-nuts] How the scopes of type parameters are defined?

2021-11-12 Thread T L 
Are the followings also intended?

func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
   return T // T (type) is not an expression
}

func Bar[T any](x T) T {
   var T = x // T redeclared in this block
   return T
}

On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner 
wrote:

>
>
> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com 
> wrote:
>
>>
>>
>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> I suspect this issue is hard/impossible to avoid, because it must be
>>> possible to self- and mutually reference type-parameters, in a way that
>>> it's not for normal parameters, to allow to write something like
>>>
>>> type Equaler[T any] interface {
>>> Equal(T) bool
>>> }
>>> func Eq[T Equaler[T]](a, b T) bool {
>>> return a.Equal(b)
>>> }
>>>
>>
>> I don't see the same problem here. "T" and "Equaler" are two different
>> identifiers.
>>
>
> But T and T are not.
>
> The point I was making is that type-parameters must inherently be scoped
> in a way that makes them visible in the type-list itself, to make writing
> code like this possible. This isn't necessary for regular parameters and
> it's what makes type-parameter lists special.
>
> I *also* said that it's probably possible to devise rules which would make
> this possible, while allowing the example you wrote, just that those rules
> would have to be complicated.
>
>
>>
>>
>>>
>>> or basically any use-case for constraint-type inference.
>>>
>>> Even if we *could* allow it consistently, the rules for doing that would
>>> likely be pretty complex. Better to take the relatively minor hit of
>>> disallowing this overloading (you can always use different names for the
>>> type-parameters, if they conflict with the constraint you want to use) than
>>> to take the hit of complex scoping rules with lots of exceptions.
>>>
>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com 
>>> wrote:
>>>
 I expect the following code compilers okay, but it doesn't.
 It looks All the three "I" in the Bar function declaration are
 viewed as the type parameter, whereas the second one is
 expected as the constraint I (at least by me).

 package main

 type I interface { M() }

 func Foo(i I) {
   i.M()
 }

 func Bar[I I](i I) { // cannot use a type parameter as constraint
   i.M()
 }

 func main() {}

 --
 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%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/CAHbs%3DNYn-r01bMXTNU2qEtYxxo2pBtL%2BgURYkNrfJH%2BRUq%3DLSA%40mail.gmail.com.

[go-nuts] Re: An intresting behaviour about number of allocations in []byte->string conversions

2020-08-14 Thread T L 
Sorry, I temporarily switch to Go 1.3.
The result is constantly 0 0 1 for Go 1.15 when N > 2.

On Saturday, August 15, 2020 at 12:30:32 AM UTC-4, T L wrote:
>
>
> package main
>
> import "fmt"
> import "bytes"
> import "testing"
>
> const N = 0
> var name = bytes.Repeat([]byte{'x'}, N)
> var m = make(map[string]string, 10)
> var s string
>
> func f() {
> s = m[string(name)]
> }
>
> func g() {
> key := string(name)
> s = m[key]
> }
>
> func h() {
> m[string(name)] = "Golang"
> }
>
> func main() {
> fmt.Println(testing.AllocsPerRun(1, f)) // 0
> fmt.Println(testing.AllocsPerRun(1, g)) // 1
> fmt.Println(testing.AllocsPerRun(1, h)) // 1
> }
>
> /* The result:
>
> N  fgH
> ------------
> >=9011
> 8,4,2,1,0  000
> 6,7011
> 3,5010
> */
>
> Some inaccuracies in testing.AllocsPerRun?
>

-- 
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/1add30d9-a12a-46fe-a5c2-6cf19ff6928do%40googlegroups.com.

[go-nuts] An intresting behaviour about number of allocations in []byte->string conversions

2020-08-14 Thread T L 

package main

import "fmt"
import "bytes"
import "testing"

const N = 0
var name = bytes.Repeat([]byte{'x'}, N)
var m = make(map[string]string, 10)
var s string

func f() {
s = m[string(name)]
}

func g() {
key := string(name)
s = m[key]
}

func h() {
m[string(name)] = "Golang"
}

func main() {
fmt.Println(testing.AllocsPerRun(1, f)) // 0
fmt.Println(testing.AllocsPerRun(1, g)) // 1
fmt.Println(testing.AllocsPerRun(1, h)) // 1
}

/* The result:

N  fgH
------------
>=9011
8,4,2,1,0  000
6,7011
3,5010
*/

Some inaccuracies in testing.AllocsPerRun?

-- 
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/44bdea3f-762e-4200-9283-de318d7393a1o%40googlegroups.com.

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

2020-06-23 Thread T L 


On Monday, June 22, 2020 at 1:25:33 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Jun 22, 2020 at 8:49 AM T L > 
> wrote: 
> > 
> > One example is the above Print function example. 
> > Another example I current get is to iterate and print 
> > all the key and values of a container in a current format. 
> > There should be more examples with this need I think. 
>
> I want to stress that we want real examples of real code that people 
> want to write, not theoretical ideas for code that people might in 
> theory want to write. 
>
> Do you have a real program that uses both slices and maps where you 
> would want to have a generic function that prints the keys and values 
> of either a slice or map?  When does that come up?  When I ask that, 
> I'm looking for a real program, not the idea that somebody somewhere 
> might want to do that.  I agree that somebody somewhere might want to 
> do that.  But is it an important enough use case that we must handle 
> it in the first attempt at adding generics to the language?  When 
> thinking about that, consider that one goal of generics is to permit 
> people to write their own container types, which will by definition 
> not be maps or slices.  Should we be looking for some mechanism that 
> can print the keys and values of any container type?  Why is it 
> important to handle the cases of slices or maps but not the case of 
> other container types? 
>
> Ian 
>

I think this is a problem whether or not long tail matters for the generic 
design. 
It might affect user happiness, I think, but it is hard to predict.

-- 
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/8ecb0b0a-64e1-4713-b92e-d203f76800ffo%40googlegroups.com.

Re: [go-nuts] [generics] Should convertibility and comparibility of two types be two kinds of constraints?

2020-06-22 Thread T L 


On Sunday, June 21, 2020 at 11:21:29 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sat, Jun 20, 2020 at 7:30 PM T L > 
> wrote: 
> > 
> > On Saturday, June 20, 2020 at 4:48:07 PM UTC-4, Ian Lance Taylor wrote: 
> >> 
> >> On Sat, Jun 20, 2020 at 8:26 AM T L  wrote: 
> >> > 
> >> > For example, if there is a builtin convertible(from, to) constraint, 
> >> > We can define a slice conversion function as 
> >> > 
> >> > func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs 
> []Tb) { 
> >> >bvs = make([]Tb, 0, len(avs) 
> >> >for _, v := range avs { 
> >> >   bvs = append(bvs, Tb(v)) 
> >> >} 
> >> >return bvs 
> >> > } 
> >> > 
> >> > We can use it as: 
> >> > 
> >> > iValues := Convert([]int{}{1, 2, 3}, interface{}(nil)) 
> >> 
> >> 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#no-way-to-express-convertability
>  
> >> 
> >> Ian 
> > 
> > 
> > What are the rationales behind this? 
>
> I'm not sure I understand your question.  The section I mentioned is 
> under "Issues".  There is nothing here that seems to need a rationale. 
> It's an issue that needs to be considered before making a language 
> change proposal. 
>
> Ian 
>

OK, I see.
it would be great if a "convertible" constraint is provided, so that
the example in the first comment of this thread will be possible.
Otherwise, by the current constraint capabilities, a conversion
callback function is needed in declaring and using the generic
slice conversion function, whereas the conversion callback
function is an unnecessary repetitiveness.

Example (by the current rules):

package main

import (
"fmt"
)

func Convert(type Ta, Tb) (avs []Ta, cb func(Ta) Tb) (bvs []Tb) {
   bvs = make([]Tb, 0, len(avs))
   for _, v := range avs {
  bvs = append(bvs, cb(v))
   }
   return bvs
}

func main() {
iValues := Convert([]int{1, 2, 3}, func(v int) interface{}{
return v
})
bytes := Convert([]int{1, 2, 3}, func(v int) byte{
return byte(v)
})
bytesSlice := Convert([]string{"abc", "xyz"}, func(v string) []byte{
return []byte(v)
})

fmt.Println(iValues...)
fmt.Println(bytes)
fmt.Println(bytesSlice)
}

Example (if convertible constraint is supported)

package main

import (
"fmt"
)

func Convert(type Ta, Tb convertible(Tb, Ta)) (avs []Ta, _ *Tb) (bvs []Tb) {
   bvs = make([]Tb, 0, len(avs))
   for _, v := range avs {
  bvs = append(bvs, Tb(v))
   }
   return bvs
}

func main() {
iValues := Convert([]int{1, 2, 3}, interface{}(nil))
bytes := Convert([]int{1, 2, 3}, byte(0))
bytesSlice := Convert([]string{"abc", "xyz"}, []byte(nil))

fmt.Println(iValues...)
fmt.Println(bytes)
fmt.Println(bytesSlice)
}

BTW, if types can be passed to functions as augments, just like the builtin 
new and make functions,
the code will be more clean:

iValues := Convert([]int{1, 2, 3}, interface{})
bytes := Convert([]int{1, 2, 3}, byte)
bytesSlice := Convert([]string{"abc", "xyz"}, []byte)

-- 
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/1d34f7fc-69f9-416e-8355-b9bc12a05e7do%40googlegroups.com.

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

2020-06-20 Thread T L 


On Saturday, June 20, 2020 at 3:08:42 PM UTC-4, David Finkel wrote:
>
>
>
> On Sat, Jun 20, 2020 at 11:03 AM T L > 
> wrote:
>
>>
>>
>> On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote:
>>>
>>> I would assume it's
>>>
>>> type MapConstraint(type K comparable, V interface{}) interface {
>>> type map[K]V
>>> }
>>>
>>> func F(type M MapConstraint(K, V), K comparable, V interface{}) (m M) {
>>> }
>>>
>>> Note that you are under no obligation to make use of a type-parameter if 
>>> you don't need it.
>>>
>>
>> I don't very understand this. Can a slice value be used as the argument 
>> of the F function?
>>
> For that, I think you'd need the interface to be:
> type MapSliceConstraint(type K comparable, V interface{}) interface {
> type map[K]V, []V
> }
>
> I'm not quite sure how to eliminate the useless K type-param for slices, 
> though.
>
> Note: the relevant draft design section is: 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-parameters-in-type-lists
>
> Here's an almost working example:
> https://go2goplay.golang.org/p/qcdfl0tuHlb
>
> It looks like there's a bug in the type-parameter constraint checking 
> because in the above example code, I get:
>
> type checking failed for main 
>
> prog.go2:11:39: K does not satisfy comparable 
>
> This, despite the type parameter definition literally requiring that K be 
> comparable:
> func genLen(type T MapSliceConstraint(K, V), K *comparable*, V 
> interface{})(collection T) int {
> return len(collection)
> }
> (example without a main() to reduce clutter: 
> https://go2goplay.golang.org/p/1gqiYuDELuI)
>


Thanks for making this example.

However, it almost reach my upper limit understanding ability to get the 
implementation.
I looks some bad practices in using C++ template.

Is it good to add a Kind list constraint? For example,

type MapOrSlice interface {
   kind map, []
}
 

>  
>>
>>>
>>> On Sat, Jun 20, 2020 at 4:14 PM T L  wrote:
>>>
>>>> I mean I don't care about the element and key types of the parameter 
>>>> type.
>>>>
>>>> For a simple example, I want to define a generic function which prints 
>>>> the length of a container (do do some other things):
>>>>
>>>> func Print(type T Container) (v T) {
>>>>// ... do some things
>>>>
>>>>fmt.Println(len(v))
>>>>
>>>>// ... do some things
>>>> }
>>>>
>>>> On Saturday, June 20, 2020 at 9:16:39 AM UTC-4, T L wrote:
>>>>>
>>>>> .
>>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to golan...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/4f42e5e9-f991-4ee7-a043-5350a62f787fo%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/4f42e5e9-f991-4ee7-a043-5350a62f787fo%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f841c497-8c29-4f16-a027-2c446f1a94b6o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f841c497-8c29-4f16-a027-2c446f1a94b6o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/a5f078ab-1464-4395-8f41-89a7aa687f0bo%40googlegroups.com.

Re: [go-nuts] [generics] Should convertibility and comparibility of two types be two kinds of constraints?

2020-06-20 Thread T L 


On Saturday, June 20, 2020 at 4:48:07 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sat, Jun 20, 2020 at 8:26 AM T L > 
> wrote: 
> > 
> > For example, if there is a builtin convertible(from, to) constraint, 
> > We can define a slice conversion function as 
> > 
> > func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs []Tb) 
> { 
> >bvs = make([]Tb, 0, len(avs) 
> >for _, v := range avs { 
> >   bvs = append(bvs, Tb(v)) 
> >} 
> >return bvs 
> > } 
> > 
> > We can use it as: 
> > 
> > iValues := Convert([]int{}{1, 2, 3}, interface{}(nil)) 
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#no-way-to-express-convertability
>  
>
> Ian 
>

What are the rationales behind this?

-- 
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/8c414385-73e8-4883-8437-629fe242436bo%40googlegroups.com.

[go-nuts] Re: [generics] Should convertibility and comparibility of two types be two kinds of constraints?

2020-06-20 Thread T L 


On Saturday, June 20, 2020 at 1:10:29 PM UTC-4, Bebop Leaf wrote:
>
>
>
> > And
> > * should "embeddable" be one kind of constraints?
>
> Would you elaborate what do you mean by "embeddable"?
>
> As for the other 3, I agree it would be good to have them as constraints.
>

For example:

type Foo(type A interface{}, B embeddable) struct {
B

// ... others
}

-- 
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/ab620354-41fd-4152-863d-ed4f9301efeao%40googlegroups.com.

[go-nuts] Re: [generics] Should convertibility and comparibility of two types be two kinds of constraints?

2020-06-20 Thread T L 
And
* should "embeddable" be one kind of constraints?
* should "has some specified fields" be one kind of constraints?

On Saturday, June 20, 2020 at 11:26:08 AM UTC-4, T L wrote:
>
> For example, if there is a builtin convertible(from, to) constraint,
> We can define a slice conversion function as
>
> func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs []Tb) {
>bvs = make([]Tb, 0, len(avs)
>for _, v := range avs {
>   bvs = append(bvs, Tb(v))
>}
>return bvs
> }
>
> We can use it as:
>
> iValues := Convert([]int{}{1, 2, 3}, interface{}(nil))
>

-- 
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/1754a8a6-a496-4a51-bc3d-ddb2dc1be75ao%40googlegroups.com.

[go-nuts] [generics] Should convertibility and comparibility of two types be two kinds of constraints?

2020-06-20 Thread T L 
For example, if there is a builtin convertible(from, to) constraint,
We can define a slice conversion function as

func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs []Tb) {
   bvs = make([]Tb, 0, len(avs)
   for _, v := range avs {
  bvs = append(bvs, Tb(v))
   }
   return bvs
}

We can use it as:

iValues := Convert([]int{}{1, 2, 3}, interface{}(nil))

-- 
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/e67fe1cd-888c-4828-ba6f-0fd8e47b58d9o%40googlegroups.com.

[go-nuts] Re: [generics] no methods with type parameters

2020-06-20 Thread T L 
The method set of a type should be stable. Generic methods make this 
impossible.

On Saturday, June 20, 2020 at 9:31:53 AM UTC-4, Carsten Orthbandt wrote:
>
> Hi!
>
> First, thanks to the Go team for the hard work and the list populace for 
> an extremely low-noise list. Very much appreciated.
>
> In the recent draft, struct methods with type parameters are explicitly 
> excluded with a note that they might be added later.
> I think I roughly understand the added complexity of having basically 2D 
> type parameters (from the struct type itself and the mehtod).
> However, and I'm really wondering why nobody brought this up, I think this 
> is a language element that would be quite akward to add later.
>
> Not because syntax would have to change in incompatible ways, but because 
> idiomatic Go will be forced to steer towards global functions for this use 
> case.
>
> Minimal example:
> https://go2goplay.golang.org/p/CxK7EuhW_fF
>
> Please note that the struct type in this example does not even use type 
> parameters.
>
> With the method receiver really being just a 0th argument to a method, I 
> don't see why having type params on methods would be such a big challenge.
>
>
> Best Regards,
> Carsten
>  
>

-- 
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/615618b1-1b92-4b8b-a1df-a81c83a0ffa1o%40googlegroups.com.

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

2020-06-20 Thread T L 


On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote:
>
> I would assume it's
>
> type MapConstraint(type K comparable, V interface{}) interface {
> type map[K]V
> }
>
> func F(type M MapConstraint(K, V), K comparable, V interface{}) (m M) {
> }
>
> Note that you are under no obligation to make use of a type-parameter if 
> you don't need it.
>

I don't very understand this. Can a slice value be used as the argument of 
the F function?
 

>
> On Sat, Jun 20, 2020 at 4:14 PM T L > 
> wrote:
>
>> I mean I don't care about the element and key types of the parameter type.
>>
>> For a simple example, I want to define a generic function which prints 
>> the length of a container (do do some other things):
>>
>> func Print(type T Container) (v T) {
>>// ... do some things
>>
>>fmt.Println(len(v))
>>
>>// ... do some things
>> }
>>
>> On Saturday, June 20, 2020 at 9:16:39 AM UTC-4, T L wrote:
>>>
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/4f42e5e9-f991-4ee7-a043-5350a62f787fo%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/4f42e5e9-f991-4ee7-a043-5350a62f787fo%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/f841c497-8c29-4f16-a027-2c446f1a94b6o%40googlegroups.com.

[go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

2020-06-20 Thread T L 
I mean I don't care about the element and key types of the parameter type.

For a simple example, I want to define a generic function which prints the 
length of a container (do do some other things):

func Print(type T Container) (v T) {
   // ... do some things

   fmt.Println(len(v))

   // ... do some things
}

On Saturday, June 20, 2020 at 9:16:39 AM UTC-4, T L wrote:
>
> .
>

-- 
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/4f42e5e9-f991-4ee7-a043-5350a62f787fo%40googlegroups.com.

[go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

2020-06-20 Thread T L 
Or any map type with a specified key type but ignore the element type.

On Saturday, June 20, 2020 at 9:16:39 AM UTC-4, T L wrote:
>
> .
>

-- 
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/b4c4c4e4-84f9-4078-a4b5-8dddebf97986o%40googlegroups.com.

[go-nuts] [generics] how to constraint a type must be a map or a slice?

2020-06-20 Thread T L 
.

-- 
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/dd80003a-ebf9-4e5c-b4ae-50d9945f11c8o%40googlegroups.com.

[go-nuts] [generics] Is the draft design good to remove the code generation in the k8s project?

2020-06-20 Thread T L 
Such as:
* non-reflected DeepCopy, Conversion
* client-go/{informers,kubernetes/typed,listers}

-- 
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/443c23e7-7945-4674-aaaf-f5d8fc5a705fo%40googlegroups.com.

Re: [go-nuts] [generics] some questions

2020-06-18 Thread T L 


On Thursday, June 18, 2020 at 8:01:22 AM UTC-4, Axel Wagner wrote:
>
>
>
> On Thu, Jun 18, 2020, 13:21 T L > wrote:
>
>>
>>
>> On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote:
>>>
>>>
>>>
>>> On Thu, Jun 18, 2020, 11:28 T L  wrote:
>>>
>>>> How to declare a generic functions which converting a slice with type 
>>>> Ta to a slice with type Tb. Like 
>>>> func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}
>>>>
>>>>
>>>>  
>> For example, I need a ConvertSlice function which will do
>> * Convert []int to []int64, and the inverse
>> * Convert string to []byte, and the inverse
>> * Convert between several struct types with the same field set, except 
>> their field tags are different.
>> * more generally, Convert []Ta to []Tb, and the inverse, where Ta can be 
>> converted to Tb.
>>
>
> None of these are interface types. I think I don't understand your 
> question. Was there a typo and you meant "integer"? In that case, the 
> answer is here:
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-constraints
> You mention four very different use cases. I don't understand how to unify 
> them into one question.
>
>
>>  
>>
>>> How to constraint a type parameter must be of an interface type?
>>>>
>>>
>>> I don't think you can. Why would you need to? Note that there will 
>>> always be constraints that you can't express.
>>>
>>
>> One need is the same as the above Convert case, there should be more. 
>>
>> func ConvertSlice(type T, I constraint)(ins []T) []I {...} 
>>
>> Where I must/may be some special interface types.
>>
>
> You still haven't said *why* you need it to be an interface type. What 
> does knowing it's an interface allow you to do? Why would it break if 
> someone passed a concrete type?
>
>
>
>>
>>>
>>>> Is it possible to define generic unnamed types?
>>>>
>>>
>>> No. It also would be useless. You can't refer to a generic, 
>>> uninstantiated type. So a generic type either needs a name to be referred 
>>> by to instantiate it, or be instantiated right immediately in its 
>>> declaration (and thus wouldn't need to be generic).
>>>
>>> If it is impossible, then how to define a generic map type which 
>>>> elements must be an unnamed integer slice?
>>>>
>>>
>>> type numeric interface {
>>> type int, int8, int16, int32, ...
>>> }
>>>
>>> type MyMap(type K comparable, T numeric) map[K][]T
>>>
>>
>> Sorry, here I meant "... must be of a slice with an unnamed element type".
>>
>
> I don't think that's possible. And the same question as above applies: Why 
> is that an important constraint to be able to express?
>
> I'm sorry, but I just don't understand what you are trying to ask.
>
> Sometimes, the map element slice type itself might be required to be shown 
>> as a type parameter.
>>
> One of the case is still related to slice conversions.
>>  
>>
>
It is a little hard to describe it clearly. I will continue this question 
when I sort it out.
 

>
>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to golan...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>
>>  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/cedd7b44-0cb1-4a60-9cbd-2f40718d3526o%40googlegroups.com.

Re: [go-nuts] Re: [generics] some questions

2020-06-18 Thread T L 
So, it is really a bug. I will report it.

On Thursday, June 18, 2020 at 8:17:22 AM UTC-4, Harald Weidner wrote:
>
> Hello, 
>
> > But the following code also fails to compile, bug? 
> > 
> > package main 
> > 
> > type Int interface { 
> > type int 
> > } 
> > 
> > func Foo(type T Int) ([]T) {} // undefined: MyInt 
> > 
> > func main() { 
> > type MyInt int 
> > Foo([]MyInt(nil)) 
> > } 
>
> It compiles if you move "type MyInt int" out of the func main scope. See 
> https://go2goplay.golang.org/p/_sWi72-0rD1 
>
> Harald 
>

-- 
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/937ace02-47b4-473b-8fc6-1107e1192d74o%40googlegroups.com.

Re: [go-nuts] [generics] some questions

2020-06-18 Thread T L 


On Thursday, June 18, 2020 at 8:01:22 AM UTC-4, Axel Wagner wrote:
>
>
>
> On Thu, Jun 18, 2020, 13:21 T L > wrote:
>
>>
>>
>> On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote:
>>>
>>>
>>>
>>> On Thu, Jun 18, 2020, 11:28 T L  wrote:
>>>
>>>> How to declare a generic functions which converting a slice with type 
>>>> Ta to a slice with type Tb. Like 
>>>> func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}
>>>>
>>>>
>>>>  
>> For example, I need a ConvertSlice function which will do
>> * Convert []int to []int64, and the inverse
>> * Convert string to []byte, and the inverse
>> * Convert between several struct types with the same field set, except 
>> their field tags are different.
>> * more generally, Convert []Ta to []Tb, and the inverse, where Ta can be 
>> converted to Tb.
>>
>
> None of these are interface types. I think I don't understand your 
> question. Was there a typo and you meant "integer"? In that case, the 
> answer is here:
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-constraints
> You mention four very different use cases. I don't understand how to unify 
> them into one question.
>
>
>>  
>>
>>> How to constraint a type parameter must be of an interface type?
>>>>
>>>
>>> I don't think you can. Why would you need to? Note that there will 
>>> always be constraints that you can't express.
>>>
>>
>> One need is the same as the above Convert case, there should be more. 
>>
>> func ConvertSlice(type T, I constraint)(ins []T) []I {...} 
>>
>> Where I must/may be some special interface types.
>>
>
> You still haven't said *why* you need it to be an interface type. What 
> does knowing it's an interface allow you to do? Why would it break if 
> someone passed a concrete type?
>

For examples, I want to convert a []int value "vs" to a []interface{} value 
so that it can be passed to the fmt.Println(Convert(int, 
interface{})(vs)...).
But I don't need a Convert generic function which can convert []int to 
[]interface{} specifically.
What I need is a common generic function which can convert []Ta value to 
[]Tb if Ta values can be converted to Tb.

That means, the above two questions are the same question.
 

>
>
>
>>
>>>
>>>> Is it possible to define generic unnamed types?
>>>>
>>>
>>> No. It also would be useless. You can't refer to a generic, 
>>> uninstantiated type. So a generic type either needs a name to be referred 
>>> by to instantiate it, or be instantiated right immediately in its 
>>> declaration (and thus wouldn't need to be generic).
>>>
>>> If it is impossible, then how to define a generic map type which 
>>>> elements must be an unnamed integer slice?
>>>>
>>>
>>> type numeric interface {
>>> type int, int8, int16, int32, ...
>>> }
>>>
>>> type MyMap(type K comparable, T numeric) map[K][]T
>>>
>>
>> Sorry, here I meant "... must be of a slice with an unnamed element type".
>>
>
> I don't think that's possible. And the same question as above applies: Why 
> is that an important constraint to be able to express?
>
> I'm sorry, but I just don't understand what you are trying to ask.
>
> Sometimes, the map element slice type itself might be required to be shown 
>> as a type parameter.
>>
> One of the case is still related to slice conversions.
>>  
>>
>>>
>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to golan...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>
>>  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/2eaf16fc-6931-45b4-977f-750a1a48dd87o%40googlegroups.com.

[go-nuts] Re: [generics] some questions

2020-06-18 Thread T L 
It looks, in most cases, the current rules recommends the types shown in 
the constraint definition must be the elementary types.

On Thursday, June 18, 2020 at 7:45:52 AM UTC-4, T L wrote:

> It looks the generic type argument must share the underlying type of a 
> type in the constraint type list.
>
> But the following code also fails to compile, bug?
>
> package main
>
> type Int interface {
> type int
> }
>
> func Foo(type T Int) ([]T) {} // undefined: MyInt
>
> func main() {
> type MyInt int
> Foo([]MyInt(nil))
> }
>
> On Thursday, June 18, 2020 at 7:22:51 AM UTC-4, T L wrote:
>>
>> Another question, how to make the following code compile:
>>
>> package main
>>
>> type IntSlice interface {
>> type []int
>> }
>>
>> func Foo(type T IntSlice) (T) {}
>>
>> func main() {
>> type MyInt int
>> Foo([]int(nil))
>> Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not 
>> found in []int)
>> }
>>
>

-- 
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/cfa7f3a8-fda2-493f-856a-75908330181do%40googlegroups.com.

[go-nuts] Re: [generics] some questions

2020-06-18 Thread T L 
It looks the generic type argument must share the underlying type of a type 
in the constraint type list.

But the following code also fails to compile, bug?

package main

type Int interface {
type int
}

func Foo(type T Int) ([]T) {} // undefined: MyInt

func main() {
type MyInt int
Foo([]MyInt(nil))
}

On Thursday, June 18, 2020 at 7:22:51 AM UTC-4, T L wrote:
>
> Another question, how to make the following code compile:
>
> package main
>
> type IntSlice interface {
> type []int
> }
>
> func Foo(type T IntSlice) (T) {}
>
> func main() {
> type MyInt int
> Foo([]int(nil))
> Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not 
> found in []int)
> }
>

-- 
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/c5f5f3b8-b609-4795-9f27-806409decd5ao%40googlegroups.com.

[go-nuts] Re: [generics] some questions

2020-06-18 Thread T L 
Another question, how to make the following code compile:

package main

type IntSlice interface {
type []int
}

func Foo(type T IntSlice) (T) {}

func main() {
type MyInt int
Foo([]int(nil))
Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not 
found in []int)
}

-- 
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/325771a1-bc75-425f-9d25-9f768bba175bo%40googlegroups.com.

Re: [go-nuts] [generics] some questions

2020-06-18 Thread T L 


On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote:
>
>
>
> On Thu, Jun 18, 2020, 11:28 T L > wrote:
>
>> How to declare a generic functions which converting a slice with type Ta 
>> to a slice with type Tb. Like 
>> func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}
>>
>>
>>  
For example, I need a ConvertSlice function which will do
* Convert []int to []int64, and the inverse
* Convert string to []byte, and the inverse
* Convert between several struct types with the same field set, except 
their field tags are different.
* more generally, Convert []Ta to []Tb, and the inverse, where Ta can be 
converted to Tb.

 

> How to constraint a type parameter must be of an interface type?
>>
>
> I don't think you can. Why would you need to? Note that there will always 
> be constraints that you can't express.
>

One need is the same as the above Convert case, there should be more. 

func ConvertSlice(type T, I constraint)(ins []T) []I {...} 

Where I must/may be some special interface types.


>
>> Is it possible to define generic unnamed types?
>>
>
> No. It also would be useless. You can't refer to a generic, uninstantiated 
> type. So a generic type either needs a name to be referred by to 
> instantiate it, or be instantiated right immediately in its declaration 
> (and thus wouldn't need to be generic).
>
> If it is impossible, then how to define a generic map type which elements 
>> must be an unnamed integer slice?
>>
>
> type numeric interface {
> type int, int8, int16, int32, ...
> }
>
> type MyMap(type K comparable, T numeric) map[K][]T
>

Sorry, here I meant "... must be of a slice with an unnamed element type".
Sometimes, the map element slice type itself might be required to be shown 
as a type parameter.
One of the case is still related to slice conversions.
 

>
> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

 

-- 
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/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com.

[go-nuts] [generics] some questions

2020-06-18 Thread T L 
How to declare a generic functions which converting a slice with type Ta to 
a slice with type Tb. Like 
func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}

How to constraint a type parameter must be of an interface type?

Is it possible to define generic unnamed types?
If it is impossible, then how to define a generic map type which elements 
must be an unnamed integer slice?

-- 
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/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com.

Re: [go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

2020-06-12 Thread T L 


On Friday, June 12, 2020 at 1:33:32 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Jun 12, 2020 at 10:08 AM T L > 
> wrote: 
> > 
> > On Friday, June 12, 2020 at 1:02:30 PM UTC-4, Ian Lance Taylor wrote: 
> >> 
> >> On Fri, Jun 12, 2020 at 9:56 AM T L  wrote: 
> >> > 
> >> > Is "uintptr(uintptr(ptr))" a typo? Or are there any other multiple 
> chained conversions examples? 
> >> 
> >> That is not a typo.  That is the case that worked in 1.14 and does not 
> >> work in 1.15. 
> >> 
> >> Ian 
> >> 
> > 
> > So "uintptr(unsafe.Pointer(ptr))" also doesn't work now? 
>
> No, that continues to work as before.  Nobody has said anything about that 
> case. 
>
> Again: the case that no longer works is uintptr(uintptr(ptr)). 
>
> Ian 
>
>
Get it. Thanks both for the explanations.
 

>
> >> > On Friday, June 12, 2020 at 12:47:03 PM UTC-4, Axel Wagner wrote: 
> >> >> 
> >> >> AIUI: The safety rules haven't changed. How the compiler interprets 
> them has. Previously, it interpreted them so as to allow multiple chained 
> conversions. Now it doesn't. 
> >> >> 
> >> >> On Fri, Jun 12, 2020 at 2:28 PM T L  wrote: 
> >> >>> 
> >> >>> 
> >> >>> Package unsafe's safety rules allow converting an unsafe.Pointer 
> into uintptr when calling certain functions. Previously, in some cases, the 
> compiler allowed multiple chained conversions (for example, 
> syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires 
> exactly one conversion. Code that used multiple conversions should be 
> updated to satisfy the safety rules. 
> >> >>> 
> >> >>> 
> >> >>> I didn't find the difference from Go 1.14. 
> >> >>> 
> >> >>> -- 
> >> >>> You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> >> >>> To unsubscribe from this group and stop receiving emails from it, 
> send an email to golan...@googlegroups.com. 
> >> >>> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/0f62c576-a1f9-467e-b99c-42f01edaa452o%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 golan...@googlegroups.com. 
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/6139806c-8937-4f71-97a0-eae51fecdb8co%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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/12d0fa65-0364-4da1-bf9a-dd6b4cef39e3o%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/d7d3986e-92b5-4748-b9ba-def58f1899d2o%40googlegroups.com.

Re: [go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

2020-06-12 Thread T L 


On Friday, June 12, 2020 at 1:02:30 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Jun 12, 2020 at 9:56 AM T L > 
> wrote: 
> > 
> > Is "uintptr(uintptr(ptr))" a typo? Or are there any other multiple 
> chained conversions examples? 
>
> That is not a typo.  That is the case that worked in 1.14 and does not 
> work in 1.15. 
>
> Ian 
>
>
So "uintptr(unsafe.Pointer(ptr))" also doesn't work now?
 

>
> > On Friday, June 12, 2020 at 12:47:03 PM UTC-4, Axel Wagner wrote: 
> >> 
> >> AIUI: The safety rules haven't changed. How the compiler interprets 
> them has. Previously, it interpreted them so as to allow multiple chained 
> conversions. Now it doesn't. 
> >> 
> >> On Fri, Jun 12, 2020 at 2:28 PM T L  wrote: 
> >>> 
> >>> 
> >>> Package unsafe's safety rules allow converting an unsafe.Pointer into 
> uintptr when calling certain functions. Previously, in some cases, the 
> compiler allowed multiple chained conversions (for example, 
> syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires 
> exactly one conversion. Code that used multiple conversions should be 
> updated to satisfy the safety rules. 
> >>> 
> >>> 
> >>> I didn't find the difference from Go 1.14. 
> >>> 
> >>> -- 
> >>> You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> >>> To unsubscribe from this group and stop receiving emails from it, send 
> an email to golan...@googlegroups.com. 
> >>> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/0f62c576-a1f9-467e-b99c-42f01edaa452o%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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/6139806c-8937-4f71-97a0-eae51fecdb8co%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/12d0fa65-0364-4da1-bf9a-dd6b4cef39e3o%40googlegroups.com.

Re: [go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

2020-06-12 Thread T L 

Is "uintptr(uintptr(ptr))" a typo? Or are there any other multiple chained 
conversions examples?

On Friday, June 12, 2020 at 12:47:03 PM UTC-4, Axel Wagner wrote:
>
> AIUI: The safety rules haven't changed. How the compiler interprets them 
> has. Previously, it interpreted them so as to allow multiple chained 
> conversions. Now it doesn't.
>
> On Fri, Jun 12, 2020 at 2:28 PM T L > 
> wrote:
>
>>
>> Package unsafe's safety rules 
>> <https://tip.golang.org/pkg/unsafe/#Pointer> allow converting an 
>> unsafe.Pointer into uintptr when calling certain functions. Previously, 
>> in some cases, the compiler allowed multiple chained conversions (for 
>> example, syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now 
>> requires exactly one conversion. Code that used multiple conversions should 
>> be updated to satisfy the safety rules. 
>>
>>
>> I didn't find the difference from Go 1.14.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/0f62c576-a1f9-467e-b99c-42f01edaa452o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0f62c576-a1f9-467e-b99c-42f01edaa452o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/6139806c-8937-4f71-97a0-eae51fecdb8co%40googlegroups.com.

[go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

2020-06-12 Thread T L 

Package unsafe's safety rules  
allow converting an unsafe.Pointer into uintptr when calling certain 
functions. Previously, in some cases, the compiler allowed multiple chained 
conversions (for example, syscall.Syscall(…, uintptr(uintptr(ptr)), …)). 
The compiler now requires exactly one conversion. Code that used multiple 
conversions should be updated to satisfy the safety rules. 


I didn't find the difference from Go 1.14.

-- 
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/0f62c576-a1f9-467e-b99c-42f01edaa452o%40googlegroups.com.

[go-nuts] Re: When "go get" is run in neither a GOPATH directory nor a module-aware directory, should GOPROXY be used or not?

2020-06-03 Thread T L 
It looks the default mode in Go 1.14 is still GOPATH mode. So GOPROXY is 
ignored
when "go get" run in neither a GOPATH directory nor a module-aware 
directory.


On Tuesday, June 2, 2020 at 9:12:59 PM UTC-4, T L wrote:

> .
>

-- 
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/b679c366-c5e9-4c0f-afc9-1c7f238ad776%40googlegroups.com.

[go-nuts] When "go get" is run in neither a GOPATH directory nor a module-aware directory, should GOPROXY be used or not?

2020-06-02 Thread T L 
.

-- 
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/6a3bd8e3-4db8-4da0-b5ac-6820c587089e%40googlegroups.com.

Re: [go-nuts] A little weird thing in using finalizer

2020-04-25 Thread T L 


On Saturday, April 25, 2020 at 1:53:28 AM UTC-4, Brian Candler wrote:
>
> On Saturday, 25 April 2020 06:35:22 UTC+1, T L wrote:
>>
>> Why is each of the finalizers called twice?
>>
>
>
> Isn't it just printed once in main and once in finalizer?
> https://play.golang.org/p/7aY9NA1AFNa
>
>
Aha, I'm sorry I forgot that println line. I thought all the lines are 
printed in finalizers. ;D 

-- 
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/bef84b46-8e95-42b6-b7f9-68830c1eab3f%40googlegroups.com.

Re: [go-nuts] A little weird thing in using finalizer

2020-04-24 Thread T L 
With time.Sleep, it always prints:

> 31
> 37
> 47
> 47
> 37
> 31
>

Why is each of the finalizers called twice?

On Saturday, April 25, 2020 at 1:08:43 AM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Apr 24, 2020 at 9:30 PM T L > 
> wrote: 
> > 
> > The following program might print: 
> > 
> >> 31 
> >> 37 
> >> 47 
> >> 47 
> >> 37 
> >> 31 
> > 
> > 
> > or 
> > 
> >> 31 
> >> 37 
> >> 47 
> >> 47 
> > 
> > 
> > but with the highest possibility to print 
> > 
> >> 31 
> >> 37 
> >> 47 
> > 
> > 
> > Is not normal? 
> > 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "math/rand" 
> > "runtime" 
> > "time" 
> > "unsafe" 
> > ) 
> > 
> > type Foo struct { 
> > x int 
> > a int 
> > } 
> > 
> > func main() { 
> > for i := 0; i < 3; i++ { 
> > f := NewFoo(i) 
> > println(f.a) 
> > } 
> > 
> > runtime.GC() 
> > 
> > time.After(time.Second) 
> > } 
> > 
> > func do(i *uint) { 
> > runtime.SetFinalizer(i, func(f *uint) { 
> > fmt.Println(*f) 
> > }) 
> > } 
> > 
> > //go:noinline 
> > func NewFoo(i int) *Foo { 
> > f := {a: rand.Intn(50)} 
> > 
> > do((*uint)(unsafe.Pointer())) 
> > 
> > return f 
> > } 
>
> Finalizers are not guaranteed to run. 
>
> That said, I'm not sure why you are calling time.After.  That doesn't 
> make finalizers any more likely to run.  You'll probably see fairly 
> reliable results if you change that to call time.Sleep instead. 
>
> 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/68c17055-b1ed-4b26-a6d2-63c02e1d8ea0%40googlegroups.com.

[go-nuts] A little weird thing in using finalizer

2020-04-24 Thread T L 
The following program might print:

31
> 37
> 47
> 47
> 37
> 31
>

or 

31
> 37
> 47
> 47
>

but with the highest possibility to print

31
> 37
> 47
>

Is not normal?


package main

import (
"fmt"
"math/rand"
"runtime"
"time"
"unsafe"
)

type Foo struct {
x int
a int
}

func main() {
for i := 0; i < 3; i++ {
f := NewFoo(i)
println(f.a)
}

runtime.GC()

time.After(time.Second)
}

func do(i *uint) {
runtime.SetFinalizer(i, func(f *uint) {
fmt.Println(*f)
})
}

//go:noinline
func NewFoo(i int) *Foo {
f := {a: rand.Intn(50)}

do((*uint)(unsafe.Pointer()))

return f
}

-- 
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/db59b870-b9c7-4411-a461-5857eb7017e2%40googlegroups.com.

Re: [go-nuts] Is the following funciton always safe to convert a string to a slice?

2020-04-24 Thread T L 
For the first example, I always thought the "runtime.KeepAlive" call is 
essential before.
But after reading the explanations from Bryan C. Mills on Slack, I changed 
my mind now.

Bryan C. Mills said: The GC tracks pointers through their original 
allocations — the pointer scan does not care about lexical types, only 
allocation types.

On Tuesday, April 21, 2020 at 8:11:49 PM UTC-4, Ian Lance Taylor wrote:
>
> On Tue, Apr 21, 2020 at 6:49 AM T L > 
> wrote: 
> > 
> > func String2ByteSlice(str string) (bs []byte) { 
> > strHdr := (*reflect.StringHeader)(unsafe.Pointer()) 
> > sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer()) 
> > 
> > // Is it possible that the str value is allocated on stack 
> > // and the stack grows at this moment, so the address value 
> > // stored in strHdr.Data will become obsoleted? 
> > 
> > sliceHdr.Data = strHdr.Data 
> > sliceHdr.Len = strHdr.Len 
> > sliceHdr.Cap = strHdr.Len 
> > 
> > runtime.KeepAlive() 
> > 
> > return 
> > } 
>
> Since you are correctly using *reflect.StringHeader, it doesn't matter 
> whether the stack is copied at that moment.  You are pointing at the 
> actual string value, so the pointer will be adjusted.  As far as I can 
> see, this is safe.  (Of course, it's not safe if somebody modifies the 
> contents of the returned []byte.) 
>
> 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/83712696-b845-4db1-acdc-34b15b50baf4%40googlegroups.com.

Re: [go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

2020-04-24 Thread T L 
Many thanks. This is quite informative.

On Wednesday, April 22, 2020 at 4:44:18 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Apr 22, 2020 at 7:08 AM T L > 
> wrote: 
> > 
> > I understand that, by the case 6 in the unsafe package docs, 
> > the second program should be safe with or without the runtime.KeepAlive 
> call. 
> > I just wonder how Go runtime achieves this goal. 
> > I have an impression that pointer assignments in Go by gc is atomically, 
> > but is this also true for uintptr value assignments? 
>
> Using the meaning of "atomic" from my previous message, then, yes, 
> both pointer assignments and uintptr assignments are done in a way 
> that can not be interrupted.  That more or less happens automatically, 
> as it's a single machine instruction either way.  And in fact it's the 
> same machine instruction, since pointers and uintptr are the same size 
> and use the same registers. 
>
> Ian 
>
>
> > On Wednesday, April 22, 2020 at 7:33:22 AM UTC-4, T L wrote: 
> >> 
> >> 
> >> 
> >> On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote: 
> >>> 
> >>> On Tue, Apr 21, 2020 at 8:17 AM T L  wrote: 
> >>> > 
> >>> > And is the runtime.KeepAlive call in the following program essential 
> to keep the correctness? 
> >>> > 
> >>> > package main 
> >>> > 
> >>> > import ( 
> >>> > "fmt" 
> >>> > "unsafe" 
> >>> > "reflect" 
> >>> > "runtime" 
> >>> > ) 
> >>> > 
> >>> > func main() { 
> >>> > a := [6]byte{'G', 'o', 'o', 'g', 'l', 'e'} 
> >>> > bs := []byte("Golang") 
> >>> > hdr := (*reflect.SliceHeader)(unsafe.Pointer()) 
> >>> > hdr.Data = uintptr(unsafe.Pointer()) 
> >>> > 
> >>> > runtime.KeepAlive() // Is this line essential here? 
> >>> > 
> >>> > hdr.Len = 2 
> >>> > hdr.Cap = len(a) 
> >>> > fmt.Printf("%s\n", bs) // Go 
> >>> > bs = bs[:cap(bs)] 
> >>> > fmt.Printf("%s\n", bs) // Google 
> >>> > } 
> >>> 
> >>> I do not think the runtime.KeepAlive is required.  Setting the Data 
> >>> field using a *SliceHeader should keep the value alive. 
> >>> 
> >>> Ian 
> >> 
> >> 
> >> 
> >> Many thanks for the answers. 
> >> 
> >> I have another question, which doesn't matter with or without the 
> runtime.KeepAlive call. 
> >> We know that assignment in Go is not atomic. 
> >> Is it possible that when the assignment "hdr.Data = 
> uintptr(unsafe.Pointer())" is half done, 
> >> the stack is resized, so the address of a might be changed (assume a is 
> allocated on stack), 
> >> the hdr.Data will be assigned the old invalid value? 
> >> 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2b9b1bec-4176-421f-8820-a6ff2bf2ead2%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/1f4cb812-0301-4858-ba7d-669853d2e27c%40googlegroups.com.

Re: [go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

2020-04-22 Thread T L 
I understand that, by the case 6 in the unsafe package docs,
the second program should be safe with or without the runtime.KeepAlive 
call.
I just wonder how Go runtime achieves this goal.
I have an impression that pointer assignments in Go by gc is atomically,
but is this also true for uintptr value assignments?


On Wednesday, April 22, 2020 at 7:33:22 AM UTC-4, T L wrote:
>
>
>
> On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Tue, Apr 21, 2020 at 8:17 AM T L  wrote: 
>> > 
>> > And is the runtime.KeepAlive call in the following program essential to 
>> keep the correctness? 
>> > 
>> > package main 
>> > 
>> > import ( 
>> > "fmt" 
>> > "unsafe" 
>> > "reflect" 
>> > "runtime" 
>> > ) 
>> > 
>> > func main() { 
>> > a := [6]byte{'G', 'o', 'o', 'g', 'l', 'e'} 
>> > bs := []byte("Golang") 
>> > hdr := (*reflect.SliceHeader)(unsafe.Pointer()) 
>> > hdr.Data = uintptr(unsafe.Pointer()) 
>> > 
>> > runtime.KeepAlive() // Is this line essential here? 
>> > 
>> > hdr.Len = 2 
>> > hdr.Cap = len(a) 
>> > fmt.Printf("%s\n", bs) // Go 
>> > bs = bs[:cap(bs)] 
>> > fmt.Printf("%s\n", bs) // Google 
>> > } 
>>
>> I do not think the runtime.KeepAlive is required.  Setting the Data 
>> field using a *SliceHeader should keep the value alive. 
>>
>> Ian 
>>
>
>
> Many thanks for the answers.
>
> I have another question, which doesn't matter with or without the 
> runtime.KeepAlive call.
> We know that assignment in Go is not atomic.
> Is it possible that when the assignment "hdr.Data = 
> uintptr(unsafe.Pointer())" is half done,
> the stack is resized, so the address of a might be changed (assume a is 
> allocated on stack),
> the hdr.Data will be assigned the old invalid value?
>
>

-- 
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/2b9b1bec-4176-421f-8820-a6ff2bf2ead2%40googlegroups.com.

Re: [go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

2020-04-22 Thread T L 


On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote:
>
> On Tue, Apr 21, 2020 at 8:17 AM T L > 
> wrote: 
> > 
> > And is the runtime.KeepAlive call in the following program essential to 
> keep the correctness? 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "unsafe" 
> > "reflect" 
> > "runtime" 
> > ) 
> > 
> > func main() { 
> > a := [6]byte{'G', 'o', 'o', 'g', 'l', 'e'} 
> > bs := []byte("Golang") 
> > hdr := (*reflect.SliceHeader)(unsafe.Pointer()) 
> > hdr.Data = uintptr(unsafe.Pointer()) 
> > 
> > runtime.KeepAlive() // Is this line essential here? 
> > 
> > hdr.Len = 2 
> > hdr.Cap = len(a) 
> > fmt.Printf("%s\n", bs) // Go 
> > bs = bs[:cap(bs)] 
> > fmt.Printf("%s\n", bs) // Google 
> > } 
>
> I do not think the runtime.KeepAlive is required.  Setting the Data 
> field using a *SliceHeader should keep the value alive. 
>
> Ian 
>


Many thanks for the answers.

I have another question, which doesn't matter with or without the 
runtime.KeepAlive call.
We know that assignment in Go is not atomic.
Is it possible that when the assignment "hdr.Data = 
uintptr(unsafe.Pointer())" is half done,
the stack is resized, so the address of a might be changed (assume a is 
allocated on stack),
the hdr.Data will be assigned the old invalid value?

-- 
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/4c9d0b1d-2fd1-4d41-9b0f-26cf93b4027b%40googlegroups.com.

[go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

2020-04-21 Thread T L 
And is the runtime.KeepAlive call in the following program essential to 
keep the correctness?

package main

import (
"fmt"
"unsafe"
"reflect"
"runtime"
)

func main() {
a := [6]byte{'G', 'o', 'o', 'g', 'l', 'e'}
bs := []byte("Golang")
hdr := (*reflect.SliceHeader)(unsafe.Pointer())
hdr.Data = uintptr(unsafe.Pointer())

runtime.KeepAlive() // Is this line essential here?

hdr.Len = 2
hdr.Cap = len(a)
fmt.Printf("%s\n", bs) // Go
bs = bs[:cap(bs)]
fmt.Printf("%s\n", bs) // Google
}

On Tuesday, April 21, 2020 at 9:48:08 AM UTC-4, T L wrote:
>
> func String2ByteSlice(str string) (bs []byte) {
> strHdr := (*reflect.StringHeader)(unsafe.Pointer())
> sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer())
> 
> // Is it possible that the str value is allocated on stack
> // and the stack grows at this moment, so the address value
> // stored in strHdr.Data will become obsoleted?
> 
> sliceHdr.Data = strHdr.Data
> sliceHdr.Len = strHdr.Len
> sliceHdr.Cap = strHdr.Len
> 
> runtime.KeepAlive()
> 
> return
> }
>
>

-- 
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/483cb026-c8ab-41eb-9e3b-479a3e750d03%40googlegroups.com.

[go-nuts] Is the following funciton always safe to convert a string to a slice?

2020-04-21 Thread T L 

func String2ByteSlice(str string) (bs []byte) {
strHdr := (*reflect.StringHeader)(unsafe.Pointer())
sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer())

// Is it possible that the str value is allocated on stack
// and the stack grows at this moment, so the address value
// stored in strHdr.Data will become obsoleted?

sliceHdr.Data = strHdr.Data
sliceHdr.Len = strHdr.Len
sliceHdr.Cap = strHdr.Len

runtime.KeepAlive()

return
}

-- 
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/237ef013-c11e-47e9-9436-d2bf59c0b5e0%40googlegroups.com.

[go-nuts] Some ideas about scope declarations and variable redeclarations.

2020-03-04 Thread T L 
Now, the qualified selector form is "aPkg.Exported".
The form is the same as object selector, "aObj.Property".
Sometimes, it is not very clear for code readers to recognize
the first parts of such slectors is an import or an object.
So, I think the C++ way "aPkg::Exported" is more readable.

Let's extend the C++ denotion a bit, by using the "::foo"
to represent the identifer "foo" declared at the top
level of the current package, and using ":bar" to
represent the innermost declared identifer "bar".
The notation ":bar" is only meaningful when it is used
as a target value in a variable declaration (see below).

Suppose we can declare scope identifers, here is
an example to show the above ideas:

var a = 1
func f() {
var a = 2
{
scope x
var a = 3
{
println(::a, x:a, a, :a) // 1 2 3 3
}
}
}

(The above description is just to make the following
described new variable redeclaration syntax look natural.
In fact ":id" may only be allowed to be used as L-values
in variable declarations below.)

We all know that, although short variable declarations (x, y := a, b)
do solve some problems, they also brings some new ones.
The new problems include:
1. break the "one solution to do something" principle in Go.
   Short declarations overlap too much with standard declarations in 
functionalities.
2. short declarations brings some confusions to Go programmers, in 
particular to new gophers.
   * It is not very clear to get which identifiers are new declared
 and which are redeclared at the first glance.
   * Almost every gophers ever dropped in the famous variable shadowing
 trap caused by using short declarations. A real world example:
 https://github.com/Azure/go-ntlmssp/pull/24
   * Not all L-values suitable to act as target values are allowed
 be show up as the target values in short declarations.
 https://github.com/golang/go/issues/30318

Recently, I just got an idea which is inspired from this thread:
https://github.com/golang/go/issues/377.
The idea (almost) removes short declarations and also solves
the problems short declarations solved. More importantly,
it doesn't bring the problems short declarations brought.
However, my perception might be limited. There might be
flaws in this idea, and the idea might bring new problems.
So any criticisms are welcome.

The following code shows the logic of the idea:

package bar

func foo() {
   var x, err = f()
   ...
   // Here ":err" means the "err" declared above.
   var y, z, :err = g()
   ...
   {
   // The ":err" also means the "err" declared above.
   var w, :err = h()
   ...
   // This "err" is a new declared one.
   var m, n, err = k()
   ...
   }
}

Selectors, dereferences, element indexing, and the above
mentioned ":id" forms are allowed to show up as target values
in a variable declaration, as long as there is at least one
pure identifier in the declaration. The pure identifiers represent
new declared variables. The new variables are initialized,
others are re-assigned with new values.

type T struct {
i *int
s []int
}
var t T
var p = new(int)

func bar() {
   // "err" is new declared, others are not.
   var *p, t.i, t.s[1], :p, err = 1, p, 2, t.i, errors.New("bar")
   // *:p is not valid. In other words, :id must show up independently.
   ...
}

The := redeclaration syntax should be kept ONLY in the
simple statements in control flows, just for aesthetics reason. 
In other words, "... := ..." is totally a shorthand of
"var ... = ..." in the simple statements in control flows.

if a, b := c, d; a {
}
//<=>
if var a, b = c, d; a { // some ugly
}
// However, personally, I also think the ugly version is acceptable.

The idea should be Go 1 compatible. What I mean here is
the above proposed new redeclartion syntax may coexist with
the current standard and short variable declarations.
And it is easy to let "go fix" translate short variable
declarations into the above proposed new syntax form.
The short declarations in the simple statements
in control flows don't need to be translated.

-- 
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/3073e599-4c37-4aa7-a78a-9685eeb54252%40googlegroups.com.

[go-nuts] Re: [golang-dev] Do slice element modification operations check whether or not the modified elements are allocated on immutable zones?

2020-01-16 Thread T L 
Glad to know this. Thanks for the info.

On Thu, Jan 16, 2020 at 8:35 AM Ralph Corderoy 
wrote:

> Hi Tapir,
>
> > Do slice element modification operations check whether or not the
> > modified elements are allocated on immutable zones?
> ...
> > //var Golang = strings.Join([]string{"Go", "lang"}, "") // not cause
> panicking
> > var Golang = "Golang"   // causes
> panicking
>
> Are you aware that memory pages may have permissions such as read-only,
> and that some data may be allocated to those pages?  Look up the address
> of the data in /proc/$pid/maps.
>
> I think this topic belongs on golang-nuts; reply-to set.
>
> --
> Cheers, Ralph.
>

-- 
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/CAHbs%3DNbQ0Yp7sOuDSwmMoQucLRtiFnu4jCyCVHfWMnYRX7%2BF_w%40mail.gmail.com.

[go-nuts] Re: About the change for default "-mod=vendor" in Go 1.14

2020-01-09 Thread T L 


On Thursday, January 9, 2020 at 3:38:56 AM UTC-5, T L wrote:
>
> Yes, when I change the "go 1.13" directive to "go 1.14", it suggests I 
> need to run 'go mod vendor' to sync.
> After the sync, it works. Thanks for the help.
>
> So if the directive is 1.13, no default "-mod=vendor" compiler flag is 
> set? And not any message is suggested?
>
> On Wednesday, January 8, 2020 at 11:51:59 AM UTC-5, Sean Liao wrote:
>>
>> works for me when tested with gp1.14beta1, are you sure your go.mod has 
>> the  "go 1.14" directive?
>> go's tooling currently assumes vendor is a full local copy of all code 
>> needed to build a module
>> with modules the recommended way is to have your patched  / unavailable 
>> module somewhere else
>> and point to it with either standard require or a replace
>>
>
> This should work, but it is to tedious, for there are tons of old 
> dependency packages.
> I need to create tons of go.mod files under those package folders and add 
> tons of replace lines in the main go.mod file.
>
> If Go SDK 1.14+ also support a special folder vendor_legacy, then things 
> would become simpler.
>

I rearranged the folder structures of my projects. It looks things are not 
that bad.
The last versions of most of the dependencies still keep API capabilities.
There are only about 5 packages need the replace line hack.

 

-- 
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/df4f1b4c-ed85-4659-9e5d-dab025129c00%40googlegroups.com.

[go-nuts] Re: About the change for default "-mod=vendor" in Go 1.14

2020-01-09 Thread T L 
Yes, when I change the "go 1.13" directive to "go 1.14", it suggests I need 
to run 'go mod vendor' to sync.
After the sync, it works. Thanks for the help.

So if the directive is 1.13, no default "-mod=vendor" compiler flag is set? 
And not any message is suggested?

On Wednesday, January 8, 2020 at 11:51:59 AM UTC-5, Sean Liao wrote:
>
> works for me when tested with gp1.14beta1, are you sure your go.mod has 
> the  "go 1.14" directive?
> go's tooling currently assumes vendor is a full local copy of all code 
> needed to build a module
> with modules the recommended way is to have your patched  / unavailable 
> module somewhere else
> and point to it with either standard require or a replace
>

This should work, but it is to tedious, for there are tons of old 
dependency packages.
I need to create tons of go.mod files under those package folders and add 
tons of replace lines in the main go.mod file.

If Go SDK 1.14+ also support a special folder vendor_legacy, then things 
would become simpler.

-- 
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/635dcc08-8246-41b1-9e97-220834b704f2%40googlegroups.com.

[go-nuts] About the change for default "-mod=vendor" in Go 1.14

2020-01-08 Thread T L 
 The release notes (https://tip.golang.org/doc/go1.14) says

When the main module contains a top-level vendor directory and its go.mod 
file specifies go 1.14 or higher, the go command now defaults to -mod=vendor 
for operations that accept that flag. A new value for that flag, -mod=mod, 
causes the go command to instead load modules from the module cache (as 
when no vendor directory is present). 


When -mod=vendor is set (explicitly or by default), the go command now 
verifies that the main module's vendor/modules.txt file is consistent with 
its go.mod file. 

I checked it with Go SDK 1.14 beta 1, and it seems the go command doesn't 
behave as the above described.
After I run "go mod vendor", all the dependencies are placed under the 
vendor folder with a modules.txt file.
Then I remove all cached modules from GOPATH and disconnect the network, 
and run "go build" again,
the command still tries to connect network to download the dependency 
modules and it fails for sure.
But "go build -mod=vendor" runs okay. Isn't "go build" equivalent to "go 
build -mod=vendor" since Go SDK 1.14?


Beside this, would this break the semantic of the vendor folder?
Now, for many of my projects, I use the vendor folder as a 
package-search-priority folder.
I have modified some packages in the vendor, and many of the packages have 
disappeared from the internet.
Is there a way to let these projects continue compiling okay with Go SDK 
1.14+?

-- 
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/0e8a3357-d9c6-496a-ad9e-358abea3e5d8%40googlegroups.com.

Re: [go-nuts] playground behaves different from local machine

2019-12-23 Thread T L 
Looks the multiple trick is not a theory. That is cool!

I don't know if this is an issue known for a long time.
If it is not, I would file an issue some time later.

On Mon, Dec 23, 2019 at 1:04 PM Axel Wagner 
wrote:

> Sorry for the off-list response, that was unintentional.
>
> I think it might be okay, but I could also think of a couple of reasons
> against it. AFAIK, Go programs for the playground are compiled with a
> patched stdlib (at least they used to be, to do the faketime-stuff. I don't
> know if we're already at a point where the playground needs *no* custom
> patches anymore). If so, the code in GOROOT might or might not be the same
> as the one used to compile the code, which might be confusing. There's also
> the general "just that there's no reason *not* to do X isn't a reason *to
> do* X" (i.e. the conservative approach of Go in general). But really, I
> can't answer what ought to be or what will be - just what is :) If you feel
> this is a use-case that should be supported, it might be worthwhile to file
> an issue (which can get an authoritative response).
>
> And just FYI (I'm not saying it's a practical approach here), it is
> theoretically possible to make the program work today, using the
> playground's support for multiple files:
> https://play.golang.org/p/KLZR7NlVZNX
> Though you probably also need to add some playground-specific code to set
> environment variables or things like that.
>
> On Mon, Dec 23, 2019 at 3:37 PM T L  wrote:
>
>>
>> > However, the playground has no GOROOT or build cache or anything
>> available: https://play.golang.org/p/RPGwtZSJSPQ
>>
>> But, isn't it ok to let the playground own a GOROOT?
>>
>> On Mon, Dec 23, 2019 at 5:47 AM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> Parsing is not the problem, type-checking is. For that, the
>>> type-information of the imported packages (in this case "fmt") must be
>>> loaded from somewhere. However, the playground has no GOROOT or build cache
>>> or anything available: https://play.golang.org/p/RPGwtZSJSPQ
>>> There will always be programs that don't run on the playground but run
>>> locally, FWIW. That's the nature of a sandbox :)
>>>
>>> On Sun, Dec 22, 2019 at 5:58 PM T L  wrote:
>>>
>>>> The code from the std go/types package parses the demo code well on
>>>> local machine, but not in playground:
>>>>
>>>> https://play.golang.org/p/BlHHgdscaXj
>>>>
>>>> What is the cause?
>>>>
>>>> --
>>>> 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/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>
>

-- 
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/CAHbs%3DNb%2BbjV5Mt72B9dFHiC__9CfFnuKa4afBt%3DsdE74cuHujg%40mail.gmail.com.

Re: [go-nuts] playground behaves different from local machine

2019-12-23 Thread T L 
;(, looks the last comment doesn't appear in go-nuts.

On Mon, Dec 23, 2019 at 9:37 AM T L  wrote:

>
> > However, the playground has no GOROOT or build cache or anything
> available: https://play.golang.org/p/RPGwtZSJSPQ
>
> But, isn't it ok to let the playground own a GOROOT?
>
> On Mon, Dec 23, 2019 at 5:47 AM Axel Wagner 
> wrote:
>
>> Parsing is not the problem, type-checking is. For that, the
>> type-information of the imported packages (in this case "fmt") must be
>> loaded from somewhere. However, the playground has no GOROOT or build cache
>> or anything available: https://play.golang.org/p/RPGwtZSJSPQ
>> There will always be programs that don't run on the playground but run
>> locally, FWIW. That's the nature of a sandbox :)
>>
>> On Sun, Dec 22, 2019 at 5:58 PM T L  wrote:
>>
>>> The code from the std go/types package parses the demo code well on
>>> local machine, but not in playground:
>>>
>>> https://play.golang.org/p/BlHHgdscaXj
>>>
>>> What is the cause?
>>>
>>> --
>>> 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/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>

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

[go-nuts] Re: playground behaves different from local machine

2019-12-23 Thread T L 

> by Axel Wagner:
> However, the playground has no GOROOT or build cache or anything 
available: https://play.golang.org/p/RPGwtZSJSPQ

But, isn't it ok to let the playground own a GOROOT?

-- 
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/7284cf89-2e1b-4a73-9bcd-22b2e7f56d3c%40googlegroups.com.

Re: [go-nuts] playground behaves different from local machine

2019-12-23 Thread T L 
> However, the playground has no GOROOT or build cache or anything
available: https://play.golang.org/p/RPGwtZSJSPQ

But, isn't it ok to let the playground own a GOROOT?

On Mon, Dec 23, 2019 at 5:47 AM Axel Wagner 
wrote:

> Parsing is not the problem, type-checking is. For that, the
> type-information of the imported packages (in this case "fmt") must be
> loaded from somewhere. However, the playground has no GOROOT or build cache
> or anything available: https://play.golang.org/p/RPGwtZSJSPQ
> There will always be programs that don't run on the playground but run
> locally, FWIW. That's the nature of a sandbox :)
>
> On Sun, Dec 22, 2019 at 5:58 PM T L  wrote:
>
>> The code from the std go/types package parses the demo code well on local
>> machine, but not in playground:
>>
>> https://play.golang.org/p/BlHHgdscaXj
>>
>> What is the cause?
>>
>> --
>> 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/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAHbs%3DNbOnatXKQ8Uy8DoxJXeVvzOS%3DoT-dAQRhjNeYRduOQKYw%40mail.gmail.com.

[go-nuts] playground behaves different from local machine

2019-12-22 Thread T L 
The code from the std go/types package parses the demo code well on local 
machine, but not in playground:

https://play.golang.org/p/BlHHgdscaXj

What is the cause?

-- 
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/a0266c54-2e3f-496f-a640-9be2d97fa6ab%40googlegroups.com.

[go-nuts] Some questions on using the "golang.org/x/tools/go/packages" package

2019-11-23 Thread T L 
The packages.Config.ParseFileParseFile docs 
(https://godoc.org/golang.org/x/tools/go/packages#Config) says

// An application may supply a custom implementation of ParseFile
// to change the effective file contents or the behavior of the parser,
// or to modify the syntax tree. For example, selectively eliminating
// unwanted function bodies can significantly accelerate type checking.


But how to exactly do to avoid parsing function bodies? And how to set the 
go/types.Config.IgnoreFuncBodies
to false when calling packages.Load() to avoid checking function bodies? I 
failed to find the option to set it.


The packages.Config.Tests docs says

// If Tests is set, the loader includes not just the packages
// matching a particular pattern but also any related test packages,
// including test-only variants of the package and the test executable.
//
// For example, when using the go command, loading "fmt" with Tests=true
// returns four packages, with IDs "fmt" (the standard package),
// "fmt [fmt.test]" (the package as compiled for the test),
// "fmt_test" (the test functions from source files in package fmt_test),
// and "fmt.test" (the test binary).


What do the "the package as compiled for the test" and "the test binary" 
mean?

-- 
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/f4116dc3-9c45-4a28-85d9-d4690e5c1eea%40googlegroups.com.

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-10-05 Thread T L 


On Saturday, October 5, 2019 at 6:28:37 AM UTC-4, ohir wrote:
>
> On Fri, 4 Oct 2019 15:15:30 -0700 (PDT) 
> T L > wrote: 
>
> > > If your out <-v must be dependent of ctx.Done not being ready you 
> > > must resolve this dependency by other means. Eg. by selecting for it 
> > > in separate select before. 
> > >   
>
> > It is not a must. It just tries to select ctx.Done if possible. 
> > In fact, if the two evens are independent with each other, 
> > there is no way to absolutely ensure the must. 
>
> If it is not a must, then introducing an order at best is void (of no use) 
> at worst it makes sure for a race condition by its very presence. 
>
> For coming together events A and B that are independent: 
>
> - proceeding them in either order A, B or in order B, A should result 
> in the same final state as if they came in said order. Hence select's 
> case ordering is unnecessary. 
>
> - otherwise (that final state depends on order) we have a dependency and 
> the 
> select switch, by language design, is not the right construct to write 
> this 
> dependency down. 
>
> FYI, AFAIR: the "1+default" select case is optimized by the compiler, so 
> now it is more 
> efficient to have "priority" written explicit than to have more than one 
> case in 
> a select (what turns on all the heavy machinery of a full select block). 
>

I do agree. I really ever benchmarked the difference, the two-select-blocks 
version
only consumes about 5% more CPU. So, for this use case, the main benefit of
supporting priority-case-order select block is it makes code look less 
verbose.

As for another use case shown in the first comment, 

select {
case <-done: return
case queue <- data:
}

In fact, the code shown in that comment is not perfect, because in other 
goroutines,
the following two lines

close(done)
close(queue)

might present a different order from they look in code. (I didn't find any 
official Go
documentation makes the guarantee that they will be closed by their 
appearance order in code.)

But if there is a way which can guarantee that "done" will always be closed 
before "queue"
(in the views of any goroutines), then

select(ordered) {
case <-done: return
case queue <- data:
}

can be executed safely in multiple goroutines concurrently.
This will simplify the implementations for some situations.

Under the current select mechanism, without supporting priority-case-order 
select block,
programmers need to make more effort to implement the same situations.
(Maybe this is not bad, as programing with channels is really fun. ;D)

 

>
> Hope this helps, 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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/192244b6-61d1-43c5-9b16-992a3d02f756%40googlegroups.com.

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 
> Please, drop it. You don't know what you're talking about. I've been 
amazed at how patient everyone has been. I think it's time to be more blunt 
in pointing out you don't understand concurrency and independent events.

Maybe. But you don't know I'm talking about for sure.

-- 
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/6521f318-b608-43f6-a15b-48c459bcd376%40googlegroups.com.

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 


On Friday, October 4, 2019 at 5:40:08 PM UTC-4, ohir wrote:
>
> On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) 
> T L > wrote: 
>
> > One priority-order select block is not only cleaner than two 
> random-order 
> > select blocks, but also more efficient. 
>
> It is neither. 
>
> 1. It is not cleaner, because you would need to somehow denote priorities. 
> If you think now about "in written order", you should think of the most 
> frequent 
> cases that you do not want to have all five, ten, twenty cases be serviced 
> on order. Not to mention that down the road someone might introduce an 
> unnoticeable bug for pure aesthetic reasons. 
>
> 2. It is not more efficient, it is less efficient because every select 
> operation 
> would need at least a "priority comparison" op, or - in general case - a 
> sort 
> op, because not only two channels can be ready, it may happen that all of 
> them will. This would have to run for every select then, unless 
> introduced by a "select_with_priorities" keyword. 
>
>
select(ordered)  {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}

is undoubtedly more efficient than 

select(randomized) {
case <-ctx.Done():
return ctx.Err()
default:
}
select(randomized)  {
case <-ctx.Done():
return ctx.Err()
case out <- v:
}

Not only one less try-receive operation is saved,
but also is the step 2 described in 
https://go101.org/article/channel.html#select-implementation saved.

 

> 3. Others tried to no avail, I will too in other words: 
>
> The select switch is deliberately randomized because language creators 
> envisioned that otherwise someone would be "smart" and will use 
> ordering to impose a **dependency** where it should not be made. 
>
> Channel operations serviced by select are treated as sourced 
> from **independent** events. Period. 
>
> If your out <-v must be dependent of ctx.Done not being ready you 
> must resolve this dependency by other means. Eg. by selecting for it 
> in separate select before. 
>

It is not a must. It just tries to select ctx.Done if possible.
In fact, if the two evens are independent with each other,
there is no way to absolutely ensure the must.
 

>
> Hope this helps, 
>

You can read the first comment in this thread for another use case of 
priority-order 
select block.
 

>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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/0c9aaa9b-ea9d-49f5-a1b4-4f94ee0de424%40googlegroups.com.

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 


On Friday, October 4, 2019 at 4:38:36 PM UTC-4, Marcin Romaszewicz wrote:
>
> What he's trying to say is that it is pointless to order select cases in 
> this example, because it is impossible to guarantee ordering in an 
> asynchronous system.
>
> You have two asynchronous data streams, ctx.Done() and "v", in that 
> example above.
>
> Generally, those select cases will happen one by one, as those 
> asynchronous channels deliver data. If "v" is ready first, shortly before 
> ctx.Done(), then v will be selected first, followed by ctx.Done(). It 
> doesn't matter that ctx.Done() wants to be higher priority, "v" arrived 
> first, before ctx.Done() was posted, so it's handled first. If ctx.Done() 
> happens first, the reverse happens. The only interesting case is when both 
> "v" and ctx.Done() are ready at the same time, which will be unlikely in 
> practice.
>
> If ctx.Done() and "v" happen together, so that both cases of that select 
> statement are available simultaneously, then sure, you can order them, but 
> this will happen very infrequently, and you still MUST handle the case 
> where "v" happens first, very close to ctx.Done(). So, if you MUST handle 
> this case, you don't really need to bother with statement priority, since 
> if your code is written well, this ordering won't matter. ctx.Done() might 
> happen while you're in the middle of handling "v", for example.
>
>
This is not frequently, but not rare.
 

> The desire to have priority to select statements presumes that you have 
> several cases happen at the same time, which isn't how this will generally 
> work. If you want to order things in a select, you have to change how it 
> behaves, and order events within a particular time window. Say you write a 
> poller which samples the event queue every second. If you do this, then 
> sure, you can order things however you want, but the cost you pay is that 
> second of buffering latency.
>

Yes, select case priority tries to always select one case of the two cases
when both the two cases are available. Without this feature, to achieve
this goal, we often need two select blocks (sorry, I mis-typed select block
as select case in my last comment). 

One priority-order select block is not only cleaner than two random-order
select blocks, but also more efficient.

>
>
> On Fri, Oct 4, 2019 at 1:19 PM T L > 
> wrote:
>
>>
>>
>> On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>>>
>>> Because ctx.Done() and v being ready for read are independent events. 
>>> You can not impose ordering on them unless there is an outer mutex that 
>>> both events are subject to.
>>>
>>> As an aside, this is why I think the best 'concurrent software' 
>>> developers are those that have been exposed to at least some hardware 
>>> design. Many programmers think in terms of 1 and 0 and everything being 
>>> ordered. This is certainly not the case in hardware, nor concurrent 
>>> software. (For example, in computer hardware, the clock/sync line is what 
>>> is used as the outer controlling event, but still things like propagation 
>>> times, etc. make even this simple statement not fully correct).
>>>
>>>
>> Still not understanding what you new saying. ;D
>>
>> Again, select case priority enables use to deduce two select cases
>> to one select case in coding in many scenarios.
>> This often leads to cleaner code, avoid can avoid the harm caused
>> by missing a try-receive select case.
>>
>>  
>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Oct 4, 2019 2:44 PM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases 
>>>
>>>
>>>
>>> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>>>
>>>> You still are not understanding  proper concurrent design. Priority 
>>>> select cases do not matter in the case of asynchronous external events. 
>>>>
>>>
>>> It at least avoids code verbosity and improves code quantity..
>>>
>>> BTW, I don't understand what you said. Could you elaborate more?
>>>
>>>
>>>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>>>
>>>> 
>>>> I just found an example in the "context" package docs:
>>>>
>>>> //  // Stream generates values with DoSomething and sends them to out
>>>> //  // until DoSomething returns an error or ctx.Done is closed.
&

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 


On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>
> Because ctx.Done() and v being ready for read are independent events. You 
> can not impose ordering on them unless there is an outer mutex that both 
> events are subject to.
>
> As an aside, this is why I think the best 'concurrent software' developers 
> are those that have been exposed to at least some hardware design. Many 
> programmers think in terms of 1 and 0 and everything being ordered. This is 
> certainly not the case in hardware, nor concurrent software. (For example, 
> in computer hardware, the clock/sync line is what is used as the outer 
> controlling event, but still things like propagation times, etc. make even 
> this simple statement not fully correct).
>
>
Still not understand what you new saying means. ;D

Again, select case priority enables use to deduce two select cases
to one select case in coding in many scenarios.
This often leads to cleaner code, and sometimes can avoid the harm 
caused by missing an essential try-receive select case.

 

> -Original Message- 
> From: T L 
> Sent: Oct 4, 2019 2:44 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases 
>
>
>
> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>
>> You still are not understanding  proper concurrent design. Priority 
>> select cases do not matter in the case of asynchronous external events. 
>>
>
> It at least avoids code verbosity and improves code quantity..
>
> BTW, I don't understand what you said. Could you elaborate more?
>
>
>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>
>> 
>> I just found an example in the "context" package docs:
>>
>> //  // Stream generates values with DoSomething and sends them to out
>> //  // until DoSomething returns an error or ctx.Done is closed.
>> //  func Stream(ctx context.Context, out chan<- Value) error {
>> //   for {
>> //   v, err := DoSomething(ctx)
>> //   if err != nil {
>> //   return err
>> //   }
>> //   select {
>> //   case <-ctx.Done():
>> //   return ctx.Err()
>> //   case out <- v:
>> //   }
>> //   }
>> //  }
>>
>> It looks the send "out <- v" still has a possibility to be executed,
>> even if "ctx.Done()" is closed.
>> But if Go supports select case priority, then this will never happen.
>>
>>
>>
>> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, T L wrote:
>>>
>>> The old thread: 
>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>
>>> Go channels are flexible, but in practice, I often encountered some 
>>> situations in which channel are hard to use.
>>> Given an example:
>>>
>>> import "math/rand"
>>>
>>> type Producer struct {
>>> data   chan int
>>> closed chan struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p :=  {
>>> data:   make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>> 
>>> go p.run()
>>> 
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a higher 
>>> priority than the second one,
>>> then coding will be much happier for the use cases like the above one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a 
>>> channel.
>>> * for senders, data will

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 


On Friday, October 4, 2019 at 4:09:09 PM UTC-4, Robert Engels wrote:
>
> Because ctx.Done() and v being ready for read are independent events. You 
> can not impose ordering on them unless there is an outer mutex that both 
> events are subject to.
>
> As an aside, this is why I think the best 'concurrent software' developers 
> are those that have been exposed to at least some hardware design. Many 
> programmers think in terms of 1 and 0 and everything being ordered. This is 
> certainly not the case in hardware, nor concurrent software. (For example, 
> in computer hardware, the clock/sync line is what is used as the outer 
> controlling event, but still things like propagation times, etc. make even 
> this simple statement not fully correct).
>
>
Still not understanding what you new saying. ;D

Again, select case priority enables use to deduce two select cases
to one select case in coding in many scenarios.
This often leads to cleaner code, avoid can avoid the harm caused
by missing a try-receive select case.

 

> -Original Message- 
> From: T L 
> Sent: Oct 4, 2019 2:44 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] Re: An old problem: lack of priority select cases 
>
>
>
> On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>>
>> You still are not understanding  proper concurrent design. Priority 
>> select cases do not matter in the case of asynchronous external events. 
>>
>
> It at least avoids code verbosity and improves code quantity..
>
> BTW, I don't understand what you said. Could you elaborate more?
>
>
>> On Oct 4, 2019, at 1:46 PM, T L  wrote:
>>
>> 
>> I just found an example in the "context" package docs:
>>
>> //  // Stream generates values with DoSomething and sends them to out
>> //  // until DoSomething returns an error or ctx.Done is closed.
>> //  func Stream(ctx context.Context, out chan<- Value) error {
>> //   for {
>> //   v, err := DoSomething(ctx)
>> //   if err != nil {
>> //   return err
>> //   }
>> //   select {
>> //   case <-ctx.Done():
>> //   return ctx.Err()
>> //   case out <- v:
>> //   }
>> //   }
>> //  }
>>
>> It looks the send "out <- v" still has a possibility to be executed,
>> even if "ctx.Done()" is closed.
>> But if Go supports select case priority, then this will never happen.
>>
>>
>>
>> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, T L wrote:
>>>
>>> The old thread: 
>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>
>>> Go channels are flexible, but in practice, I often encountered some 
>>> situations in which channel are hard to use.
>>> Given an example:
>>>
>>> import "math/rand"
>>>
>>> type Producer struct {
>>> data   chan int
>>> closed chan struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p :=  {
>>> data:   make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>> 
>>> go p.run()
>>> 
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a higher 
>>> priority than the second one,
>>> then coding will be much happier for the use cases like the above one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a 
>>> channel.
>>> * for senders, data will never be sent to clo

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 


On Friday, October 4, 2019 at 3:32:31 PM UTC-4, Robert Engels wrote:
>
> You still are not understanding  proper concurrent design. Priority select 
> cases do not matter in the case of asynchronous external events. 
>

It at least avoids code verbosity and improves code quantity..

BTW, I don't understand what you said. Could you elaborate more?


> On Oct 4, 2019, at 1:46 PM, T L > wrote:
>
> 
> I just found an example in the "context" package docs:
>
> //  // Stream generates values with DoSomething and sends them to out
> //  // until DoSomething returns an error or ctx.Done is closed.
> //  func Stream(ctx context.Context, out chan<- Value) error {
> //for {
> //v, err := DoSomething(ctx)
> //if err != nil {
> //return err
> //}
> //select {
> //case <-ctx.Done():
> //return ctx.Err()
> //case out <- v:
> //}
> //}
> //  }
>
> It looks the send "out <- v" still has a possibility to be executed,
> even if "ctx.Done()" is closed.
> But if Go supports select case priority, then this will never happen.
>
>
>
> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, T L wrote:
>>
>> The old thread: 
>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>
>> Go channels are flexible, but in practice, I often encountered some 
>> situations in which channel are hard to use.
>> Given an example:
>>
>> import "math/rand"
>>
>> type Producer struct {
>> data   chan int
>> closed chan struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p :=  {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher 
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to 
>> implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/b7a14153-253e-43c4-bda5-96079601465f%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/b7a14153-253e-43c4-bda5-96079601465f%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/77fca2e9-120d-45e0-8ae9-5d24b63827bd%40googlegroups.com.

[go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 


On Friday, October 4, 2019 at 2:46:36 PM UTC-4, T L wrote:
>
> I just found an example in the "context" package docs:
>
> //  // Stream generates values with DoSomething and sends them to out
> //  // until DoSomething returns an error or ctx.Done is closed.
> //  func Stream(ctx context.Context, out chan<- Value) error {
> //for {
> //v, err := DoSomething(ctx)
> //if err != nil {
> //return err
> //}
> //select {
> //case <-ctx.Done():
> //return ctx.Err()
> //case out <- v:
> //}
> //}
> //  }
>
> It looks the send "out <- v" still has a possibility to be executed,
> even if "ctx.Done()" is closed.
> But if Go supports select case priority, then this will never happen.
>
>
This might be some over absolutely.
There is still a samll chance "ctx.Done()" is being closed when "out <- v" 
is being executed.

Should the docs be changed to:

//  func Stream(ctx context.Context, out chan<- Value) error {
//  for {
//  v, err := DoSomething(ctx)
//  if err != nil {
//  return err
//  }
//  select {
//  case <-ctx.Done():
//  return ctx.Err()
//  case default:
//  }
//  select {
//  case <-ctx.Done():
//  return ctx.Err()
//      case out <- v:
//  }
//  }
//  }


 

>
>
> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, T L wrote:
>>
>> The old thread: 
>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>
>> Go channels are flexible, but in practice, I often encountered some 
>> situations in which channel are hard to use.
>> Given an example:
>>
>> import "math/rand"
>>
>> type Producer struct {
>> data   chan int
>> closed chan struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p :=  {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher 
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to 
>> implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>

-- 
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/c8dca21d-57c5-4942-8f05-062a78f64dbc%40googlegroups.com.

[go-nuts] Re: An old problem: lack of priority select cases

2019-10-04 Thread T L 
I just found an example in the "context" package docs:

//  // Stream generates values with DoSomething and sends them to out
//  // until DoSomething returns an error or ctx.Done is closed.
//  func Stream(ctx context.Context, out chan<- Value) error {
//  for {
//  v, err := DoSomething(ctx)
//  if err != nil {
//  return err
//  }
//  select {
//  case <-ctx.Done():
//  return ctx.Err()
//  case out <- v:
//  }
//  }
//  }

It looks the send "out <- v" still has a possibility to be executed,
even if "ctx.Done()" is closed.
But if Go supports select case priority, then this will never happen.



On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, T L wrote:
>
> The old thread: 
> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>
> Go channels are flexible, but in practice, I often encountered some 
> situations in which channel are hard to use.
> Given an example:
>
> import "math/rand"
>
> type Producer struct {
> data   chan int
> closed chan struct{}
> }
>
> func NewProducer() *Producer {
> p :=  {
> data:   make(chan int),
> closed: make(chan struct{}),
> }
> 
> go p.run()
> 
> return p
> }
>
> func (p *Produce) Stream() chan int {
> return p.data
> }
>
> func (p *Producer) run() {
> for {
> // If non-blocking cases are selected by their appearance order,
> // then the following slect block is a perfect use.
> select {
> case(0) <-p.closed: return
> case p.data <- rand.Int():
> }
> }
> }
>
> func (p *Produce) Clsoe() {
> close(p.closed)
> close(p.data)
> }
>
> func main() {
> p := NewProducer()
> for n := p.Stream() {
> // use n ...
> }
> }
>
>
> If the first case in the select block in the above example has a higher 
> priority than the second one,
> then coding will be much happier for the use cases like the above one.
>
> In short, the above use case requires:
> * for receivers, data streaming end is notified by the close of a channel.
> * for senders, data will never be sent to closed channel.
>
> But, as Go 1 doesn't support priority select cases, it is much tedious to 
> implement the code
> satisfying the above listed requirements. The final implementation is 
> often very ugly and inefficient.
>
> Does anyone else also experience the pain?
>

-- 
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/b7a14153-253e-43c4-bda5-96079601465f%40googlegroups.com.

Re: [go-nuts] A confusion on the cgo document.

2019-10-02 Thread T L 
Got it. Thanks, Ian.

On Mon, Sep 30, 2019 at 9:10 PM Ian Lance Taylor  wrote:

> On Mon, Sep 30, 2019 at 1:01 AM T L  wrote:
> >
> > https://golang.org/cmd/cgo/#hdr-Passing_pointers
> >
> > When passing a pointer to a field in a struct, the Go memory in question
> is the memory occupied by the field, not the entire struct. When passing a
> pointer to an element in an array or slice, the Go memory in question is
> the entire array or the entire backing array of the slice.
> >
> > Why do structs and arrays have this difference?
>
> Because it's normal to call a C function with ([0], len(a)) to let
> the C function examine all elements of the array or slice.  It's not
> normal to call a C function with () and expect the C function to
> examine all elements of the struct; if the C function wants to examine
> all elements of a struct, you would pass , not   But you don't
> want to pass  to a C function; with the way C pointers work, you
> want to pass a pointer to an element, not a pointer to the array or
> slice.  (Admittedly passing a pointer to an array would work anyhow,
> but passing a pointer to a slice would not.)
>
> 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/CAHbs%3DNbw7Yyx%2BO6E6q8AfD6VMHO2RpXDd5%2B3-rJng8UsQ4POQw%40mail.gmail.com.

[go-nuts] A confusion on the cgo document.

2019-09-30 Thread T L 
https://golang.org/cmd/cgo/#hdr-Passing_pointers

When passing a pointer to a field in a struct, the Go memory in question is 
the memory occupied by the field, not the entire struct. When passing a 
pointer to an element in an array or slice, the Go memory in question is 
the entire array or the entire backing array of the slice. 

Why do structs and arrays have this difference? 

-- 
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/c8d7b2da-53cc-4350-afda-07d474c4b980%40googlegroups.com.

Re: [go-nuts] Go playfield has no time limit now?

2019-09-25 Thread T L 


On Wednesday, September 25, 2019 at 7:52:31 AM UTC-4, Axel Wagner wrote:
>
> (note, that the playground never responded in realtime - the process was 
> run to its conclusion and a JSON doc containing all the output with 
> appropriate timing was served and replayed using javascript. See 
> https://blog.golang.com/playground)
>

That is cool! Thanks for the information.
 

>
> On Wed, Sep 25, 2019 at 1:50 PM Axel Wagner  > wrote:
>
>> It obviously still has a time-limit: 
>> https://play.golang.org/p/GH67vNtpZyp (also, your program is an endless 
>> loop too)
>> What changed, I guess, is that output produced before the process got cut 
>> of is now actually served.
>>
>> On Wed, Sep 25, 2019 at 1:29 PM T L > 
>> wrote:
>>
>>> For example: https://play.golang.org/p/YhWgTpzGj0T
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golan...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/14f950d2-a23e-4770-a155-52ec7ace7440%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/14f950d2-a23e-4770-a155-52ec7ace7440%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/0808c76d-4aa1-4e38-9e5e-e66cdfefb5b0%40googlegroups.com.

[go-nuts] Go playfield has no time limit now?

2019-09-25 Thread T L 
For example: https://play.golang.org/p/YhWgTpzGj0T

-- 
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/14f950d2-a23e-4770-a155-52ec7ace7440%40googlegroups.com.

[go-nuts] Re: request for feedback: another websocket server implementation

2019-09-18 Thread T L 
Just for reference. Here are other Go websocket implementations:
* Gorilla WebSocket https://github.com/gorilla/websocket
* https://github.com/nhooyr/websocket
* https://github.com/gobwas/ws
* x/net/websocket https://godoc.org/golang.org/x/net/websocket

On Tuesday, September 17, 2019 at 6:29:08 PM UTC-4, Jochen Voss wrote:
>
> Dear all,
>
> Because I wanted to learn about the websocket protocol, I have implemented 
> a websocket server in Go:
>
> code: https://github.com/seehuhn/go-websocket
> documentation: https://godoc.org/seehuhn.de/go/websocket
>
> I would be happy to receive feedback about my code.
>
> Specific questions:
>
> - Does the API look reasonable?  Anything to improve?
>
> - I use the function readMultiplexer (at the end of reader.go) to read 
> all frame headers from the network connection, and to make sure that the 
> readers of the frame bodies don't step on each other's feet.  Similarly, 
> the function writeMultiplexer (at the end of writer.go) coordinates all 
> writers and performs all writes to the network connection.  This system is 
> held together by a tangle of go channels.  The code is much messier than I 
> would like it to be.  Is there a way to structure such code so that it is 
> easier to reason about, so that I can be more confident that it is correct?  
> The bits a struggled most with are the various ways the connection can be 
> closed (closed by server explicitly or because of a protocol error, closed 
> by client with/without close frame).
>
> - I attempted to profile the code, to find whether there are any 
> performance bottlenecks.  My code for this is in websocket_test.go 
> (function BenchmarkEcho), but the profiles then only ever show the code 
> waiting for data on go channels or for data from the network.  My feeling 
> is that I was really benchmarking the network connection and not my code.  
> Is there a way to improve BenchmarkEcho to get more meaningful results?
>
> Many thanks,
> Jochen
>
>

-- 
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/a27de519-8864-46b9-ba35-733d45f1d49b%40googlegroups.com.

Re: [go-nuts] Who can explain more on the "upgrade" module version selector?

2019-09-15 Thread T L 


On Sunday, September 15, 2019 at 12:35:27 PM UTC-4, Axel Wagner wrote:
>
> On Sun, Sep 15, 2019 at 6:11 PM T L > 
> wrote:
>
>> Do you mean if there is already a require line in the go.mod file,
>> which requires a non-formal tagged version,
>> then "go get ...@latest" will rollback the require to the latest formal 
>> tagged version,
>> but "go get ...@upgrade" will not?
>>
>
> AIUI (not a specialist, didn't try): *If* that "non-formal tagged version" 
> is a child-commit of the latest tagged version, then yes, that's what I 
> mean. If it isn't, then either will use the tagged version.
>

Thanks for helping me get the doc says!
 

>  
>
>>
>>
>>  
>>
>>>
>>> On Sat, Sep 14, 2019 at 10:35 AM T L  wrote:
>>>
>>>> The doc https://golang.org/cmd/go/#hdr-Module_queries says:
>>>>
>>>> The string "upgrade" is like "latest", but if the module is currently 
>>>>> required at a later version than the version "latest" would select (for 
>>>>> example, a newer pre-release version), "upgrade" will select the later 
>>>>> version instead. 
>>>>>
>>>>
>>>> But I don't very get it. Who can explain it more to let me understand 
>>>> it better?
>>>>
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to golan...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/6a4ace13-3ad8-4154-846c-e8d5f343b022%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/6a4ace13-3ad8-4154-846c-e8d5f343b022%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f17a504d-95da-46b4-ad0c-3b544e579176%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f17a504d-95da-46b4-ad0c-3b544e579176%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/2ce13c39-fe03-4795-b192-6cba50f69aab%40googlegroups.com.

Re: [go-nuts] Who can explain more on the "upgrade" module version selector?

2019-09-15 Thread T L 


On Saturday, September 14, 2019 at 11:04:06 AM UTC-4, Axel Wagner wrote:
>
> Can you explain more specifically what you don't understand?
> The example seems pretty clear: Say you currently require the latest 
> master commit (e.g. by using a pseudo-version), which is a couple commits 
> ahead of the latest released version, then "latest" will select the 
> release, while "upgrade" will select the current commit.
>

Do you mean if there is already a require line in the go.mod file,
which requires a non-formal tagged version,
then "go get ...@latest" will rollback the require to the latest formal 
tagged version,
but "go get ...@upgrade" will not?


 

>
> On Sat, Sep 14, 2019 at 10:35 AM T L > 
> wrote:
>
>> The doc https://golang.org/cmd/go/#hdr-Module_queries says:
>>
>> The string "upgrade" is like "latest", but if the module is currently 
>>> required at a later version than the version "latest" would select (for 
>>> example, a newer pre-release version), "upgrade" will select the later 
>>> version instead. 
>>>
>>
>> But I don't very get it. Who can explain it more to let me understand it 
>> better?
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/6a4ace13-3ad8-4154-846c-e8d5f343b022%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/6a4ace13-3ad8-4154-846c-e8d5f343b022%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/f17a504d-95da-46b4-ad0c-3b544e579176%40googlegroups.com.

[go-nuts] Who can explain more on the "upgrade" module version selector?

2019-09-14 Thread T L 
The doc https://golang.org/cmd/go/#hdr-Module_queries says:

The string "upgrade" is like "latest", but if the module is currently 
> required at a later version than the version "latest" would select (for 
> example, a newer pre-release version), "upgrade" will select the later 
> version instead. 
>

But I don't very get it. Who can explain it more to let me understand it 
better?


-- 
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/6a4ace13-3ad8-4154-846c-e8d5f343b022%40googlegroups.com.

Re: [go-nuts] Re: If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

2019-09-14 Thread T L 


On Friday, September 13, 2019 at 3:19:55 PM UTC-4, andrey mirtchovski wrote:
>
> are you following the steps outlined below? 
>
> https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher 
>
> in particular, for a v2 (or v3) it states that the go.mod file must be 
> updated: 
>
> > Update the go.mod file to include a /v3 at the end of the module path in 
> the module directive (e.g., module github.com/my/module/v3). 
>
>
Aha, maybe I have read it, but I forgot it. Thanks for pointing the mistake 
I made.

On the other hand, I think output message is not very clear, it is even 
some misleading.
 

>
> On Fri, Sep 13, 2019 at 12:53 PM T L > 
> wrote: 
> > 
> > I really don't get how modules are got. 
> > I create another repo with all versions are module based, but it still 
> fails on getting v2. 
> > 
> > $ go get github.com/go101/mod_versions_b/v2@latest 
> > go: finding github.com/go101/mod_versions_b/v2 v2.1.1 
> > go get github.com/go101/mod_versions_b/v2@latest: module 
> github.com/go101/mod_versions_b@latest (v1.0.0) found, but does not 
> contain package github.com/go101/mod_versions_b/v2 
> > 
> > It looks, the go command found the target version v2.1.1, but it 
> downloads v1.0.0 in the end. 
> > What is the mistake I made in the process? 
> > 
> > 
> > On Friday, September 13, 2019 at 2:22:16 PM UTC-4, T L wrote: 
> >> 
> >> For example, 
> >> 
> >> $ $ go get github.com/go101/mod_versions/v3@latest 
> >> go: finding github.com/go101/mod_versions/v3 v3.1.0 
> >> go get github.com/go101/mod_versions/v3@latest: module 
> github.com/go101/mod_versions@latest (v2.0.0+incompatible) found, but 
> does not contain package github.com/go101/mod_versions/v3 
> >> 
> >> Is it required to remove all v2.x.y+incompatible versions? 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/71315e79-cbb0-4838-9c85-1ec183f7bb3f%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/e05b20ed-af0a-4ab1-9598-655a797e7fec%40googlegroups.com.

[go-nuts] Re: If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

2019-09-13 Thread T L 
I really don't get how modules are got.
I create another repo with all versions are module based, but it still 
fails on getting v2.

$ go get github.com/go101/mod_versions_b/v2@latest
go: finding github.com/go101/mod_versions_b/v2 v2.1.1
go get github.com/go101/mod_versions_b/v2@latest: module 
github.com/go101/mod_versions_b@latest (v1.0.0) found, but does not contain 
package github.com/go101/mod_versions_b/v2

It looks, the go command found the target version v2.1.1, but it downloads 
v1.0.0 in the end.
What is the mistake I made in the process?


On Friday, September 13, 2019 at 2:22:16 PM UTC-4, T L wrote:
>
> For example,
>
> $ $ go get github.com/go101/mod_versions/v3@latest
> go: finding github.com/go101/mod_versions/v3 v3.1.0
> go get github.com/go101/mod_versions/v3@latest: module 
> github.com/go101/mod_versions@latest (v2.0.0+incompatible) found, but 
> does not contain package github.com/go101/mod_versions/v3
>
> Is it required to remove all v2.x.y+incompatible versions?
>

-- 
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/71315e79-cbb0-4838-9c85-1ec183f7bb3f%40googlegroups.com.

[go-nuts] If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

2019-09-13 Thread T L 
For example,

$ $ go get github.com/go101/mod_versions/v3@latest
go: finding github.com/go101/mod_versions/v3 v3.1.0
go get github.com/go101/mod_versions/v3@latest: module 
github.com/go101/mod_versions@latest (v2.0.0+incompatible) found, but does 
not contain package github.com/go101/mod_versions/v3

Is it required to remove all v2.x.y+incompatible versions?

-- 
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/2d177077-d1a7-405f-a420-a7d28f2fc833%40googlegroups.com.

Re: [go-nuts] What happens if the hash retrieved from sumdb and the one in go.sum file of the main module are different?

2019-09-13 Thread T L 


On Thursday, September 12, 2019 at 11:58:30 AM UTC-4, T L wrote:
>
>
>
> On Wednesday, September 11, 2019 at 5:33:02 PM UTC-4, Ian Lance Taylor 
> wrote:
>>
>> The go tool reports a checksum mismatch error. 
>>
>> Ian 
>>
>
> "go help module-auth" says
>
> If a downloaded module is not yet included in go.sum and it is a publicly
> available module, the go command consults the Go checksum database to fetch
> the expected go.sum lines.
>
> and ""go help modules" says
>
> No matter the source of the modules, the go command checks downloads 
> against
> known checksums, to detect unexpected changes in the content of any 
> specific
> module version from one day to the next. This check first consults the 
> current
> module's go.sum file but falls back to the Go checksum database, 
> controlled by
> the GOSUMDB and GONOSUMDB environment variables. See 'go help module-auth'
> for details.
>
> By these explanations, is my following understanding correct?
> 1. when I "git clone" a Go program project which contains a go.mod and a 
> go.sum file.
>then sumdb will not be connected if I run "go build" under the project.
> 2. when I "go get" a package under my modules based project,
>sumdb will be connected to fetch the hash of the dependency package,
>if the fetch result and local cached dependency hash matches,
>then two hash lines will be added the go.sum file of my project,
>
>if the dependency package is also modules based, in other words,
>it has its own go.mod and go.sum files, the hashes of the dependency 
> packages
>of the dependency package will not be fetched from sumdb.
>
>
Here, for the case of the dependency module is also modules based,
will the hash lines in the go.sum file in the dependency module be copied 
directly
into the go.sum file of the man project module? Instead of fetching them 
from sumdb.

-- 
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/64b5298c-ba7f-4aaa-b57f-ed81fb7f96b5%40googlegroups.com.

Re: [go-nuts] An old problem: lack of priority select cases

2019-09-12 Thread T L 


On Thursday, September 12, 2019 at 11:22:35 AM UTC-4, trishc...@gmail.com 
wrote:
>
> Why not just set up priority blockers against the one


What does priority blockers mean?

-- 
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/5f620a25-a37e-491c-87b4-cc49342af22e%40googlegroups.com.

Re: [go-nuts] What happens if the hash retrieved from sumdb and the one in go.sum file of the main module are different?

2019-09-12 Thread T L 


On Wednesday, September 11, 2019 at 5:33:02 PM UTC-4, Ian Lance Taylor 
wrote:
>
> The go tool reports a checksum mismatch error. 
>
> Ian 
>

"go help module-auth" says

If a downloaded module is not yet included in go.sum and it is a publicly
available module, the go command consults the Go checksum database to fetch
the expected go.sum lines.

and ""go help modules" says

No matter the source of the modules, the go command checks downloads against
known checksums, to detect unexpected changes in the content of any specific
module version from one day to the next. This check first consults the 
current
module's go.sum file but falls back to the Go checksum database, controlled 
by
the GOSUMDB and GONOSUMDB environment variables. See 'go help module-auth'
for details.

By these explanations, is my following understanding correct?
1. when I "git clone" a Go program project which contains a go.mod and a 
go.sum file.
   then sumdb will not be connected if I run "go build" under the project.
2. when I "go get" a package under my modules based project,
   sumdb will be connected to fetch the hash of the dependency package,
   if the fetch result and local cached dependency hash matches,
   then two hash lines will be added the go.sum file of my project,
   
   if the dependency package is also modules based, in other words,
   it has its own go.mod and go.sum files, the hashes of the dependency 
packages
   of the dependency package will not be fetched from sumdb.



-- 
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/92d8a563-c454-47aa-a8ff-1bc2131b3d52%40googlegroups.com.

[go-nuts] What happens if the hash retrieved from sumdb and the one in go.sum file of the main module are different?

2019-09-11 Thread T L 
.

-- 
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/86617c09-5a81-4e5c-9c1d-2419c8382681%40googlegroups.com.

[go-nuts] Re: Is there a way to use the pakckages under vendor folder and from module cache?

2019-09-10 Thread T L 
Thanks for the suggestion.

I think the replace method works, but it is some tedious.
I need to add a "go.mod" file for each of the subfolders under "oldvendor",
and add a line in the "go.mod" of the main module.

But it looks this is the only way which works currently.
It would be great if there is a simpler way to support both
always-on vendor and cached vendor at the same time.

On Tuesday, September 10, 2019 at 12:30:56 PM UTC-4, t hepudds wrote:
>
> Hello T L,
>
> I think I might not fully understand the exact scenario, but one thing 
> some people have done when they have something in their vendor directory 
> that they can't otherwise find anywhere else (e.g., perhaps because it is 
> modified, or maybe the only copy of a now-missing dependency is in your 
> vendor directory) is to rename the vendor directory to something else 
> ("oldvendor", or whatever name makes sense), and then set 'replace' 
> directives in the main project's go.mod file to point into the "oldvendor" 
> directory for whatever pieces from there are needed.
>
> For example, something like:
>
>require github.com/some/dependency v0.0.0
>
>replace github.com/some/dependency => ./oldvendor/
> github.com/some/dependency
>
> I think that would allow you to pick and choose what you want from your 
> old vendor directory.
>
> In terms of your other question, I think -mod=vendor is currently all or 
> nothing. There is a proposal to perhaps one day support partial vendoring, 
> but that is not in the current software.
>
> Regards,
> thepudds
>
> On Tuesday, September 10, 2019 at 8:59:28 AM UTC-4, T L wrote:
>>
>> I maintain an private old Go project, which depends many many old 
>> packages.
>> Before the module mode, I put all these dependency packages under the 
>> vendor folder.
>> In the developing process, from time to time, I modified some of 
>> dependency packages.
>>
>> Meanwhile, I plan to migrate the project to modules mode and need to 
>> import some new module packages.
>> I found I encountered an embarrassing situation.
>> If I delete the vendor folder and run "go mod vendor" in modules mode to 
>> rebuild the vendor,
>> the command will fail. One reason is some dependency packages disappeared.
>> The other reason is many packages are updated and broke capabilities.
>> And I don't want the new download to overwrite my local modifications for 
>> some dependency packages.
>>
>> So, is there a way to let me continue use the these old dependency 
>> packages and use some new modules based packages?
>>
>>

-- 
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/39f0b51b-3b0b-434e-a784-254b0f6bca47%40googlegroups.com.

[go-nuts] Re: Is there a way to use the pakckages under vendor folder and from module cache?

2019-09-10 Thread T L 
Or can go commands support a new special folder: dependencies.
Its functionality is like the functionality of vendor folders,
but to avoid being messed up with the packages under vendors.

When running "go build -mod=vendor", the packages under the "dependencies" 
folder
have higher look-up priorities than the packages under "vendor" folder.

On Tuesday, September 10, 2019 at 9:03:52 AM UTC-4, T L wrote:
>
> I mean "to use the pakckages under vendor folder and from module cache at 
> the same time".
>
> I have one question, is it better to add a "go mod cache-locally" command 
> to save the dependency modules
> in a "module-cache" folder in the current project, so that "go build 
> -use-local-module-cache" can use
> the packages in the old "vendor" folder and the "module-cache" folder?
>
> On Tuesday, September 10, 2019 at 8:59:28 AM UTC-4, T L wrote:
>>
>> I maintain an private old Go project, which depends many many old 
>> packages.
>> Before the module mode, I put all these dependency packages under the 
>> vendor folder.
>> In the developing process, from time to time, I modified some of 
>> dependency packages.
>>
>> Meanwhile, I plan to migrate the project to modules mode and need to 
>> import some new module packages.
>> I found I encountered an embarrassing situation.
>> If I delete the vendor folder and run "go mod vendor" in modules mode to 
>> rebuild the vendor,
>> the command will fail. One reason is some dependency packages disappeared.
>> The other reason is many packages are updated and broke capabilities.
>> And I don't want the new download to overwrite my local modifications for 
>> some dependency packages.
>>
>> So, is there a way to let me continue use the these old dependency 
>> packages and use some new modules based packages?
>>
>>

-- 
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/6df7328f-6894-4501-b624-91fa2660161c%40googlegroups.com.

[go-nuts] Re: Is there a way to use the pakckages under vendor folder and from module cache?

2019-09-10 Thread T L 
I mean "to use the pakckages under vendor folder and from module cache at 
the same time".

I have one question, is it better to add a "go mod cache-locally" command 
to save the dependency modules
in a "module-cache" folder in the current project, so that "go build 
-use-local-module-cache" can use
the packages in the old "vendor" folder and the "module-cache" folder?

On Tuesday, September 10, 2019 at 8:59:28 AM UTC-4, T L wrote:
>
> I maintain an private old Go project, which depends many many old packages.
> Before the module mode, I put all these dependency packages under the 
> vendor folder.
> In the developing process, from time to time, I modified some of 
> dependency packages.
>
> Meanwhile, I plan to migrate the project to modules mode and need to 
> import some new module packages.
> I found I encountered an embarrassing situation.
> If I delete the vendor folder and run "go mod vendor" in modules mode to 
> rebuild the vendor,
> the command will fail. One reason is some dependency packages disappeared.
> The other reason is many packages are updated and broke capabilities.
> And I don't want the new download to overwrite my local modifications for 
> some dependency packages.
>
> So, is there a way to let me continue use the these old dependency 
> packages and use some new modules based packages?
>
>

-- 
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/a19c1fbf-fca8-4171-b830-01a226577f36%40googlegroups.com.

[go-nuts] Is there a way to use the pakckages under vendor folder and from module cache?

2019-09-10 Thread T L 
I maintain an private old Go project, which depends many many old packages.
Before the module mode, I put all these dependency packages under the 
vendor folder.
In the developing process, from time to time, I modified some of dependency 
packages.

Meanwhile, I plan to migrate the project to modules mode and need to import 
some new module packages.
I found I encountered an embarrassing situation.
If I delete the vendor folder and run "go mod vendor" in modules mode to 
rebuild the vendor,
the command will fail. One reason is some dependency packages disappeared.
The other reason is many packages are updated and broke capabilities.
And I don't want the new download to overwrite my local modifications for 
some dependency packages.

So, is there a way to let me continue use the these old dependency packages 
and use some new modules based packages?

-- 
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/97d7cc59-1334-4976-a251-71795397b947%40googlegroups.com.

Re: [go-nuts] Re: An old problem: lack of priority select cases

2019-09-07 Thread T L 
@Leo Lara

In face, you code the Mutex+WaitGroup in your code can be replaced with a 
Cond var plus a counter: https://play.golang.org/p/hVLamTjHj6J

On Wednesday, September 4, 2019 at 5:44:11 AM UTC-4, Leo Lara wrote:
>
> Hi Marcin,
>
> I think https://play.golang.org/p/RiKi1PGVSvF is basically what I do with 
> atomic operations in my blog post 
> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>  in 
> the section "Some experiments", and then using the wait group as I say 
> later in the section "The solution involves wait groups",
>
> I think it is more constrained than my final solution because:
>  + You need to make sure that all producers have started (run Add(1)) 
> before you call Close. You would need to use a mutex around Add and Wait to 
> solve this, I think now that a RWLock have the read arround Add(1) and the 
> write around Wait could be better.
>  + All writing goroutines will stay blocked until a reader reads all, 
> using a closing channel is better because you can use select and they could 
> unblock without a reader.
>
>
> On Wednesday, August 28, 2019 at 10:37:52 PM UTC+2, Marcin Romaszewicz 
> wrote:
>>
>> Think of a channel as existing for the lifetime of a particular data 
>> stream, and not have it be associated with either producer or consumer. 
>> Here's an example:
>>
>> https://play.golang.org/p/aEAXXtz2X1g
>>
>> The channel here is closed after all producers have exited, and all 
>> consumers continue to run until the channel is drained of data.
>>
>> The producers are managed by something somewhere in your code - and that 
>> is the scope at which it makes sense to create channel ownership. I've used 
>> a waitgroup to ensure that the channel is closed after all producers exit, 
>> but you can use whatever barrier construct you want.
>>
>> Even if you must have a channel per producer, you can safely close the 
>> producer side, without notifying the downstream about this. The example 
>> early in the thread uses multiple channels, with one channel being used to 
>> signal that the producers should exit. Channels aren't really the right 
>> model for this, you want a thread safe flag of some sort. For example:
>>
>> var exitFlag uint64
>> func producer(chan data int, wg *sync.WaitGroup) {
>> defer wg.Done()
>> for {
>> shouldExit := atomic.LoadUint64()
>> if shouldExit == 1 {
>>  return
>> }
>> chan <- rand.Intn(100)
>> }
>> }
>>
>> Here's 10 producers and 3 consumers sharing a channel and closing it 
>> safely upon receiving an exit flag:
>> https://play.golang.org/p/RiKi1PGVSvF
>>
>> -- Marcin
>>
>> On Wed, Aug 28, 2019 at 11:29 AM Leo Lara  wrote:
>>
>>> I do not think priority select is *necessary*, it could be a nice 
>>> addition if the performance does not change.
>>>
>>> On Wednesday, August 28, 2019 at 8:27:36 PM UTC+2, Leo Lara wrote:
>>>>
>>>> Hi Robert,
>>>>
>>>> From the article: """To bound more the problem, in my case, you control 
>>>> the writers but not the readers"""
>>>>
>>>> So what I was trying to do was to be able to close, with mutiple 
>>>> writers, while being transparent for the readers. The readers only need to 
>>>> read as usual form the channel.
>>>>
>>>> For example, if you want to write a library where the user just reads 
>>>> from a channel, this is an approach I found where the user of the lirbary 
>>>> deos nto have to do anything special. Of course, there might be another 
>>>> solution, but if you need to modify the reader we are talking about a 
>>>> different problem.
>>>>
>>>> Cheers!!
>>>>
>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>>>
>>>>> A better solution is to wrap the writes using a RWLock, grab the read 
>>>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>>>
>>>>> Just encapsulate it all in a MultiWriterChannel struct - generics 
>>>>> would help here :)
>>>>>
>>>>> -Original Message- 
>>>>> From: Leo Lara 
>>>>> Sent: Aug 28, 2019 11:24 AM 
>>>>> To: golang-nuts 
>>>>> Subject: [go-nuts] Re: An old problem: lack of priority select cases 
>>>>>

[go-nuts] Re: Closed channel vs nil channel when writing

2019-09-02 Thread T L 


On Sunday, September 1, 2019 at 12:03:58 PM UTC-4, clement auger wrote:
>
> hi,
>
> I am looking for further details and explanations about the various 
> behaviors
> associated with closed Vs nil channels.
>
> I already read 
> https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel
> and other publications such as 
>
> https://medium.com/justforfunc/why-are-there-nil-channels-in-go-9877cc0b2308 
> (for example)
>
> They repeat the explanation of the behaviors the programmer will have to 
> deal with, 
> however they don't really explain the internal, nor the reasons of the 
> differences
> found with this example https://play.golang.org/p/4LuZ32gzWbu when 
> closing or niling the channel
>
> I wonder under which case it is useful to panic on write, Vs branching to 
> a default case within a select.
> Said differently what is the advantage of a panic Vs a syntax like ok := 
> mychan <- myval; if !ok { return "not wrote" }
>
> This happened while reading at T.L. in 
> https://groups.google.com/forum/#!topic/golang-nuts/lEKehHH7kZY
>
> *Yes, there are ways to handle the problem of uncertain number of senders, 
> but there are no simple ways.*
> *A mechanism must be designed to avoid any sender writing to a closed 
> channel.*
>
> thanks for anyone able to provide some details.
>


https://go101.org/article/channel.html 

-- 
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/8e676ea6-9565-4745-8052-2a4f677faf41%40googlegroups.com.

[go-nuts] Re: By passing go type check when performing bitwise operator

2019-09-02 Thread T L 


On Sunday, September 1, 2019 at 2:03:37 PM UTC-4, Albert Tedja wrote:
>
>  I am trying to perform some bitwise operators, but Go is not letting me 
> because the mask is an uint and the values are int. Setting the mask to int 
> will break the code since I am shifting bits right and left and prefer the 
> prefix 0 when shifting right, and if I am not mistaken, Go does not have 
> >>>.
>
>
>
Not like Java, Go supports unsigned integers, so >>> is not essential in Go.
 

-- 
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/6ad7cb9a-4147-4bfa-808b-5cc4aa5db626%40googlegroups.com.

Re: [go-nuts] An old problem: lack of priority select cases

2019-09-02 Thread T L 


On Sunday, September 1, 2019 at 2:05:49 PM UTC-4, Albert Tedja wrote:
>
> This is something I ran into a while back, and made a library for it, 
> though, I prefer not to spam the mailing list.  Feel free to send me a dm 
> and I'll send you a github link if you are interested.
>

It would be great if you can share the library here. I'm surely interested. 
And I think many other gophers also have interests. :)
 

>
> On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote:
>>
>>
>>
>> On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>>>
>>>
>>>
>>> On Sat, 31 Aug 2019 at 10:02, T L  wrote:
>>>
>>>>
>>>>
>>>> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>>>>>
>>>>>> The reason you're wanting priority select is because you are shutting 
>>>>>> down the data channel preemptively, but you can wait for an 
>>>>>> acknowledgement 
>>>>>> from the run goroutine instead:
>>>>>>
>>>>>> https://play.golang.org/p/qSWluYy4ifl
>>>>>>
>>>>>>
>>>>> Your solution is clever. The Close method can be called multiple time 
>>>>> safely.
>>>>> Is there such a beautiful solution for multiple senders?
>>>>>  
>>>>>
>>>>
>>>> Translating a multi-senders problem to a single sender problem is the 
>>>> only way I can get:
>>>> https://play.golang.org/p/dAppUxP96g4
>>>>
>>>
>>> The answer really depends on what you're actually trying to do. What are 
>>> the multiple senders? What's the actual problem you're trying to solve?
>>>
>>> I'd fairly sure you'll be able do what you want without requiring a 
>>> prioritised select, which is what this thread was about.
>>>
>>>   cheers,
>>> rog.
>>>
>>>
>> Yes, there are ways to handle the problem of uncertain number of senders, 
>> but there are no simple ways.
>> A mechanism must be designed to avoid any sender writing to a closed 
>> channel.
>>  
>>
>>>  
>>>>
>>>>>
>>>>>> On Wed, 28 Aug 2019 at 18:06, T L  wrote:
>>>>>>
>>>>>>> The old thread: 
>>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>>>>>
>>>>>>> Go channels are flexible, but in practice, I often encountered some 
>>>>>>> situations in which channel are hard to use.
>>>>>>> Given an example:
>>>>>>>
>>>>>>> import "math/rand"
>>>>>>>
>>>>>>> type Producer struct {
>>>>>>> data   chan int
>>>>>>> closed chan struct{}
>>>>>>> }
>>>>>>>
>>>>>>> func NewProducer() *Producer {
>>>>>>> p :=  {
>>>>>>> data:   make(chan int),
>>>>>>> closed: make(chan struct{}),
>>>>>>> }
>>>>>>> 
>>>>>>> go p.run()
>>>>>>> 
>>>>>>> return p
>>>>>>> }
>>>>>>>
>>>>>>> func (p *Produce) Stream() chan int {
>>>>>>> return p.data
>>>>>>> }
>>>>>>>
>>>>>>> func (p *Producer) run() {
>>>>>>> for {
>>>>>>> // If non-blocking cases are selected by their appearance 
>>>>>>> order,
>>>>>>> // then the following slect block is a perfect use.
>>>>>>> select {
>>>>>>> case(0) <-p.closed: return
>>>>>>> case p.data <- rand.Int():
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> func (p *Produce) Clsoe() {
>>>>>>> close(p.closed)
>>>>>>> close(p.data)
>>>>>>> }
>>>>>>>
>>>>>>> func main() {
>>>>>>> p := NewPr

Re: [go-nuts] An old problem: lack of priority select cases

2019-09-01 Thread T L 
You can simply validate it by run: go run -race main.go
for you program: https://play.golang.org/p/JRSEPU3Uf17


On Sunday, September 1, 2019 at 1:30:30 PM UTC-4, Robert Engels wrote:
>
> The memory model is pretty unspecified but they’re working on it. As a 
> defacto behavior it is pretty hard to have what I stated not be the case. 
>
> On Sep 1, 2019, at 9:46 AM, T L > wrote:
>
> This is not true, at least no Go official documentation admits this.
>
> On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote:
>>
>> That is incorrect. The atomic operations must exhibit the same happens 
>> before relationships as the mutex. If the mutex flushes the related cache 
>> lines the atomic load will pick it up. 
>>
>> On Aug 31, 2019, at 10:55 PM, T L  wrote:
>>
>>
>>
>> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote:
>>>
>>> Yes, that is why the original code did not use a lock on the read but 
>>> the read of the flag was wrong. The version I posted in the other thread 
>>> works fine locally. time.Sleep() has problems in the playground 
>>>
>>
>> You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ?
>> No no, it is not a good ideas to use mutex in write but atomic in read to 
>> avoid concurrently accessing the same value.
>>  
>>
>>>
>>> On Aug 31, 2019, at 7:50 AM, T L  wrote:
>>>
>>>
>>>
>>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote:
>>>>
>>>> If you comment out the read method then all threads will block. That is 
>>>> the the behavior of an unbuffered channel - a writer blocks until a reader 
>>>> is ready. Which is why you always need a valid reader running. Unless the 
>>>> channel is closed and then the writer will panic. 
>>>>
>>>> The code I provided is valid. 
>>>>
>>>
>>> In fact, if I comment out the write instead read part, the code will 
>>> also crash on all goroutines are blocked.
>>>  
>>>
>>>>
>>>> On Aug 31, 2019, at 2:40 AM, T L  wrote:
>>>>
>>>>
>>>>
>>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>>>>>
>>>>> You changed the Read() method incorrectly - it should be using the 
>>>>> Read lock, not the Write lock.
>>>>>
>>>>> Still, as I pointed out when I posted it, Play has a problem where it 
>>>>> aborts if all routines are sleeping (not just blocked), so you need to 
>>>>> run 
>>>>> it locally.
>>>>>
>>>>
>>>> My fault. But it doesn't matter, for the Read method is never called (I 
>>>> commented it off).
>>>> It also crash locally for all goroutines are blocked.
>>>>  
>>>>
>>>>> -Original Message- 
>>>>> From: T L 
>>>>> Sent: Aug 30, 2019 12:05 PM 
>>>>> To: golang-nuts 
>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>>
>>>>>
>>>>>
>>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>>>>>
>>>>>>
>>>>>> Makes no difference in the code I posted as long as they all use 
>>>>>> the same MultiWriterChannel. In fact, others can be late started, as 
>>>>>> they 
>>>>>> will fail fast if the channel is already closed.
>>>>>>
>>>>>
>>>>> https://play.golang.org/p/pcwIu2w8ZRb
>>>>>
>>>>> All go routines are blocked in the modified version.
>>>>>  
>>>>>
>>>>>> -Original Message- 
>>>>>> From: T L 
>>>>>> Sent: Aug 30, 2019 11:13 AM 
>>>>>> To: golang-nuts 
>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>>>>>>>
>>>>>>> I don't think so. Why do you think that is the case? The RWLock is 
>>>>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it 
>>>>>>> is 
>>>>>>> guaranteed to get it (as the code is structured) - the subsequ

Re: [go-nuts] An old problem: lack of priority select cases

2019-09-01 Thread T L 
This is not true, at least no Go official documentation admits this.

On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote:
>
> That is incorrect. The atomic operations must exhibit the same happens 
> before relationships as the mutex. If the mutex flushes the related cache 
> lines the atomic load will pick it up. 
>
> On Aug 31, 2019, at 10:55 PM, T L > wrote:
>
>
>
> On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote:
>>
>> Yes, that is why the original code did not use a lock on the read but the 
>> read of the flag was wrong. The version I posted in the other thread works 
>> fine locally. time.Sleep() has problems in the playground 
>>
>
> You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ?
> No no, it is not a good ideas to use mutex in write but atomic in read to 
> avoid concurrently accessing the same value.
>  
>
>>
>> On Aug 31, 2019, at 7:50 AM, T L  wrote:
>>
>>
>>
>> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote:
>>>
>>> If you comment out the read method then all threads will block. That is 
>>> the the behavior of an unbuffered channel - a writer blocks until a reader 
>>> is ready. Which is why you always need a valid reader running. Unless the 
>>> channel is closed and then the writer will panic. 
>>>
>>> The code I provided is valid. 
>>>
>>
>> In fact, if I comment out the write instead read part, the code will also 
>> crash on all goroutines are blocked.
>>  
>>
>>>
>>> On Aug 31, 2019, at 2:40 AM, T L  wrote:
>>>
>>>
>>>
>>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>>>>
>>>> You changed the Read() method incorrectly - it should be using the Read 
>>>> lock, not the Write lock.
>>>>
>>>> Still, as I pointed out when I posted it, Play has a problem where it 
>>>> aborts if all routines are sleeping (not just blocked), so you need to run 
>>>> it locally.
>>>>
>>>
>>> My fault. But it doesn't matter, for the Read method is never called (I 
>>> commented it off).
>>> It also crash locally for all goroutines are blocked.
>>>  
>>>
>>>> -Original Message- 
>>>> From: T L 
>>>> Sent: Aug 30, 2019 12:05 PM 
>>>> To: golang-nuts 
>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>
>>>>
>>>>
>>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>>>>
>>>>>
>>>>> Makes no difference in the code I posted as long as they all use 
>>>>> the same MultiWriterChannel. In fact, others can be late started, as they 
>>>>> will fail fast if the channel is already closed.
>>>>>
>>>>
>>>> https://play.golang.org/p/pcwIu2w8ZRb
>>>>
>>>> All go routines are blocked in the modified version.
>>>>  
>>>>
>>>>> -Original Message----- 
>>>>> From: T L 
>>>>> Sent: Aug 30, 2019 11:13 AM 
>>>>> To: golang-nuts 
>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>>
>>>>>
>>>>>
>>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>>>>>>
>>>>>> I don't think so. Why do you think that is the case? The RWLock is 
>>>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it 
>>>>>> is 
>>>>>> guaranteed to get it (as the code is structured) - the subsequent 
>>>>>> readers 
>>>>>> will queue behind the "writer = closer".
>>>>>>
>>>>>
>>>>> How about unknown/random number of senders and readers?
>>>>>  
>>>>>
>>>>>>
>>>>>> -Original Message- 
>>>>>> From: T L 
>>>>>> Sent: Aug 30, 2019 8:50 AM 
>>>>>> To: golang-nuts 
>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>>>
>>>>>> @Robert 
>>>>>> I think there is a difference between the code of @Leo and you.
>>>>>> In you code, the Wirte/Read/Close are all possible to block for ever.
>>

Re: [go-nuts] An old problem: lack of priority select cases

2019-09-01 Thread T L 


On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote:
>
>
>
> On Sat, 31 Aug 2019 at 10:02, T L > wrote:
>
>>
>>
>> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>>>
>>>
>>>
>>> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>>>
>>>> The reason you're wanting priority select is because you are shutting 
>>>> down the data channel preemptively, but you can wait for an 
>>>> acknowledgement 
>>>> from the run goroutine instead:
>>>>
>>>> https://play.golang.org/p/qSWluYy4ifl
>>>>
>>>>
>>> Your solution is clever. The Close method can be called multiple time 
>>> safely.
>>> Is there such a beautiful solution for multiple senders?
>>>  
>>>
>>
>> Translating a multi-senders problem to a single sender problem is the 
>> only way I can get:
>> https://play.golang.org/p/dAppUxP96g4
>>
>
> The answer really depends on what you're actually trying to do. What are 
> the multiple senders? What's the actual problem you're trying to solve?
>
> I'd fairly sure you'll be able do what you want without requiring a 
> prioritised select, which is what this thread was about.
>
>   cheers,
> rog.
>
>
Yes, there are ways to handle the problem of uncertain number of senders, 
but there are no simple ways.
A mechanism must be designed to avoid any sender writing to a closed 
channel.
 

>  
>>
>>>
>>>> On Wed, 28 Aug 2019 at 18:06, T L  wrote:
>>>>
>>>>> The old thread: 
>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>>>
>>>>> Go channels are flexible, but in practice, I often encountered some 
>>>>> situations in which channel are hard to use.
>>>>> Given an example:
>>>>>
>>>>> import "math/rand"
>>>>>
>>>>> type Producer struct {
>>>>> data   chan int
>>>>> closed chan struct{}
>>>>> }
>>>>>
>>>>> func NewProducer() *Producer {
>>>>> p :=  {
>>>>> data:   make(chan int),
>>>>> closed: make(chan struct{}),
>>>>> }
>>>>> 
>>>>> go p.run()
>>>>> 
>>>>> return p
>>>>> }
>>>>>
>>>>> func (p *Produce) Stream() chan int {
>>>>> return p.data
>>>>> }
>>>>>
>>>>> func (p *Producer) run() {
>>>>> for {
>>>>> // If non-blocking cases are selected by their appearance 
>>>>> order,
>>>>> // then the following slect block is a perfect use.
>>>>> select {
>>>>> case(0) <-p.closed: return
>>>>> case p.data <- rand.Int():
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> func (p *Produce) Clsoe() {
>>>>> close(p.closed)
>>>>> close(p.data)
>>>>> }
>>>>>
>>>>> func main() {
>>>>> p := NewProducer()
>>>>> for n := p.Stream() {
>>>>> // use n ...
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> If the first case in the select block in the above example has a 
>>>>> higher priority than the second one,
>>>>> then coding will be much happier for the use cases like the above one.
>>>>>
>>>>> In short, the above use case requires:
>>>>> * for receivers, data streaming end is notified by the close of a 
>>>>> channel.
>>>>> * for senders, data will never be sent to closed channel.
>>>>>
>>>>> But, as Go 1 doesn't support priority select cases, it is much tedious 
>>>>> to implement the code
>>>>> satisfying the above listed requirements. The final implementation is 
>>>>> often very ugly and inefficient.
>>>>>
>>>>> Does anyone else also experience the pain?
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "golang-nuts" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to golan...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/432f9d63-5223-4119-b7e7-b1eb2dd57cdc%40googlegroups.com.

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-31 Thread T L 


On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote:
>
> Yes, that is why the original code did not use a lock on the read but the 
> read of the flag was wrong. The version I posted in the other thread works 
> fine locally. time.Sleep() has problems in the playground 
>

You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ?
No no, it is not a good ideas to use mutex in write but atomic in read to 
avoid concurrently accessing the same value.
 

>
> On Aug 31, 2019, at 7:50 AM, T L > wrote:
>
>
>
> On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote:
>>
>> If you comment out the read method then all threads will block. That is 
>> the the behavior of an unbuffered channel - a writer blocks until a reader 
>> is ready. Which is why you always need a valid reader running. Unless the 
>> channel is closed and then the writer will panic. 
>>
>> The code I provided is valid. 
>>
>
> In fact, if I comment out the write instead read part, the code will also 
> crash on all goroutines are blocked.
>  
>
>>
>> On Aug 31, 2019, at 2:40 AM, T L  wrote:
>>
>>
>>
>> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>>>
>>> You changed the Read() method incorrectly - it should be using the Read 
>>> lock, not the Write lock.
>>>
>>> Still, as I pointed out when I posted it, Play has a problem where it 
>>> aborts if all routines are sleeping (not just blocked), so you need to run 
>>> it locally.
>>>
>>
>> My fault. But it doesn't matter, for the Read method is never called (I 
>> commented it off).
>> It also crash locally for all goroutines are blocked.
>>  
>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 30, 2019 12:05 PM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>
>>>
>>>
>>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>>>
>>>>
>>>> Makes no difference in the code I posted as long as they all use 
>>>> the same MultiWriterChannel. In fact, others can be late started, as they 
>>>> will fail fast if the channel is already closed.
>>>>
>>>
>>> https://play.golang.org/p/pcwIu2w8ZRb
>>>
>>> All go routines are blocked in the modified version.
>>>  
>>>
>>>> -Original Message- 
>>>> From: T L 
>>>> Sent: Aug 30, 2019 11:13 AM 
>>>> To: golang-nuts 
>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>
>>>>
>>>>
>>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>>>>>
>>>>> I don't think so. Why do you think that is the case? The RWLock is 
>>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it 
>>>>> is 
>>>>> guaranteed to get it (as the code is structured) - the subsequent readers 
>>>>> will queue behind the "writer = closer".
>>>>>
>>>>
>>>> How about unknown/random number of senders and readers?
>>>>  
>>>>
>>>>>
>>>>> -Original Message- 
>>>>> From: T L 
>>>>> Sent: Aug 30, 2019 8:50 AM 
>>>>> To: golang-nuts 
>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>>
>>>>> @Robert 
>>>>> I think there is a difference between the code of @Leo and you.
>>>>> In you code, the Wirte/Read/Close are all possible to block for ever.
>>>>>
>>>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>>>>>>
>>>>>>
>>>>>> Oops. You are right. The original used two different methods Closed() 
>>>>>> and Read() and when I refactored I forgot to add the Read lock to the 
>>>>>> Read(). That's why you always have code reviews...
>>>>>>
>>>>>> -Original Message- 
>>>>>> From: T L 
>>>>>> Sent: Aug 29, 2019 6:25 PM 
>>>>>> To: golang-nuts 
>>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, August 28, 2019

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-31 Thread T L 


On Saturday, August 31, 2019 at 8:24:31 AM UTC-4, Robert Engels wrote:
>
> If you comment out the read method then all threads will block. That is 
> the the behavior of an unbuffered channel - a writer blocks until a reader 
> is ready. Which is why you always need a valid reader running. Unless the 
> channel is closed and then the writer will panic. 
>
> The code I provided is valid. 
>

In fact, if I comment out the write instead read part, the code will also 
crash on all goroutines are blocked.
 

>
> On Aug 31, 2019, at 2:40 AM, T L > wrote:
>
>
>
> On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>>
>> You changed the Read() method incorrectly - it should be using the Read 
>> lock, not the Write lock.
>>
>> Still, as I pointed out when I posted it, Play has a problem where it 
>> aborts if all routines are sleeping (not just blocked), so you need to run 
>> it locally.
>>
>
> My fault. But it doesn't matter, for the Read method is never called (I 
> commented it off).
> It also crash locally for all goroutines are blocked.
>  
>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 30, 2019 12:05 PM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>
>>
>>
>> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>>
>>>
>>> Makes no difference in the code I posted as long as they all use the 
>>> same MultiWriterChannel. In fact, others can be late started, as they will 
>>> fail fast if the channel is already closed.
>>>
>>
>> https://play.golang.org/p/pcwIu2w8ZRb
>>
>> All go routines are blocked in the modified version.
>>  
>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 30, 2019 11:13 AM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>
>>>
>>>
>>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>>>>
>>>> I don't think so. Why do you think that is the case? The RWLock is 
>>>> "fair" in the sense that once the 'closer' attempts to get the lock, it is 
>>>> guaranteed to get it (as the code is structured) - the subsequent readers 
>>>> will queue behind the "writer = closer".
>>>>
>>>
>>> How about unknown/random number of senders and readers?
>>>  
>>>
>>>>
>>>> -Original Message- 
>>>> From: T L 
>>>> Sent: Aug 30, 2019 8:50 AM 
>>>> To: golang-nuts 
>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>
>>>> @Robert 
>>>> I think there is a difference between the code of @Leo and you.
>>>> In you code, the Wirte/Read/Close are all possible to block for ever.
>>>>
>>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>>>>>
>>>>>
>>>>> Oops. You are right. The original used two different methods Closed() 
>>>>> and Read() and when I refactored I forgot to add the Read lock to the 
>>>>> Read(). That's why you always have code reviews...
>>>>>
>>>>> -Original Message- 
>>>>> From: T L 
>>>>> Sent: Aug 29, 2019 6:25 PM 
>>>>> To: golang-nuts 
>>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels 
>>>>> wrote:
>>>>>>
>>>>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>>>>>
>>>>>
>>>>> Doesn't the Read method need to be guarded by the reader lock?
>>>>>
>>>>>  
>>>>>
>>>>>>
>>>>>> It won’t run correctly in the playground because it terminates when 
>>>>>> all routines are asleep - which happens during the test (not sure why it 
>>>>>> does this, as sleeping is different than a deadlock).
>>>>>>
>>>>>> It is probably less efficient, and less orderly than the other 
>>>>>> example using WaitGroup but you get the idea I hope. It forcibly 
>>>>>> terminates 
>>>>>> the writers before they compl

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-31 Thread T L 


On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote:
>
>
>
> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>>
>> The reason you're wanting priority select is because you are shutting 
>> down the data channel preemptively, but you can wait for an acknowledgement 
>> from the run goroutine instead:
>>
>> https://play.golang.org/p/qSWluYy4ifl
>>
>>
> Your solution is clever. The Close method can be called multiple time 
> safely.
> Is there such a beautiful solution for multiple senders?
>  
>

Translating a multi-senders problem to a single sender problem is the only 
way I can get:
https://play.golang.org/p/dAppUxP96g4

 

>
>> On Wed, 28 Aug 2019 at 18:06, T L  wrote:
>>
>>> The old thread: 
>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>
>>> Go channels are flexible, but in practice, I often encountered some 
>>> situations in which channel are hard to use.
>>> Given an example:
>>>
>>> import "math/rand"
>>>
>>> type Producer struct {
>>> data   chan int
>>> closed chan struct{}
>>> }
>>>
>>> func NewProducer() *Producer {
>>> p :=  {
>>> data:   make(chan int),
>>> closed: make(chan struct{}),
>>> }
>>> 
>>> go p.run()
>>> 
>>> return p
>>> }
>>>
>>> func (p *Produce) Stream() chan int {
>>> return p.data
>>> }
>>>
>>> func (p *Producer) run() {
>>> for {
>>> // If non-blocking cases are selected by their appearance order,
>>> // then the following slect block is a perfect use.
>>> select {
>>> case(0) <-p.closed: return
>>> case p.data <- rand.Int():
>>> }
>>> }
>>> }
>>>
>>> func (p *Produce) Clsoe() {
>>> close(p.closed)
>>> close(p.data)
>>> }
>>>
>>> func main() {
>>> p := NewProducer()
>>> for n := p.Stream() {
>>> // use n ...
>>> }
>>> }
>>>
>>>
>>> If the first case in the select block in the above example has a higher 
>>> priority than the second one,
>>> then coding will be much happier for the use cases like the above one.
>>>
>>> In short, the above use case requires:
>>> * for receivers, data streaming end is notified by the close of a 
>>> channel.
>>> * for senders, data will never be sent to closed channel.
>>>
>>> But, as Go 1 doesn't support priority select cases, it is much tedious 
>>> to implement the code
>>> satisfying the above listed requirements. The final implementation is 
>>> often very ugly and inefficient.
>>>
>>> Does anyone else also experience the pain?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com.

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-31 Thread T L 


On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>
> The reason you're wanting priority select is because you are shutting down 
> the data channel preemptively, but you can wait for an acknowledgement from 
> the run goroutine instead:
>
> https://play.golang.org/p/qSWluYy4ifl
>
>
Your solution is clever. The Close method can be called multiple time 
safely.
Is there such a beautiful solution for multiple senders?
 

>
> On Wed, 28 Aug 2019 at 18:06, T L > wrote:
>
>> The old thread: 
>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>
>> Go channels are flexible, but in practice, I often encountered some 
>> situations in which channel are hard to use.
>> Given an example:
>>
>> import "math/rand"
>>
>> type Producer struct {
>> data   chan int
>> closed chan struct{}
>> }
>>
>> func NewProducer() *Producer {
>> p :=  {
>> data:   make(chan int),
>> closed: make(chan struct{}),
>> }
>> 
>> go p.run()
>> 
>> return p
>> }
>>
>> func (p *Produce) Stream() chan int {
>> return p.data
>> }
>>
>> func (p *Producer) run() {
>> for {
>> // If non-blocking cases are selected by their appearance order,
>> // then the following slect block is a perfect use.
>> select {
>> case(0) <-p.closed: return
>> case p.data <- rand.Int():
>> }
>> }
>> }
>>
>> func (p *Produce) Clsoe() {
>> close(p.closed)
>> close(p.data)
>> }
>>
>> func main() {
>> p := NewProducer()
>> for n := p.Stream() {
>> // use n ...
>> }
>> }
>>
>>
>> If the first case in the select block in the above example has a higher 
>> priority than the second one,
>> then coding will be much happier for the use cases like the above one.
>>
>> In short, the above use case requires:
>> * for receivers, data streaming end is notified by the close of a channel.
>> * for senders, data will never be sent to closed channel.
>>
>> But, as Go 1 doesn't support priority select cases, it is much tedious to 
>> implement the code
>> satisfying the above listed requirements. The final implementation is 
>> often very ugly and inefficient.
>>
>> Does anyone else also experience the pain?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/15b4b573-ee9c-4552-be78-84b303173ad7%40googlegroups.com.

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-31 Thread T L 


On Friday, August 30, 2019 at 1:40:33 PM UTC-4, Robert Engels wrote:
>
> You changed the Read() method incorrectly - it should be using the Read 
> lock, not the Write lock.
>
> Still, as I pointed out when I posted it, Play has a problem where it 
> aborts if all routines are sleeping (not just blocked), so you need to run 
> it locally.
>

My fault. But it doesn't matter, for the Read method is never called (I 
commented it off).
It also crash locally for all goroutines are blocked.
 

> -Original Message- 
> From: T L 
> Sent: Aug 30, 2019 12:05 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>
>
>
> On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>>
>>
>> Makes no difference in the code I posted as long as they all use the 
>> same MultiWriterChannel. In fact, others can be late started, as they will 
>> fail fast if the channel is already closed.
>>
>
> https://play.golang.org/p/pcwIu2w8ZRb
>
> All go routines are blocked in the modified version.
>  
>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 30, 2019 11:13 AM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>
>>
>>
>> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>>>
>>> I don't think so. Why do you think that is the case? The RWLock is 
>>> "fair" in the sense that once the 'closer' attempts to get the lock, it is 
>>> guaranteed to get it (as the code is structured) - the subsequent readers 
>>> will queue behind the "writer = closer".
>>>
>>
>> How about unknown/random number of senders and readers?
>>  
>>
>>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 30, 2019 8:50 AM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>
>>> @Robert 
>>> I think there is a difference between the code of @Leo and you.
>>> In you code, the Wirte/Read/Close are all possible to block for ever.
>>>
>>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>>>>
>>>>
>>>> Oops. You are right. The original used two different methods Closed() 
>>>> and Read() and when I refactored I forgot to add the Read lock to the 
>>>> Read(). That's why you always have code reviews...
>>>>
>>>> -Original Message- 
>>>> From: T L 
>>>> Sent: Aug 29, 2019 6:25 PM 
>>>> To: golang-nuts 
>>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>>
>>>>
>>>>
>>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:
>>>>>
>>>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>>>>
>>>>
>>>> Doesn't the Read method need to be guarded by the reader lock?
>>>>
>>>>  
>>>>
>>>>>
>>>>> It won’t run correctly in the playground because it terminates when 
>>>>> all routines are asleep - which happens during the test (not sure why it 
>>>>> does this, as sleeping is different than a deadlock).
>>>>>
>>>>> It is probably less efficient, and less orderly than the other example 
>>>>> using WaitGroup but you get the idea I hope. It forcibly terminates the 
>>>>> writers before they complete by design.
>>>>>
>>>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
>>>>> wrote:
>>>>>
>>>>> One should also be careful regarding the conceptual demands he or she 
>>>>> is making.
>>>>> Having a shared resource (that is complex enough that it cannot be 
>>>>> atomically accessed or modified) means essentially that "having multiple 
>>>>> writers being transparent to the readers", fundamentally, is not possible.
>>>>>
>>>>> From the moment itself when such a resource is shared, there must be 
>>>>> some sort of mecanism (that one using resources atomically usable) that 
>>>>> ensures the integrity of it.
>>>>> Maybe what you're talking about is having it transparent in terms of 
>>>>> code, in which case we both agree, but if you're looking for something 
>>>>> transparent in essence, as

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-30 Thread T L 


On Friday, August 30, 2019 at 12:39:41 PM UTC-4, Robert Engels wrote:
>
>
> Makes no difference in the code I posted as long as they all use the 
> same MultiWriterChannel. In fact, others can be late started, as they will 
> fail fast if the channel is already closed.
>

https://play.golang.org/p/pcwIu2w8ZRb

All go routines are blocked in the modified version.
 

> -Original Message- 
> From: T L 
> Sent: Aug 30, 2019 11:13 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>
>
>
> On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>>
>> I don't think so. Why do you think that is the case? The RWLock is "fair" 
>> in the sense that once the 'closer' attempts to get the lock, it is 
>> guaranteed to get it (as the code is structured) - the subsequent readers 
>> will queue behind the "writer = closer".
>>
>
> How about unknown/random number of senders and readers?
>  
>
>>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 30, 2019 8:50 AM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>
>> @Robert 
>> I think there is a difference between the code of @Leo and you.
>> In you code, the Wirte/Read/Close are all possible to block for ever.
>>
>> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>>>
>>>
>>> Oops. You are right. The original used two different methods Closed() 
>>> and Read() and when I refactored I forgot to add the Read lock to the 
>>> Read(). That's why you always have code reviews...
>>>
>>> -Original Message- 
>>> From: T L 
>>> Sent: Aug 29, 2019 6:25 PM 
>>> To: golang-nuts 
>>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>>
>>>
>>>
>>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:
>>>>
>>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>>>
>>>
>>> Doesn't the Read method need to be guarded by the reader lock?
>>>
>>>  
>>>
>>>>
>>>> It won’t run correctly in the playground because it terminates when all 
>>>> routines are asleep - which happens during the test (not sure why it does 
>>>> this, as sleeping is different than a deadlock).
>>>>
>>>> It is probably less efficient, and less orderly than the other example 
>>>> using WaitGroup but you get the idea I hope. It forcibly terminates the 
>>>> writers before they complete by design.
>>>>
>>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
>>>> wrote:
>>>>
>>>> One should also be careful regarding the conceptual demands he or she 
>>>> is making.
>>>> Having a shared resource (that is complex enough that it cannot be 
>>>> atomically accessed or modified) means essentially that "having multiple 
>>>> writers being transparent to the readers", fundamentally, is not possible.
>>>>
>>>> From the moment itself when such a resource is shared, there must be 
>>>> some sort of mecanism (that one using resources atomically usable) that 
>>>> ensures the integrity of it.
>>>> Maybe what you're talking about is having it transparent in terms of 
>>>> code, in which case we both agree, but if you're looking for something 
>>>> transparent in essence, as in performance, logical construction and all 
>>>> the 
>>>> rest, I think there is a misunderstanding here: even if it was added in 
>>>> the 
>>>> language, there would be many many things going on under the hood, as it 
>>>> is 
>>>> already (and cannot really be otherwise) for channel use alone.
>>>>
>>>> As for the priority using selects, I think it's more of something to be 
>>>> dealt with on the "user-side". There are many kinds of priority in 
>>>> general, 
>>>> and trying to implement something in the language itself would IMO either 
>>>> be too specific compared to the nessecary time to do so or it would 
>>>> probably have a huge overhead on the "classical' use case of the select 
>>>> construct.
>>>> + the fact that it is apparently already possible using RWMutexes.
>>>>
>>>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  a 
>>&

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-30 Thread T L 


On Friday, August 30, 2019 at 10:35:29 AM UTC-4, Robert Engels wrote:
>
> I don't think so. Why do you think that is the case? The RWLock is "fair" 
> in the sense that once the 'closer' attempts to get the lock, it is 
> guaranteed to get it (as the code is structured) - the subsequent readers 
> will queue behind the "writer = closer".
>

How about unknown/random number of senders and readers?
 

>
> -Original Message- 
> From: T L 
> Sent: Aug 30, 2019 8:50 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>
> @Robert 
> I think there is a difference between the code of @Leo and you.
> In you code, the Wirte/Read/Close are all possible to block for ever.
>
> On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>>
>>
>> Oops. You are right. The original used two different methods Closed() and 
>> Read() and when I refactored I forgot to add the Read lock to the Read(). 
>> That's why you always have code reviews...
>>
>> -Original Message- 
>> From: T L 
>> Sent: Aug 29, 2019 6:25 PM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>>
>>
>>
>> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:
>>>
>>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>>
>>
>> Doesn't the Read method need to be guarded by the reader lock?
>>
>>  
>>
>>>
>>> It won’t run correctly in the playground because it terminates when all 
>>> routines are asleep - which happens during the test (not sure why it does 
>>> this, as sleeping is different than a deadlock).
>>>
>>> It is probably less efficient, and less orderly than the other example 
>>> using WaitGroup but you get the idea I hope. It forcibly terminates the 
>>> writers before they complete by design.
>>>
>>> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
>>> wrote:
>>>
>>> One should also be careful regarding the conceptual demands he or she is 
>>> making.
>>> Having a shared resource (that is complex enough that it cannot be 
>>> atomically accessed or modified) means essentially that "having multiple 
>>> writers being transparent to the readers", fundamentally, is not possible.
>>>
>>> From the moment itself when such a resource is shared, there must be 
>>> some sort of mecanism (that one using resources atomically usable) that 
>>> ensures the integrity of it.
>>> Maybe what you're talking about is having it transparent in terms of 
>>> code, in which case we both agree, but if you're looking for something 
>>> transparent in essence, as in performance, logical construction and all the 
>>> rest, I think there is a misunderstanding here: even if it was added in the 
>>> language, there would be many many things going on under the hood, as it is 
>>> already (and cannot really be otherwise) for channel use alone.
>>>
>>> As for the priority using selects, I think it's more of something to be 
>>> dealt with on the "user-side". There are many kinds of priority in general, 
>>> and trying to implement something in the language itself would IMO either 
>>> be too specific compared to the nessecary time to do so or it would 
>>> probably have a huge overhead on the "classical' use case of the select 
>>> construct.
>>> + the fact that it is apparently already possible using RWMutexes.
>>>
>>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  a 
>>> écrit :
>>>
>>>> Think of a channel as existing for the lifetime of a particular data 
>>>> stream, and not have it be associated with either producer or consumer. 
>>>> Here's an example:
>>>>
>>>> https://play.golang.org/p/aEAXXtz2X1g
>>>>
>>>> The channel here is closed after all producers have exited, and all 
>>>> consumers continue to run until the channel is drained of data.
>>>>
>>>> The producers are managed by something somewhere in your code - and 
>>>> that is the scope at which it makes sense to create channel ownership. 
>>>> I've 
>>>> used a waitgroup to ensure that the channel is closed after all producers 
>>>> exit, but you can use whatever barrier construct you want.
>>>>
>>>> Even if you must have a channel per producer, you can safely close the 
>>

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-30 Thread T L 
@Robert 
I think there is a difference between the code of @Leo and you.
In you code, the Wirte/Read/Close are all possible to block for ever.

On Thursday, August 29, 2019 at 8:59:10 PM UTC-4, Robert Engels wrote:
>
>
> Oops. You are right. The original used two different methods Closed() and 
> Read() and when I refactored I forgot to add the Read lock to the Read(). 
> That's why you always have code reviews...
>
> -Original Message- 
> From: T L 
> Sent: Aug 29, 2019 6:25 PM 
> To: golang-nuts 
> Subject: Re: [go-nuts] An old problem: lack of priority select cases 
>
>
>
> On Wednesday, August 28, 2019 at 10:05:06 PM UTC-4, robert engels wrote:
>>
>> Here is a version using RWLock https://play.golang.org/p/YOwuYFiqtlf
>>
>
> Doesn't the Read method need to be guarded by the reader lock?
>
>  
>
>>
>> It won’t run correctly in the playground because it terminates when all 
>> routines are asleep - which happens during the test (not sure why it does 
>> this, as sleeping is different than a deadlock).
>>
>> It is probably less efficient, and less orderly than the other example 
>> using WaitGroup but you get the idea I hope. It forcibly terminates the 
>> writers before they complete by design.
>>
>> On Aug 28, 2019, at 4:09 PM, Michel Levieux  
>> wrote:
>>
>> One should also be careful regarding the conceptual demands he or she is 
>> making.
>> Having a shared resource (that is complex enough that it cannot be 
>> atomically accessed or modified) means essentially that "having multiple 
>> writers being transparent to the readers", fundamentally, is not possible.
>>
>> From the moment itself when such a resource is shared, there must be some 
>> sort of mecanism (that one using resources atomically usable) that ensures 
>> the integrity of it.
>> Maybe what you're talking about is having it transparent in terms of 
>> code, in which case we both agree, but if you're looking for something 
>> transparent in essence, as in performance, logical construction and all the 
>> rest, I think there is a misunderstanding here: even if it was added in the 
>> language, there would be many many things going on under the hood, as it is 
>> already (and cannot really be otherwise) for channel use alone.
>>
>> As for the priority using selects, I think it's more of something to be 
>> dealt with on the "user-side". There are many kinds of priority in general, 
>> and trying to implement something in the language itself would IMO either 
>> be too specific compared to the nessecary time to do so or it would 
>> probably have a huge overhead on the "classical' use case of the select 
>> construct.
>> + the fact that it is apparently already possible using RWMutexes.
>>
>> Le mer. 28 août 2019 à 22:37, Marcin Romaszewicz  a 
>> écrit :
>>
>>> Think of a channel as existing for the lifetime of a particular data 
>>> stream, and not have it be associated with either producer or consumer. 
>>> Here's an example:
>>>
>>> https://play.golang.org/p/aEAXXtz2X1g
>>>
>>> The channel here is closed after all producers have exited, and all 
>>> consumers continue to run until the channel is drained of data.
>>>
>>> The producers are managed by something somewhere in your code - and that 
>>> is the scope at which it makes sense to create channel ownership. I've used 
>>> a waitgroup to ensure that the channel is closed after all producers exit, 
>>> but you can use whatever barrier construct you want.
>>>
>>> Even if you must have a channel per producer, you can safely close the 
>>> producer side, without notifying the downstream about this. The example 
>>> early in the thread uses multiple channels, with one channel being used to 
>>> signal that the producers should exit. Channels aren't really the right 
>>> model for this, you want a thread safe flag of some sort. For example:
>>>
>>> var exitFlag uint64
>>> func producer(chan data int, wg *sync.WaitGroup) {
>>> defer wg.Done()
>>> for {
>>> shouldExit := atomic.LoadUint64()
>>> if shouldExit == 1 {
>>>  return
>>> }
>>> chan <- rand.Intn(100)
>>> }
>>> }
>>>
>>> Here's 10 producers and 3 consumers sharing a channel and closing it 
>>> safely upon receiving an exit flag:
>>> https://play.golang.org/p/RiKi1PGVSvF
>>>
>>> -- Marcin
>>>
>

Re: [go-nuts] An old problem: lack of priority select cases

2019-08-29 Thread T L 
>>> deos nto have to do anything special. Of course, there might be another 
>>>> solution, but if you need to modify the reader we are talking about a 
>>>> different problem.
>>>>
>>>> Cheers!!
>>>>
>>>> On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote:
>>>>>
>>>>> A better solution is to wrap the writes using a RWLock, grab the read 
>>>>> lock for writing, and the Write lock for closing. Pretty simple.
>>>>>
>>>>> Just encapsulate it all in a MultiWriterChannel struct - generics 
>>>>> would help here :)
>>>>>
>>>>> -Original Message- 
>>>>> From: Leo Lara 
>>>>> Sent: Aug 28, 2019 11:24 AM 
>>>>> To: golang-nuts 
>>>>> Subject: [go-nuts] Re: An old problem: lack of priority select cases 
>>>>>
>>>>> This is connected with my article: 
>>>>> https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2
>>>>>
>>>>> I think there I show it is possible to workaround that limitation 
>>>>> using standard Go tools. Of course, the code would be simple with 
>>>>> priority 
>>>>> select, but also perhaps select would become less efficient.
>>>>>
>>>>> On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L wrote:
>>>>>>
>>>>>> The old thread: 
>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o
>>>>>>
>>>>>> Go channels are flexible, but in practice, I often encountered some 
>>>>>> situations in which channel are hard to use.
>>>>>> Given an example:
>>>>>>
>>>>>> import "math/rand"
>>>>>>
>>>>>> type Producer struct {
>>>>>> data   chan int
>>>>>> closed chan struct{}
>>>>>> }
>>>>>>
>>>>>> func NewProducer() *Producer {
>>>>>> p :=  {
>>>>>> data:   make(chan int),
>>>>>> closed: make(chan struct{}),
>>>>>> }
>>>>>> 
>>>>>> go p.run()
>>>>>> 
>>>>>> return p
>>>>>> }
>>>>>>
>>>>>> func (p *Produce) Stream() chan int {
>>>>>> return p.data
>>>>>> }
>>>>>>
>>>>>> func (p *Producer) run() {
>>>>>> for {
>>>>>> // If non-blocking cases are selected by their appearance 
>>>>>> order,
>>>>>> // then the following slect block is a perfect use.
>>>>>> select {
>>>>>> case(0) <-p.closed: return
>>>>>> case p.data <- rand.Int():
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> func (p *Produce) Clsoe() {
>>>>>> close(p.closed)
>>>>>> close(p.data)
>>>>>> }
>>>>>>
>>>>>> func main() {
>>>>>> p := NewProducer()
>>>>>> for n := p.Stream() {
>>>>>> // use n ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> If the first case in the select block in the above example has a 
>>>>>> higher priority than the second one,
>>>>>> then coding will be much happier for the use cases like the above one.
>>>>>>
>>>>>> In short, the above use case requires:
>>>>>> * for receivers, data streaming end is notified by the close of a 
>>>>>> channel.
>>>>>> * for senders, data will never be sent to closed channel.
>>>>>>
>>>>>> But, as Go 1 doesn't support priority select cases, it is much 
>>>>>> tedious to implement the code
>>>>>> satisfying the above listed requirements. The final implementation is 
>>>>>> often very ugly and inefficient.
>>>>>>
>>>>>> Does anyone else also experience the pain?
>>>>>>
>>>>>
>>>>> -- 
>>>>> You received thi

  1   2   3   4   5   6   >