Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

TD;DR;
Erratas: I mean, I got all the genericity (not "generosity") I need
(without "I shall")

I'm sorry and please accept the amendment.

El lun, 23 oct 2023 a las 18:21, Victor Giordano ()
escribió:

> Yes Ineed Mike! Generics can be good and can be bad... perhaps just as the
> OOP inheritance.
>
> And thanks Alex indeed! His answer was enlightening!
>
> TD;DR;
> Just another personal feeling.
>
> Prior to generics: with interfaces I live a happy life, I got all the
> generosity I shall need... if I wanna work with slices of interfaces I
> learn that I have to use the for range loop for converting each element of
> the interface's slice into the concrete type. I learned it from this
> article  (Look for "Values of
> []T can't be directly converted to []I, even if type T implements interface
> type I").
>
>
>
> El lun, 23 oct 2023 a las 16:59, Mike Schinkel ()
> escribió:
>
>> Absolutely, some times generics are not needed.
>>
>> I actually don't find a need to use them that often which is probably why
>> when I came across a use-case that really needed them I was so stumped as
>> to how make it work.  Kudos again to Axel for helping me recognize my
>> blindspot.
>>
>> -Mike
>> P.S. BTW, regarding your *"I mean this...
>> "* link, I already addressed
>> 
>> why that was not sufficient for the use-case earlier in the thread. #justfyi
>>
>> On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote:
>>
>>> Very interesting case.
>>>
>>> As Alex says, if you "help" the compiler writing  the actual type
>>> parameter like `Append[Suiter](slice, suiter)` it works. I have seen this
>>> before in Java when generics comes into town... I guess with time golang
>>> team with time will improve the type inference engine... this also happens
>>> with typescript... perhaps is a common trait in evolution of language
>>> compilers.
>>>
>>> Now if you allow me, I do appreciate that not using generics and using
>>> interfaces in your Append method things will work... I mean this
>>> ...
>>> I know... probably it won't fit to your coding issues... but what I feel
>>> sometimes is that generics aren't necessary and we tend to make use. I
>>> don't know.. forgive me if I'm wrong... just an opinion.
>>>
>>>
>>> El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com
>>> escribió:
>>>
 On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com
 wrote:

 Sorry, I didn't look your full code.
 I think the full code should work with Go toolchain 1.21.n.


 Aha, it actually doesn't. I'm surprised.


 On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:

 How so?

 Can you give an example scenario where it could cause unintended
 consequences?  Or some other negative?

 -Mike

 On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
 wrote:


 It is hard to call such type inference better. That is too aggressive.

 --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/eD7207kM8zA/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/c62243c1-d6af-41c1-b64d-be7d59063576n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> V
>


-- 
V

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

Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

Yes Ineed Mike! Generics can be good and can be bad... perhaps just as the
OOP inheritance.

And thanks Alex indeed! His answer was enlightening!

TD;DR;
Just another personal feeling.

Prior to generics: with interfaces I live a happy life, I got all the
generosity I shall need... if I wanna work with slices of interfaces I
learn that I have to use the for range loop for converting each element of
the interface's slice into the concrete type. I learned it from this article
 (Look for "Values of []T can't
be directly converted to []I, even if type T implements interface type I").



El lun, 23 oct 2023 a las 16:59, Mike Schinkel ()
escribió:

> Absolutely, some times generics are not needed.
>
> I actually don't find a need to use them that often which is probably why
> when I came across a use-case that really needed them I was so stumped as
> to how make it work.  Kudos again to Axel for helping me recognize my
> blindspot.
>
> -Mike
> P.S. BTW, regarding your *"I mean this...
> "* link, I already addressed
> 
> why that was not sufficient for the use-case earlier in the thread. #justfyi
>
> On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote:
>
>> Very interesting case.
>>
>> As Alex says, if you "help" the compiler writing  the actual type
>> parameter like `Append[Suiter](slice, suiter)` it works. I have seen this
>> before in Java when generics comes into town... I guess with time golang
>> team with time will improve the type inference engine... this also happens
>> with typescript... perhaps is a common trait in evolution of language
>> compilers.
>>
>> Now if you allow me, I do appreciate that not using generics and using
>> interfaces in your Append method things will work... I mean this
>> ...
>> I know... probably it won't fit to your coding issues... but what I feel
>> sometimes is that generics aren't necessary and we tend to make use. I
>> don't know.. forgive me if I'm wrong... just an opinion.
>>
>>
>> El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com
>> escribió:
>>
>>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com
>>> wrote:
>>>
>>> Sorry, I didn't look your full code.
>>> I think the full code should work with Go toolchain 1.21.n.
>>>
>>>
>>> Aha, it actually doesn't. I'm surprised.
>>>
>>>
>>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>>
>>> How so?
>>>
>>> Can you give an example scenario where it could cause unintended
>>> consequences?  Or some other negative?
>>>
>>> -Mike
>>>
>>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
>>> wrote:
>>>
>>>
>>> It is hard to call such type inference better. That is too aggressive.
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/eD7207kM8zA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/c62243c1-d6af-41c1-b64d-be7d59063576n%40googlegroups.com
> 
> .
>


-- 
V

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

Re: [go-nuts] Can Generics match implementers of an interface?

[Mike Schinkel]

Absolutely, some times generics are not needed.  

I actually don't find a need to use them that often which is probably why 
when I came across a use-case that really needed them I was so stumped as 
to how make it work.  Kudos again to Axel for helping me recognize my 
blindspot.

-Mike
P.S. BTW, regarding your *"I mean this... 
"* link, I already addressed 
 why 
that was not sufficient for the use-case earlier in the thread. #justfyi

On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote:

> Very interesting case.
>
> As Alex says, if you "help" the compiler writing  the actual type 
> parameter like `Append[Suiter](slice, suiter)` it works. I have seen this 
> before in Java when generics comes into town... I guess with time golang 
> team with time will improve the type inference engine... this also happens 
> with typescript... perhaps is a common trait in evolution of language 
> compilers.
>
> Now if you allow me, I do appreciate that not using generics and using 
> interfaces in your Append method things will work... I mean this 
> ... 
> I know... probably it won't fit to your coding issues... but what I feel 
> sometimes is that generics aren't necessary and we tend to make use. I 
> don't know.. forgive me if I'm wrong... just an opinion.
>
>
> El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com 
> escribió:
>
>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>>
>> Sorry, I didn't look your full code.
>> I think the full code should work with Go toolchain 1.21.n.
>>
>>
>> Aha, it actually doesn't. I'm surprised.
>>
>>
>> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>>
>> How so? 
>>
>> Can you give an example scenario where it could cause unintended 
>> consequences?  Or some other negative?
>>
>> -Mike
>>
>> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
>> wrote:
>>
>>
>> It is hard to call such type inference better. That is too aggressive.
>>
>>

-- 
You received this message because you 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/c62243c1-d6af-41c1-b64d-be7d59063576n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Mike Schinkel]

Yes, I was surprised too.  It actually took me the better part of a day 
trying to get this to work before finally posting to the list.

It turns out that this limit was actually documented by Ian Lance Taylor 
back in February 2023:

https://github.com/golang/go/issues/58650

Look for the section entitled *"Inferring based on interfaces."*

Again, it sure would be nice it this were possible, if for no other reason 
than to keep others being as time-inefficient as I was while trying to 
figure it out. 

-Mike
On Sunday, October 22, 2023 at 11:01:47 PM UTC-4 tapi...@gmail.com wrote:

> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>
> Sorry, I didn't look your full code.
> I think the full code should work with Go toolchain 1.21.n.
>
>
> Aha, it actually doesn't. I'm surprised.
>
>
> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>
> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
You received this message because you 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/d4b59845-bd40-4c24-9838-8b1210dfc205n%40googlegroups.com.

Re: [go-nuts] Can Generics match implementers of an interface?

[Victor Giordano]

Very interesting case.

As Alex says, if you "help" the compiler writing  the actual type parameter 
like `Append[Suiter](slice, suiter)` it works. I have seen this before in 
Java when generics comes into town... I guess with time golang team with 
time will improve the type inference engine... this also happens with 
typescript... perhaps is a common trait in evolution of language compilers.

Now if you allow me, I do appreciate that not using generics and using 
interfaces in your Append method things will work... I mean this 
... 
I know... probably it won't fit to your coding issues... but what I feel 
sometimes is that generics aren't necessary and we tend to make use. I 
don't know.. forgive me if I'm wrong... just an opinion.


El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com 
escribió:

> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>
> Sorry, I didn't look your full code.
> I think the full code should work with Go toolchain 1.21.n.
>
>
> Aha, it actually doesn't. I'm surprised.
>
>
> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote:
>
> How so? 
>
> Can you give an example scenario where it could cause unintended 
> consequences?  Or some other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>

-- 
You received this message because you 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/f9ccf911-c7f7-4b68-bee6-26df2eb6eb1fn%40googlegroups.com.

Re: [go-nuts] Re: custom slog Handler which adds Attribute and WithGroup

['Sean Liao' via golang-nuts]

The slog API doesn't allow wrapping handlers this way. slog.Handlers hold
state for the current open group.
You'll need a full implementation of a handler to do this.

(Technically it's possible if you record the group/attrs in With/WithGroup
yourself and only call the wrapped handler in Handle, but you lose any
preformatting performance benefits a handler may have implemented.)

- sean


On Mon, Oct 23, 2023 at 2:50 PM Johann Höchtl 
wrote:

> As I got zero reply to that answer, let me rephrase it probably more
> easily:
>
> I would like to use slog, no other logging library
> I would like to have an entry called eventID which is at the root level
> and has a unique uuid for every log entry
> I would like to use a group for every application specific key-val pairs
>
> What I trired so far:
>
>- Use a Handler to add eventID : The key gets added to the logger yet
>at the group nesting level, not at the root level
>- Use a ReplaceAttr-Function: I add the key on initiailisation yet
>leave the value unassigned to Replace it in the ReplaceAttr-Function: The
>ReplaceAttr-Function sees the  root level addded eventID only untill a call
>to .WithGroup, then the  eventId is no longer available within the
>ReplaceAttr-Function
>
>
> Any help?
> Johann Höchtl schrieb am Donnerstag, 5. Oktober 2023 um 17:59:30 UTC+2:
>
>> I created a custom slog Handler which adds an attribute eventId which is
>> a GUID
>>
>> A NewLogger function returns that logger wrapped into a group: Every
>> further key-value provided should go into that group.
>>
>> Unfortunately the eventId also gets promoted into that group although it
>> should be at the parent level.
>>
>> See here the Goplay https://play.golang.com/p/a10f09jMwL3
>>
>> Thank you for your help, Johann
>>
> --
> You received this message because you 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/16dc9f51-6c8c-4fd9-9942-5e365399e26dn%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/CAGabyPokE8SKBtqKiUNs9_aieX2mWdxKm4XrwOoYOoe6jV%3DMUA%40mail.gmail.com.

[go-nuts] Can a lambda passed to other functions be inlined by a Go compiler?

[Shamil Mukhetdinov]

Imagine you have something like this:

* func foo(data []int, suitable func(v int) bool) []int { *
*   result := make([]int, 0, len(data) *
*for _, v := range data { *
*if suitable(v) { *
*result = append(result, v) *
*} *
*} return result *
*} *


func main() { 
data := []int{1, 2, 3, 4, 5} 
foo(data, func(v int) bool { return v % 2 == 0 }) 
}

If instead of suitable lambda I use an explicit function call, that call 
may be inlined in Go.

But C++ supporting inlining for copied closures.

Does golang support inlining for lambdas, if I have that function 
signature? Or only non-escaping to the other functions lambdas can be 
inlined?

I found this issue which is still open

-- 
You received this message because you 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/059c6b10-dc81-4f17-bc56-1db59f2a1fbcn%40googlegroups.com.

Re: [go-nuts] Re: recommended statistics package? Requirements: ANOVA, Brown-Forsythe

[Martin Schnabel]

Hi,

I attempted to translate the linked JS implementation for fun. Maybe 
someone can use it as a starting point and correct or verify its 
correctness.


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

Have fun!

On 10/23/23 07:38, Jan wrote:
hi, I did a quick search and I didn't find anything in Go. But looking 
at the definition and at one implementation in JS 
, it sounds something relatively easy to write and share :)  You can use the R implementation to create some test datasets. Maybe gonum/stat  would be a potential home for such a function ? What do you think ?


cheers
On Friday, October 20, 2023 at 10:54:55 AM UTC+2 王富民awaw wrote:

Hi follow Gophers

I wonder is there a canonical, verifiably correct Go package for
statistics?
In particular, Go code that does the Brown-Forsythe test of equal
variance.
Ideally in pure Go, but linking with CGo is OK.

A search on Google and pkg.go.dev  does not
return helpful results.
I wonder is there anything that the community could share?

--
You received this message because you 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/7ee10c0f-8af6-4b31-baaf-ce2ccb9c0211n%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/7fe194f0-2d29-4b44-8654-e857365ba5cc%40mb0.org.

[go-nuts] Re: custom slog Handler which adds Attribute and WithGroup

[Johann Höchtl]

As I got zero reply to that answer, let me rephrase it probably more easily:

I would like to use slog, no other logging library
I would like to have an entry called eventID which is at the root level and 
has a unique uuid for every log entry
I would like to use a group for every application specific key-val pairs

What I trired so far:

   - Use a Handler to add eventID : The key gets added to the logger yet at 
   the group nesting level, not at the root level
   - Use a ReplaceAttr-Function: I add the key on initiailisation yet leave 
   the value unassigned to Replace it in the ReplaceAttr-Function: The 
   ReplaceAttr-Function sees the  root level addded eventID only untill a call 
   to .WithGroup, then the  eventId is no longer available within the 
   ReplaceAttr-Function


Any help?
Johann Höchtl schrieb am Donnerstag, 5. Oktober 2023 um 17:59:30 UTC+2:

> I created a custom slog Handler which adds an attribute eventId which is a 
> GUID
>
> A NewLogger function returns that logger wrapped into a group: Every 
> further key-value provided should go into that group.
>
> Unfortunately the eventId also gets promoted into that group although it 
> should be at the parent level.
>
> See here the Goplay https://play.golang.com/p/a10f09jMwL3
>
> Thank you for your help, Johann
>

-- 
You received this message because you 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/16dc9f51-6c8c-4fd9-9942-5e365399e26dn%40googlegroups.com.

[go-nuts] Go called by C: is the goroutine locked to a thread?

[Domenico Andreoli]

Hi,

  I'm writing a Go library to embed/extend CPython (Pygolo 
). CPython uses thread local storage and 
therefore I need to care about pinning goroutines to OS threads accordingly.

It's pretty much clear that when the Python interpreter is embedded it can 
be accessed only from one goroutine and that such goroutine must be locked 
to an OS thread all the time.

It's possible to create Python thread states and allow multiple threads to 
access the interpreter, therefore other goroutines - if locked to an OS 
thread - can access the interpreter (modulo Python GIL).

It's also clear that if the Python interpreter calls back a Go function it 
will happen from one of the locked threads of above and therefore nothing 
special needs to be done on the Go side.

Or not? If a thread is locked no other goroutines are allowed to run as per 
documentation of LockOSThread, so on which goroutine the Go callback will 
actually run?

Different story is when Go is used to extend the Python interpreter, when 
Go calls are happening in a thread not owned by the Go runtime. Here I have 
some doubts, I think I read something about cgo locking threads of Go 
callbacks but I can't find it any more. 

I guess that at the first Go call cgo initializes the Go runtime and 
suddenly a few threads and goroutines spawn to life but how the goroutine 
scheduling works when C is in control of the calling threads?

Is it possible that multiple goroutines get scheduled on the caller C 
thread?

Are Go callbacks goroutines reused? If not and I leave a Go callback 
goroutine locked to a thread, is the calling C thread going to be killed, 
as per documentation of LockOSThread?

Thanks in advance for any clarification.

Regards,
Dom

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


-- 
You received this message because you 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/bf3ca959-f772-4940-a48b-f21993394e2dn%40googlegroups.com.