[go-nuts] Who are the Go maintainers?

[Matt Hickford]

https://go.dev/doc/contribute says "Only Go maintainers (also referred
to as “approvers”) can cast a +2 vote."

Who are the Go maintainers? Is this the same set of people as
https://github.com/orgs/golang/people (seems to be mostly Googlers and
ex-Googlers)? Or a subset?

-- 
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/CAGJzqskf2336kOAAn2YpXGTWgPGiL8%2Bz7mDuKzu2UzUCGppXkQ%40mail.gmail.com.

[go-nuts] Which one is the latest optimization: ASM/Pure Go implementations?

[Holloway Kean Ho]

Hi all,

To clarify, which one is latest and right optimization development 
direction?


Example case:

(floor_asm.go <--> floor_amd64.s VS floor_noasm.go)

1) 
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_asm.go;bpv=0;bpt=0

2) 
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_amd64.s;bpv=0;bpt=0

3) 
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor.go;l=21;bpv=0;bpt=0


Context:

1) I'm currently adopt+modifying the standard library to facilitate TinyGo 
and translatable to Rust. => 1 peaceful standard library complementing the 
existing standard libraries.

2) The objective is support coverage (e.g. works on as many hardware as 
possible) over some performance sacrifice.


3) My heart tells me noasm.go is the latest because:

3.1) ultimately Go developer can achieve consistent results independnet of 
hardware; thus, does not restrict one to sell kidney for getting MYR10k+ 
hardware. TinyGo can operate with this at no issue (tested as well).

3.2) Heartbleed bug case proven that relying hardware can cause 
inconsistency results despite proper software.


4) My head tells me asm.go is the latest because:

4.1) why self-impose limits when hardware can perform better.


Thanks in advanced.


Regards,

Holloway

-- 
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/5a5eb0d8-6071-4698-93ad-c352f8870622n%40googlegroups.com.

Re: [go-nuts] Go code owners: what are primary and secondary owners?

[Ian Lance Taylor]

On Wed, Nov 9, 2022 at 2:15 PM M Hickford  wrote:
>
> Presumably all primaries and secondaries are Go maintainers?

Probably?  I haven't checked, though.

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/CAOyqgcWmTuX1Fs8MHyW4%3Dc3C%2B3oA0gOHVfCnYji58EHsqe9-iw%40mail.gmail.com.

Re: [go-nuts] Go code owners: what are primary and secondary owners?

[Ian Lance Taylor]

On Wed, Nov 9, 2022 at 2:11 PM M Hickford  wrote:
>
> On Wed, 9 Nov 2022 at 19:39, Ian Lance Taylor  wrote:
> >
> > On Wed, Nov 9, 2022 at 11:28 AM M Hickford  wrote:
> > >
> > > https://dev.golang.org/owners list primary and secondary owners, but 
> > > doesn't explain what this means. What do primaries and secondaries do?
> >
> > It's pretty informal.  For most packages primary owners are people who
> > take responsibility for the future direction of the package, including
> > any major changes.  Secondary owners are people who are familiar with
> > the package and are willing to review bug fixes.  But there are no
> > strict rules or even guidelines.
> >
> > It's mostly used to add reviewers to incoming Gerritt changes.
> >
> > Ian
>
> Thanks. Does it affect who can approve a change? Or can any Go
> maintainer approve any change in any path?
> https://go.dev/doc/contribute#votes

At present any maintainer (anybody with +2 rights) can approve any
change in any path.

In https://go.dev/issue/53383 we raised the possibility of some people
only having +2 rights over certain files (those that are specific to a
GOOS and/or GOARCH) but that has not been implemented.

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

Re: [go-nuts] Go code owners: what are primary and secondary owners?

[M Hickford]

Presumably all primaries and secondaries are Go maintainers?

-- 
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/CAGJzqskAH466S3hWWPSpvA6ju1gV6E%3DUzFnXhP8rtpGRsXC%2Byw%40mail.gmail.com.

Re: [go-nuts] Go code owners: what are primary and secondary owners?

[M Hickford]

On Wed, 9 Nov 2022 at 19:39, Ian Lance Taylor  wrote:
>
> On Wed, Nov 9, 2022 at 11:28 AM M Hickford  wrote:
> >
> > https://dev.golang.org/owners list primary and secondary owners, but 
> > doesn't explain what this means. What do primaries and secondaries do?
>
> It's pretty informal.  For most packages primary owners are people who
> take responsibility for the future direction of the package, including
> any major changes.  Secondary owners are people who are familiar with
> the package and are willing to review bug fixes.  But there are no
> strict rules or even guidelines.
>
> It's mostly used to add reviewers to incoming Gerritt changes.
>
> Ian

Thanks. Does it affect who can approve a change? Or can any Go
maintainer approve any change in any path?
https://go.dev/doc/contribute#votes

-- 
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/CAGJzqskBx3xP%3DsWJw4brMmjQJiVRG8%3Dbads7yOmjypt%3DqV6sOg%40mail.gmail.com.

Re: [go-nuts] Idea for a language addition for error handling: inject/eject

[Gorka Guardiola]

On Wed, Nov 9, 2022, 20:47 Ian Lance Taylor  wrote:

> On Wed, Nov 9, 2022 at 10:40 AM Gorka Guardiola  wrote:
>
> Seems related to https://go.dev/issue/54361, although due to inject it
> is not the same.
>

I hadn't seen that proposal.

>
It is similar in the sense that it is a more powerful return, but this is
much more limited and restricted (1 call level explicitly annotated in the
function call vs. returning N levels to a label/function name). In that
sense it is a subset of what can be done with that change but more
structured. I feel it could be easier to reason about.

The changes to the language, runtime, compiler... are also quite more
limited. The bad part is the need for two new reserved words.

G.

-- 
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/CACm3i_hyfB2SSXGZ5NjNNW%2BBpzB3xgiqkTOZMVjRowi2uV6u0A%40mail.gmail.com.

Re: [go-nuts] Issues with parsing `time.String()` in Go 1.19

[Erez Rokah]

Thanks for the response, I somehow thought that was added in Go 1.19. Sorry 
for the confusion and thanks again for the help


On Wednesday, 9 November 2022 at 21:54:18 UTC+2 Ian Lance Taylor wrote:

> On Wed, Nov 9, 2022 at 9:00 AM Erez Rokah  wrote:
> >
> > The string format used is `"2006-01-02 15:04:05.9 -0700 MST"` 
> which is `time.String()` internal format
>
> Thanks.
>
> You originally asked whether this is a bug or not. I don't think this
> is a bug. It's true that it's not easy to use time.Parse to parse a
> string generated by time.String. That is perhaps unfortunate, but
> it's a consequence of how the various functions work.
>
> As I noted earlier the -m= has been around for a long time. I don't
> know what changed in Go 1.19. When I run your test with Go 1.18, it
> fails for me.
>
> Ian
>
> > On Wednesday, 9 November 2022 at 18:48:09 UTC+2 Ian Lance Taylor wrote:
> >>
> >> On Wed, Nov 9, 2022 at 8:33 AM Erez Rokah  wrote:
> >> >
> >> > I'm not sure if this is a bug or not. The following test will print 
> both error messages:
> >> >
> >> > ```
> >> > func TestTimeStringParse(t *testing.T) {
> >> > for i := 0; i < 10; i++ {
> >> > timeString := time.Now().Add(time.Duration(rand.Int63())).String()
> >> > _, err := time.Parse(defaultStringFormat, timeString)
> >> > if err == nil {
> >> > t.Errorf("time.Parse(%q) should return error", timeString)
> >> > } else {
> >> > t.Errorf("time.Parse(%q) should not return error", timeString)
> >> > }
> >> > }
> >> > }
> >> > ```
> >> >
> >> > The failure stems from Go 1.19 adding the extra text `m=+` for 
> the monotonic clock.
> >> > This doesn't happen for every `time.String()` invocation, which is a 
> bit confusing.
> >> > I understand one shouldn't try to parse `time.String()`, especially 
> with the private format, however this does looks like something that worked 
> before Go 1.19.
> >> >
> >> > Would be glad to know what others think.
> >>
> >>
> >> What is defaultStringFormat?
> >>
> >> Adding m= is not new in Go 1.19.
> >>
> >> 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/bc51019f-9794-41eb-8a86-96234bc1ea11n%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/14508b2e-c2b1-4cdc-92d9-90da0c469531n%40googlegroups.com.

Re: [go-nuts] Issues with parsing `time.String()` in Go 1.19

[Ian Lance Taylor]

On Wed, Nov 9, 2022 at 9:00 AM Erez Rokah  wrote:
>
> The string format used is `"2006-01-02 15:04:05.9 -0700 MST"` which 
> is `time.String()` internal format

Thanks.

You originally asked whether this is a bug or not.  I don't think this
is a bug.  It's true that it's not easy to use time.Parse to parse a
string generated by time.String.  That is perhaps unfortunate, but
it's a consequence of how the various functions work.

As I noted earlier the -m= has been around for a long time.  I don't
know what changed in Go 1.19.  When I run your test with Go 1.18, it
fails for me.

Ian

> On Wednesday, 9 November 2022 at 18:48:09 UTC+2 Ian Lance Taylor wrote:
>>
>> On Wed, Nov 9, 2022 at 8:33 AM Erez Rokah  wrote:
>> >
>> > I'm not sure if this is a bug or not. The following test will print both 
>> > error messages:
>> >
>> > ```
>> > func TestTimeStringParse(t *testing.T) {
>> > for i := 0; i < 10; i++ {
>> > timeString := time.Now().Add(time.Duration(rand.Int63())).String()
>> > _, err := time.Parse(defaultStringFormat, timeString)
>> > if err == nil {
>> > t.Errorf("time.Parse(%q) should return error", timeString)
>> > } else {
>> > t.Errorf("time.Parse(%q) should not return error", timeString)
>> > }
>> > }
>> > }
>> > ```
>> >
>> > The failure stems from Go 1.19 adding the extra text `m=+` for the 
>> > monotonic clock.
>> > This doesn't happen for every `time.String()` invocation, which is a bit 
>> > confusing.
>> > I understand one shouldn't try to parse `time.String()`, especially with 
>> > the private format, however this does looks like something that worked 
>> > before Go 1.19.
>> >
>> > Would be glad to know what others think.
>>
>>
>> What is defaultStringFormat?
>>
>> Adding m= is not new in Go 1.19.
>>
>> 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/bc51019f-9794-41eb-8a86-96234bc1ea11n%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/CAOyqgcW3XAGsc%2B_MRLi3bPNbYCS4okciZr5q%2BYCeMWKWemeYDw%40mail.gmail.com.

Re: [go-nuts] Idea for a language addition for error handling: inject/eject

[Ian Lance Taylor]

On Wed, Nov 9, 2022 at 10:40 AM Gorka Guardiola  wrote:
>
> I have the following idea [1] for decluttering error handling in go. It looks 
> similar to others already presented, but is is different in important ways:
>
> 1) It does not interfere with or use panic
> 2) Is general enough that one can wrap errors with other errors or check 
> different kinds of errors.
> 3) Hopefully it does not disturb the flow of code to make it difficult to 
> read (it is similar to return,
> not to exceptions, it is not thrown and caught).
>
> Maybe something like this has been proposed before, but I am not aware of it.
>
> This is an informal writeup, hopefully it is understandable enough, but if 
> not, feel free to ask any questions.
>
> Thoughts?

Seems related to https://go.dev/issue/54361, although due to inject it
is not the same.

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/CAOyqgcVjb4D4cjy8-VUE2sKMc-Gr_n2%2BtDPENXN42UbGjcyi5g%40mail.gmail.com.

Re: [go-nuts] Go code owners: what are primary and secondary owners?

[Ian Lance Taylor]

On Wed, Nov 9, 2022 at 11:28 AM M Hickford  wrote:
>
> https://dev.golang.org/owners list primary and secondary owners, but doesn't 
> explain what this means. What do primaries and secondaries do?

It's pretty informal.  For most packages primary owners are people who
take responsibility for the future direction of the package, including
any major changes.  Secondary owners are people who are familiar with
the package and are willing to review bug fixes.  But there are no
strict rules or even guidelines.

It's mostly used to add reviewers to incoming Gerritt changes.

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

[go-nuts] Go code owners: what are primary and secondary owners?

[M Hickford]

https://dev.golang.org/owners list primary and secondary owners, but
doesn't explain what this means. What do primaries and secondaries do?

-- 
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/CAGJzqsmW3kkE27FO%3DUY6Qe_OUZOhpv4t5-_XOSTCL6MP45wvGQ%40mail.gmail.com.

[go-nuts] Go tour translation workflow

[Viktor Pakhuchyi]

Hi there!

I'm writing on behalf of Go community from Ukraine.

We want to add Ukrainian translation to the Go tour.
I've found that the already existing documentation doesn't cover all my
questions.
That's why I've decided to ask you here for some tips.

What is clear:
1. Repository can be cloned by using this link -
https://go.googlesource.com/website
2. This document tells what files to change and that an App Engine
deployment is needed -
https://cs.opensource.google/go/x/website/+/master:tour/TRANSLATE

So, after all, what is needed is a link to the deployed Go tour with a new
translation, right?

However, what is the right way to keep it up to date with the original
repository?
What approach do most people use?

Is there any described journey of adding a new translation?
I would be very grateful for that.

Thanks in advance!
Viktor

-- 
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/CALQXhcqvsEK0iwomS-5VesOb-nyJTnD5dG_-beB_YV%2BfaRVVsw%40mail.gmail.com.

[go-nuts] Idea for a language addition for error handling: inject/eject

[Gorka Guardiola]

I have the following idea [1] for decluttering error handling in go. It
looks similar to others already presented, but is is different in important
ways:

1) It does not interfere with or use panic
2) Is general enough that one can wrap errors with other errors or check
different kinds of errors.
3) Hopefully it does not disturb the flow of code to make it difficult to
read (it is similar to return,
not to exceptions, it is not thrown and caught).

Maybe something like this has been proposed before, but I am not aware of
it.

This is an informal writeup, hopefully it is understandable enough, but if
not, feel free to ask any questions.

Thoughts?


[1]
https://docs.google.com/document/d/1VUDGX_y8MPnNLBActbefFjZlp6EaaGcoflZy6OS8p9c/edit?usp=sharing

-- 
- curiosity sKilled the cat

-- 
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/CACm3i_i86RozyGGAo1e8oyJw3jG4Mqv7UyziqxRr-oZ%2Bu-DqrQ%40mail.gmail.com.

[go-nuts] Creating c-archive that uses external symbols

[Aviram Hassan]

Hi,
I wish to create a c-archive that contains only specific symbols, importing
on runtime the needed symbols.
I managed to create a `.o` file that I believe contains only my functions
using
`go tool compile -shared -dynlink main.go`
but then when I do
`go tool link -buildmode=c-archive -extld clang -extldflags='-undefined
dynamic_lookup' -installsuffix /tmp -o main.a main.o`
It tries to find all the runtime stuff I want it to link at runtime.
Thanks in advance,
Aviram

-- 
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/CALOd%2BB1m6YrB%3D72j9VGVcw77yAQRhoxQSZ_8UPjqhH07tAguGQ%40mail.gmail.com.

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

[Aviram Hassan]

Thank you.
I found that the best way (or only?) is to have an assembly function
reference a Go function, then the compiler creates a wrapper that can be
used.

On Tue, Nov 8, 2022 at 7:14 PM Ian Lance Taylor  wrote:

> 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/CALOd%2BB2HXmMc%2BExPPGtBqzeHDPoBQ8mE1AUPZs6SaaySvdgN9A%40mail.gmail.com.

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

['Mark' via golang-nuts]

Thank you! I've now switched to using any as you suggested & also use 
strings.Builder.

On Wednesday, November 9, 2022 at 4:33:48 PM UTC dun...@harris3.org wrote:

> > 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)
>
> You need to convert to "any": https://go.dev/play/p/1pMhs22S-8P
>
> P.S. It would be better to use https://pkg.go.dev/strings#Builder for 
> building a string
>
> On Tuesday, 8 November 2022 at 13:09:51 UTC Mark wrote:
>
>> 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 

Re: [go-nuts] Issues with parsing `time.String()` in Go 1.19

[Erez Rokah]

The string format used is `"2006-01-02 15:04:05.9 -0700 MST"` which 
is `time.String()` internal format

On Wednesday, 9 November 2022 at 18:48:09 UTC+2 Ian Lance Taylor wrote:

> On Wed, Nov 9, 2022 at 8:33 AM Erez Rokah  wrote:
> >
> > I'm not sure if this is a bug or not. The following test will print both 
> error messages:
> >
> > ```
> > func TestTimeStringParse(t *testing.T) {
> > for i := 0; i < 10; i++ {
> > timeString := time.Now().Add(time.Duration(rand.Int63())).String()
> > _, err := time.Parse(defaultStringFormat, timeString)
> > if err == nil {
> > t.Errorf("time.Parse(%q) should return error", timeString)
> > } else {
> > t.Errorf("time.Parse(%q) should not return error", timeString)
> > }
> > }
> > }
> > ```
> >
> > The failure stems from Go 1.19 adding the extra text `m=+` for the 
> monotonic clock.
> > This doesn't happen for every `time.String()` invocation, which is a bit 
> confusing.
> > I understand one shouldn't try to parse `time.String()`, especially with 
> the private format, however this does looks like something that worked 
> before Go 1.19.
> >
> > Would be glad to know what others think.
>
>
> What is defaultStringFormat?
>
> Adding m= is not new in Go 1.19.
>
> 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/bc51019f-9794-41eb-8a86-96234bc1ea11n%40googlegroups.com.

Re: [go-nuts] Issues with parsing `time.String()` in Go 1.19

[Ian Lance Taylor]

On Wed, Nov 9, 2022 at 8:33 AM Erez Rokah  wrote:
>
> I'm not sure if this is a bug or not. The following test will print both 
> error messages:
>
> ```
> func TestTimeStringParse(t *testing.T) {
>   for i := 0; i < 10; i++ {
> timeString := time.Now().Add(time.Duration(rand.Int63())).String()
> _, err := time.Parse(defaultStringFormat, timeString)
>if err == nil {
>  t.Errorf("time.Parse(%q) should return error", timeString)
> } else {
>   t.Errorf("time.Parse(%q) should not return error", timeString)
> }
>   }
> }
> ```
>
> The failure stems from Go 1.19 adding the extra text `m=+` for the 
> monotonic clock.
> This doesn't happen for every `time.String()` invocation, which is a bit 
> confusing.
> I understand one shouldn't try to parse `time.String()`, especially with the 
> private format, however this does looks like something that worked before Go 
> 1.19.
>
> Would be glad to know what others think.


What is defaultStringFormat?

Adding m= is not new in Go 1.19.

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/CAOyqgcWip6K-WYbwoYKwisEDJ0m9_W92V-UFsRiuQweA9K_sQg%40mail.gmail.com.

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

[Duncan Harris]

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

You need to convert to "any": https://go.dev/play/p/1pMhs22S-8P

P.S. It would be better to use https://pkg.go.dev/strings#Builder for 
building a string

On Tuesday, 8 November 2022 at 13:09:51 UTC Mark wrote:

> 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/3169ebd2-d854-4e7d-addd-9b11918feb45n%40googlegroups.com.

[go-nuts] Issues with parsing `time.String()` in Go 1.19

[Erez Rokah]

Hello!

I'm not sure if this is a bug or not. The following test will print both 
error messages:

```
func TestTimeStringParse(t *testing.T) {
  for i := 0; i < 10; i++ {
timeString := time.Now().Add(time.Duration(rand.Int63())).String()
_, err := time.Parse(defaultStringFormat, timeString)
   if err == nil {
 t.Errorf("time.Parse(%q) should return error", timeString)
} else {
  t.Errorf("time.Parse(%q) should not return error", timeString)
}
  }
}
```

The failure stems from Go 1.19 adding the extra text `m=+` for the 
monotonic clock.
This doesn't happen for every `time.String()` invocation, which is a bit 
confusing.
I understand one shouldn't try to parse `time.String()`, especially with 
the private format, however this does looks like something that worked 
before Go 1.19.

Would be glad to know what others think.
Cheers,
Erez

-- 
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/2d1d3de0-4a29-478e-a7f3-517e904097f0n%40googlegroups.com.

Re: [go-nuts] Re: Go implementation of CLP

[Bharghava Varun Ayada]

I'm exploring CLP for a logging platform and I think either a cgo or native 
go library might be something that would help us.

On Tuesday, 4 October 2022 at 22:03:34 UTC+5:30 david...@gmail.com wrote:

> It would be awesome to help SeaweedFS, so I'm eager to hear more about 
> your ideas to try and understand anything we can do.
>
> Sorry if some of my questions are naive. At a high level I'm trying to 
> better understand two topics:
> 1. the use cases (or features) we/CLP can help with
> 2. the technical aspects/limitations that make a pure-go implementation 
> necessary/beneficial
>
> I saw that SeaweedFS currently can automatically compresses certain file 
> types with Gzip (very cool btw).
> I can imagine that augmenting this feature with CLP for log file types 
> could be beneficial.
> Are these the log files you're referring to? Does SeaweedFS itself also 
> produce log files that can benefit from CLP? Perhaps CLP could help with 
> both cases?
>
> As I imagine packaging the current form of CLP with SeaweedFS is awkward, 
> is packaging a main reason for a pure-go implementation?
> Would a library with programmatic API be favourable for integration rather 
> than calling out to another tool/executable (as required in CLP's current 
> form)?
> Would a go package using cgo (to reuse some existing cpp code) be 
> desirable or is there a requirement for strictly go code?
>
> -david
>
> On Sunday, 2 October 2022 at 22:36:38 UTC-4 ChrisLu wrote:
>
>> Thanks! CLP is great! 
>>
>> I am working on a distributed file system, SeaweedFS, 
>> https://github.com/seaweedfs/seaweedfs
>> I am interested in a pure-go implementation to store the log files more 
>> efficiently.
>>
>> Chris
>>
>> On Sun, Oct 2, 2022 at 6:45 PM david lion  wrote:
>>
>>> Hi Chris,
>>>
>>> I'm one of the CLP developers. We'd be interested in hearing your use 
>>> case and any features you'd like implemented in CLP.
>>> As for a Go implementation, are you asking about bindings to directly 
>>> call CLP functionality from a Go program or are you interested in a 
>>> complete re-write in Go?
>>>
>>> -david
>>>
>>> On Friday, 30 September 2022 at 03:58:44 UTC-4 ChrisLu wrote:
>>>
 Seems there are no Go implementation for Compressed Log Processor (CLP) 
 yet? 

 CLP is a tool capable of losslessly compressing text logs and searching 
 the compressed logs without decompression.

 https://github.com/y-scope/clp

 Chris

>>> -- 
>>> 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/XeDIZfTMlX8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/0c57905a-1096-4688-b268-93742c48316fn%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/63f2d52c-fc2b-44ef-a27e-e5d695626f74n%40googlegroups.com.