Re: [go-nuts] CIDR from ip range

[bar jan (janbar)]

I used the new feature netip of Go1.18 to write code that applies both ipv4 
and ipv6

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


在2015年3月22日星期日 UTC+8 12:48:25 写道：

> On Wednesday, March 18, 2015 at 7:33:54 AM UTC+1, Bakul Shah wrote:
>>
>> Rewriting this in Go is not difficult but you have to add some 
>> support functions so it's more like 80 lines!  See 
>>
>> http://play.golang.org/p/nJE2EPx88- 
>>
>
> Just to say thank you! I'm a designer mainly so if you will need a 
> "80-1000 lines" logo or something contact me and I will try to help :-)
> best,
> Victor
>
>

-- 
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/48ffda28-7ee6-41b3-a3c6-2acbd0b33e19n%40googlegroups.com.

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

['Keith Randall' via golang-nuts]

Should be fixed by https://go-review.googlesource.com/c/go/+/448899

On Tuesday, November 8, 2022 at 4:34:00 PM UTC-8 Keith Randall wrote:

> (Although normally lfstack nodes should not be heap allocated in the first 
> place?)
>
>
> On Tuesday, November 8, 2022 at 4:32:11 PM UTC-8 Keith Randall wrote:
>
>> I don't think checkptr is intended to be applied blindly inside the 
>> runtime. The lfstack code is definitely doing things that checkptr was 
>> designed to catch and flag.
>> Maybe the lfstack routines need a go:nocheckptr annotation?
>>
>> On Tuesday, November 8, 2022 at 11:21:30 AM UTC-8 David Pacheco wrote:
>>
>>> Hello,
>>>
>>> I’m trying to track down an issue reported by the Go memory allocator.  
>>> Most of the failure modes look like this one:
>>> https://github.com/golang/go/issues/53289#issuecomment-1292744833
>>> but some of them look like:
>>> https://github.com/golang/go/issues/53289#issuecomment-1289743609
>>>
>>> It looks to me like these could be different manifestations of the same 
>>> issue.  Following the advice in the second message, I tried to build Go and 
>>> run the test suite with `export GO_GCFLAGS="-d=checkptr"` in src/make.bash. 
>>>  With that, I saw checkptr fail:
>>>
>>> fatal error: checkptr: pointer arithmetic result points to invalid 
>>> allocation
>>>
>>> goroutine 23171 [running]:
>>> runtime.throw({0x8198ae?, 0xc0001560cf?})
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/panic.go:1047
>>>  
>>> +0x5d fp=0xc0029f4e70 sp=0xc0029f4e40 pc=0x43c95d
>>> runtime.checkptrArithmetic(0x770f40?, {0x0, 0x0, 0x0?})
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/checkptr.go:70
>>>  
>>> +0xea fp=0xc0029f4eb0 sp=0xc0029f4e70 pc=0x40856a
>>> runtime.lfstackUnpack(...)
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_64bit.go:52
>>> runtime.(*lfstack).pop(...)
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack.go:47
>>> runtime.LFStackPop(...)
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/export_test.go:70
>>> runtime_test.TestLFStack(0xc000d26b60)
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_test.go:52
>>>  
>>> +0x2de fp=0xc0029f4f70 sp=0xc0029f4eb0 pc=0x6deb9e
>>> testing.tRunner(0xc000d26b60, 0x820dc0)
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1446
>>>  
>>> +0x10b fp=0xc0029f4fc0 sp=0xc0029f4f70 pc=0x4fd94b
>>> testing.(*T).Run.func1()
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1493
>>>  
>>> +0x2a fp=0xc0029f4fe0 sp=0xc0029f4fc0 pc=0x4fe7ea
>>> runtime.goexit()
>>> 
>>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/asm_amd64.s:1594
>>>  
>>> +0x1 fp=0xc0029f4fe8 sp=0xc0029f4fe0 pc=0x476121
>>> created by testing.(*T).Run
>>>
>>> That points to this code:
>>>
>>> https://github.com/golang/go/blob/39ac1fbd1393deed245dcf653220b14376f6/src/runtime/lfstack_64bit.go#L52
>>>
>>> So I dug into the checkptr check and added some more printlns and I 
>>> found that this appears to be a heap address (0xc0001560c0), and 
>>> “originals” is empty (in checkptrArithmetic).  Given that, I’m not sure how 
>>> this could ever work, since “originals” seems to come from the compiler (so 
>>> it doesn’t depend on runtime state).  Can someone point me in the right 
>>> direction to better understanding what’s wrong here?  Alternatively, is 
>>> there other information that would be useful to debug this problem?
>>>
>>> Thanks,
>>> Dave
>>>
>>

-- 
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/c4dbf10f-824c-4b36-9f71-fd74a9c3ccdan%40googlegroups.com.

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

['Keith Randall' via golang-nuts]

(Although normally lfstack nodes should not be heap allocated in the first 
place?)


On Tuesday, November 8, 2022 at 4:32:11 PM UTC-8 Keith Randall wrote:

> I don't think checkptr is intended to be applied blindly inside the 
> runtime. The lfstack code is definitely doing things that checkptr was 
> designed to catch and flag.
> Maybe the lfstack routines need a go:nocheckptr annotation?
>
> On Tuesday, November 8, 2022 at 11:21:30 AM UTC-8 David Pacheco wrote:
>
>> Hello,
>>
>> I’m trying to track down an issue reported by the Go memory allocator.  
>> Most of the failure modes look like this one:
>> https://github.com/golang/go/issues/53289#issuecomment-1292744833
>> but some of them look like:
>> https://github.com/golang/go/issues/53289#issuecomment-1289743609
>>
>> It looks to me like these could be different manifestations of the same 
>> issue.  Following the advice in the second message, I tried to build Go and 
>> run the test suite with `export GO_GCFLAGS="-d=checkptr"` in src/make.bash. 
>>  With that, I saw checkptr fail:
>>
>> fatal error: checkptr: pointer arithmetic result points to invalid 
>> allocation
>>
>> goroutine 23171 [running]:
>> runtime.throw({0x8198ae?, 0xc0001560cf?})
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/panic.go:1047
>>  
>> +0x5d fp=0xc0029f4e70 sp=0xc0029f4e40 pc=0x43c95d
>> runtime.checkptrArithmetic(0x770f40?, {0x0, 0x0, 0x0?})
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/checkptr.go:70
>>  
>> +0xea fp=0xc0029f4eb0 sp=0xc0029f4e70 pc=0x40856a
>> runtime.lfstackUnpack(...)
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_64bit.go:52
>> runtime.(*lfstack).pop(...)
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack.go:47
>> runtime.LFStackPop(...)
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/export_test.go:70
>> runtime_test.TestLFStack(0xc000d26b60)
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_test.go:52
>>  
>> +0x2de fp=0xc0029f4f70 sp=0xc0029f4eb0 pc=0x6deb9e
>> testing.tRunner(0xc000d26b60, 0x820dc0)
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1446
>>  
>> +0x10b fp=0xc0029f4fc0 sp=0xc0029f4f70 pc=0x4fd94b
>> testing.(*T).Run.func1()
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1493
>>  
>> +0x2a fp=0xc0029f4fe0 sp=0xc0029f4fc0 pc=0x4fe7ea
>> runtime.goexit()
>> 
>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/asm_amd64.s:1594
>>  
>> +0x1 fp=0xc0029f4fe8 sp=0xc0029f4fe0 pc=0x476121
>> created by testing.(*T).Run
>>
>> That points to this code:
>>
>> https://github.com/golang/go/blob/39ac1fbd1393deed245dcf653220b14376f6/src/runtime/lfstack_64bit.go#L52
>>
>> So I dug into the checkptr check and added some more printlns and I found 
>> that this appears to be a heap address (0xc0001560c0), and “originals” is 
>> empty (in checkptrArithmetic).  Given that, I’m not sure how this could 
>> ever work, since “originals” seems to come from the compiler (so it doesn’t 
>> depend on runtime state).  Can someone point me in the right direction to 
>> better understanding what’s wrong here?  Alternatively, is there other 
>> information that would be useful to debug this problem?
>>
>> Thanks,
>> Dave
>>
>

-- 
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/8f0ba721-12bd-4b8a-953c-046f77f8906dn%40googlegroups.com.

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

['Keith Randall' via golang-nuts]

I don't think checkptr is intended to be applied blindly inside the 
runtime. The lfstack code is definitely doing things that checkptr was 
designed to catch and flag.
Maybe the lfstack routines need a go:nocheckptr annotation?

On Tuesday, November 8, 2022 at 11:21:30 AM UTC-8 David Pacheco wrote:

> Hello,
>
> I’m trying to track down an issue reported by the Go memory allocator.  
> Most of the failure modes look like this one:
> https://github.com/golang/go/issues/53289#issuecomment-1292744833
> but some of them look like:
> https://github.com/golang/go/issues/53289#issuecomment-1289743609
>
> It looks to me like these could be different manifestations of the same 
> issue.  Following the advice in the second message, I tried to build Go and 
> run the test suite with `export GO_GCFLAGS="-d=checkptr"` in src/make.bash. 
>  With that, I saw checkptr fail:
>
> fatal error: checkptr: pointer arithmetic result points to invalid 
> allocation
>
> goroutine 23171 [running]:
> runtime.throw({0x8198ae?, 0xc0001560cf?})
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/panic.go:1047
>  
> +0x5d fp=0xc0029f4e70 sp=0xc0029f4e40 pc=0x43c95d
> runtime.checkptrArithmetic(0x770f40?, {0x0, 0x0, 0x0?})
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/checkptr.go:70
>  
> +0xea fp=0xc0029f4eb0 sp=0xc0029f4e70 pc=0x40856a
> runtime.lfstackUnpack(...)
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_64bit.go:52
> runtime.(*lfstack).pop(...)
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack.go:47
> runtime.LFStackPop(...)
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/export_test.go:70
> runtime_test.TestLFStack(0xc000d26b60)
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_test.go:52
>  
> +0x2de fp=0xc0029f4f70 sp=0xc0029f4eb0 pc=0x6deb9e
> testing.tRunner(0xc000d26b60, 0x820dc0)
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1446
>  
> +0x10b fp=0xc0029f4fc0 sp=0xc0029f4f70 pc=0x4fd94b
> testing.(*T).Run.func1()
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1493
>  
> +0x2a fp=0xc0029f4fe0 sp=0xc0029f4fc0 pc=0x4fe7ea
> runtime.goexit()
> 
> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/asm_amd64.s:1594
>  
> +0x1 fp=0xc0029f4fe8 sp=0xc0029f4fe0 pc=0x476121
> created by testing.(*T).Run
>
> That points to this code:
>
> https://github.com/golang/go/blob/39ac1fbd1393deed245dcf653220b14376f6/src/runtime/lfstack_64bit.go#L52
>
> So I dug into the checkptr check and added some more printlns and I found 
> that this appears to be a heap address (0xc0001560c0), and “originals” is 
> empty (in checkptrArithmetic).  Given that, I’m not sure how this could 
> ever work, since “originals” seems to come from the compiler (so it doesn’t 
> depend on runtime state).  Can someone point me in the right direction to 
> better understanding what’s wrong here?  Alternatively, is there other 
> information that would be useful to debug this problem?
>
> Thanks,
> Dave
>

-- 
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/72543344-ad79-4f90-b8a5-13392db1e7afn%40googlegroups.com.

Re: [go-nuts] Re: Unicode variable name error

['Dan Kortschak' via golang-nuts]

On Tue, 2022-11-08 at 09:17 -0800, TheDiveO wrote:
> I've always wondered how to deal with exported versus unexported
> identifiers in scripts like Chinese?

There is an issue for this https://go.dev/issue/22188 which discusses
the approaches that are currently used with a view to making it easier.
It also links to previous issues about 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/665360ff854b4abc823a5882f6f1584fdfb6ba5f.camel%40kortschak.io.

Re: [go-nuts] Re: Unicode variable name error

[TheDiveO]

I've always wondered how to deal with exported versus unexported 
identifiers in scripts like Chinese?

On Sunday, November 6, 2022 at 3:08:59 PM UTC+1 ba...@iitbombay.org wrote:

> In Indic scripts in certain contexts you have to use a vowel sign for the 
> typography to make sense; you can’t use a vowel letter in its place. So for 
> example the middle “ku” in my name has to be written as ક+ુ — which will be 
> rendered as કુ — even though it is equivalent to ક+્+ઉ. Also, “halant” (્), 
> is not a letter! 
>
> I would strongly urge Nikhilesh and other people wanting to use any Indic 
> script to **avoid* * it (even if Go implements TR31 as in Swift) and 
> instead use the lossless transliteration scheme of IAST if the program 
> calls for an Indian word as a Go object name.   
> https://en.wikipedia.org/wiki/International_Alphabet_of_Sanskrit_Transliteration
>   
> 
>
>
> On Nov 6, 2022, at 4:02 AM, Rob Pike  wrote:
>
> 
>
> % unicode -d పే
>
> U+0C2A 'ప' telugu letter pa
>
> U+0C47 'ే' telugu vowel sign ee
>
> % unicode -U C2A C47
>
> U+0C2A 'ప' TELUGU LETTER PA
>
> category: Lo
>
> canonical combining classes: 0
>
> bidirectional category: L
>
> mirrored: N
>
> U+0C47 'ే' TELUGU VOWEL SIGN EE
>
> category: Mn
>
> canonical combining classes: 0
>
> bidirectional category: NSM
>
> mirrored: N
>
> %
>
>
> The problem is the second code point, U+0C47, Telugu vowel sign EE. It is 
> not in the letter class. If I change your program to use just the first 
> code point, it works: https://play.golang.com/p/eNvuZH33s65
>
>
> The rules for identifiers in Go were chosen because they are easy to 
> implement, but they do have the problem that they do not treat all 
> languages equally. They may expand one day, but at the moment this is the 
> situation.
>
>
> There are a number of open issues around this. Start with 
> https://github.com/golang/go/issues/20706 if you want to read more.
>
>
> -rob
>
>
>
>
> On Sun, Nov 6, 2022 at 9:52 PM Konstantin Khomoutov  
> wrote:
>
>> On Sun, Nov 06, 2022 at 01:45:53PM +0530, Nikhilesh Susarla wrote:
>>
>> >> Per the Go spec[1], an identifier consists of a Unicode letter 
>> followed by
>> >> zero or more Unicode letters or digits. The character పే is in the 
>> Unicode
>> >> category nonspacing mark rather than the category letter.
>> [...]
>> > So, if the unicode letters are there in the nonspacing mark as you
>> > mentioned they can't be used right ?
>>
>> I sense the source of your misunderstanding might be rooted in your lack 
>> of
>> certain basics about Unicode. You seem to call "a letter" anything which 
>> may
>> appear in a text document (a Go source code file is a text document) but 
>> this
>> it not true. Maybe that's just a terminological problem, but still the 
>> fact
>> is, the Unicode standard calls "letters" a very particular group of things
>> among those the Unicode standard describes. To give a very simplified 
>> example,
>> in the text string "foo bar" there are six letters (five distinct) and one
>> space character which is not a letter. The charcter being discussed is 
>> not a
>> letter in Unicode, either.
>>
>> -- 
>> 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/20221106105154.xkoemtt6tx25flam%40carbon
>> .
>>
> -- 
> 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/CAOXNBZS085qwY5tXj%3Di5MeBguXeemHYBmSzjZks--MNmALohcg%40mail.gmail.com
>  
> 
> .
>
>

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

Re: [go-nuts] Choosing ABI for a function

[Ian Lance Taylor]

On Tue, Nov 8, 2022 at 7:55 AM Aviram Hassan  wrote:
>
> I see that some runtime functions have both `abi0` interface and 
> `ABIInternal`.
> I was wondering what makes the compiler do so, and if I can make it do the 
> same for my defined functions?
> A bit of a background - I'm doing a bit of a lowlevel fun, and I want to hook 
> Go functions using just Go code (no assembly) so I want to have the same 
> interface as the original ones.

There is background information for this at
https://go.googlesource.com/proposal/+/refs/heads/master/design/27539-internal-abi.md
.

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/CAOyqgcVxKWLV%3D%3De3pH2KH%2Bu-obFaWdeLuKwsUKUCfHn23ABVGw%40mail.gmail.com.

Re: [go-nuts] Why not sync.Mutex is designed as an interface

[Ian Lance Taylor]

On Tue, Nov 8, 2022 at 7:55 AM Xie Yuchen  wrote:
>
> I checked with the issue about how to refer no-copy and the check of cmd/vet. 
> After checking, I'm curious that why not define mutex as an interface, as 
> interface always copy like a reference, which means users don't worry to copy 
> by value and cause an error.
>
> Design by the interface can always copy like a reference and no need to mark 
> it as cannot copy. However, we need to provide a default implementation of 
> the mutex and the construction of mutex is not short and clean anymore.
>
> Would like to see how do you think about this confusion.

That would mean that the zero value of sync.Mutex would not be usable.

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/CAOyqgcUsspZ%3DQo5HBsBh%3DKNXjmMt%3DWNjueHQD-MALHxrqS1vMQ%40mail.gmail.com.

[go-nuts] Re: Why not sync.Mutex is designed as an interface

[TheDiveO]

>From my limited experience, I notice two things:

   1. I've rarely ever seen the need arise in my limited own experience to 
   copy objects that would like to share their mutex. I would rather consider 
   this to be most of the time a design issue, but I will be happy to stand 
   corrected. The rationale to me in these cases is that the mutex is 
   protecting a set of information closely "locked" to the lock it is 
   protecting it. When do you even copy the information? Surely not while you 
   don't have the lock, but then you end up with a locked copy. Now, if the 
   copies reference the same lock, what does that really mean? You have two 
   copies of the information, yet a single lock? Why then not having a single 
   source of information with a single lock or two sets of information that 
   can develop independently and have their own locks?
   2. Due to the way Interfaces work in Go you can define your own Mutex 
   interface and then sync.Mutex will be one implementation of it. (I hope 
   that I didn't miss something here, but that is what immediately came to my 
   mind.)


On Tuesday, November 8, 2022 at 4:55:13 PM UTC+1 xieyu...@gmail.com wrote:

> I checked with the issue about how to refer no-copy and the check of 
> cmd/vet. After checking, I'm curious that why not define mutex as an 
> interface, as interface always copy like a reference, which means users 
> don't worry to copy by value and cause an error.
>
> Design by the interface can always copy like a reference and no need to 
> mark it as cannot copy. However, we need to provide a default 
> implementation of the mutex and the construction of mutex is not short and 
> clean anymore.
>
> Would like to see how do you think about this confusion. 
>
> Regrads
>

-- 
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/1294c600-2078-46d3-bbad-50e0c80a3a28n%40googlegroups.com.

Re: [go-nuts] Picnic Senior Go Dev

[Yamil Bracho]

Hi, Giorgi and nice to meet you.
I am interested in this position so enclosed my resume for your reference.
Just let me know if you need any additional information.

Best Regards,
Yamil


El mar, 8 nov 2022 a las 10:54, Giorgi Dalakishvili
() escribió:

> Hello Go Devs, I am Giorgi Tech recruiter at Picnic, Palo Alto / Ca based
> fast-growing app with 2 million users already.
> I want you to offer Golang Dev job, you can work remotely.
> If you have three years of experience in the Go language I want to offer
> you a really good working environment, a competitive and good salary with
> equity and bonuses.
>
> See attached job description below.
>
> best regards.
>
> --
> 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/bffca344-04fd-49dd-b7cf-76ed47ba212bn%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/CAEZYzU14i21M847fE5wSuuno-CGpwHm0pNMNtUuTUqV6yuLmdw%40mail.gmail.com.

[go-nuts] Why not sync.Mutex is designed as an interface

[Xie Yuchen]

I checked with the issue about how to refer no-copy and the check of 
cmd/vet. After checking, I'm curious that why not define mutex as an 
interface, as interface always copy like a reference, which means users 
don't worry to copy by value and cause an error.

Design by the interface can always copy like a reference and no need to 
mark it as cannot copy. However, we need to provide a default 
implementation of the mutex and the construction of mutex is not short and 
clean anymore.

Would like to see how do you think about this confusion. 

Regrads

-- 
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/741371e6-6322-4d4d-b49d-f592b4f7eaf7n%40googlegroups.com.

[go-nuts] Choosing ABI for a function

[Aviram Hassan]

Hi,
I see that some runtime functions have both `abi0` interface and 
`ABIInternal`.
I was wondering what makes the compiler do so, and if I can make it do the 
same for my defined functions?
A bit of a background - I'm doing a bit of a lowlevel fun, and I want to 
hook Go functions using just Go code (no assembly) so I want to have the 
same interface as the original ones.

Thanks!

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

[go-nuts] Picnic Senior Go Dev

[Giorgi Dalakishvili]

Hello Go Devs, I am Giorgi Tech recruiter at Picnic, Palo Alto / Ca based 
fast-growing app with 2 million users already.
I want you to offer Golang Dev job, you can work remotely.
If you have three years of experience in the Go language I want to offer 
you a really good working environment, a competitive and good salary with 
equity and bonuses.

See attached job description below.

best regards.

-- 
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/bffca344-04fd-49dd-b7cf-76ed47ba212bn%40googlegroups.com.


Picnic_Go_Job_Description.docx
Description: MS-Word 2007 document

Re: [go-nuts] Is it possible to switch on type T in a generic function?

['Mark' via golang-nuts]

Thanks for your help and very interesting ideas. In the end I used this:

type Set[T comparable] map[T]struct{}

func New[T comparable](elements ...T) Set[T] {
set := make(Set[T], len(elements))
for _, element := range elements {
set[element] = struct{}{}
}
return set
}

func (me Set[T]) String() string {
elements := make([]T, 0, len(me))
for element := range me {
elements = append(elements, element)
}
sort.Slice(elements, func(i, j int) bool {
return less(elements[i], elements[j])
})
s := "{"
sep := ""
for _, element := range elements {
s += sep + asStr(element)
sep = " "
}
return s + "}"
}

func asStr(x any) string {
if s, ok := x.(string); ok {
return fmt.Sprintf("%q", s)
}
return fmt.Sprintf("%v", x)
}

func less(a, b any) bool {
switch x := a.(type) {
case int:
return x < b.(int)
case float64:
return x < b.(float64)
case string:
return x < b.(string)
default:
return fmt.Sprintf("%v", a) < fmt.Sprintf("%v", b)
}
}

Interestingly, I couldn't put the asStr() code in the String() function 
since doing so produced this error:

invalid operation: cannot use type assertion on type parameter value 
element (variable of type T constrained by comparable)

Anyway, I'm happy that it all works now. (I know I ought to include every 
int & float32, but this is enough for now).



On Tuesday, November 8, 2022 at 11:29:34 AM UTC rog wrote:

> If you're sure that T is an int or a string, then why not constrain it as 
> such? https://go.dev/play/p/1kT6EacMHco
>
> You could go further and constrain it to allow any type with ordering 
> defined: https://go.dev/play/p/il5koj1RPkh
>
> If you want to allow any kind of comparable key in your set, one could 
> observe that essentially you're trying to solve the same problem that the 
> fmt package is solving when it converts maps to string. It uses the 
> internal fmtsort  package, which, as 
> luck would have it, has been factored out into an externally available 
> package . So 
> you could do this: https://go.dev/play/p/oKTGSm_o22a
>
> To answer the specific question you asked, there is an issue that tracks 
> the ability to do a switch directly on a type parameter: 
> https://github.com/golang/go/issues/45380
>
> But you can also work around the lack of that feature by doing something 
> like this: https://go.dev/play/p/3C2a61Ojbxs
>
> Hope this helps,
>
>   rog.
>
>
> On Tue, 8 Nov 2022 at 08:53, 'Mark' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Given a function:
>>
>> func F[T comparable](a T) {
>> }
>>
>> is it possible to check T's type inside F?
>>
>> My use case is that I have a function with signature G[T comparable](x 
>> []T) and inside G I want to sort the elements in slice x where T could be 
>> int or string.
>>
>> This arises in a tiny generic set module I've created: 
>> https://github.com/mark-summerfield/gset
>> In the String() method I want to return a string with the elements sorted 
>> (for human readability and for testing convenience); but at the moment I 
>> can only do this by converting all elements to strings and sorting them 
>> which isn't good for ints.
>>
>> -- 
>> 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/e746f065-24fa-474a-90ec-2d8367bf3e3bn%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/dea0057c-fd75-4a05-a171-0a77bbd1d051n%40googlegroups.com.

Re: [go-nuts] Goroutine to thread mapping

[Robert Engels]

To answer the rest of the question, since they are premptable they can be 
resumed on any thread. Go tries to use the same thread for performance but will 
issue memory barriers when it cannot. 

> On Nov 8, 2022, at 5:17 AM, peterGo  wrote:
> 
> 
> piotr,
> 
> Goroutines are now asynchronously preemptible. As a result, loops without 
> function calls no longer potentially deadlock the scheduler or significantly 
> delay garbage collection. February 2020,  https://go.dev/doc/go1.14#runtime
> 
> peter
> 
> 
>> On Tuesday, November 8, 2022 at 3:31:25 AM UTC-5 piotr.w...@gmail.com wrote:
>> I mean the Plan 9 assembler. Also assume the function is a leaf function, 
>> just a long one. Can such a function be preempted by Go runtime and 
>> re-assigned to another thread or can the reassignment happen only 
>> cooperatively, in a number of roughly predictable selected places? 
>> 
>> poniedziałek, 7 listopada 2022 o 18:46:42 UTC+1 ren...@ix.netcom.com 
>> napisał(a):
>>> Do you mean Go assembly or an assembly function called via CGo?
>>> 
> On Nov 7, 2022, at 11:28 AM, Piotr Wyderski  wrote:
> 
 
>>> 
 Hello,
 
 A goroutine needs ultimately to be assigned to an OS thread. If a 
 goroutine calls an assembly function F, can the thread assignment change 
 during the execution of F? 
 In other words, is F guaranteed to return on the same thread it was called?
 
Best regards, Piotr
  
>>> 
 -- 
 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/03f2cf25-7e52-41ca-ac20-a04877d5df9dn%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/69436177-2cee-452f-8df9-837353a4e742n%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/826AAB22-11F3-4B0E-9770-C04112D240DE%40ix.netcom.com.

Re: [go-nuts] Is it possible to switch on type T in a generic function?

[roger peppe]

If you're sure that T is an int or a string, then why not constrain it as
such? https://go.dev/play/p/1kT6EacMHco

You could go further and constrain it to allow any type with ordering
defined: https://go.dev/play/p/il5koj1RPkh

If you want to allow any kind of comparable key in your set, one could
observe that essentially you're trying to solve the same problem that the
fmt package is solving when it converts maps to string. It uses the
internal fmtsort  package, which, as
luck would have it, has been factored out into an externally available
package . So
you could do this: https://go.dev/play/p/oKTGSm_o22a

To answer the specific question you asked, there is an issue that tracks
the ability to do a switch directly on a type parameter:
https://github.com/golang/go/issues/45380

But you can also work around the lack of that feature by doing something
like this: https://go.dev/play/p/3C2a61Ojbxs

Hope this helps,

  rog.


On Tue, 8 Nov 2022 at 08:53, 'Mark' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Given a function:
>
> func F[T comparable](a T) {
> }
>
> is it possible to check T's type inside F?
>
> My use case is that I have a function with signature G[T comparable](x
> []T) and inside G I want to sort the elements in slice x where T could be
> int or string.
>
> This arises in a tiny generic set module I've created:
> https://github.com/mark-summerfield/gset
> In the String() method I want to return a string with the elements sorted
> (for human readability and for testing convenience); but at the moment I
> can only do this by converting all elements to strings and sorting them
> which isn't good for ints.
>
> --
> 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/e746f065-24fa-474a-90ec-2d8367bf3e3bn%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/CAJhgacibPQ%3DbgK74G4YSiyHdQQrNZJpahFph3Zz2%2BhDe_2j_0g%40mail.gmail.com.

Re: [go-nuts] Goroutine to thread mapping

[peterGo]

piotr,

Goroutines are now asynchronously preemptible. As a result, loops without 
function calls no longer potentially deadlock the scheduler or 
significantly delay garbage collection. February 2020,  
https://go.dev/doc/go1.14#runtime

peter


On Tuesday, November 8, 2022 at 3:31:25 AM UTC-5 piotr.w...@gmail.com wrote:

> I mean the Plan 9 assembler. Also assume the function is a leaf function, 
> just a long one. Can such a function be preempted by Go runtime and 
> re-assigned to another thread or can the reassignment happen only 
> cooperatively, in a number of roughly predictable selected places? 
>
> poniedziałek, 7 listopada 2022 o 18:46:42 UTC+1 ren...@ix.netcom.com 
> napisał(a):
>
>> Do you mean Go assembly or an assembly function called via CGo?
>>
>> On Nov 7, 2022, at 11:28 AM, Piotr Wyderski  wrote:
>>
>> 
>>
>> Hello,
>>
>> A goroutine needs ultimately to be assigned to an OS thread. If a 
>> goroutine calls an assembly function F, can the thread assignment change 
>> during the execution of F? 
>> In other words, is F guaranteed to return on the same thread it was 
>> called?
>>
>>Best regards, Piotr
>>  
>>
>> -- 
>> 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/03f2cf25-7e52-41ca-ac20-a04877d5df9dn%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/69436177-2cee-452f-8df9-837353a4e742n%40googlegroups.com.

Re: [go-nuts] Is it possible to switch on type T in a generic function?

[Jan Mercl]

On Tue, Nov 8, 2022 at 10:56 AM 'Mark' via golang-nuts
 wrote:
> // Want to sort by T < T //
> elements := make([]string, 0, len(me))
> for element := range me {
> elements = append(elements, fmt.Sprintf("%#v", element))
> }
> sort.Strings(elements)
> /


Not tested:

// Want to sort by T < T //
elements := make([]T, 0, len(me))
for element := range me {
elements = append(elements, element)
}
sort.Slice(elements, func(i, j int) bool { return
less(elements[i], elements[j]) })
/

But you need to extend the less function to handle mixed types. Like
in less(42, "foo").

-- 
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/CAA40n-UC7NevL7EtrLNb9rJRDSXDtf9AaZ-FX497b41XR2jJ5A%40mail.gmail.com.

Re: [go-nuts] Is it possible to switch on type T in a generic function?

['Mark' via golang-nuts]

I see that your example works, but I can't see how to adapt it to my use 
case.

type Set[T comparable] map[T]struct{}

func New[T comparable](elements ...T) Set[T] {
set := make(Set[T], len(elements))
for _, element := range elements {
set[element] = struct{}{}
}
return set
}

func (me Set[T]) String() string {
// Want to sort by T < T //
elements := make([]string, 0, len(me))
for element := range me {
elements = append(elements, fmt.Sprintf("%#v", element))
}
sort.Strings(elements)
/
s := "{"
sep := ""
for _, element := range elements {
s += fmt.Sprintf("%s%s", sep, element)
sep = " "
}
return s + "}"
}

On Tuesday, November 8, 2022 at 9:19:48 AM UTC Jan Mercl wrote:

> On Tue, Nov 8, 2022 at 9:53 AM 'Mark' via golang-nuts
>  wrote:
>
> > Given a function:
> >
> > func F[T comparable](a T) {
> > }
> >
> > is it possible to check T's type inside F?
> >
> > My use case is that I have a function with signature G[T comparable](x 
> []T) and inside G I want to sort the elements in slice x where T could be 
> int or string.
>
> https://go.dev/play/p/zxQYVvOMX35 ?
>

-- 
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/577c056e-bf3f-4002-b431-f73aeda75a6dn%40googlegroups.com.

Re: [go-nuts] Is it possible to switch on type T in a generic function?

[Jan Mercl]

On Tue, Nov 8, 2022 at 9:53 AM 'Mark' via golang-nuts
 wrote:

> Given a function:
>
> func F[T comparable](a T) {
> }
>
> is it possible to check T's type inside F?
>
> My use case is that I have a function with signature G[T comparable](x []T) 
> and inside G I want to sort the elements in slice x where T could be int or 
> string.

https://go.dev/play/p/zxQYVvOMX35 ?

-- 
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/CAA40n-Xei-qGr149VjURsfKOp42THVTBowGeFxHY_bdwowYMmQ%40mail.gmail.com.

[go-nuts] Is it possible to switch on type T in a generic function?

['Mark' via golang-nuts]

Given a function:

func F[T comparable](a T) {
}

is it possible to check T's type inside F?

My use case is that I have a function with signature G[T comparable](x []T) 
and inside G I want to sort the elements in slice x where T could be int or 
string.

This arises in a tiny generic set module I've created: 
https://github.com/mark-summerfield/gset
In the String() method I want to return a string with the elements sorted 
(for human readability and for testing convenience); but at the moment I 
can only do this by converting all elements to strings and sorting them 
which isn't good for ints.

-- 
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/e746f065-24fa-474a-90ec-2d8367bf3e3bn%40googlegroups.com.

Re: [go-nuts] Goroutine to thread mapping

[Piotr Wyderski]

I am fine with affinity changes during, say, a mutex or channel operation. 
But does (or merely can) Go preempt the execution of leaf assembly 
functions, basically re-creating threads in user space? Or is the currently 
assigned thread mapping locked until the function decides to return, as 
cooperative multitasking would suggest? 

poniedziałek, 7 listopada 2022 o 19:01:22 UTC+1 Amnon napisał(a):

> Go makes no guarantees about the affinity between goroutines and threads, 
> and the mapping does  typically jump around a lot during the execution of 
> a program.
>
> On Monday, 7 November 2022 at 17:46:42 UTC ren...@ix.netcom.com wrote:
>
>> Do you mean Go assembly or an assembly function called via CGo?
>>
>> On Nov 7, 2022, at 11:28 AM, Piotr Wyderski  wrote:
>>
>> 
>>
>> Hello,
>>
>> A goroutine needs ultimately to be assigned to an OS thread. If a 
>> goroutine calls an assembly function F, can the thread assignment change 
>> during the execution of F? 
>> In other words, is F guaranteed to return on the same thread it was 
>> called?
>>
>>Best regards, Piotr
>>  
>>
>> -- 
>> 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/03f2cf25-7e52-41ca-ac20-a04877d5df9dn%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/e53412c6-574f-4b6e-8e66-35673840fa6dn%40googlegroups.com.

Re: [go-nuts] Goroutine to thread mapping

[Piotr Wyderski]

I mean the Plan 9 assembler. Also assume the function is a leaf function, 
just a long one. Can such a function be preempted by Go runtime and 
re-assigned to another thread or can the reassignment happen only 
cooperatively, in a number of roughly predictable selected places? 

poniedziałek, 7 listopada 2022 o 18:46:42 UTC+1 ren...@ix.netcom.com 
napisał(a):

> Do you mean Go assembly or an assembly function called via CGo?
>
> On Nov 7, 2022, at 11:28 AM, Piotr Wyderski  wrote:
>
> 
>
> Hello,
>
> A goroutine needs ultimately to be assigned to an OS thread. If a 
> goroutine calls an assembly function F, can the thread assignment change 
> during the execution of F? 
> In other words, is F guaranteed to return on the same thread it was called?
>
>Best regards, Piotr
>  
>
> -- 
> 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/03f2cf25-7e52-41ca-ac20-a04877d5df9dn%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/b7e74630-0034-41f3-939a-4d8c8894d891n%40googlegroups.com.