Re: [go-nuts] big int panic on text conversion

['Dan Kortschak' via golang-nuts]

On Wed, 2024-02-14 at 02:07 -0800, Poonai wrote:
> Thanks all,
> 
> figured out the issue:
> 
> func main() {
>     a := big.NewInt(1)
>     b := *a
>     c := *a
>     c.Sub(, big.NewInt(1))
>     fmt.Println(b.String())
>     fmt.Println(c.String())
>     fmt.Println(a.String())
> }
> 
> 
> reproducible code. don't know what causing it tho :(

Minimised: https://go.dev/play/p/oL17vkcjaEl

This is happening because the sum in a doesn't result in a
normalisation of b, https://go.dev/play/p/cIBDbRXFnAT (in this
situation where the abs field represents a zero, it should be zero
length).

Given that this can happen without a race or unsafe modifications it
might be worth filing a issue for.

-- 
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/6823242c8654f406db5dfc2bb04d1ca0efa51139.camel%40kortschak.io.

[go-nuts] Trying to understand aversion to main package

[Jerry Londergaard]

I see quite a few modules out there where they seem to be putting in as 
little into the main package as possible. Literally they will sometimes be 
a few lines:
```
import foobar
func main() {
os.Exit(foobar.Run())
}
```
Yet then go on to do all the things I would've thought are the domain of a 
main package, in the foobar package, like arg parsing, pulling in config 
items from env vars, setting up deps etc, and then running the actual thing.

Why not just put that code into the actual main package? Sure, maybe not 
all into the main *function* itself, but in the main package at least.

I understand that you don't want to be putting any real business logic into 
that main package, but I'm just talking about entry point type specific 
stuff. People might say they want to keep main 'light', but sometimes it 
feels like it's a competition to have the fewest lines as possible in the 
main package. 

kube-proxy[1] is an example of this. Maybe this starts to make more sense 
when the amount of code you would be putting into main become a lot, 
kube-proxy may qualify for this, but I see other cases where I don't 
understand the reasoning.

Certainly not all are like that[2], but in some circles that I travel it 
seems to be a common way of thinking.

Am I missing something ?

1. 
https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-proxy/proxy.go 

2. https://github.com/ethereum/go-ethereum/blob/master/cmd/geth/main.go

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e7b6de50-0351-4d2e-83a9-2207ba04b68an%40googlegroups.com.

Re: [go-nuts] big int panic on text conversion

[Poonai]

Thanks all,

figured out the issue:

func main() {
a := big.NewInt(1)
b := *a
c := *a
c.Sub(, big.NewInt(1))
fmt.Println(b.String())
fmt.Println(c.String())
fmt.Println(a.String())
}


reproducible code. don't know what causing it tho :(

On Wednesday, February 14, 2024 at 2:52:19 PM UTC+5:30 Brian Candler wrote:

> Have you tried running your entire code under the race detector?
> https://go.dev/blog/race-detector
>
> On Wednesday 14 February 2024 at 06:02:02 UTC Kurtis Rader wrote:
>
>> Maybe provide a minimal reproducible example (
>> https://stackoverflow.com/help/minimal-reproducible-example)?
>>
>> While it is theoretically possible there is a bug in the `big` package 
>> that could result in such panics it is much more likely the bug is in your 
>> code. So showing us how you are using the `big` package will help us help 
>> you.
>>
>> On Tue, Feb 13, 2024 at 9:36 PM Poonai  wrote:
>>
>>> big int panics during text conversion randomly 
>>>
>>> stack trace:
>>>
>>> panic: runtime error: index out of range [1] with length 1
>>>
>>> goroutine 2088184 [running]:
>>> math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
>>> /usr/local/go/src/math/big/natconv.go:340 +0x3d2
>>> math/big.(*Int).Text(...)
>>> /usr/local/go/src/math/big/intconv.go:25
>>> math/big.(*Int).String(...)
>>> /usr/local/go/src/math/big/intconv.go:40
>>>
>>> It shows up randomly, help me debug
>>>
>>> -- 
>>> 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/db0a5e73-0a1d-4dfb-9629-1d54cf492f95n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4e9b8a2b-ae01-4bb3-9a8d-8fa612da7a97n%40googlegroups.com.

Re: [go-nuts] big int panic on text conversion

['Brian Candler' via golang-nuts]

Have you tried running your entire code under the race detector?
https://go.dev/blog/race-detector

On Wednesday 14 February 2024 at 06:02:02 UTC Kurtis Rader wrote:

> Maybe provide a minimal reproducible example (
> https://stackoverflow.com/help/minimal-reproducible-example)?
>
> While it is theoretically possible there is a bug in the `big` package 
> that could result in such panics it is much more likely the bug is in your 
> code. So showing us how you are using the `big` package will help us help 
> you.
>
> On Tue, Feb 13, 2024 at 9:36 PM Poonai  wrote:
>
>> big int panics during text conversion randomly 
>>
>> stack trace:
>>
>> panic: runtime error: index out of range [1] with length 1
>>
>> goroutine 2088184 [running]:
>> math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
>> /usr/local/go/src/math/big/natconv.go:340 +0x3d2
>> math/big.(*Int).Text(...)
>> /usr/local/go/src/math/big/intconv.go:25
>> math/big.(*Int).String(...)
>> /usr/local/go/src/math/big/intconv.go:40
>>
>> It shows up randomly, help me debug
>>
>> -- 
>> 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/db0a5e73-0a1d-4dfb-9629-1d54cf492f95n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

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

Re: [go-nuts] Bad code contribution experience

[Ian Lance Taylor]

On Mon, Jan 29, 2024 at 7:29 PM mr@gmail.com  wrote:
>
> I want to vent my frustration. The experience of contributing has been 
> unpleasant for me. I have noticed that similar fixes are prioritized and 
> merged faster, while I spent time resolving the issue and reporting it, but 
> it did not receive an effective merge. Although it was during the freeze 
> period, I assumed it would be merged soon after the release. However, that 
> was not the case. In terms of submission time, my pull request was submitted 
> almost a month earlier than others', yet the newly submitted ones were merged 
> more quickly (https://go-review.googlesource.com/c/go/+/55). Perhaps I 
> should not have created a pull request during the freeze period.
>
> https://go-review.googlesource.com/c/go/+/543177

I'm sorry you had a bad experience.  As you know, your earlier change
was waiting for the release freeze.  Then it looks like people simply
didn't notice that the newer change more or less duplicated yours.  We
get so many changes that it's hard for anybody to keep track of them
all.  I understand your frustration.  If you have any suggestions for
how to avoid this kind of problem in the future, we would like to hear
them.

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/CAOyqgcX789ohvg2usXLJOigbKRGJ-6or9x7dkk6wcvFxgNFkLg%40mail.gmail.com.

Re: [go-nuts] big int panic on text conversion

[Kurtis Rader]

Maybe provide a minimal reproducible example (
https://stackoverflow.com/help/minimal-reproducible-example)?

While it is theoretically possible there is a bug in the `big` package that
could result in such panics it is much more likely the bug is in your code.
So showing us how you are using the `big` package will help us help you.

On Tue, Feb 13, 2024 at 9:36 PM Poonai  wrote:

> big int panics during text conversion randomly
>
> stack trace:
>
> panic: runtime error: index out of range [1] with length 1
>
> goroutine 2088184 [running]:
> math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
> /usr/local/go/src/math/big/natconv.go:340 +0x3d2
> math/big.(*Int).Text(...)
> /usr/local/go/src/math/big/intconv.go:25
> math/big.(*Int).String(...)
> /usr/local/go/src/math/big/intconv.go:40
>
> It shows up randomly, help me debug
>
> --
> 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/db0a5e73-0a1d-4dfb-9629-1d54cf492f95n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

Re: [go-nuts] big int panic on text conversion

['Dan Kortschak' via golang-nuts]

On Tue, 2024-02-13 at 21:35 -0800, Poonai wrote:
> big int panics during text conversion randomly 
> 
> stack trace:
> 
> panic: runtime error: index out of range [1] with length 1
> 
> goroutine 2088184 [running]:
> math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
>         /usr/local/go/src/math/big/natconv.go:340 +0x3d2
> math/big.(*Int).Text(...)
>         /usr/local/go/src/math/big/intconv.go:25
> math/big.(*Int).String(...)
>         /usr/local/go/src/math/big/intconv.go:40
> 
> It shows up randomly, help me debug

I think you have probably ended up with a zero big.Int with a non-zero
length abs field. This is likely either from unsafe manipulation or a
race.

The crash can be replicated thus https://go.dev/play/p/WV78xvsbn4m

-- 
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/887305154dab7b435f14d8e5e1278742aa62deb7.camel%40kortschak.io.

[go-nuts] Re: big int panic on text conversion

[Poonai]

I'm not able to reproduce as well

On Wednesday, February 14, 2024 at 11:05:52 AM UTC+5:30 Poonai wrote:

> big int panics during text conversion randomly 
>
> stack trace:
>
> panic: runtime error: index out of range [1] with length 1
>
> goroutine 2088184 [running]:
> math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
> /usr/local/go/src/math/big/natconv.go:340 +0x3d2
> math/big.(*Int).Text(...)
> /usr/local/go/src/math/big/intconv.go:25
> math/big.(*Int).String(...)
> /usr/local/go/src/math/big/intconv.go:40
>
> It shows up randomly, help me debug
>

-- 
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/f856e1f9-61f6-4192-9b1d-c94a28f35d6fn%40googlegroups.com.

[go-nuts] big int panic on text conversion

[Poonai]

big int panics during text conversion randomly 

stack trace:

panic: runtime error: index out of range [1] with length 1

goroutine 2088184 [running]:
math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
/usr/local/go/src/math/big/natconv.go:340 +0x3d2
math/big.(*Int).Text(...)
/usr/local/go/src/math/big/intconv.go:25
math/big.(*Int).String(...)
/usr/local/go/src/math/big/intconv.go:40

It shows up randomly, help me debug

-- 
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/db0a5e73-0a1d-4dfb-9629-1d54cf492f95n%40googlegroups.com.

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Péter Szarvas]

Wonderful news, thanks for the quick issue opening. I will follow this on 
github

Sean Liao a következőt írta (2024. február 8., csütörtök, 23:43:11 UTC+1):

> I've filed it as https://go.dev/issue/65624
>
> - sean
>
> On Thu, Feb 8, 2024 at 6:58 PM Kyle Shannon  wrote:
> >
> > On 2/8/24 11:30, Jason Phillips wrote:
> >
> > Can you create a small self-contained program that reproduces the issue? 
> The following program returns 404 locally, as I'd expect, but does get 
> killed in the Go playground: https://go.dev/play/p/FigBLK8KrAK
> >
> > Perhaps a simpler reproduction that's runnable on the playground:
> >
> > https://go.dev/play/p/gmQGJsyNCT6
> >
> > This returns 301 with a Location of /x/. Note the trailing slash in the 
> mux pattern, which was missing in your example.
> >
> >
> > Perhaps there's an issue with the Playground networking implementation 
> that's incompatible with the 1.22 changes?
> >
> > On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:
> >>
> >> I haven't played around with it yet, but have you tried to separately 
> register /something/ ?
> >>
> >> mux := http.NewServeMux()
> >> mux.HandleFunc("/something/", func...)
> >> mux.HandleFunc("/something/{id}/{$}", func...)
> >>
> >> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
> >>>
> >>> Hello,
> >>>
> >>> I noticed if you set up a route like /something/{id}/{$}, it results 
> in an infinite loop if I navigate to /someting/ (with the trailing slash). 
> I got a redirect to Location: /something/, and so on. Finally the page 
> breaks after multiple rounds.
> >>>
> >>> Example:
> >>> mux := http.NewServeMux()
> >>> mux.HandleFunc("/something/{id}/{$}", func...))
> >>>
> >>> Should I raise and issue or am I doing something wrong here?
> >>>
> >>> Thanks,
> >>> Peter
> >
> > --
> > 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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com
> .
> >
> >
> > --
> > Kyle
> >
> > --
> > 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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.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/fb18c143-20f6-4c66-b0c3-a41d83099a76n%40googlegroups.com.

Re: [go-nuts] Is there a way to cast interface to embedded type?

[Christopher C]

Thanks to both of you. I'll try out your suggestions.

On Friday, February 9, 2024 at 4:35:31 PM UTC-5 Mike Schinkel wrote:

> On Feb 9, 2024, at 3:37 PM, Christopher C  wrote:
>
> I have a base struct that implements an interface. There are multiple 
> other structs that embed this base struct.  I would like to pass the an 
> interface into a function that can cast it as the base struct and call some 
> functions tied to the base struct.
>  
> Something like this...
> https://go.dev/play/p/DUzXr31s8Pn
>
>
> You can't cast like in your example, but you can create an interface — 
> call is `Baser` using idiomatic interface naming to identify the `Base` 
> type which will have an empty `Base()` method — and then type assert to it 
> after which, if it succeeds you can type assert to `*Base`, like so:
>
> https://go.dev/play/p/-gcKGf4_AFg
>
> Hope this helps.
>
> -Mike
>
>

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

Re: [go-nuts] heap ballast

['Sean Liao' via golang-nuts]

The modern way to handle this is with GOMEMLIMIT
https://tip.golang.org/doc/gc-guide

- sean

On Mon, Feb 12, 2024 at 8:33 PM Mike Mitchell
 wrote:
>
> Purely for the sake of experiment (this is not a production environment 
> thing), I have tried to test out the Heap Ballast technique of reducing the 
> number of garbage collections with a small heap size, which I read about in a 
> blog post by Twitch, and I think I must have misinterpreted the use case of 
> such a technique. Can anyone help clarify for me? Thank you in advance
>
> My program consists of a webserver in the main func
>
>  http.ListenAndServe(":6000", http.DefaultServeMux)
>
> and I create a small ballast on my Digital Ocean 1 GB ram droplet (the twitch 
> blog post said they made a ballast of 10 <<30) but I did 10 << 20
>
>  ballast := make([]byte, 10<<20)
>
> I then sent a million requests to it
>
> ab -k -c 8 -n 100 "http://127.0.0.1:6000/;
>
> I also did the same without the heap ballast.
>
> The results (see attached images) surprised me because there was basically 
> the same number of garbage collections with and without the ballast. The only 
> difference the ballast seems to have made was that it increased HeapIdle 
> enormously.  How do people use Heap Ballast to reduce the number of GCs?
>
>  go version go1.21.1 linux/amd64
>
> I have read many people referring to this Heap Ballast technique as a way to 
> reduce the number of garbage collections with a small heap size. In fact, 
> this is what it says in the Twitch article
>
> At steady state, our application was triggering ~8–10 garbage collection (GC) 
> cycles a second (400–600 per minute).
>
> 30% of CPU cycles were being spent in function calls related to GC
>
> During traffic spikes the number of GC cycles would increase
>
> Our heap size on average was fairly small (<450Mib)
>
> At steady state, our application was triggering ~8–10 garbage collection (GC) 
> cycles a second (400–600 per minute).
>
> 30% of CPU cycles were being spent in function calls related to GC
>
> During traffic spikes the number of GC cycles would increase
>
> Our heap size on average was fairly small (<450Mib)
>
>
>
>
>
> --
> 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/7cee5b4e-24cc-4579-b5c9-62b93298c931n%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/CAGabyPpEHMKkOPC-5C_BiaUA2o4x%2BOq8wKz4QkbjqDNVUS2Avg%40mail.gmail.com.

Re: [go-nuts] Re: need a package to read/write shell history flat file database

[Marcello H]

This package (FZF) is also using the history file, perhaps there's 
something usable inside.
https://github.com/junegunn/fzf

Op zondag 11 februari 2024 om 06:41:11 UTC+1 schreef Kurtis Rader:

> Thanks, but that requires me to implement the code I would rather not have 
> to reinvent given that shells like Bash, Ksh, and Fish already have code to 
> do what I need. The problem is that those solutions are written in C and 
> C++ respectively rather than Go. While I consider myself an expert in C 
> (having started programming with it around 1985) I am only minimally 
> competent in C++. I'll translate the Fish C++ code into Go if I have to but 
> am hoping there is a published Go equivalent to save me that effort.
>
> P.S., This is to remove the dependency on a daemon process to update a 
> BoltDB database by the Fish shell. The BoltDB dependency (go.etcd.io/bbolt) 
> greatly increases the size and complexity of the Fish shell. The opaque 
> binary database managed by BoltDB is also annoying. It would be preferable 
> to use a flat file database using JSON or text protobufs for storing 
> command history.
>
> On Sat, Feb 10, 2024 at 9:15 PM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Sat, 2024-02-10 at 21:01 -0800, Kurtis Rader wrote:
>> > The only solution I can find that gets close to my requirements is
>> > https://github.com/ergochat/readline, but AFAICT it does not handle
>> > updates to the on-disk history file by concurrently executing
>> > processes.
>>
>> There is also https://pkg.go.dev/github.com/peterh/liner, which also
>> does not handle history persistence, but which makes it relatively easy
>> to add.
>>
>> -- 
>> 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/e37a98a811c8e1cccfef8feffafef5260e7e5e56.camel%40kortschak.io
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

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

[go-nuts] Re: gopls: How to suppress a warning?

[Ernest Micklei]

Applying the answer from Robert, you get
```
"gopls": {
"ui.diagnostic.analyses": {
"composites": false
}
},
```
On Friday 23 December 2022 at 09:21:39 UTC+1 Torsten Bronger wrote:

> Hallöchen!
>
> 'Robert Findley' via golang-nuts writes:
>
> > You can disable the "composites" analyzer: https://github.com/golang/
> > tools/blob/master/gopls/doc/analyzers.md#composites
> >
> > Update the "analyses" configuration to include "composites": false,
> > as described here: https://github.com/golang/tools/blob/master/gopls/
> > doc/settings.md#analyses-mapstringbool 
>
> Thank you, this worked!
>
> Regards,
> Torsten.
>
> -- 
> Torsten Bronger
>
>

-- 
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/330d5687-1332-4e51-b9d0-310aaf3244f9n%40googlegroups.com.

[go-nuts] Re: net/http: 1.22.0, Enhanced routing, httpmuxgo121

['qiulaidongfeng' via golang-nuts]

If you want to default GODEBUG=httpmuxgo121=0.
One way to do this is to set go1.22.0 on the go line of go.mod, or add a 
//go:debug httpmuxgo121=0 to the go file of the main package.

On Monday, February 12, 2024 at 3:09:38 PM UTC+8 qiulaidongfeng wrote:

> Starting with go1.21, GODEBUG is set by default according to the go line 
> of go.mod.
>
> On Monday, February 12, 2024 at 11:47:31 AM UTC+8 xab3r wrote:
>
>> Hello there
>>
>> I've just tried new routing patterns in Go 1.22.0, and I noticed that I 
>> have to set httpmuxgo121=0 explicitly in order to get it enabled. When the 
>> release notes say to "set httpmuxgo121=1 to restore the old behaviour". So, 
>> as I understand it, by default, it should work with new path patterns.
>>
>> This is the handler
>> ```
>> mux.HandleFunc("GET /hello", func(w http.ResponseWriter, r *http.Request) 
>> {
>>   fmt.Fprint(w, "Hello")
>> })
>> ```
>>
>> So this piece of code is not gonna work if I run it like this
>> `$ go run main.go`
>> The server responds with 404.
>>
>> But it's working as expected when I explicitly set httpmuxgo121 to 0
>> `$ GODEBUG=httpmuxgo121=0 go run main.go`
>>
>> Also, I compiled go from sources with extra logs and `use121` variable 
>> https://github.com/golang/go/blob/master/src/net/http/servemux121.go#L23
>> is set to 1 by default, when I don't specify it explicitly via the ENV 
>> variable.
>>
>> What's the correct behaviour? Any clues are welcome
>>
>> 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/9cf2393a-cbd6-4a47-8a55-6fb8fb958b1fn%40googlegroups.com.

[go-nuts] Re: net/http: 1.22.0, Enhanced routing, httpmuxgo121

['qiulaidongfeng' via golang-nuts]

Starting with go1.21, GODEBUG is set by default according to the go line of 
go.mod.

On Monday, February 12, 2024 at 11:47:31 AM UTC+8 xab3r wrote:

> Hello there
>
> I've just tried new routing patterns in Go 1.22.0, and I noticed that I 
> have to set httpmuxgo121=0 explicitly in order to get it enabled. When the 
> release notes say to "set httpmuxgo121=1 to restore the old behaviour". So, 
> as I understand it, by default, it should work with new path patterns.
>
> This is the handler
> ```
> mux.HandleFunc("GET /hello", func(w http.ResponseWriter, r *http.Request) {
>   fmt.Fprint(w, "Hello")
> })
> ```
>
> So this piece of code is not gonna work if I run it like this
> `$ go run main.go`
> The server responds with 404.
>
> But it's working as expected when I explicitly set httpmuxgo121 to 0
> `$ GODEBUG=httpmuxgo121=0 go run main.go`
>
> Also, I compiled go from sources with extra logs and `use121` variable 
> https://github.com/golang/go/blob/master/src/net/http/servemux121.go#L23
> is set to 1 by default, when I don't specify it explicitly via the ENV 
> variable.
>
> What's the correct behaviour? Any clues are welcome
>
> 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/99be14cf-93ee-4270-aaf8-36f846e995c4n%40googlegroups.com.

[go-nuts] net/http: 1.22.0, Enhanced routing, httpmuxgo121

[xab3r]

Hello there

I've just tried new routing patterns in Go 1.22.0, and I noticed that I 
have to set httpmuxgo121=0 explicitly in order to get it enabled. When the 
release notes say to "set httpmuxgo121=1 to restore the old behaviour". So, 
as I understand it, by default, it should work with new path patterns.

This is the handler
```
mux.HandleFunc("GET /hello", func(w http.ResponseWriter, r *http.Request) {
  fmt.Fprint(w, "Hello")
})
```

So this piece of code is not gonna work if I run it like this
`$ go run main.go`
The server responds with 404.

But it's working as expected when I explicitly set httpmuxgo121 to 0
`$ GODEBUG=httpmuxgo121=0 go run main.go`

Also, I compiled go from sources with extra logs and `use121` variable 
https://github.com/golang/go/blob/master/src/net/http/servemux121.go#L23
is set to 1 by default, when I don't specify it explicitly via the ENV 
variable.

What's the correct behaviour? Any clues are welcome

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/2f35e7de-68eb-4a70-85e7-540f8b080b2fn%40googlegroups.com.

Re: [go-nuts] Re: KeepAlive with net.Listen

[Robert Engels]

If you implemented it and it works - I guess I don’t understand your question. You must know how tcp/http works. On Feb 11, 2024, at 8:25 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:Yes I did implement. You can check it here.https://github.com/roychowdhuryrohit-dev/slugOn Sunday, February 11, 2024 at 5:00:02 PM UTC-8 Robert Engels wrote:If it is a web server that supports http clients you still have to implement the protocol correctly. At the lowest level that is what all web server implementations do - they read from the socket directly. On Feb 11, 2024, at 7:54 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:As stated earlier, objective is to create a web server without using net/http, instead directly reading from the socket connection.On Sunday, February 11, 2024 at 4:49:09 PM UTC-8 Robert Engels wrote:If you have http keep alive on - either side should block when reading - it is a full duplex connection. You will only get eof if the tcp connection is closed. If http keep alive is off, then the connection is closed after the server sends the response - the tcp protocol allows the client to read this data even though the connection is shut down. On Feb 11, 2024, at 5:36 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:Yes I got it but I want to know if reader.ReadString("\n") is supposed to throw io.EOF rather than blocking for next request in the connection.On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:There is no such thing as a pool of idle connections at the tcp level. As each side of the connection is bound to a specific port on both ends and can’t be unbound. You may be referring to http over tcp where the client and server do not close the connection after each request - they keep it open for the next request from that client. Http2 complicates this a bit as it has multiple connections over a single tcp connection. On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:I got your point. But reader.ReadString('\n') does not block like you said. After a request gets parsed, from the next iteration it keeps on emitting io.EOF until next request arrives.On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:You're thinking backwards. "Long polling" is something done at the *client* side: this is where you send a HTTP request, but the reply intentionally doesn't come back for a long time - generally until the server detects some event that needs reporting.At a web *server*, you simply read the request from the socket(*), process it, reply, and go straight back to reading the next request. Read will block until the next request comes in (or the connection is closed).  In other words, the goroutine handling that TCP connection just has a loop. There's no need to "wake" this goroutine from anywhere.(*) You need to read until the end of the request (request headers + body, if any). Again, RFC2616 tells you how the request is delimited - see section 5.On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:Thanks, that makes so much sense. So should I long-poll until next request line comes or keep-alive times out? Is there a better way to detect incoming requests and then maybe awake the goroutine using channels?On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:Handling keep-alives on the *server* side doesn't require any sort of connection pool. Just create one goroutine for each incoming TCP connection, and once you've handled one request, loop around, waiting for another request on the same connection.(That's assuming the client does request use of keep-alives of course; if they don't, you should close the connection. This depends on which HTTP version they requested and the Connection: header if present. Full details in RFC 2616)On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:Hello fellow gophers, I am currently building an experimental HTTP/1.1 framework based on TCP sockets as part of my course project. In project requirements, I have been asked to make a web server which can handle keep-alive properly without using the net/http library. The project link can be found below:https://github.com/roychowdhuryrohit-dev/slugI have recently found out that if I SetKeepAlive(true) and SetKeepAlivePeriod(time.Second * time.Duration(timeout)), it is not enough to hold the connection. Additionally, any subsequent requests are freezing.Then I found out that net/http's Transport manages a pool for idle connections. I want to go for a similar approach for my project. But I am not able to figure out how to detect income requests for my idle connections that I will be storing in the pool. Specifically, I want to know how listener.Accept() can give me an idle connection if it exists in the pool.



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe 

Re: [go-nuts] Re: KeepAlive with net.Listen

['Rohit Roy Chowdhury' via golang-nuts]

Yes I did implement. You can check it here.
https://github.com/roychowdhuryrohit-dev/slug

On Sunday, February 11, 2024 at 5:00:02 PM UTC-8 Robert Engels wrote:

> If it is a web server that supports http clients you still have to 
> implement the protocol correctly. At the lowest level that is what all web 
> server implementations do - they read from the socket directly. 
>
> On Feb 11, 2024, at 7:54 PM, 'Rohit Roy Chowdhury' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> As stated earlier, objective is to create a web server without using 
> net/http, instead directly reading from the socket connection.
>
>
>
> On Sunday, February 11, 2024 at 4:49:09 PM UTC-8 Robert Engels wrote:
>
>> 
>> If you have http keep alive on - either side should block when reading - 
>> it is a full duplex connection. You will only get eof if the tcp connection 
>> is closed. 
>>
>> If http keep alive is off, then the connection is closed after the server 
>> sends the response - the tcp protocol allows the client to read this data 
>> even though the connection is shut down. 
>>
>> On Feb 11, 2024, at 5:36 PM, 'Rohit Roy Chowdhury' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>> Yes I got it but I want to know if *reader.ReadString("\n")* is 
>> supposed to throw *io.EOF* rather than blocking for next request in the 
>> connection.
>>
>>
>>
>> On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:
>>
>>> There is no such thing as a pool of idle connections at the tcp level. 
>>> As each side of the connection is bound to a specific port on both ends and 
>>> can’t be unbound. 
>>>
>>> You may be referring to http over tcp where the client and server do not 
>>> close the connection after each request - they keep it open for the next 
>>> request from that client. Http2 complicates this a bit as it has multiple 
>>> connections over a single tcp connection. 
>>>
>>> On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
>>> I got your point. But *reader.ReadString('\n')* does not block like 
>>> you said. After a request gets parsed, from the next iteration it keeps on 
>>> emitting *io.EOF *until next request arrives.
>>>
>>>
>>>
>>> On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:
>>>
 You're thinking backwards. "Long polling" is something done at the 
 *client* side: this is where you send a HTTP request, but the reply 
 intentionally doesn't come back for a long time - generally until the 
 server detects some event that needs reporting.

 At a web *server*, you simply read the request from the socket(*), 
 process it, reply, and go straight back to reading the next request. Read 
 will block until the next request comes in (or the connection is closed).  
 In other words, the goroutine handling that TCP connection just has a 
 loop. 
 There's no need to "wake" this goroutine from anywhere.

 (*) You need to read until the end of the request (request headers + 
 body, if any). Again, RFC2616 tells you how the request is delimited - see 
 section 5.

 On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:

> Thanks, that makes so much sense. So should I long-poll until next 
> request line comes or keep-alive times out? Is there a better way to 
> detect 
> incoming requests and then maybe awake the goroutine using channels?
> On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:
>
>> Handling keep-alives on the *server* side doesn't require any sort of 
>> connection pool. Just create one goroutine for each incoming TCP 
>> connection, and once you've handled one request, loop around, waiting 
>> for 
>> another request on the same connection.
>>
>> (That's assuming the client does request use of keep-alives of 
>> course; if they don't, you should close the connection. This depends on 
>> which HTTP version they requested and the Connection: header if present. 
>> Full details in RFC 2616)
>>
>> On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury 
>> wrote:
>>
>>> Hello fellow gophers, I am currently building an experimental 
>>> HTTP/1.1 framework based on TCP sockets as part of my course project. 
>>> In 
>>> project requirements, I have been asked to make a web server which can 
>>> handle keep-alive properly without using the net/http library. The 
>>> project 
>>> link can be found below:
>>> https://github.com/roychowdhuryrohit-dev/slug
>>> I have recently found out that if I *SetKeepAlive(true)* and 
>>> *SetKeepAlivePeriod(time.Second 
>>> * time.Duration(timeout))*, it is not enough to hold the 
>>> connection. Additionally, any subsequent requests are freezing.
>>> [image: Screenshot 2024-02-09 at 9.39.08 PM.png]
>>>
>>> Then I found out 

Re: [go-nuts] Re: KeepAlive with net.Listen

[Robert Engels]

If it is a web server that supports http clients you still have to implement the protocol correctly. At the lowest level that is what all web server implementations do - they read from the socket directly. On Feb 11, 2024, at 7:54 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:As stated earlier, objective is to create a web server without using net/http, instead directly reading from the socket connection.On Sunday, February 11, 2024 at 4:49:09 PM UTC-8 Robert Engels wrote:If you have http keep alive on - either side should block when reading - it is a full duplex connection. You will only get eof if the tcp connection is closed. If http keep alive is off, then the connection is closed after the server sends the response - the tcp protocol allows the client to read this data even though the connection is shut down. On Feb 11, 2024, at 5:36 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:Yes I got it but I want to know if reader.ReadString("\n") is supposed to throw io.EOF rather than blocking for next request in the connection.On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:There is no such thing as a pool of idle connections at the tcp level. As each side of the connection is bound to a specific port on both ends and can’t be unbound. You may be referring to http over tcp where the client and server do not close the connection after each request - they keep it open for the next request from that client. Http2 complicates this a bit as it has multiple connections over a single tcp connection. On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:I got your point. But reader.ReadString('\n') does not block like you said. After a request gets parsed, from the next iteration it keeps on emitting io.EOF until next request arrives.On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:You're thinking backwards. "Long polling" is something done at the *client* side: this is where you send a HTTP request, but the reply intentionally doesn't come back for a long time - generally until the server detects some event that needs reporting.At a web *server*, you simply read the request from the socket(*), process it, reply, and go straight back to reading the next request. Read will block until the next request comes in (or the connection is closed).  In other words, the goroutine handling that TCP connection just has a loop. There's no need to "wake" this goroutine from anywhere.(*) You need to read until the end of the request (request headers + body, if any). Again, RFC2616 tells you how the request is delimited - see section 5.On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:Thanks, that makes so much sense. So should I long-poll until next request line comes or keep-alive times out? Is there a better way to detect incoming requests and then maybe awake the goroutine using channels?On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:Handling keep-alives on the *server* side doesn't require any sort of connection pool. Just create one goroutine for each incoming TCP connection, and once you've handled one request, loop around, waiting for another request on the same connection.(That's assuming the client does request use of keep-alives of course; if they don't, you should close the connection. This depends on which HTTP version they requested and the Connection: header if present. Full details in RFC 2616)On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:Hello fellow gophers, I am currently building an experimental HTTP/1.1 framework based on TCP sockets as part of my course project. In project requirements, I have been asked to make a web server which can handle keep-alive properly without using the net/http library. The project link can be found below:https://github.com/roychowdhuryrohit-dev/slugI have recently found out that if I SetKeepAlive(true) and SetKeepAlivePeriod(time.Second * time.Duration(timeout)), it is not enough to hold the connection. Additionally, any subsequent requests are freezing.Then I found out that net/http's Transport manages a pool for idle connections. I want to go for a similar approach for my project. But I am not able to figure out how to detect income requests for my idle connections that I will be storing in the pool. Specifically, I want to know how listener.Accept() can give me an idle connection if it exists in the pool.



-- 
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/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%40googlegroups.com.




-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this 

Re: [go-nuts] Re: KeepAlive with net.Listen

['Rohit Roy Chowdhury' via golang-nuts]

As stated earlier, objective is to create a web server without using 
net/http, instead directly reading from the socket connection.

On Sunday, February 11, 2024 at 4:49:09 PM UTC-8 Robert Engels wrote:

> 
> If you have http keep alive on - either side should block when reading - 
> it is a full duplex connection. You will only get eof if the tcp connection 
> is closed. 
>
> If http keep alive is off, then the connection is closed after the server 
> sends the response - the tcp protocol allows the client to read this data 
> even though the connection is shut down. 
>
> On Feb 11, 2024, at 5:36 PM, 'Rohit Roy Chowdhury' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> Yes I got it but I want to know if *reader.ReadString("\n")* is supposed 
> to throw *io.EOF* rather than blocking for next request in the connection.
>
>
>
> On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:
>
>> There is no such thing as a pool of idle connections at the tcp level. As 
>> each side of the connection is bound to a specific port on both ends and 
>> can’t be unbound. 
>>
>> You may be referring to http over tcp where the client and server do not 
>> close the connection after each request - they keep it open for the next 
>> request from that client. Http2 complicates this a bit as it has multiple 
>> connections over a single tcp connection. 
>>
>> On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>> I got your point. But *reader.ReadString('\n')* does not block like you 
>> said. After a request gets parsed, from the next iteration it keeps on 
>> emitting *io.EOF *until next request arrives.
>>
>>
>>
>> On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:
>>
>>> You're thinking backwards. "Long polling" is something done at the 
>>> *client* side: this is where you send a HTTP request, but the reply 
>>> intentionally doesn't come back for a long time - generally until the 
>>> server detects some event that needs reporting.
>>>
>>> At a web *server*, you simply read the request from the socket(*), 
>>> process it, reply, and go straight back to reading the next request. Read 
>>> will block until the next request comes in (or the connection is closed).  
>>> In other words, the goroutine handling that TCP connection just has a loop. 
>>> There's no need to "wake" this goroutine from anywhere.
>>>
>>> (*) You need to read until the end of the request (request headers + 
>>> body, if any). Again, RFC2616 tells you how the request is delimited - see 
>>> section 5.
>>>
>>> On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:
>>>
 Thanks, that makes so much sense. So should I long-poll until next 
 request line comes or keep-alive times out? Is there a better way to 
 detect 
 incoming requests and then maybe awake the goroutine using channels?
 On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:

> Handling keep-alives on the *server* side doesn't require any sort of 
> connection pool. Just create one goroutine for each incoming TCP 
> connection, and once you've handled one request, loop around, waiting for 
> another request on the same connection.
>
> (That's assuming the client does request use of keep-alives of course; 
> if they don't, you should close the connection. This depends on which 
> HTTP 
> version they requested and the Connection: header if present. Full 
> details 
> in RFC 2616)
>
> On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:
>
>> Hello fellow gophers, I am currently building an experimental 
>> HTTP/1.1 framework based on TCP sockets as part of my course project. In 
>> project requirements, I have been asked to make a web server which can 
>> handle keep-alive properly without using the net/http library. The 
>> project 
>> link can be found below:
>> https://github.com/roychowdhuryrohit-dev/slug
>> I have recently found out that if I *SetKeepAlive(true)* and 
>> *SetKeepAlivePeriod(time.Second 
>> * time.Duration(timeout))*, it is not enough to hold the connection. 
>> Additionally, any subsequent requests are freezing.
>> [image: Screenshot 2024-02-09 at 9.39.08 PM.png]
>>
>> Then I found out that net/http's Transport manages a pool for idle 
>> connections. I want to go for a similar approach for my project. But I 
>> am 
>> not able to figure out how to detect income requests for my idle 
>> connections that I will be storing in the pool. Specifically, I want to 
>> know how listener.Accept() can give me an idle connection if it exists 
>> in 
>> the pool.
>>
> -- 
>> 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 

Re: [go-nuts] Re: KeepAlive with net.Listen

[Robert Engels]

If you have http keep alive on - either side should block when reading - it is a full duplex connection. You will only get eof if the tcp connection is closed. If http keep alive is off, then the connection is closed after the server sends the response - the tcp protocol allows the client to read this data even though the connection is shut down. On Feb 11, 2024, at 5:36 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:Yes I got it but I want to know if reader.ReadString("\n") is supposed to throw io.EOF rather than blocking for next request in the connection.On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:There is no such thing as a pool of idle connections at the tcp level. As each side of the connection is bound to a specific port on both ends and can’t be unbound. You may be referring to http over tcp where the client and server do not close the connection after each request - they keep it open for the next request from that client. Http2 complicates this a bit as it has multiple connections over a single tcp connection. On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:I got your point. But reader.ReadString('\n') does not block like you said. After a request gets parsed, from the next iteration it keeps on emitting io.EOF until next request arrives.On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:You're thinking backwards. "Long polling" is something done at the *client* side: this is where you send a HTTP request, but the reply intentionally doesn't come back for a long time - generally until the server detects some event that needs reporting.At a web *server*, you simply read the request from the socket(*), process it, reply, and go straight back to reading the next request. Read will block until the next request comes in (or the connection is closed).  In other words, the goroutine handling that TCP connection just has a loop. There's no need to "wake" this goroutine from anywhere.(*) You need to read until the end of the request (request headers + body, if any). Again, RFC2616 tells you how the request is delimited - see section 5.On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:Thanks, that makes so much sense. So should I long-poll until next request line comes or keep-alive times out? Is there a better way to detect incoming requests and then maybe awake the goroutine using channels?On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:Handling keep-alives on the *server* side doesn't require any sort of connection pool. Just create one goroutine for each incoming TCP connection, and once you've handled one request, loop around, waiting for another request on the same connection.(That's assuming the client does request use of keep-alives of course; if they don't, you should close the connection. This depends on which HTTP version they requested and the Connection: header if present. Full details in RFC 2616)On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:Hello fellow gophers, I am currently building an experimental HTTP/1.1 framework based on TCP sockets as part of my course project. In project requirements, I have been asked to make a web server which can handle keep-alive properly without using the net/http library. The project link can be found below:https://github.com/roychowdhuryrohit-dev/slugI have recently found out that if I SetKeepAlive(true) and SetKeepAlivePeriod(time.Second * time.Duration(timeout)), it is not enough to hold the connection. Additionally, any subsequent requests are freezing.Then I found out that net/http's Transport manages a pool for idle connections. I want to go for a similar approach for my project. But I am not able to figure out how to detect income requests for my idle connections that I will be storing in the pool. Specifically, I want to know how listener.Accept() can give me an idle connection if it exists in the pool.



-- 
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/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%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/8014b001-ef32-4937-b31e-1ce6b24baf48n%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 

Re: [go-nuts] Re: KeepAlive with net.Listen

['Rohit Roy Chowdhury' via golang-nuts]

Yes I got it but I want to know if *reader.ReadString("\n")* is supposed to 
throw *io.EOF* rather than blocking for next request in the connection.

On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:

> There is no such thing as a pool of idle connections at the tcp level. As 
> each side of the connection is bound to a specific port on both ends and 
> can’t be unbound. 
>
> You may be referring to http over tcp where the client and server do not 
> close the connection after each request - they keep it open for the next 
> request from that client. Http2 complicates this a bit as it has multiple 
> connections over a single tcp connection. 
>
> On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> I got your point. But *reader.ReadString('\n')* does not block like you 
> said. After a request gets parsed, from the next iteration it keeps on 
> emitting *io.EOF *until next request arrives.
>
>
>
> On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:
>
>> You're thinking backwards. "Long polling" is something done at the 
>> *client* side: this is where you send a HTTP request, but the reply 
>> intentionally doesn't come back for a long time - generally until the 
>> server detects some event that needs reporting.
>>
>> At a web *server*, you simply read the request from the socket(*), 
>> process it, reply, and go straight back to reading the next request. Read 
>> will block until the next request comes in (or the connection is closed).  
>> In other words, the goroutine handling that TCP connection just has a loop. 
>> There's no need to "wake" this goroutine from anywhere.
>>
>> (*) You need to read until the end of the request (request headers + 
>> body, if any). Again, RFC2616 tells you how the request is delimited - see 
>> section 5.
>>
>> On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:
>>
>>> Thanks, that makes so much sense. So should I long-poll until next 
>>> request line comes or keep-alive times out? Is there a better way to detect 
>>> incoming requests and then maybe awake the goroutine using channels?
>>> On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:
>>>
 Handling keep-alives on the *server* side doesn't require any sort of 
 connection pool. Just create one goroutine for each incoming TCP 
 connection, and once you've handled one request, loop around, waiting for 
 another request on the same connection.

 (That's assuming the client does request use of keep-alives of course; 
 if they don't, you should close the connection. This depends on which HTTP 
 version they requested and the Connection: header if present. Full details 
 in RFC 2616)

 On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:

> Hello fellow gophers, I am currently building an experimental HTTP/1.1 
> framework based on TCP sockets as part of my course project. In project 
> requirements, I have been asked to make a web server which can handle 
> keep-alive properly without using the net/http library. The project link 
> can be found below:
> https://github.com/roychowdhuryrohit-dev/slug
> I have recently found out that if I *SetKeepAlive(true)* and 
> *SetKeepAlivePeriod(time.Second 
> * time.Duration(timeout))*, it is not enough to hold the connection. 
> Additionally, any subsequent requests are freezing.
> [image: Screenshot 2024-02-09 at 9.39.08 PM.png]
>
> Then I found out that net/http's Transport manages a pool for idle 
> connections. I want to go for a similar approach for my project. But I am 
> not able to figure out how to detect income requests for my idle 
> connections that I will be storing in the pool. Specifically, I want to 
> know how listener.Accept() can give me an idle connection if it exists in 
> the pool.
>
 -- 
> 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/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%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/8014b001-ef32-4937-b31e-1ce6b24baf48n%40googlegroups.com.

Re: [go-nuts] Re: KeepAlive with net.Listen

[Robert Engels]

There is no such thing as a pool of idle connections at the tcp level. As each side of the connection is bound to a specific port on both ends and can’t be unbound. You may be referring to http over tcp where the client and server do not close the connection after each request - they keep it open for the next request from that client. Http2 complicates this a bit as it has multiple connections over a single tcp connection. On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts  wrote:I got your point. But reader.ReadString('\n') does not block like you said. After a request gets parsed, from the next iteration it keeps on emitting io.EOF until next request arrives.On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:You're thinking backwards. "Long polling" is something done at the *client* side: this is where you send a HTTP request, but the reply intentionally doesn't come back for a long time - generally until the server detects some event that needs reporting.At a web *server*, you simply read the request from the socket(*), process it, reply, and go straight back to reading the next request. Read will block until the next request comes in (or the connection is closed).  In other words, the goroutine handling that TCP connection just has a loop. There's no need to "wake" this goroutine from anywhere.(*) You need to read until the end of the request (request headers + body, if any). Again, RFC2616 tells you how the request is delimited - see section 5.On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:Thanks, that makes so much sense. So should I long-poll until next request line comes or keep-alive times out? Is there a better way to detect incoming requests and then maybe awake the goroutine using channels?On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:Handling keep-alives on the *server* side doesn't require any sort of connection pool. Just create one goroutine for each incoming TCP connection, and once you've handled one request, loop around, waiting for another request on the same connection.(That's assuming the client does request use of keep-alives of course; if they don't, you should close the connection. This depends on which HTTP version they requested and the Connection: header if present. Full details in RFC 2616)On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:Hello fellow gophers, I am currently building an experimental HTTP/1.1 framework based on TCP sockets as part of my course project. In project requirements, I have been asked to make a web server which can handle keep-alive properly without using the net/http library. The project link can be found below:https://github.com/roychowdhuryrohit-dev/slugI have recently found out that if I SetKeepAlive(true) and SetKeepAlivePeriod(time.Second * time.Duration(timeout)), it is not enough to hold the connection. Additionally, any subsequent requests are freezing.Then I found out that net/http's Transport manages a pool for idle connections. I want to go for a similar approach for my project. But I am not able to figure out how to detect income requests for my idle connections that I will be storing in the pool. Specifically, I want to know how listener.Accept() can give me an idle connection if it exists in the pool.



-- 
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/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%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/0033731F-373E-43B2-9348-11506C797D11%40ix.netcom.com.

[go-nuts] Re: KeepAlive with net.Listen

['Rohit Roy Chowdhury' via golang-nuts]

I got your point. But *reader.ReadString('\n')* does not block like you 
said. After a request gets parsed, from the next iteration it keeps on 
emitting *io.EOF *until next request arrives.

On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:

> You're thinking backwards. "Long polling" is something done at the 
> *client* side: this is where you send a HTTP request, but the reply 
> intentionally doesn't come back for a long time - generally until the 
> server detects some event that needs reporting.
>
> At a web *server*, you simply read the request from the socket(*), process 
> it, reply, and go straight back to reading the next request. Read will 
> block until the next request comes in (or the connection is closed).  In 
> other words, the goroutine handling that TCP connection just has a loop. 
> There's no need to "wake" this goroutine from anywhere.
>
> (*) You need to read until the end of the request (request headers + body, 
> if any). Again, RFC2616 tells you how the request is delimited - see 
> section 5.
>
> On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:
>
>> Thanks, that makes so much sense. So should I long-poll until next 
>> request line comes or keep-alive times out? Is there a better way to detect 
>> incoming requests and then maybe awake the goroutine using channels?
>> On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:
>>
>>> Handling keep-alives on the *server* side doesn't require any sort of 
>>> connection pool. Just create one goroutine for each incoming TCP 
>>> connection, and once you've handled one request, loop around, waiting for 
>>> another request on the same connection.
>>>
>>> (That's assuming the client does request use of keep-alives of course; 
>>> if they don't, you should close the connection. This depends on which HTTP 
>>> version they requested and the Connection: header if present. Full details 
>>> in RFC 2616)
>>>
>>> On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:
>>>
 Hello fellow gophers, I am currently building an experimental HTTP/1.1 
 framework based on TCP sockets as part of my course project. In project 
 requirements, I have been asked to make a web server which can handle 
 keep-alive properly without using the net/http library. The project link 
 can be found below:
 https://github.com/roychowdhuryrohit-dev/slug
 I have recently found out that if I *SetKeepAlive(true)* and 
 *SetKeepAlivePeriod(time.Second 
 * time.Duration(timeout))*, it is not enough to hold the connection. 
 Additionally, any subsequent requests are freezing.
 [image: Screenshot 2024-02-09 at 9.39.08 PM.png]

 Then I found out that net/http's Transport manages a pool for idle 
 connections. I want to go for a similar approach for my project. But I am 
 not able to figure out how to detect income requests for my idle 
 connections that I will be storing in the pool. Specifically, I want to 
 know how listener.Accept() can give me an idle connection if it exists in 
 the pool.

>>>

-- 
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/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%40googlegroups.com.

[go-nuts] Re: KeepAlive with net.Listen

['Brian Candler' via golang-nuts]

You're thinking backwards. "Long polling" is something done at the *client* 
side: this is where you send a HTTP request, but the reply intentionally 
doesn't come back for a long time - generally until the server detects some 
event that needs reporting.

At a web *server*, you simply read the request from the socket(*), process 
it, reply, and go straight back to reading the next request. Read will 
block until the next request comes in (or the connection is closed).  In 
other words, the goroutine handling that TCP connection just has a loop. 
There's no need to "wake" this goroutine from anywhere.

(*) You need to read until the end of the request (request headers + body, 
if any). Again, RFC2616 tells you how the request is delimited - see 
section 5.

On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote:

> Thanks, that makes so much sense. So should I long-poll until next request 
> line comes or keep-alive times out? Is there a better way to detect 
> incoming requests and then maybe awake the goroutine using channels?
> On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote:
>
>> Handling keep-alives on the *server* side doesn't require any sort of 
>> connection pool. Just create one goroutine for each incoming TCP 
>> connection, and once you've handled one request, loop around, waiting for 
>> another request on the same connection.
>>
>> (That's assuming the client does request use of keep-alives of course; if 
>> they don't, you should close the connection. This depends on which HTTP 
>> version they requested and the Connection: header if present. Full details 
>> in RFC 2616)
>>
>> On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:
>>
>>> Hello fellow gophers, I am currently building an experimental HTTP/1.1 
>>> framework based on TCP sockets as part of my course project. In project 
>>> requirements, I have been asked to make a web server which can handle 
>>> keep-alive properly without using the net/http library. The project link 
>>> can be found below:
>>> https://github.com/roychowdhuryrohit-dev/slug
>>> I have recently found out that if I *SetKeepAlive(true)* and 
>>> *SetKeepAlivePeriod(time.Second 
>>> * time.Duration(timeout))*, it is not enough to hold the connection. 
>>> Additionally, any subsequent requests are freezing.
>>> [image: Screenshot 2024-02-09 at 9.39.08 PM.png]
>>>
>>> Then I found out that net/http's Transport manages a pool for idle 
>>> connections. I want to go for a similar approach for my project. But I am 
>>> not able to figure out how to detect income requests for my idle 
>>> connections that I will be storing in the pool. Specifically, I want to 
>>> know how listener.Accept() can give me an idle connection if it exists in 
>>> the pool.
>>>
>>

-- 
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/40fbf74d-81a4-43e2-b439-0b4afa9bb29an%40googlegroups.com.

Re: [go-nuts] Re: need a package to read/write shell history flat file database

[Kurtis Rader]

Thanks, but that requires me to implement the code I would rather not have
to reinvent given that shells like Bash, Ksh, and Fish already have code to
do what I need. The problem is that those solutions are written in C and
C++ respectively rather than Go. While I consider myself an expert in C
(having started programming with it around 1985) I am only minimally
competent in C++. I'll translate the Fish C++ code into Go if I have to but
am hoping there is a published Go equivalent to save me that effort.

P.S., This is to remove the dependency on a daemon process to update a
BoltDB database by the Fish shell. The BoltDB dependency (go.etcd.io/bbolt)
greatly increases the size and complexity of the Fish shell. The opaque
binary database managed by BoltDB is also annoying. It would be preferable
to use a flat file database using JSON or text protobufs for storing
command history.

On Sat, Feb 10, 2024 at 9:15 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Sat, 2024-02-10 at 21:01 -0800, Kurtis Rader wrote:
> > The only solution I can find that gets close to my requirements is
> > https://github.com/ergochat/readline, but AFAICT it does not handle
> > updates to the on-disk history file by concurrently executing
> > processes.
>
> There is also https://pkg.go.dev/github.com/peterh/liner, which also
> does not handle history persistence, but which makes it relatively easy
> to add.
>
> --
> 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/e37a98a811c8e1cccfef8feffafef5260e7e5e56.camel%40kortschak.io
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

Re: [go-nuts] Re: need a package to read/write shell history flat file database

['Dan Kortschak' via golang-nuts]

On Sat, 2024-02-10 at 21:01 -0800, Kurtis Rader wrote:
> The only solution I can find that gets close to my requirements is
> https://github.com/ergochat/readline, but AFAICT it does not handle
> updates to the on-disk history file by concurrently executing
> processes.

There is also https://pkg.go.dev/github.com/peterh/liner, which also
does not handle history persistence, but which makes it relatively easy
to add.

-- 
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/e37a98a811c8e1cccfef8feffafef5260e7e5e56.camel%40kortschak.io.

[go-nuts] Re: need a package to read/write shell history flat file database

[Kurtis Rader]

The only solution I can find that gets close to my requirements is
https://github.com/ergochat/readline, but AFAICT it does not handle updates
to the on-disk history file by concurrently executing processes.

On Sat, Feb 10, 2024 at 6:55 PM Kurtis Rader  wrote:

> I'm looking for a package that will read/write a flat file database of
> shell commands from multiple processes. I could take an existing
> implementation in a different language, such as the one used by Bash or
> Fish, and rewrite it in Go but was hoping someone has already done this.
> The specific structure (e.g., YAML, JSON, something else) isn't important.
> I'm just looking for an implementation that is known to correctly handle
> appending new entries from concurrently running processes and rewriting the
> file when entries are deleted.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

[go-nuts] need a package to read/write shell history flat file database

[Kurtis Rader]

I'm looking for a package that will read/write a flat file database of
shell commands from multiple processes. I could take an existing
implementation in a different language, such as the one used by Bash or
Fish, and rewrite it in Go but was hoping someone has already done this.
The specific structure (e.g., YAML, JSON, something else) isn't important.
I'm just looking for an implementation that is known to correctly handle
appending new entries from concurrently running processes and rewriting the
file when entries are deleted.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

Re: [go-nuts] main.go:1:1: expected 'package', found 'EOF'

[Cengiz Korkmaz]

Thank you, just save it before run. no correct answers anywhere. 

On Wednesday, November 17, 2021 at 7:40:37 AM UTC+3 Francis wrote:

> Thank you all, CRTL + S , was the trick!.. I had a similar problem.
>
> On Thursday, April 20, 2017 at 12:45:07 AM UTC rame...@gmail.com wrote:
>
>> Thank you, Nico.
>>
>>
>> On Friday, January 23, 2015 at 6:16:15 AM UTC-8, Nico wrote:
>>>
>>> Did you save before calling GoRun? 
>>>
>>

-- 
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/e8f5bfb9-79ff-4451-af4f-79769a312f49n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin]

Created a issue based on our discussion:
https://github.com/golang/go/issues/65653

On Saturday, February 10, 2024 at 10:49:58 PM UTC+1 Martin wrote:

> Hey Aldemar and Thomas,
>
> thanks for your hints.
>
> >  While trying to upgrade a go package to 1.22.0 today, I ran into this 
> same issue in my coverage step. From testing different combinations of 
> options for `go test`, it seems that the 'no such file or directory' errors 
> and resulting non-zero exit code occur when go test processes a 
> folder/package that isn't included in the -coverpkg list- e.g. in your 
> case, any package that isn't part of ./internal. When I set -coverpkg equal 
> to the entire list of packages in the project, the error goes away.
>
> You are right, if I adopt your command, the errors go away.
>
> There seem several issues with the new code coverage design, see
> https://github.com/golang/go/issues/65570
> https://github.com/golang/go/issues/65636
>
> In both issues its addressed, that with
> $ GOEXPERIMENT=nocoverageredesign go test -v ./... 
> -coverprofile=coverage.out -coverpkg=./internal/... -covermode count
>
> The old behaviour is used and the error is gone as well.
>
> I assume the root cause is related to the both issues linked above, but 
> will create a new issue anyway.
> I will include your findings as well.
>
> On Thursday, February 8, 2024 at 11:14:58 PM UTC+1 Thomas McNulty wrote:
>
>> While trying to upgrade a go package to 1.22.0 today, I ran into this 
>> same issue in my coverage step. From testing different combinations of 
>> options for `go test`, it seems that the 'no such file or directory' errors 
>> and resulting non-zero exit code occur when go test processes a 
>> folder/package that isn't included in the -coverpkg list- e.g. in your 
>> case, any package that isn't part of ./internal. When I set -coverpkg equal 
>> to the entire list of packages in the project, the error goes away.
>>
>> Running with some packages (in this case, mocks) excluded:
>>
>> % go version
>> go version go1.22.0 darwin/arm64
>> % CVPKG=$(go list ./... | grep -v mocks | tr '\n' ',')
>> % go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count 
>>  ./...
>>   ... (tests passing)
>> github.com///internal/mocks/a/b: open 
>> /var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b849/covmeta.3a394ea9611306b457bfb2f5b2169adffc13123f3b07d667fd86b58eac717920:
>>  
>> no such file or directory
>> github.com///internal/mocks/c: open 
>> /var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b851/covmeta.5fc2c6ff11ae04da5c2cdbbb4c9e9e64d515086b2a7a7f5660d5dc409cdf5724:
>>  
>> no such file or directory
>> github.com///internal/mocks/e/f: open 
>> /var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b853/covmeta.2405ba52a1121a0f4a20da157347d9217eff95f8d18b9ae656cf0414aefe8221:
>>  
>> no such file or directory
>>   ... (more tests passing)
>> % echo $? 
>>  
>> 1
>>
>>
>> Vs. running with no packages excluded:
>>
>> % go version
>> go version go1.22.0 darwin/arm64
>> % CVPKG=$(go list ./... | tr '\n' ',')
>> % go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count 
>> ./...
>>  (all tests passing)
>> % echo $?
>> 0
>> On Thursday, February 8, 2024 at 2:41:18 PM UTC-5 Martin Schallnahs wrote:
>>
>>> Hey Brian,
>>>
>>> dont get me wrong!
>>>
>>> My usual setup is Continuous Integration Pipeline running in Linux VMs 
>>> which, in case of my golang projects, start fresh golang docker container 
>>> images from DockerHub.
>>> In case of this problem I used golang:1.22.0-alpine3.19 and 
>>> golang:1.22.0 (debian basd).
>>> For both I have the problem I describe.
>>> I just wanted to show, that its not a Docker problem and used my local 
>>> Windows machine do prove that.
>>>
>>> I grabbed my Macbook Pro (Intel), installed freshly Golang 1.22.0 and 
>>> run the mentioned go test command on the reproducer, and for me here the 
>>> problem also gets triggered.
>>> As you explained I use the corrected reproducer, with the Test not 
>>> failing, and have "go 1.22.0" in the go.mod.
>>>
>>>
>>> $ go version
>>> go version go1.22.0 darwin/amd64
>>>
>>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>>> -covermode count
>>> example.com/m: open 
>>> /var/folders/dm/k73ydgtx15l7dzwc3qk_wmhcgn/T/go-build3097649140/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>>  
>>> no such file or directory
>>>
>>> === RUN TestHelloer
>>> --- PASS: TestHelloer (0.00s)
>>> PASS
>>> coverage: 100.0% of statements in ./internal/...
>>> ok example.com/m/internal 0.261s coverage: 100.0% of statements in 
>>> ./internal/…
>>>
>>>
>>> Bit confusing, that it works for you though.
>>> On Thursday, February 8, 2024 at 6:11:15 PM UTC+1 Brian Candler wrote:
>>>
 $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
 -covermode count || echo 

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin]

Hey Aldemar and Thomas,

thanks for your hints.

>  While trying to upgrade a go package to 1.22.0 today, I ran into this 
same issue in my coverage step. From testing different combinations of 
options for `go test`, it seems that the 'no such file or directory' errors 
and resulting non-zero exit code occur when go test processes a 
folder/package that isn't included in the -coverpkg list- e.g. in your 
case, any package that isn't part of ./internal. When I set -coverpkg equal 
to the entire list of packages in the project, the error goes away.

You are right, if I adopt your command, the errors go away.

There seem several issues with the new code coverage design, see
https://github.com/golang/go/issues/65570
https://github.com/golang/go/issues/65636

In both issues its addressed, that with
$ GOEXPERIMENT=nocoverageredesign go test -v ./... 
-coverprofile=coverage.out -coverpkg=./internal/... -covermode count

The old behaviour is used and the error is gone as well.

I assume the root cause is related to the both issues linked above, but 
will create a new issue anyway.
I will include your findings as well.

On Thursday, February 8, 2024 at 11:14:58 PM UTC+1 Thomas McNulty wrote:

> While trying to upgrade a go package to 1.22.0 today, I ran into this same 
> issue in my coverage step. From testing different combinations of options 
> for `go test`, it seems that the 'no such file or directory' errors and 
> resulting non-zero exit code occur when go test processes a folder/package 
> that isn't included in the -coverpkg list- e.g. in your case, any package 
> that isn't part of ./internal. When I set -coverpkg equal to the entire 
> list of packages in the project, the error goes away.
>
> Running with some packages (in this case, mocks) excluded:
>
> % go version
> go version go1.22.0 darwin/arm64
> % CVPKG=$(go list ./... | grep -v mocks | tr '\n' ',')
> % go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count 
>  ./...
>   ... (tests passing)
> github.com///internal/mocks/a/b: open 
> /var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b849/covmeta.3a394ea9611306b457bfb2f5b2169adffc13123f3b07d667fd86b58eac717920:
>  
> no such file or directory
> github.com///internal/mocks/c: open 
> /var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b851/covmeta.5fc2c6ff11ae04da5c2cdbbb4c9e9e64d515086b2a7a7f5660d5dc409cdf5724:
>  
> no such file or directory
> github.com///internal/mocks/e/f: open 
> /var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b853/covmeta.2405ba52a1121a0f4a20da157347d9217eff95f8d18b9ae656cf0414aefe8221:
>  
> no such file or directory
>   ... (more tests passing)
> % echo $? 
>  
> 1
>
>
> Vs. running with no packages excluded:
>
> % go version
> go version go1.22.0 darwin/arm64
> % CVPKG=$(go list ./... | tr '\n' ',')
> % go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count 
> ./...
>  (all tests passing)
> % echo $?
> 0
> On Thursday, February 8, 2024 at 2:41:18 PM UTC-5 Martin Schallnahs wrote:
>
>> Hey Brian,
>>
>> dont get me wrong!
>>
>> My usual setup is Continuous Integration Pipeline running in Linux VMs 
>> which, in case of my golang projects, start fresh golang docker container 
>> images from DockerHub.
>> In case of this problem I used golang:1.22.0-alpine3.19 and golang:1.22.0 
>> (debian basd).
>> For both I have the problem I describe.
>> I just wanted to show, that its not a Docker problem and used my local 
>> Windows machine do prove that.
>>
>> I grabbed my Macbook Pro (Intel), installed freshly Golang 1.22.0 and run 
>> the mentioned go test command on the reproducer, and for me here the 
>> problem also gets triggered.
>> As you explained I use the corrected reproducer, with the Test not 
>> failing, and have "go 1.22.0" in the go.mod.
>>
>>
>> $ go version
>> go version go1.22.0 darwin/amd64
>>
>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count
>> example.com/m: open 
>> /var/folders/dm/k73ydgtx15l7dzwc3qk_wmhcgn/T/go-build3097649140/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> no such file or directory
>>
>> === RUN TestHelloer
>> --- PASS: TestHelloer (0.00s)
>> PASS
>> coverage: 100.0% of statements in ./internal/...
>> ok example.com/m/internal 0.261s coverage: 100.0% of statements in 
>> ./internal/…
>>
>>
>> Bit confusing, that it works for you though.
>> On Thursday, February 8, 2024 at 6:11:15 PM UTC+1 Brian Candler wrote:
>>
>>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>>> -covermode count || echo "flaky:$?"
>>> example.com/m: open 
>>> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>>  
>>> no such file or directory
>>>
>>> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
>>> -coverpkg=./internal/... 

[go-nuts] Re: KeepAlive with net.Listen

['Brian Candler' via golang-nuts]

Handling keep-alives on the *server* side doesn't require any sort of 
connection pool. Just create one goroutine for each incoming TCP 
connection, and once you've handled one request, loop around, waiting for 
another request on the same connection.

(That's assuming the client does request use of keep-alives of course; if 
they don't, you should close the connection. This depends on which HTTP 
version they requested and the Connection: header if present. Full details 
in RFC 2616)

On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote:

> Hello fellow gophers, I am currently building an experimental HTTP/1.1 
> framework based on TCP sockets as part of my course project. In project 
> requirements, I have been asked to make a web server which can handle 
> keep-alive properly without using the net/http library. The project link 
> can be found below:
> https://github.com/roychowdhuryrohit-dev/slug
> I have recently found out that if I *SetKeepAlive(true)* and 
> *SetKeepAlivePeriod(time.Second 
> * time.Duration(timeout))*, it is not enough to hold the connection. 
> Additionally, any subsequent requests are freezing.
> [image: Screenshot 2024-02-09 at 9.39.08 PM.png]
>
> Then I found out that net/http's Transport manages a pool for idle 
> connections. I want to go for a similar approach for my project. But I am 
> not able to figure out how to detect income requests for my idle 
> connections that I will be storing in the pool. Specifically, I want to 
> know how listener.Accept() can give me an idle connection if it exists in 
> the pool.
>

-- 
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/a644122f-40ea-4d65-9d71-192e07595fc9n%40googlegroups.com.

Re: [go-nuts] Opening network connections blocks system thread

['Brian Candler' via golang-nuts]

I can't see how a large number of waiting goroutines would cause an 
increase in the number of OS threads, which was the OP's original problem 
(hitting the 10,000 thread limit)

What the OP is implying - but we have not seen good evidence for yet - is 
that in some circumstances a non-blocking connect() becomes blocking. But 
even then, how would Go know to allocate an OS thread for it *before* 
calling it??

I suspect something else is going on. Does the original program with the 
10,000 thread problem make any use of external C code, directly or 
indirectly?

On Saturday 10 February 2024 at 05:17:21 UTC Kurtis Rader wrote:

> On Fri, Feb 9, 2024 at 2:10 PM Ian Lance Taylor  wrote:
>
>> On Fri, Feb 9, 2024 at 11:57 AM Kurtis Rader  
>> wrote:
>> >
>> > The connect() syscall is normally blocking. It doesn't return until the 
>> connection is established or an error occurs. It can be made non-blocking 
>> by putting the file-descriptor into non-blocking mode before the connect() 
>> call. However, that then requires either an async callback or another 
>> syscall to check whether the connection was established or an error 
>> occurred. Neither approach is idiomatic Go.
>>
>> That is true, but the Go standard library's net package does use
>> non-blocking calls to connect internally when implementing net.Dial
>> and friends.
>>
>> I don't have any problem running the original program on Linux 6.5.13.
>>
>
> Yes, I realized after my previous reply that Go could obviously use 
> non-blocking connect() calls coupled with select(), poll(), or similar 
> mechanisms to wakeup a goroutine blocked waiting for a net.Dial() (or 
> equivalent) connection to complete in order to minimize the number of OS 
> threads required to handle in-flight network connections. Without requiring 
> exposing an async callback or a mechanism to explicitly start a connection 
> and at a later time test whether it has been established or failed.
>
> What might be happening for the O.P. is that the systems they are 
> connecting to are not explicitly accepting or rejecting the connections in 
> a timely manner. Thus causing a huge number of goroutines blocked waiting 
> for the net.Dial() to complete. The systems they are connecting to may be 
> simply discarding the TCP SYN packets due to firewall rules or something 
> similar. This is something that is going to be hard for the Go community to 
> provide help since it is fundamentally not an issue with Go itself.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

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

Re: [go-nuts] Opening network connections blocks system thread

[Kurtis Rader]

On Fri, Feb 9, 2024 at 2:10 PM Ian Lance Taylor  wrote:

> On Fri, Feb 9, 2024 at 11:57 AM Kurtis Rader  wrote:
> >
> > The connect() syscall is normally blocking. It doesn't return until the
> connection is established or an error occurs. It can be made non-blocking
> by putting the file-descriptor into non-blocking mode before the connect()
> call. However, that then requires either an async callback or another
> syscall to check whether the connection was established or an error
> occurred. Neither approach is idiomatic Go.
>
> That is true, but the Go standard library's net package does use
> non-blocking calls to connect internally when implementing net.Dial
> and friends.
>
> I don't have any problem running the original program on Linux 6.5.13.
>

Yes, I realized after my previous reply that Go could obviously use
non-blocking connect() calls coupled with select(), poll(), or similar
mechanisms to wakeup a goroutine blocked waiting for a net.Dial() (or
equivalent) connection to complete in order to minimize the number of OS
threads required to handle in-flight network connections. Without requiring
exposing an async callback or a mechanism to explicitly start a connection
and at a later time test whether it has been established or failed.

What might be happening for the O.P. is that the systems they are
connecting to are not explicitly accepting or rejecting the connections in
a timely manner. Thus causing a huge number of goroutines blocked waiting
for the net.Dial() to complete. The systems they are connecting to may be
simply discarding the TCP SYN packets due to firewall rules or something
similar. This is something that is going to be hard for the Go community to
provide help since it is fundamentally not an issue with Go itself.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

Fwd: [go-nuts] [1.22] Is installing go under $HOME no longer possible?

[Johana de Roxas]

I just saw a big turn, that is the reason why to not do something about it.
And not even say about it. And to not work even on it.

-- Forwarded message -
From: Tetsuo Handa 
Date: Sat, Feb 10, 2024, 8:59 AM
Subject: [go-nuts] [1.22] Is installing go under $HOME no longer possible?
To: 


I noticed that go 1.22 started emitting

  warning: GOPATH set to GOROOT ($HOME/go) has no effect

and VSCode plugin noisily emits "Failed to run ..." messages
due to this warning message).

Although https://go.dev/doc/install suggests doing

  tar -C /usr/local -xzf go1.22.0.linux-amd64.tar.gz

and

  export PATH=$PATH:/usr/local/go/bin

, I'm doing

  tar -C $HOME -xzf go1.21.7.linux-amd64.tar.gz

and

  export PATH=$PATH:~/go/bin/

so that external packages can be installed without requiring
the write permission under /usr/local/go/ directory.

Installing under $HOME worked without problems until go 1.21.7 .
If this is an intentional change, please update https://go.dev/doc/install
to explicitly comment that installing under $HOME is not possible.

-- 
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/d2642225-3cf7-4c91-9059-fd45c880c6a5%40I-love.SAKURA.ne.jp
.

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

[go-nuts] Re: Profiling and PGO

['qiulaidongfeng' via golang-nuts]

Using benchmark and benchstat, you can compare the improvement obtained 
with PGO  .

On Friday, February 9, 2024 at 10:43:16 PM UTC+8 Agustin Horacio Urquiza 
Toledo wrote:

> I’m trying to compare the efficiency of two binaries before and after 
> applying Profile-Guided Optimization . For this, I’m using Go’s profiling, 
> specifically the flame graph. However, I’m getting two almost identical 
> stacks; the only difference is that some functions are inlined. It seems 
> that pprof doesn’t recognize that these functions are part of the same 
> execution path. I need to understand the percentage of improvement I’m 
> getting when compiling with PGO.
>
> My question is: Is there a way to indicate to pprof that these two paths 
> are part of the same execution? Or, is there a way to measure the 
> improvement obtained with PGO?"
>

-- 
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/f8def38d-9f9a-409f-93c3-5c2c9f32c67bn%40googlegroups.com.

[go-nuts] [1.22] Is installing go under $HOME no longer possible?

[Tetsuo Handa]

I noticed that go 1.22 started emitting

  warning: GOPATH set to GOROOT ($HOME/go) has no effect

and VSCode plugin noisily emits "Failed to run ..." messages
due to this warning message).

Although https://go.dev/doc/install suggests doing

  tar -C /usr/local -xzf go1.22.0.linux-amd64.tar.gz

and

  export PATH=$PATH:/usr/local/go/bin

, I'm doing

  tar -C $HOME -xzf go1.21.7.linux-amd64.tar.gz

and

  export PATH=$PATH:~/go/bin/

so that external packages can be installed without requiring
the write permission under /usr/local/go/ directory.

Installing under $HOME worked without problems until go 1.21.7 .
If this is an intentional change, please update https://go.dev/doc/install
to explicitly comment that installing under $HOME is not possible.

-- 
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/d2642225-3cf7-4c91-9059-fd45c880c6a5%40I-love.SAKURA.ne.jp.

[go-nuts] Re: v1.22.0 Performance Issues

[Stephen Illingworth]

Hi Michael,

Thanks for looking at the profiles. I must confess that I didn't know about 
the --diff_base option. I'll take a closer look at the results of the diff 
and see if that can help me spot anything.

In answer to your questions: I'm certain these profiles were produced from 
the same source code and I'm also certain that the same amount of logical 
work was being done. I can rerun the tests and reproduce the results.

I'll raise an GitHub issue tomorrow if nothing else comes to light.


Thanks again
Stephen

On Friday 9 February 2024 at 22:16:10 UTC Michael Knyszek wrote:

> Hey Stephen,
>
> I poked at your profiles (diffing them) but my only guess is that it's a 
> compiler change that's the culprit. (For future reference, I produced this 
> output with the --diff_base flag, which subtracts one profile from 
> another.)
>
> Showing nodes accounting for -1.34s, 0.44% of 305.86s total
> Dropped 4 nodes (cum <= 1.53s)
> Showing top 20 nodes out of 248
>   flat  flat%   sum%cum   cum%
> -2.85s  0.93%  0.93% -2.89s  0.94%  
> github.com/jetsetilly/gopher2600/hardware/tia/audio.(*Audio).Step
> -2.80s  0.92%  1.85% -1.68s  0.55%  
> github.com/jetsetilly/gopher2600/hardware/tia.(*TIA).QuickStep
>  1.52s   0.5%  1.35%  1.91s  0.62%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*Video).Pixel
>  1.27s  0.42%  0.94%  2.04s  0.67%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*MissileSprite).tick
> -1.18s  0.39%  1.32% -1.18s  0.39%  
> github.com/jetsetilly/gopher2600/hardware/memory/cartridge.(*Cartridge).AccessPassive
>  
> (inline)
> -0.84s  0.27%  1.60% -0.99s  0.32%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*PlayerSprite).tick
>  0.67s  0.22%  1.38%  1.24s  0.41%  
> github.com/jetsetilly/gopher2600/hardware/cpu.(*CPU).read8Bit
>  0.61s   0.2%  1.18%  1.46s  0.48%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*Video).Tick
> -0.54s  0.18%  1.35% -0.59s  0.19%  
> github.com/jetsetilly/gopher2600/hardware/memory/cartridge.(*atari4k).Access
> -0.54s  0.18%  1.53% -0.51s  0.17%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*PlayerSprite).pixel
>  0.49s  0.16%  1.37%  0.49s  0.16%  
> github.com/jetsetilly/gopher2600/hardware/memory/memorymap.MapAddress 
> (inline)
>  0.47s  0.15%  1.22%  0.60s   0.2%  
> github.com/jetsetilly/gopher2600/hardware/memory/cartridge.(*Cartridge).Write 
> (inline)
>  0.47s  0.15%  1.06%  1.32s  0.43%  
> github.com/jetsetilly/gopher2600/hardware/riot/timer.(*Timer).Step
>  0.41s  0.13%  0.93%  0.41s  0.13%  
> github.com/jetsetilly/gopher2600/hardware/memory/vcs.(*RIOTMemory).ChipRefer
>  0.40s  0.13%   0.8%  0.44s  0.14%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*MissileSprite).pixel
>  0.39s  0.13%  0.67%  0.39s  0.13%  
> github.com/jetsetilly/gopher2600/hardware/memory/vcs.(*RIOTMemory).ChipHasChanged
>  0.36s  0.12%  0.55%  0.62s   0.2%  
> github.com/jetsetilly/gopher2600/hardware/riot/ports.(*Ports).Step
>  0.35s  0.11%  0.44%  0.35s  0.11%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*BallSprite).pixel
> -0.33s  0.11%  0.55% -0.59s  0.19%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*BallSprite).tick
>  0.33s  0.11%  0.44%  0.85s  0.28%  
> github.com/jetsetilly/gopher2600/hardware/tia/video.(*MissileSprite).tickHMOVE
>
> A couple questions just so we're on the same page:
> - Are you certain these two profiles were produced from the same source 
> code?
> - Are you certain these two profiles represent the same amount of logical 
> work being done? (As an example, in the context of a web service, I 
> wouldn't want to measure 30s of traffic, but rather N identical requests 
> handled to make an apples-to-apples comparison.)
>
> If yes to both, then I think my conclusion is that this is probably the 
> result of a compiler change, given that the flat time increases all seem to 
> come from "user" code (as opposed to, say, runtime code).
>
> Do you have a reproducer? It might be worth filing a GitHub issue at this 
> point. (https://github.com/golang/go/issues/new/choose)
>
> Thanks,
> Michael
>
> On Friday, February 9, 2024 at 3:13:12 PM UTC-5 Stephen Illingworth wrote:
>
>> Hello,
>>
>> I'm trying v1.22.0 and I'm measuring an approximate drop in performance 
>> of 10%. I'm comparing to v1.21.7
>>
>> I'm looking at the release notes but I can't see anything that I would 
>> think would be having an impact. Is anyone else noticing a performance drop?
>>
>> I've created a cpu.profile for my project for each the two go versions. 
>>
>> I can't see anything obviously different between the two profiles but 
>> then again, I'm not very skilled with pprof. I've uploaded them to github 
>> if anyone wants to help.
>>
>> https://github.com/JetSetIlly/gopher2600_performance_profiles
>>
>>
>> Regards
>> Stephen
>>
>

Re: [go-nuts] Opening network connections blocks system thread

[Ian Lance Taylor]

On Fri, Feb 9, 2024 at 11:57 AM Kurtis Rader  wrote:
>
> The connect() syscall is normally blocking. It doesn't return until the 
> connection is established or an error occurs. It can be made non-blocking by 
> putting the file-descriptor into non-blocking mode before the connect() call. 
> However, that then requires either an async callback or another syscall to 
> check whether the connection was established or an error occurred. Neither 
> approach is idiomatic Go.

That is true, but the Go standard library's net package does use
non-blocking calls to connect internally when implementing net.Dial
and friends.

I don't have any problem running the original program on Linux 6.5.13.

Ian


> On Fri, Feb 9, 2024 at 7:29 AM Venkat T V  wrote:
>>
>> Hi,
>>
>> I am debugging an issue where a server opening a large number of connections 
>> on startup sometimes dies with "program exceeds 1-thread limit". I know 
>> file IO operations could lock up an OS thread. Still seeing this crash after 
>> eliminating file IO, and it looks like "syscall.connect" is a blocking call 
>> and could tie up an OS thread. This is on Linux with golang 1.21.7.
>>
>> I wrote a small program to test this out. Running this with "go run 
>> osthreads.go -parallel 500 -threads 5" does trigger crashes sometimes, and I 
>> see goroutines blocked on "syscall.connect" and "syscall.fcntl". Could I get 
>> confirmation that this is expected behavior and Connect is a blocking 
>> syscall?
>>
>> ===
>> package main
>>
>> import (
>> "flag"
>> "fmt"
>> "net"
>> "runtime"
>> "runtime/debug"
>> "sync"
>> "time"
>> )
>>
>> func main() {
>> numThreads := flag.Int("threads", 10, "number of threads (in addition to 
>> GOMAXPROCS)")
>> parallelism := flag.Int("parallel", 100, "number of parallel goroutines to 
>> start")
>> flag.Parse()
>>
>> maxThreads := runtime.GOMAXPROCS(-1) + *numThreads
>> fmt.Printf("GOMAXPROCS=%d, max threads=%d\n", runtime.GOMAXPROCS(-1), 
>> maxThreads)
>> debug.SetMaxThreads(maxThreads)
>>
>> // Server that does not accept any connections
>> listener, err := net.Listen("tcp", "127.0.0.1:9090")
>> if err != nil {
>> fmt.Println(err)
>> return
>> }
>> defer listener.Close()
>>
>> wg := sync.WaitGroup{}
>> startSignal := make(chan struct{})
>>
>> // Spawn all goroutines
>> for i := 0; i < *parallelism; i++ {
>> wg.Add(1)
>> go func(id int) {
>> defer wg.Done()
>> <-startSignal
>>
>> conn, err := net.DialTimeout("tcp", "127.0.0.1:9090", time.Second)
>> if err != nil {
>> fmt.Printf("%d: error: %s\n", id, err)
>> return
>> }
>> defer conn.Close()
>> time.Sleep(time.Second)
>> }(i)
>> }
>>
>> time.Sleep(time.Second)
>>
>> // Start them all at once
>> close(startSignal)
>> wg.Wait()
>> }
>>
>> ===
>>
>> --
>> 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/33ab22bf-088a-4724-8cfb-62b7f51fca96n%40googlegroups.com.
>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD92p6ZBjugETbX%3D5KjCqS7HH-Dv4PSuUg%3D9AZwBbioG1A%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/CAOyqgcVWPysC2vsqvXeVWmwswNBEQ5uaKQkPsZLguuiDnY_Omw%40mail.gmail.com.

Re: [go-nuts] Is there a way to cast interface to embedded type?

[Mike Schinkel]

> On Feb 9, 2024, at 3:37 PM, Christopher C  
> wrote:
> 
> I have a base struct that implements an interface. There are multiple other 
> structs that embed this base struct.  I would like to pass the an interface 
> into a function that can cast it as the base struct and call some functions 
> tied to the base struct.
>  
> Something like this...
> https://go.dev/play/p/DUzXr31s8Pn

You can't cast like in your example, but you can create an interface — call is 
`Baser` using idiomatic interface naming to identify the `Base` type which will 
have an empty `Base()` method — and then type assert to it after which, if it 
succeeds you can type assert to `*Base`, like so:

https://go.dev/play/p/-gcKGf4_AFg 

Hope this helps.

-Mike

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1149B1AB-059E-42B4-A593-549D4793F7B5%40newclarity.net.

Re: [go-nuts] Is there a way to cast interface to embedded type?

[burak serdar]

On Fri, Feb 9, 2024 at 1:37 PM Christopher C
 wrote:
>
> I have a base struct that implements an interface. There are multiple other 
> structs that embed this base struct.  I would like to pass the an interface 
> into a function that can cast it as the base struct and call some functions 
> tied to the base struct.

No, because type assertion tests the type of the object contained in
an interface, and that object is not the base object.

However, you can put whatever functions you are planning to call in
that base object into another interface, and call that:

type Base struct {...}

func (Base) A() {}
func (Base) B() {}

type HasA interface {
  A()
}

func f(in HasA) {
   type hasB interface {
  B()
   }
   b,ok:=in.(hasB)
   if ok {
  b.B()
  }
}




>
> Something like this...
> https://go.dev/play/p/DUzXr31s8Pn
>
> --
> 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/1ded992c-3f90-4c30-99a5-532e573cf16fn%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/CAMV2Rqr2fhqDEOxD3jhe8U1fZ1GFvNoNRHanpAykfa8UVfFtyw%40mail.gmail.com.

[go-nuts] Is there a way to cast interface to embedded type?

[Christopher C]

I have a base struct that implements an interface. There are multiple other 
structs that embed this base struct.  I would like to pass the an interface 
into a function that can cast it as the base struct and call some functions 
tied to the base struct.
 
Something like this...
https://go.dev/play/p/DUzXr31s8Pn

-- 
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/1ded992c-3f90-4c30-99a5-532e573cf16fn%40googlegroups.com.

[go-nuts] v1.22.0 Performance Issues

[Stephen Illingworth]

Hello,

I'm trying v1.22.0 and I'm measuring an approximate drop in performance of 
10%. I'm comparing to v1.21.7

I'm looking at the release notes but I can't see anything that I would 
think would be having an impact. Is anyone else noticing a performance drop?

I've created a cpu.profile for my project for each the two go versions. 

I can't see anything obviously different between the two profiles but then 
again, I'm not very skilled with pprof. I've uploaded them to github if 
anyone wants to help.

https://github.com/JetSetIlly/gopher2600_performance_profiles


Regards
Stephen

-- 
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/eaf270fe-0010-48c5-9442-1a14e4de6b16n%40googlegroups.com.

Re: [go-nuts] Opening network connections blocks system thread

[Kurtis Rader]

The connect() syscall is normally blocking. It doesn't return until the
connection is established or an error occurs. It can be made
non-blocking by putting the file-descriptor into non-blocking mode before
the connect() call. However, that then requires either an async callback or
another syscall to check whether the connection was established or an error
occurred. Neither approach is idiomatic Go.

On Fri, Feb 9, 2024 at 7:29 AM Venkat T V  wrote:

> Hi,
>
> I am debugging an issue where a server opening a large number of
> connections on startup sometimes dies with "program exceeds 1-thread
> limit". I know file IO operations could lock up an OS thread. Still seeing
> this crash after eliminating file IO, and it looks like "syscall.connect"
> is a blocking call and could tie up an OS thread. This is on Linux with
> golang 1.21.7.
>
> I wrote a small program to test this out. Running this with "go run
> osthreads.go -parallel 500 -threads 5" does trigger crashes sometimes, and
> I see goroutines blocked on "syscall.connect" and "syscall.fcntl". Could I
> get confirmation that this is expected behavior and Connect is a blocking
> syscall?
>
> ===
> package main
>
> import (
> "flag"
> "fmt"
> "net"
> "runtime"
> "runtime/debug"
> "sync"
> "time"
> )
>
> func main() {
> numThreads := flag.Int("threads", 10, "number of threads (in addition to
> GOMAXPROCS)")
> parallelism := flag.Int("parallel", 100, "number of parallel goroutines
> to start")
> flag.Parse()
>
> maxThreads := runtime.GOMAXPROCS(-1) + *numThreads
> fmt.Printf("GOMAXPROCS=%d, max threads=%d\n", runtime.GOMAXPROCS(-1),
> maxThreads)
> debug.SetMaxThreads(maxThreads)
>
> // Server that does not accept any connections
> listener, err := net.Listen("tcp", "127.0.0.1:9090")
> if err != nil {
> fmt.Println(err)
> return
> }
> defer listener.Close()
>
> wg := sync.WaitGroup{}
> startSignal := make(chan struct{})
>
> // Spawn all goroutines
> for i := 0; i < *parallelism; i++ {
> wg.Add(1)
> go func(id int) {
> defer wg.Done()
> <-startSignal
>
> conn, err := net.DialTimeout("tcp", "127.0.0.1:9090", time.Second)
> if err != nil {
> fmt.Printf("%d: error: %s\n", id, err)
> return
> }
> defer conn.Close()
> time.Sleep(time.Second)
> }(i)
> }
>
> time.Sleep(time.Second)
>
> // Start them all at once
> close(startSignal)
> wg.Wait()
> }
>
> ===
>
> --
> 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/33ab22bf-088a-4724-8cfb-62b7f51fca96n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

[go-nuts] Opening network connections blocks system thread

[Venkat T V]

Hi,

I am debugging an issue where a server opening a large number of 
connections on startup sometimes dies with "program exceeds 1-thread 
limit". I know file IO operations could lock up an OS thread. Still seeing 
this crash after eliminating file IO, and it looks like "syscall.connect" 
is a blocking call and could tie up an OS thread. This is on Linux with 
golang 1.21.7.

I wrote a small program to test this out. Running this with "go run 
osthreads.go -parallel 500 -threads 5" does trigger crashes sometimes, and 
I see goroutines blocked on "syscall.connect" and "syscall.fcntl". Could I 
get confirmation that this is expected behavior and Connect is a blocking 
syscall?

===
package main

import (
"flag"
"fmt"
"net"
"runtime"
"runtime/debug"
"sync"
"time"
)

func main() {
numThreads := flag.Int("threads", 10, "number of threads (in addition to 
GOMAXPROCS)")
parallelism := flag.Int("parallel", 100, "number of parallel goroutines to 
start")
flag.Parse()

maxThreads := runtime.GOMAXPROCS(-1) + *numThreads
fmt.Printf("GOMAXPROCS=%d, max threads=%d\n", runtime.GOMAXPROCS(-1), 
maxThreads)
debug.SetMaxThreads(maxThreads)

// Server that does not accept any connections
listener, err := net.Listen("tcp", "127.0.0.1:9090")
if err != nil {
fmt.Println(err)
return
}
defer listener.Close()

wg := sync.WaitGroup{}
startSignal := make(chan struct{})

// Spawn all goroutines
for i := 0; i < *parallelism; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
<-startSignal

conn, err := net.DialTimeout("tcp", "127.0.0.1:9090", time.Second)
if err != nil {
fmt.Printf("%d: error: %s\n", id, err)
return
}
defer conn.Close()
time.Sleep(time.Second)
}(i)
}

time.Sleep(time.Second)

// Start them all at once
close(startSignal)
wg.Wait()
}

===

-- 
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/33ab22bf-088a-4724-8cfb-62b7f51fca96n%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

['Brian Candler' via golang-nuts]

Sorry you're right, it's "otool -L" for macOS.

And you say that if you cross-compile from Linux with 1.22.0 to build a 
macOS binary, you get a size approx 93.8MB as well? Very odd.

On Friday 9 February 2024 at 14:43:35 UTC cpu...@gmail.com wrote:

> Yes, CGO is disabled. ldd doesn't seem to exist on MacOS:
>
> make build && ls -la ./evcc && otool -L ./evcc
>
> 1.21.7
>
> CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
> github.com/evcc-io/evcc/server.Version=0.124.1 -X 
> github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
> -rwxr-xr-x  1 andig  staff  *93824418*  9 Feb 14:38 ./evcc
> ./evcc:
> /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> /usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> 
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 0.0.0, current version 0.0.0)
> /System/Library/Frameworks/Security.framework/Versions/A/Security 
> (compatibility version 0.0.0, current version 0.0.0)
>
> 1.22.0
>
> CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
> github.com/evcc-io/evcc/server.Version=0.124.1 -X 
> github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
> -rwxr-xr-x  1 andig  staff  *81119026*  9 Feb 14:37 ./evcc
> ./evcc:
> /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> /usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
> version 0.0.0)
> 
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 0.0.0, current version 0.0.0)
> /System/Library/Frameworks/Security.framework/Versions/A/Security 
> (compatibility version 0.0.0, current version 0.0.0)
>
> On Friday, February 9, 2024 at 2:22:36 PM UTC+1 Brian Candler wrote:
>
>> Have you at any point set CGO_ENABLED=0 ?
>>
>> What does "ldd /path/to/binary" show on both the old (larger) and new 
>> (smaller) binaries?  Maybe one is dynamically linked and the other 
>> statically linked?
>>
>

-- 
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/510198df-4b95-4c55-8cc1-a40c13703578n%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

[cpu...@gmail.com]

Yes, CGO is disabled. ldd doesn't seem to exist on MacOS:

make build && ls -la ./evcc && otool -L ./evcc

1.21.7

CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
github.com/evcc-io/evcc/server.Version=0.124.1 -X 
github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
-rwxr-xr-x  1 andig  staff  *93824418*  9 Feb 14:38 ./evcc
./evcc:
/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
version 0.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
version 0.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security 
(compatibility version 0.0.0, current version 0.0.0)

1.22.0

CGO_ENABLED=0 go build -v -tags=release -trimpath -ldflags='-X 
github.com/evcc-io/evcc/server.Version=0.124.1 -X 
github.com/evcc-io/evcc/server.Commit=596071b42 -s -w'
-rwxr-xr-x  1 andig  staff  *81119026*  9 Feb 14:37 ./evcc
./evcc:
/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current 
version 0.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current 
version 0.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security 
(compatibility version 0.0.0, current version 0.0.0)

On Friday, February 9, 2024 at 2:22:36 PM UTC+1 Brian Candler wrote:

> Have you at any point set CGO_ENABLED=0 ?
>
> What does "ldd /path/to/binary" show on both the old (larger) and new 
> (smaller) binaries?  Maybe one is dynamically linked and the other 
> statically linked?
>

-- 
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/5787a122-8581-41e7-81d5-9ae2b0e28942n%40googlegroups.com.

[go-nuts] Profiling and PGO

[Agustin Horacio Urquiza Toledo]

I’m trying to compare the efficiency of two binaries before and after 
applying Profile-Guided Optimization . For this, I’m using Go’s profiling, 
specifically the flame graph. However, I’m getting two almost identical 
stacks; the only difference is that some functions are inlined. It seems 
that pprof doesn’t recognize that these functions are part of the same 
execution path. I need to understand the percentage of improvement I’m 
getting when compiling with PGO.

My question is: Is there a way to indicate to pprof that these two paths 
are part of the same execution? Or, is there a way to measure the 
improvement obtained with PGO?"

-- 
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/11628d55-73c3-44e1-91bf-8fcc8adb1631n%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

['Brian Candler' via golang-nuts]

Have you at any point set CGO_ENABLED=0 ?

What does "ldd /path/to/binary" show on both the old (larger) and new 
(smaller) binaries?  Maybe one is dynamically linked and the other 
statically linked?

-- 
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/fb7d0cf7-0ebf-4205-aaac-cc8422fab2cfn%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

[cpu...@gmail.com]

Just gave it another try cross-compiling to Arm on Linux. This time binary 
size stays the same. Sorry if my excitement was too premature.

On Friday, February 9, 2024 at 2:11:25 PM UTC+1 cpu...@gmail.com wrote:

> It's really surprising (positively). Compiling with -ldflags='-s -w' if 
> anyone wants to try this.
>
> On Friday, February 9, 2024 at 1:23:20 PM UTC+1 qiulaidongfeng wrote:
>
>> Quick search to find go1.22 as follows  CL  like  
>> https://go-review.googlesource.com/c/go/+/521615   reduces binary size. 
>> However, from 93MB to 81MB, I think it is most likely the result of the 
>> joint efforts of many CLs.
>>
>> On Friday, February 9, 2024 at 7:46:48 PM UTC+8 cpu...@gmail.com wrote:
>>
>>> I was surprised to see my application (MacOS binary) go from 93MB to 
>>> 81MB (no PGO). Release notes don't mention this.
>>>
>>> Has anyone made similar experience or knows why that is?
>>>
>>> Thanks,
>>> Andi
>>>
>>

-- 
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/74abf623-f1cc-4835-9893-8bc91d3e2afbn%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

[cpu...@gmail.com]

It's really surprising (positively). Compiling with -ldflags='-s -w' if 
anyone wants to try this.

On Friday, February 9, 2024 at 1:23:20 PM UTC+1 qiulaidongfeng wrote:

> Quick search to find go1.22 as follows  CL  like  
> https://go-review.googlesource.com/c/go/+/521615   reduces binary size. 
> However, from 93MB to 81MB, I think it is most likely the result of the 
> joint efforts of many CLs.
>
> On Friday, February 9, 2024 at 7:46:48 PM UTC+8 cpu...@gmail.com wrote:
>
>> I was surprised to see my application (MacOS binary) go from 93MB to 81MB 
>> (no PGO). Release notes don't mention this.
>>
>> Has anyone made similar experience or knows why that is?
>>
>> Thanks,
>> Andi
>>
>

-- 
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/c93a73d1-ea18-4d12-9127-0787ffb5f51cn%40googlegroups.com.

[go-nuts] Re: Go 1.22 binary size improvements?

['qiulaidongfeng' via golang-nuts]

Quick search to find go1.22 as follows  CL  like  
https://go-review.googlesource.com/c/go/+/521615   reduces binary size. 
However, from 93MB to 81MB, I think it is most likely the result of the 
joint efforts of many CLs.

On Friday, February 9, 2024 at 7:46:48 PM UTC+8 cpu...@gmail.com wrote:

> I was surprised to see my application (MacOS binary) go from 93MB to 81MB 
> (no PGO). Release notes don't mention this.
>
> Has anyone made similar experience or knows why that is?
>
> Thanks,
> Andi
>

-- 
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/f7d074ec-88ad-44fe-a472-811663bd1199n%40googlegroups.com.

[go-nuts] Go 1.22 binary size improvements?

[cpu...@gmail.com]

I was surprised to see my application (MacOS binary) go from 93MB to 81MB 
(no PGO). Release notes don't mention this.

Has anyone made similar experience or knows why that is?

Thanks,
Andi

-- 
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/d9ba2568-90d7-4a0f-8b25-83a3f01ad662n%40googlegroups.com.

[go-nuts] What are the reason for the performance improvement cause by alloc data of different sizes to adjacent memory addresses?

['qiulaidongfeng' via golang-nuts]

I recently added a new API (AllocSoonUse) to the 
https://gitee.com/qiulaidongfeng/arena I wrote (copy in 
https://github.com/qiulaidongfeng/arena)
This API allocdata to adjacent []byte, and the length can be set.
I use this benchmark code : https://go.dev/play/p/nAGveraT5_h

benchmark Brief description, use AllocSoonUse and new to allocate some data 
of different sizes that does not contain Pointers and use it soon after 
allocation.

I use `go test -bench=. -count=10 -benchtime=2s > new.txt && benchstat 
new.txt`  got this result
 │   new.txt   │
 │   sec/op│
NoStd-16   207.4µ ± 4%
Std-16 245.0µ ± 1%
geomean225.4µ

It appears that using AllocSoonUse takes 15.34% less time than using new in 
some scenarios.

I initially speculated that the reason for the performance improvement was 
the change in cache hit rate.

But using this benchmark https://go.dev/play/p/SCNMV6I9GWC and `go test 
-bench=. -count=10 -benchtime=2s > new.txt && benchstat new.txt`  got this 
result
 │   new.txt   │
 │   sec/op│
NoStd-16   206.6µ ± 3%
Std-16 236.0µ ± 2%
geomean220.9µ

It appears that there is still a 12.45% performance gap after commenting 
out the access code to allocated memory to reduce the access to memory.

I want to get the performance gap so the reason.

The possibility has been ruled out, AllocSoonUse  allows free memory in a 
way that allows for immediate reuse  , but I did not enable this opt-in.

-- 
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/13dfb086-3fc4-4361-80eb-fc6466cfd72fn%40googlegroups.com.

[go-nuts] Arctic Warfare is now available (powered by Ebitengine)

[Trevor Slocum]

Arctic Warfare is now available to play. Battle tanks in the arctic, 
demolish trees and annihilate snowmen.

Play: https://rocketnine.itch.io/arctic-warfare
Code: https://code.rocket9labs.com/tslocum/arcticwarfare

-- 
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/4f3826b7-fc10-4cae-b970-7874565b3387n%40googlegroups.com.

Re: [go-nuts] Re: templates not working for me

[Ian Lance Taylor]

On Wed, Feb 7, 2024 at 10:11 PM joseph.p...@gmail.com
 wrote:
>
> Variable substitution doesn't seem to work in an included template file. Is 
> that a known limitation?

golang-nuts is for general discussion of Go, its tools, and its
standard library.  It's fine to ask about the Gin web framework here,
but you are likely to get better answers if you ask in a forum that is
focused on Gin.

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

Re: [go-nuts] Re: Changing PWD ruins test caching

[Kevin Burke]

You're right. I ended up inserting a shim to replace os/env.go in the
standard library, that would dump the stack trace of anything that called
os.Getenv("PWD"). It turns out that a popular testing library was doing
this - https://github.com/onsi/ginkgo/issues/1355.

On Thu, Feb 8, 2024 at 3:19 PM 'Sean Liao' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Using a basic example which just imports os
> https://go.dev/play/p/BmX0ds901-4 (the rest copied from gobyexample)
> copied to 2 different directories, I do see cache hits, so I don't
> think it's from just the import?
>
> 23:12:37 ~/tmp/testrepo0530/a 0:00:00
> main » go1.22.0 test .
> testcache: example: test ID 7554777255756c714a6773663261576871416373
> => d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c
> testcache: example: input list not found: cache entry not found: open
>
> /home/user/.cache/go-build/d9/d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c-a:
> no such file or directory
> testcache: example: test ID 695f4e6944335a64497850503861366643364c48
> => e7d8d7272b091d2d5d155ff077e599c1e7c31eaad2d9bf3549e2d03149e94357
> testcache: example: input list not found: cache entry not found: open
>
> /home/user/.cache/go-build/e7/e7d8d7272b091d2d5d155ff077e599c1e7c31eaad2d9bf3549e2d03149e94357-a:
> no such file or directory
> testcache: example: save test ID
> d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c =>
> input ID 8671bffc7a3ec5201bb26a0eccecb5599259f0d0e63624375378b61cc00a0733
> => 516ef3f5e0d83ea893583f43f60e654775b3769b5f99f2de7b99487eae637298
> testcache: example: save test ID
> e7d8d7272b091d2d5d155ff077e599c1e7c31eaad2d9bf3549e2d03149e94357 =>
> input ID 8671bffc7a3ec5201bb26a0eccecb5599259f0d0e63624375378b61cc00a0733
> => 42e8604e2c4807cd097efad167887d4d0ddfc76afda71e21f8145604d93ebce5
> ok  example 0.001s
>
> 23:12:42 ~/tmp/testrepo0530/a 0:00:00
> main » cd ../b
>
> 23:12:46 ~/tmp/testrepo0530/b 0:00:00
> main » go1.22.0 test .
> testcache: example: test ID 7554777255756c714a6773663261576871416373
> => d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c
> testcache: example: test ID
> d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c =>
> input ID 8671bffc7a3ec5201bb26a0eccecb5599259f0d0e63624375378b61cc00a0733
> => 516ef3f5e0d83ea893583f43f60e654775b3769b5f99f2de7b99487eae637298
> ok  example (cached)
>
>
> - sean
>
> On Thu, Feb 8, 2024 at 12:13 AM Kevin Burke  wrote:
> >
> > Sorry for slow reply. We are using Alpine, which I don't think is either
> of those flavors.
> >
> > I discovered this by enabling GODEBUG=gocachehash=1, running the tests
> twice, and then checking the diff between the two test runs.
> >
> > On Tue, Nov 28, 2023 at 11:57 AM 'Bryan C. Mills' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
> >>
> >> As far as I can tell the code in question is only built on AIX and
> OpenBSD — are you using one of those two platforms?
> >> If not, perhaps the caching problem is coming from somewhere else.
> >>
> >> That said, it does appear that calls to `os.Chdir` result in a spurious
> dependency on the PWD variable:
> >>
> https://cs.opensource.google/go/go/+/master:src/os/file.go;l=340-345;drc=d961b12be9001cf8dbf8f52847607dbf84d94f8d
> >>
> >> On Thursday, November 23, 2023 at 1:50:04 PM UTC-5 Kevin Burke wrote:
> >>>
> >>> We have some tests that are pretty slow. I would like to use Go's test
> caching to skip them in our CI environment, if nothing in the code or the
> environment has changed. Our CI environment has a set of _agents_, each of
> which can run multiple jobs simultaneously. As a result, they check out
> code into a different directory each time they run a job.
> >>>
> >>> Go's test caching checks every env var loaded by the test program. If
> any of them change, then Go assumes that the cache is busted and the test
> must be run.
> >>>
> >>> Any program that imports "os" hits this logic in the os package, which
> checks the value of the $PWD environment variable:
> >>>
> >>> // We query the working directory at init, to use it later to search
> for the
> >>> // executable file
> >>> // errWd will be checked later, if we need to use initWd
> >>> var initWd, errWd = Getwd()
> >>>
> >>> So checking code out to different directories means that any program
> that imports "os" cannot have test caching. This seems like a shame because
> the code is all laid out in the same place in the working directory.
> >>>
> >>> Has anyone tried to fix this issue? Do you think this is worth trying
> to patch or modify the test caching behavior in Go itself? I could solve
> this by running a chroot or another layer of Docker, of course, but I'd
> prefer not to do these because of the difficulty of getting data in and out
> of each one, communicating with other Docker containers, etc.
> >>
> >> --
> >> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> >> To unsubscribe from this 

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

['Sean Liao' via golang-nuts]

I've filed it as https://go.dev/issue/65624

- sean

On Thu, Feb 8, 2024 at 6:58 PM Kyle Shannon  wrote:
>
> On 2/8/24 11:30, Jason Phillips wrote:
>
> Can you create a small self-contained program that reproduces the issue? The 
> following program returns 404 locally, as I'd expect, but does get killed in 
> the Go playground: https://go.dev/play/p/FigBLK8KrAK
>
> Perhaps a simpler reproduction that's runnable on the playground:
>
> https://go.dev/play/p/gmQGJsyNCT6
>
> This returns 301 with a Location of /x/.  Note the trailing slash in the mux 
> pattern, which was missing in your example.
>
>
> Perhaps there's an issue with the Playground networking implementation that's 
> incompatible with the 1.22 changes?
>
> On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:
>>
>> I haven't played around with it yet, but have you tried to separately 
>> register /something/ ?
>>
>> mux := http.NewServeMux()
>> mux.HandleFunc("/something/", func...)
>> mux.HandleFunc("/something/{id}/{$}", func...)
>>
>> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
>>>
>>> Hello,
>>>
>>> I noticed if you set up a route like /something/{id}/{$}, it results in an 
>>> infinite loop if I navigate to /someting/ (with the trailing slash). I got 
>>> a redirect to Location: /something/, and so on. Finally the page breaks 
>>> after multiple rounds.
>>>
>>> Example:
>>> mux := http.NewServeMux()
>>> mux.HandleFunc("/something/{id}/{$}", func...))
>>>
>>> Should I raise and issue or am I doing something wrong here?
>>>
>>> Thanks,
>>> Peter
>
> --
> 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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com.
>
>
> --
> Kyle
>
> --
> 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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.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/CAGabyPryHf98e_OcB1ffC2ZdTQ_s88Vm-kG%2Bm1mtbNu1TCAwbA%40mail.gmail.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Thomas McNulty]

While trying to upgrade a go package to 1.22.0 today, I ran into this same 
issue in my coverage step. From testing different combinations of options 
for `go test`, it seems that the 'no such file or directory' errors and 
resulting non-zero exit code occur when go test processes a folder/package 
that isn't included in the -coverpkg list- e.g. in your case, any package 
that isn't part of ./internal. When I set -coverpkg equal to the entire 
list of packages in the project, the error goes away.

Running with some packages (in this case, mocks) excluded:

% go version
go version go1.22.0 darwin/arm64
% CVPKG=$(go list ./... | grep -v mocks | tr '\n' ',')
% go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count 
 ./...
  ... (tests passing)
github.com///internal/mocks/a/b: open 
/var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b849/covmeta.3a394ea9611306b457bfb2f5b2169adffc13123f3b07d667fd86b58eac717920:
 
no such file or directory
github.com///internal/mocks/c: open 
/var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b851/covmeta.5fc2c6ff11ae04da5c2cdbbb4c9e9e64d515086b2a7a7f5660d5dc409cdf5724:
 
no such file or directory
github.com///internal/mocks/e/f: open 
/var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b853/covmeta.2405ba52a1121a0f4a20da157347d9217eff95f8d18b9ae656cf0414aefe8221:
 
no such file or directory
  ... (more tests passing)
% echo $?   
   
1


Vs. running with no packages excluded:

% go version
go version go1.22.0 darwin/arm64
% CVPKG=$(go list ./... | tr '\n' ',')
% go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count 
./...
 (all tests passing)
% echo $?
0
On Thursday, February 8, 2024 at 2:41:18 PM UTC-5 Martin Schallnahs wrote:

> Hey Brian,
>
> dont get me wrong!
>
> My usual setup is Continuous Integration Pipeline running in Linux VMs 
> which, in case of my golang projects, start fresh golang docker container 
> images from DockerHub.
> In case of this problem I used golang:1.22.0-alpine3.19 and golang:1.22.0 
> (debian basd).
> For both I have the problem I describe.
> I just wanted to show, that its not a Docker problem and used my local 
> Windows machine do prove that.
>
> I grabbed my Macbook Pro (Intel), installed freshly Golang 1.22.0 and run 
> the mentioned go test command on the reproducer, and for me here the 
> problem also gets triggered.
> As you explained I use the corrected reproducer, with the Test not 
> failing, and have "go 1.22.0" in the go.mod.
>
>
> $ go version
> go version go1.22.0 darwin/amd64
>
> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> example.com/m: open 
> /var/folders/dm/k73ydgtx15l7dzwc3qk_wmhcgn/T/go-build3097649140/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> no such file or directory
>
> === RUN TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
> coverage: 100.0% of statements in ./internal/...
> ok example.com/m/internal 0.261s coverage: 100.0% of statements in 
> ./internal/…
>
>
> Bit confusing, that it works for you though.
> On Thursday, February 8, 2024 at 6:11:15 PM UTC+1 Brian Candler wrote:
>
>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count || echo "flaky:$?"
>> example.com/m: open 
>> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> no such file or directory
>>
>> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
>> -coverpkg=./internal/... -covermode count
>> example.com/m: open 
>> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> The system cannot find the file specified.
>>
>> Those look like the underlying errors causing the exit code 1. But it 
>> works fine for me under both Linux and macOS, as long as I have "go 1.22.0" 
>> in go.mod. Maybe someone who knows more about Windows can help?
>>
>> On Thursday 8 February 2024 at 17:03:18 UTC Martin Schallnahs wrote:
>>
>>> Hi Brian,
>>>
>>> thanks for checking out, yes that I wanted also to write you.
>>> We need it currently in our CI as some dependency scanner tool does not 
>>> work with the "go X.Y.Z." syntax, but I tried, and for my problem it did 
>>> not was the cause.
>>>
>>>
>>> > If a test fails, I would expect it to terminate with an error (exit 
>>> code 1 in this case).
>>>
>>> See my second mail, the test case should not fail, it was kinda a typo 
>>> (tried to shorten the reproducer to much in my first mail).
>>>
>>> > If I run your reproducer locally (not in Docker) with the modified 
>>> TestHelloer, it works fine(*) and gives me an exit code of 0
>>>
>>> Yes, when I run it with golang 1.21.7 it works fine as well, as my 
>>> problem statement is about golang 1.22.0.
>>>
>>> > Therefore, if your 

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Aldemar F]

I have the same issue here.

Running tests on a linux (ubuntu based).

It only happens when a use the flag coverpkg.

I have managed to "solve" it on an very bad way, creating an empty test 
file in packages that don't have tests

(removed the files paths)

```
open 
/tmp/go-build2070237917/b334/covmeta.ce414c14907a52c0962d732a8a53fd8b6639b1f9a004b9c6e110921165bab8c3:
 
no such file or directory
open 
/tmp/go-build2070237917/b335/covmeta.41db8a5854133f388ac5e1dae6628818f4bfb391b0fed738b0e33c2fa26dd79b:
 
no such file or directory
... ... 
```

Em quinta-feira, 8 de fevereiro de 2024 às 16:41:18 UTC-3, Martin 
Schallnahs escreveu:

> Hey Brian,
>
> dont get me wrong!
>
> My usual setup is Continuous Integration Pipeline running in Linux VMs 
> which, in case of my golang projects, start fresh golang docker container 
> images from DockerHub.
> In case of this problem I used golang:1.22.0-alpine3.19 and golang:1.22.0 
> (debian basd).
> For both I have the problem I describe.
> I just wanted to show, that its not a Docker problem and used my local 
> Windows machine do prove that.
>
> I grabbed my Macbook Pro (Intel), installed freshly Golang 1.22.0 and run 
> the mentioned go test command on the reproducer, and for me here the 
> problem also gets triggered.
> As you explained I use the corrected reproducer, with the Test not 
> failing, and have "go 1.22.0" in the go.mod.
>
>
> $ go version
> go version go1.22.0 darwin/amd64
>
> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> example.com/m: open 
> /var/folders/dm/k73ydgtx15l7dzwc3qk_wmhcgn/T/go-build3097649140/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> no such file or directory
>
> === RUN TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
> coverage: 100.0% of statements in ./internal/...
> ok example.com/m/internal 0.261s coverage: 100.0% of statements in 
> ./internal/…
>
>
> Bit confusing, that it works for you though.
> On Thursday, February 8, 2024 at 6:11:15 PM UTC+1 Brian Candler wrote:
>
>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count || echo "flaky:$?"
>> example.com/m: open 
>> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> no such file or directory
>>
>> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
>> -coverpkg=./internal/... -covermode count
>> example.com/m: open 
>> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> The system cannot find the file specified.
>>
>> Those look like the underlying errors causing the exit code 1. But it 
>> works fine for me under both Linux and macOS, as long as I have "go 1.22.0" 
>> in go.mod. Maybe someone who knows more about Windows can help?
>>
>> On Thursday 8 February 2024 at 17:03:18 UTC Martin Schallnahs wrote:
>>
>>> Hi Brian,
>>>
>>> thanks for checking out, yes that I wanted also to write you.
>>> We need it currently in our CI as some dependency scanner tool does not 
>>> work with the "go X.Y.Z." syntax, but I tried, and for my problem it did 
>>> not was the cause.
>>>
>>>
>>> > If a test fails, I would expect it to terminate with an error (exit 
>>> code 1 in this case).
>>>
>>> See my second mail, the test case should not fail, it was kinda a typo 
>>> (tried to shorten the reproducer to much in my first mail).
>>>
>>> > If I run your reproducer locally (not in Docker) with the modified 
>>> TestHelloer, it works fine(*) and gives me an exit code of 0
>>>
>>> Yes, when I run it with golang 1.21.7 it works fine as well, as my 
>>> problem statement is about golang 1.22.0.
>>>
>>> > Therefore, if your problem only occurs when using Docker, then you 
>>> should provide a docker-based reproducer (including the Dockerfile)
>>>
>>> Happens locally as well. And in my original setup it was using a fresh 
>>> docker container from golang (in an CI/GitLab pipeline) and did this:
>>>
>>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>>> -covermode count || echo "flaky:$?"
>>> example.com/m: open 
>>> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>>  
>>> no such file or directory
>>>
>>> === RUN   TestHelloer
>>> --- PASS: TestHelloer (0.00s)
>>> PASS
>>> coverage: 100.0% of statements in ./internal/...
>>> ok   example.com/m/internal 0.004s coverage: 100.0% of statements in 
>>> ./internal/...
>>> flaky:1
>>> $ go tool cover -html=coverage.out -o coverage.html
>>> $ go tool cover -func=coverage.out
>>> example.com/m/internal/helloer.go:3: Helloer 100.0%
>>> total: (statements) 100.0%
>>>
>>>
>>> But I just tried it locally (Windows) and there it happens as well:
>>>
>>> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
>>> -coverpkg=./internal/... -covermode count
>>> 

[go-nuts] User-visible regression in the x509.Certificate struct from go 1.21.6 to 1.22.0

[Victor Lowther]

It looks like adding the x509.OID type and associated fields to the 
x509.Certificate struct breaks the ability to gob-encode the certificate.  
The following test program succeeds on go 1.21.6 and fails on 1.22.0:

package main

import (
"log"
"bytes"
"encoding/gob"
"crypto/x509"
"crypto/rsa"
"crypto/dsa"
"crypto/ecdh"
"crypto/ecdsa"
"crypto/ed25519"
)

func init() {
gob.Register(rsa.PrivateKey{})
gob.Register(dsa.PrivateKey{})
gob.Register(ecdh.PrivateKey{})
gob.Register(ecdsa.PrivateKey{})
gob.Register(ed25519.PrivateKey{})
gob.Register(rsa.PublicKey{})
gob.Register(dsa.PublicKey{})
gob.Register(ecdh.PublicKey{})
gob.Register(ecdsa.PublicKey{})
gob.Register(ed25519.PublicKey{})
}

func main() {
c := {}
b := {}

enc := gob.NewEncoder(b)
if err := enc.Encode(c); err != nil {
log.Printf("Failed to gob encode empty x.509 cert: %v", err)
} else {
log.Printf("Encoded empty x.509 cert")
}
}

It looks like the x509.OID type is not able to be marshalled by gob since 
it is a struct that contains a single unexported field, and it doesn't 
implement text or binary marshalling.

-- 
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/2a335349-3c9b-45b5-94d5-fb4f8c7edabcn%40googlegroups.com.

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Patricia Decker]

Thanks for that! Adding the additional HandleFunc for "/x/" does result in
a 200: https://go.dev/play/p/5upNoAhAlPs

On Thu, Feb 8, 2024 at 10:59 AM Kyle Shannon  wrote:

> On 2/8/24 11:30, Jason Phillips wrote:
>
> Can you create a small self-contained program that reproduces the issue?
> The following program returns 404 locally, as I'd expect, but does get
> killed in the Go playground: https://go.dev/play/p/FigBLK8KrAK
>
> Perhaps a simpler reproduction that's runnable on the playground:
>
> https://go.dev/play/p/gmQGJsyNCT6
>
> This returns 301 with a Location of /x/.  Note the trailing slash in the
> mux pattern, which was missing in your example.
>
>
> Perhaps there's an issue with the Playground networking implementation
> that's incompatible with the 1.22 changes?
>
> On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:
>
>> I haven't played around with it yet, but have you tried to separately
>> register /something/ ?
>>
>> mux := http.NewServeMux()
>> mux.HandleFunc("/something/", func...)
>> mux.HandleFunc("/something/{id}/{$}", func...)
>>
>> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
>>
>>> Hello,
>>>
>>> I noticed if you set up a route like /something/{id}/{$}, it results in
>>> an infinite loop if I navigate to /someting/ (with the trailing slash). I
>>> got a redirect to Location: /something/, and so on. Finally the page breaks
>>> after multiple rounds.
>>>
>>> Example:
>>> mux := http.NewServeMux()
>>> mux.HandleFunc("/something/{id}/{$}", func...))
>>>
>>> Should I raise and issue or am I doing something wrong here?
>>>
>>> Thanks,
>>> Peter
>>>
>> --
> 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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com
> 
> .
>
>
> --
> Kyle
>
> --
> 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/vbmvPMVhhjk/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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.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/CADeDRJJrdd%2BvuVOiqG1vy-FK0GW24GqxEmsioYxnUonKQPqupw%40mail.gmail.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin Schallnahs]

P.S.: According to the release notes of golang 1.22.0 the "go test -cover" 
was worked on, so thats why insist to find out if its a bug (and also 
because it prevents me from upgrading a project to golang 1.22.0 right now).

" go test -cover now prints coverage summaries for covered packages that do 
not have their own test files. Prior to Go 1.22 a go test -cover run for 
such a package would report"

On Thursday, February 8, 2024 at 6:11:15 PM UTC+1 Brian Candler wrote:

> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count || echo "flaky:$?"
> example.com/m: open 
> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> no such file or directory
>
> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
> -coverpkg=./internal/... -covermode count
> example.com/m: open 
> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> The system cannot find the file specified.
>
> Those look like the underlying errors causing the exit code 1. But it 
> works fine for me under both Linux and macOS, as long as I have "go 1.22.0" 
> in go.mod. Maybe someone who knows more about Windows can help?
>
> On Thursday 8 February 2024 at 17:03:18 UTC Martin Schallnahs wrote:
>
>> Hi Brian,
>>
>> thanks for checking out, yes that I wanted also to write you.
>> We need it currently in our CI as some dependency scanner tool does not 
>> work with the "go X.Y.Z." syntax, but I tried, and for my problem it did 
>> not was the cause.
>>
>>
>> > If a test fails, I would expect it to terminate with an error (exit 
>> code 1 in this case).
>>
>> See my second mail, the test case should not fail, it was kinda a typo 
>> (tried to shorten the reproducer to much in my first mail).
>>
>> > If I run your reproducer locally (not in Docker) with the modified 
>> TestHelloer, it works fine(*) and gives me an exit code of 0
>>
>> Yes, when I run it with golang 1.21.7 it works fine as well, as my 
>> problem statement is about golang 1.22.0.
>>
>> > Therefore, if your problem only occurs when using Docker, then you 
>> should provide a docker-based reproducer (including the Dockerfile)
>>
>> Happens locally as well. And in my original setup it was using a fresh 
>> docker container from golang (in an CI/GitLab pipeline) and did this:
>>
>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count || echo "flaky:$?"
>> example.com/m: open 
>> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> no such file or directory
>>
>> === RUN   TestHelloer
>> --- PASS: TestHelloer (0.00s)
>> PASS
>> coverage: 100.0% of statements in ./internal/...
>> ok   example.com/m/internal 0.004s coverage: 100.0% of statements in 
>> ./internal/...
>> flaky:1
>> $ go tool cover -html=coverage.out -o coverage.html
>> $ go tool cover -func=coverage.out
>> example.com/m/internal/helloer.go:3: Helloer 100.0%
>> total: (statements) 100.0%
>>
>>
>> But I just tried it locally (Windows) and there it happens as well:
>>
>> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
>> -coverpkg=./internal/... -covermode count
>> example.com/m: open 
>> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> The system cannot find the file specified.
>>
>> === RUN   TestHelloer
>> --- PASS: TestHelloer (0.00s)
>> PASS
>> coverage: 100.0% of statements in ./internal/...
>> ok  example.com/m/internal  15.260s coverage: 100.0% of statements 
>> in ./internal/...
>>
>>
>> So for now I checked it on:
>> - windows
>> - debian (via docker container)
>> - alpine (via docker container)
>>
>> All with 1.22.0.
>>
>> >  since you say that the coverage file is created, and presumably you 
>> would have noticed the "toolchain not available" error message. In any 
>> case, you're using a base image with go 1.22.0.
>>
>> Exactly.
>> As seen in the output above, further commands (go tool cover) using the 
>> coverage.out work fine.
>>
>> On Thursday 8 February 2024 at 10:46:44 UTC+1 Brian Candler wrote:
>>
>>> I found the solution to the "toolchain not available" problem: put "go 
>>> 1.22.0" instead of "go 1.22" in go.mod. Clues picked up from #62278 
>>> .
>>>
>>> It's confusing for people who've been using go for a while though, when 
>>> go.mod used to contain "go X.Y" and it was invalid to put "go X.Y.Z". Now 
>>> that appears to have swapped around 
>>> .
>>>
>>> On Thursday 8 February 2024 at 08:30:25 UTC Brian Candler wrote:
>>>
 Is it a bug or exepected behaviour?


 If a test fails, I would expect it to terminate with an error (exit 
 code 1 in this case).

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin Schallnahs]

Hey Brian,

dont get me wrong!

My usual setup is Continuous Integration Pipeline running in Linux VMs 
which, in case of my golang projects, start fresh golang docker container 
images from DockerHub.
In case of this problem I used golang:1.22.0-alpine3.19 and golang:1.22.0 
(debian basd).
For both I have the problem I describe.
I just wanted to show, that its not a Docker problem and used my local 
Windows machine do prove that.

I grabbed my Macbook Pro (Intel), installed freshly Golang 1.22.0 and run 
the mentioned go test command on the reproducer, and for me here the 
problem also gets triggered.
As you explained I use the corrected reproducer, with the Test not failing, 
and have "go 1.22.0" in the go.mod.


$ go version
go version go1.22.0 darwin/amd64
$ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
example.com/m: open 
/var/folders/dm/k73ydgtx15l7dzwc3qk_wmhcgn/T/go-build3097649140/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
no such file or directory
=== RUN TestHelloer
--- PASS: TestHelloer (0.00s)
PASS
coverage: 100.0% of statements in ./internal/...
ok example.com/m/internal 0.261s coverage: 100.0% of statements in 
./internal/…


Bit confusing, that it works for you though.
On Thursday, February 8, 2024 at 6:11:15 PM UTC+1 Brian Candler wrote:

> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count || echo "flaky:$?"
> example.com/m: open 
> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> no such file or directory
>
> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
> -coverpkg=./internal/... -covermode count
> example.com/m: open 
> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> The system cannot find the file specified.
>
> Those look like the underlying errors causing the exit code 1. But it 
> works fine for me under both Linux and macOS, as long as I have "go 1.22.0" 
> in go.mod. Maybe someone who knows more about Windows can help?
>
> On Thursday 8 February 2024 at 17:03:18 UTC Martin Schallnahs wrote:
>
>> Hi Brian,
>>
>> thanks for checking out, yes that I wanted also to write you.
>> We need it currently in our CI as some dependency scanner tool does not 
>> work with the "go X.Y.Z." syntax, but I tried, and for my problem it did 
>> not was the cause.
>>
>>
>> > If a test fails, I would expect it to terminate with an error (exit 
>> code 1 in this case).
>>
>> See my second mail, the test case should not fail, it was kinda a typo 
>> (tried to shorten the reproducer to much in my first mail).
>>
>> > If I run your reproducer locally (not in Docker) with the modified 
>> TestHelloer, it works fine(*) and gives me an exit code of 0
>>
>> Yes, when I run it with golang 1.21.7 it works fine as well, as my 
>> problem statement is about golang 1.22.0.
>>
>> > Therefore, if your problem only occurs when using Docker, then you 
>> should provide a docker-based reproducer (including the Dockerfile)
>>
>> Happens locally as well. And in my original setup it was using a fresh 
>> docker container from golang (in an CI/GitLab pipeline) and did this:
>>
>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count || echo "flaky:$?"
>> example.com/m: open 
>> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> no such file or directory
>>
>> === RUN   TestHelloer
>> --- PASS: TestHelloer (0.00s)
>> PASS
>> coverage: 100.0% of statements in ./internal/...
>> ok   example.com/m/internal 0.004s coverage: 100.0% of statements in 
>> ./internal/...
>> flaky:1
>> $ go tool cover -html=coverage.out -o coverage.html
>> $ go tool cover -func=coverage.out
>> example.com/m/internal/helloer.go:3: Helloer 100.0%
>> total: (statements) 100.0%
>>
>>
>> But I just tried it locally (Windows) and there it happens as well:
>>
>> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
>> -coverpkg=./internal/... -covermode count
>> example.com/m: open 
>> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>>  
>> The system cannot find the file specified.
>>
>> === RUN   TestHelloer
>> --- PASS: TestHelloer (0.00s)
>> PASS
>> coverage: 100.0% of statements in ./internal/...
>> ok  example.com/m/internal  15.260s coverage: 100.0% of statements 
>> in ./internal/...
>>
>>
>> So for now I checked it on:
>> - windows
>> - debian (via docker container)
>> - alpine (via docker container)
>>
>> All with 1.22.0.
>>
>> >  since you say that the coverage file is created, and presumably you 
>> would have noticed the "toolchain not available" error message. In any 
>> case, you're using a base image with go 1.22.0.
>>
>> Exactly.
>> As 

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Kyle Shannon]

On 2/8/24 11:30, Jason Phillips wrote:
Can you create a small self-contained program that reproduces the 
issue? The following program returns 404 locally, as I'd expect, but 
does get killed in the Go playground: https://go.dev/play/p/FigBLK8KrAK

Perhaps a simpler reproduction that's runnable on the playground:

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

This returns 301 with a Location of /x/.  Note the trailing slash in the 
mux pattern, which was missing in your example.


Perhaps there's an issue with the Playground networking implementation 
that's incompatible with the 1.22 changes?


On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:

I haven't played around with it yet, but have you tried to
separately register /something/ ?

mux := http.NewServeMux()
mux.HandleFunc("/something/", func...)
mux.HandleFunc("/something/{id}/{$}", func...)

On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas
wrote:

Hello,

I noticed if you set up a route like /something/{id}/{$}, it
results in an infinite loop if I navigate to /someting/ (with
the trailing slash). I got a redirect to Location:
/something/, and so on. Finally the page breaks after multiple
rounds.

Example:
mux := http.NewServeMux()
mux.HandleFunc("/something/{id}/{$}", func...))

Should I raise and issue or am I doing something wrong here?

Thanks,
Peter

--
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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com 
.


--
Kyle

--
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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.com.

[go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Jason Phillips]

Can you create a small self-contained program that reproduces the issue? 
The following program returns 404 locally, as I'd expect, but does get 
killed in the Go playground: https://go.dev/play/p/FigBLK8KrAK

Perhaps there's an issue with the Playground networking implementation 
that's incompatible with the 1.22 changes?

On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:

> I haven't played around with it yet, but have you tried to separately 
> register /something/ ?
>
> mux := http.NewServeMux()
> mux.HandleFunc("/something/", func...)
> mux.HandleFunc("/something/{id}/{$}", func...)
>
> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
>
>> Hello,
>>
>> I noticed if you set up a route like /something/{id}/{$}, it results in 
>> an infinite loop if I navigate to /someting/ (with the trailing slash). I 
>> got a redirect to Location: /something/, and so on. Finally the page breaks 
>> after multiple rounds.
>>
>> Example:
>> mux := http.NewServeMux()
>> mux.HandleFunc("/something/{id}/{$}", func...))
>>
>> Should I raise and issue or am I doing something wrong here?
>>
>> Thanks,
>> Peter
>>
>

-- 
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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

['Brian Candler' via golang-nuts]

$ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count || echo "flaky:$?"
example.com/m: open 
/tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
no such file or directory

C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
-coverpkg=./internal/... -covermode count
example.com/m: open 
C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
The system cannot find the file specified.

Those look like the underlying errors causing the exit code 1. But it works 
fine for me under both Linux and macOS, as long as I have "go 1.22.0" in 
go.mod. Maybe someone who knows more about Windows can help?

On Thursday 8 February 2024 at 17:03:18 UTC Martin Schallnahs wrote:

> Hi Brian,
>
> thanks for checking out, yes that I wanted also to write you.
> We need it currently in our CI as some dependency scanner tool does not 
> work with the "go X.Y.Z." syntax, but I tried, and for my problem it did 
> not was the cause.
>
>
> > If a test fails, I would expect it to terminate with an error (exit code 
> 1 in this case).
>
> See my second mail, the test case should not fail, it was kinda a typo 
> (tried to shorten the reproducer to much in my first mail).
>
> > If I run your reproducer locally (not in Docker) with the modified 
> TestHelloer, it works fine(*) and gives me an exit code of 0
>
> Yes, when I run it with golang 1.21.7 it works fine as well, as my problem 
> statement is about golang 1.22.0.
>
> > Therefore, if your problem only occurs when using Docker, then you 
> should provide a docker-based reproducer (including the Dockerfile)
>
> Happens locally as well. And in my original setup it was using a fresh 
> docker container from golang (in an CI/GitLab pipeline) and did this:
>
> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count || echo "flaky:$?"
> example.com/m: open 
> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> no such file or directory
>
> === RUN   TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
> coverage: 100.0% of statements in ./internal/...
> ok   example.com/m/internal 0.004s coverage: 100.0% of statements in 
> ./internal/...
> flaky:1
> $ go tool cover -html=coverage.out -o coverage.html
> $ go tool cover -func=coverage.out
> example.com/m/internal/helloer.go:3: Helloer 100.0%
> total: (statements) 100.0%
>
>
> But I just tried it locally (Windows) and there it happens as well:
>
> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
> -coverpkg=./internal/... -covermode count
> example.com/m: open 
> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
>  
> The system cannot find the file specified.
>
> === RUN   TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
> coverage: 100.0% of statements in ./internal/...
> ok  example.com/m/internal  15.260s coverage: 100.0% of statements in 
> ./internal/...
>
>
> So for now I checked it on:
> - windows
> - debian (via docker container)
> - alpine (via docker container)
>
> All with 1.22.0.
>
> >  since you say that the coverage file is created, and presumably you 
> would have noticed the "toolchain not available" error message. In any 
> case, you're using a base image with go 1.22.0.
>
> Exactly.
> As seen in the output above, further commands (go tool cover) using the 
> coverage.out work fine.
>
> On Thursday 8 February 2024 at 10:46:44 UTC+1 Brian Candler wrote:
>
>> I found the solution to the "toolchain not available" problem: put "go 
>> 1.22.0" instead of "go 1.22" in go.mod. Clues picked up from #62278 
>> .
>>
>> It's confusing for people who've been using go for a while though, when 
>> go.mod used to contain "go X.Y" and it was invalid to put "go X.Y.Z". Now 
>> that appears to have swapped around 
>> .
>>
>> On Thursday 8 February 2024 at 08:30:25 UTC Brian Candler wrote:
>>
>>> Is it a bug or exepected behaviour?
>>>
>>>
>>> If a test fails, I would expect it to terminate with an error (exit code 
>>> 1 in this case).
>>>
>>> If I run your reproducer locally (not in Docker) with the modified 
>>> TestHelloer, it works fine(*) and gives me an exit code of 0:
>>>
>>> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>>> -covermode count
>>> ?   example.com/m [no test files]
>>> === RUN   TestHelloer
>>> --- PASS: TestHelloer (0.00s)
>>> PASS
>>>
>>> coverage: 100.0% of statements in ./internal/...
>>> ok   example.com/m/internal 0.135s coverage: 100.0% of statements in 
>>> ./internal/...
>>> % echo $?
>>> 0
>>>
>>> Therefore, if your problem only occurs when using Docker, then you 
>>> should provide a 

[go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Patricia Decker]

I haven't played around with it yet, but have you tried to separately 
register /something/ ?

mux := http.NewServeMux()
mux.HandleFunc("/something/", func...)
mux.HandleFunc("/something/{id}/{$}", func...)

On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:

> Hello,
>
> I noticed if you set up a route like /something/{id}/{$}, it results in an 
> infinite loop if I navigate to /someting/ (with the trailing slash). I got 
> a redirect to Location: /something/, and so on. Finally the page breaks 
> after multiple rounds.
>
> Example:
> mux := http.NewServeMux()
> mux.HandleFunc("/something/{id}/{$}", func...))
>
> Should I raise and issue or am I doing something wrong here?
>
> Thanks,
> Peter
>

-- 
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/c4389c9a-6d46-4931-9ace-c4e77b67b00bn%40googlegroups.com.

[go-nuts] Re: How to determine system requirements for an application?

[Joao Silva]

Hi friend, did you manage to solve it, I was having the same problem as you.

Em sexta-feira, 3 de julho de 2020 às 06:59:04 UTC-3, smartaq...@gmail.com 
escreveu:

> Hello,
>
> If we make an application in golang then how to determine the system 
> requirements required for its flawless execution. 
>
> What are the parameters to justify the estimated values ​​of CPU and RAM, 
> especially for the application.exe built in Golang
>
> 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/d0c12bad-fd2b-49ed-bc2b-8d78d3646479n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin Schallnahs]

Hi Brian,

thanks for checking out, yes that I wanted also to write you.
We need it currently in our CI as some dependency scanner tool does not 
work with the "go X.Y.Z." syntax, but I tried, and for my problem it did 
not was the cause.


> If a test fails, I would expect it to terminate with an error (exit code 
1 in this case).

See my second mail, the test case should not fail, it was kinda a typo 
(tried to shorten the reproducer to much in my first mail).

> If I run your reproducer locally (not in Docker) with the modified 
TestHelloer, it works fine(*) and gives me an exit code of 0

Yes, when I run it with golang 1.21.7 it works fine as well, as my problem 
statement is about golang 1.22.0.

> Therefore, if your problem only occurs when using Docker, then you should 
provide a docker-based reproducer (including the Dockerfile)

Happens locally as well. And in my original setup it was using a fresh 
docker container from golang (in an CI/GitLab pipeline) and did this:

$ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count || echo "flaky:$?"
example.com/m: open 
/tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
no such file or directory
=== RUN   TestHelloer
--- PASS: TestHelloer (0.00s)
PASS
coverage: 100.0% of statements in ./internal/...
ok   example.com/m/internal 0.004s coverage: 100.0% of statements in 
./internal/...
flaky:1
$ go tool cover -html=coverage.out -o coverage.html
$ go tool cover -func=coverage.out
example.com/m/internal/helloer.go:3: Helloer 100.0%
total: (statements) 100.0%


But I just tried it locally (Windows) and there it happens as well:

C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out 
-coverpkg=./internal/... -covermode count
example.com/m: open 
C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
The system cannot find the file specified.
=== RUN   TestHelloer
--- PASS: TestHelloer (0.00s)
PASS
coverage: 100.0% of statements in ./internal/...
ok  example.com/m/internal  15.260s coverage: 100.0% of statements in 
./internal/...


So for now I checked it on:
- windows
- debian (via docker container)
- alpine (via docker container)

All with 1.22.0.

>  since you say that the coverage file is created, and presumably you 
would have noticed the "toolchain not available" error message. In any 
case, you're using a base image with go 1.22.0.

Exactly.
As seen in the output above, further commands (go tool cover) using the 
coverage.out work fine.

On Thursday 8 February 2024 at 10:46:44 UTC+1 Brian Candler wrote:

> I found the solution to the "toolchain not available" problem: put "go 
> 1.22.0" instead of "go 1.22" in go.mod. Clues picked up from #62278 
> .
>
> It's confusing for people who've been using go for a while though, when 
> go.mod used to contain "go X.Y" and it was invalid to put "go X.Y.Z". Now 
> that appears to have swapped around 
> .
>
> On Thursday 8 February 2024 at 08:30:25 UTC Brian Candler wrote:
>
>> Is it a bug or exepected behaviour?
>>
>>
>> If a test fails, I would expect it to terminate with an error (exit code 
>> 1 in this case).
>>
>> If I run your reproducer locally (not in Docker) with the modified 
>> TestHelloer, it works fine(*) and gives me an exit code of 0:
>>
>> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count
>> ?   example.com/m [no test files]
>> === RUN   TestHelloer
>> --- PASS: TestHelloer (0.00s)
>> PASS
>>
>> coverage: 100.0% of statements in ./internal/...
>> ok   example.com/m/internal 0.135s coverage: 100.0% of statements in 
>> ./internal/...
>> % echo $?
>> 0
>>
>> Therefore, if your problem only occurs when using Docker, then you should 
>> provide a docker-based reproducer (including the Dockerfile)
>>
>> (*) However, I had to change the go.mod file to say version 1.21.  If it 
>> says 1.22, I get an error.
>>
>> Under Linux (go1.21.7):
>>
>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count
>> go: downloading go1.22 (linux/amd64)
>> go: download go1.22 for linux/amd64: toolchain not available
>>
>> Under macOS (go1.21.6):
>>
>> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
>> -covermode count
>> go: downloading go1.22 (darwin/arm64)
>> go: download go1.22 for darwin/arm64: toolchain not available
>>
>> I don't *think* this is the same problem as you're seeing, since you say 
>> that the coverage file is created, and presumably you would have noticed 
>> the "toolchain not available" error message. In any case, you're using a 
>> base image with go 1.22.0.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop 

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

['Brian Candler' via golang-nuts]

I found the solution to the "toolchain not available" problem: put "go 
1.22.0" instead of "go 1.22" in go.mod. Clues picked up from #62278 
.

It's confusing for people who've been using go for a while though, when 
go.mod used to contain "go X.Y" and it was invalid to put "go X.Y.Z". Now 
that appears to have swapped around 
.

On Thursday 8 February 2024 at 08:30:25 UTC Brian Candler wrote:

> Is it a bug or exepected behaviour?
>
>
> If a test fails, I would expect it to terminate with an error (exit code 1 
> in this case).
>
> If I run your reproducer locally (not in Docker) with the modified 
> TestHelloer, it works fine(*) and gives me an exit code of 0:
>
> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> ?   example.com/m [no test files]
> === RUN   TestHelloer
> --- PASS: TestHelloer (0.00s)
> PASS
>
> coverage: 100.0% of statements in ./internal/...
> ok   example.com/m/internal 0.135s coverage: 100.0% of statements in 
> ./internal/...
> % echo $?
> 0
>
> Therefore, if your problem only occurs when using Docker, then you should 
> provide a docker-based reproducer (including the Dockerfile)
>
> (*) However, I had to change the go.mod file to say version 1.21.  If it 
> says 1.22, I get an error.
>
> Under Linux (go1.21.7):
>
> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> go: downloading go1.22 (linux/amd64)
> go: download go1.22 for linux/amd64: toolchain not available
>
> Under macOS (go1.21.6):
>
> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count
> go: downloading go1.22 (darwin/arm64)
> go: download go1.22 for darwin/arm64: toolchain not available
>
> I don't *think* this is the same problem as you're seeing, since you say 
> that the coverage file is created, and presumably you would have noticed 
> the "toolchain not available" error message. In any case, you're using a 
> base image with go 1.22.0.
>

-- 
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/9247783b-ea6f-43ed-9ba5-9384dd7e4e08n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

['Brian Candler' via golang-nuts]

Is it a bug or exepected behaviour?


If a test fails, I would expect it to terminate with an error (exit code 1 
in this case).

If I run your reproducer locally (not in Docker) with the modified 
TestHelloer, it works fine(*) and gives me an exit code of 0:

% go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
?   example.com/m [no test files]
=== RUN   TestHelloer
--- PASS: TestHelloer (0.00s)
PASS
coverage: 100.0% of statements in ./internal/...
ok   example.com/m/internal 0.135s coverage: 100.0% of statements in 
./internal/...
% echo $?
0

Therefore, if your problem only occurs when using Docker, then you should 
provide a docker-based reproducer (including the Dockerfile)

(*) However, I had to change the go.mod file to say version 1.21.  If it 
says 1.22, I get an error.

Under Linux (go1.21.7):

$ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
go: downloading go1.22 (linux/amd64)
go: download go1.22 for linux/amd64: toolchain not available

Under macOS (go1.21.6):

% go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
go: downloading go1.22 (darwin/arm64)
go: download go1.22 for darwin/arm64: toolchain not available

I don't *think* this is the same problem as you're seeing, since you say 
that the coverage file is created, and presumably you would have noticed 
the "toolchain not available" error message. In any case, you're using a 
base image with go 1.22.0.

-- 
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/9c635e17-c1a4-46d0-92a1-d553e1b503f4n%40googlegroups.com.

[go-nuts] Re: templates not working for me

[joseph.p...@gmail.com]

Ok,

Variable substitution doesn't seem to work in an included template file. Is 
that a known limitation?

On Saturday, February 3, 2024 at 11:40:40 PM UTC-8 joseph.p...@gmail.com 
wrote:

> I'm goofing around with GIN and trying some examples. I can't get 
> templating to work for me.
>
> File inclusion works, but variable substitution does not.
>
> GOLANG version 1.20.12
>
> package main
>
>
> import "github.com/gin-gonic/gin"
>
> import "net/http"
>
> // import "gorm.io/driver/sqlite"
>
> // import "gorm.io/gorm"
>
>
> func main() {
>
>
> server := gin.Default()
>
>
> server.Static("/stylesheets", "./")
>
>
> server.LoadHTMLGlob("templates/*.html")
>
>
> server.GET("/test", func(ctx *gin.Context) {
>
> ctx.JSON(200, gin.H{
>
> "message": "OK!!",
>
> })
>
> })
>
> server.GET("/temp", func(ctx *gin.Context) {
>
> ctx.HTML(http.StatusOK, "index.html", gin.H{
>
> "title": "Main website",
>
> "foo": "bar",
>
> })
>
> })
>
> server.GET("/index", func(ctx *gin.Context) {
>
> ctx.JSON(200, gin.H{
>
> "message": "OK!!",
>
> })
>
> })
>
> server.Run(":8080")
>
> }
>
> Specifically, opening a browser and accessing the /temp endpoint doesn't 
> change the title or print the text of 'foo'
>
> templates/header.html:
>
> 
>
>{{.title}}
>
>   
>
>https://cdn.jsdelivr.net/npm/boot...@5.3.2/dist/css/bootstrap.min.css 
> " 
> rel="stylesheet" 
> integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN"
>  
> crossorigin="anonymous">
>
>  
>
>
>  
>
>
>
> What's going on here?
>
>
>

-- 
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/897d8172-07e2-42f5-a06d-57885d41fc16n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin]

I need to add:

In the post the reproducer test is of course to short, so the test show 
that it fails all the time. But that triggers the problem anyway. Better 
would be this:

func TestHelloer(t *testing.T) {
  want := "Hello, world!"
  got := Helloer()
  if got != want {
t.Errorf("Helloer() = %v, want %v", got, want)
  }
}

Also, the output of the go test call has a inidication why it has exit 
status 1:

$ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count
example.com/m: open 
/tmp/go-build1679138031/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72:
 
no such file or directory
=== RUN   TestHelloer
helloer_test.go:8: Helloer() = Hello, world!, want Hello, world!
--- FAIL: TestHelloer (0.00s)
FAIL
coverage: 100.0% of statements in ./internal/...
FAILexample.com/m/internal0.003s


Also this happens with the Alpine based image, but also for the Debian 
based image as well.

On Thursday, February 8, 2024 at 12:43:32 AM UTC+1 Martin wrote:

> I am using the new `golang:1.22.0-alpine3.19` Alpine image to build and 
> test a Golang 1.22.0 application. The test uses coverage like that `go 
> test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count`. The test command seems to work fine, but the exit status 
> is 1. The created coverage.out seems also fine, as I could use go tool 
> cover with it, see below.
>
> Golang version: 1.22.0
> Container Image: golang:1.22.0-alpine3.19
>
> Reproducer:
>
> main.go:
> package main
>
> import (
>   "example.com/m/internal"
>   "fmt"
> )
>
> func main() {
>   fmt.Println(internal.Helloer())
> }
>
>
> internal/helloer.go:
> package internal
>
> func Helloer() string {
>   return "Hello, world!"
> }
>
> internal/helloer_test.go:
> package internal
>
> import "testing"
>
> func TestHelloer(t *testing.T) {
>   want := "Hello, world!"
>   got := Helloer()
>   t.Errorf("Helloer() = %v, want %v", got, want)
> }
>
> go.mod:
> module example.com/m
>
> go 1.22
>
> Shell commands for testing:
>
> apk add --no-cache build-base
> go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
> -covermode count || echo "flaky:$?"
> go tool cover -html=coverage.out -o coverage.html
> go tool cover -func=coverage.out
>
>
> Is it a bug or exepected behaviour?
>
>
>
>

-- 
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/c2fcc039-075e-4208-879e-5fdc11a0a18dn%40googlegroups.com.

Re: [go-nuts] Re: Changing PWD ruins test caching

[Kevin Burke]

Sorry for slow reply. We are using Alpine, which I don't think is either of
those flavors.

I discovered this by enabling GODEBUG=gocachehash=1, running the tests
twice, and then checking the diff between the two test runs.

On Tue, Nov 28, 2023 at 11:57 AM 'Bryan C. Mills' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> As far as I can tell the code in question is only built on AIX and OpenBSD
> — are you using one of those two platforms?
> If not, perhaps the caching problem is coming from somewhere else.
>
> That said, it does appear that calls to `os.Chdir` result in a spurious
> dependency on the PWD variable:
>
> https://cs.opensource.google/go/go/+/master:src/os/file.go;l=340-345;drc=d961b12be9001cf8dbf8f52847607dbf84d94f8d
>
> On Thursday, November 23, 2023 at 1:50:04 PM UTC-5 Kevin Burke wrote:
>
>> We have some tests that are pretty slow. I would like to use Go's test
>> caching to skip them in our CI environment, if nothing in the code or the
>> environment has changed. Our CI environment has a set of _agents_, each of
>> which can run multiple jobs simultaneously. As a result, they check out
>> code into a different directory each time they run a job.
>>
>> Go's test caching checks every env var loaded by the test program. If any
>> of them change, then Go assumes that the cache is busted and the test must
>> be run.
>>
>> Any program that imports "os" hits this logic in the os package, which
>> checks the value of the $PWD environment variable:
>>
>> // We query the working directory at init, to use it later to search for
>> the
>> // executable file
>> // errWd will be checked later, if we need to use initWd
>> var initWd, errWd = Getwd()
>>
>> So checking code out to different directories means that any program that
>> imports "os" cannot have test caching. This seems like a shame because the
>> code is all laid out in the same place in the working directory.
>>
>> Has anyone tried to fix this issue? Do you think this is worth trying to
>> patch or modify the test caching behavior in Go itself? I could solve this
>> by running a chroot or another layer of Docker, of course, but I'd prefer
>> not to do these because of the difficulty of getting data in and out of
>> each one, communicating with other Docker containers, etc.
>>
> --
> 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/74iG66JVA9s/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/9507e736-9d8a-4929-9812-3a89358a1cf3n%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/CAKcy5egYecGK8oSaB1xA439BPQ-BnCKi9vHpafe_qzRtQ_D%2B2w%40mail.gmail.com.

[go-nuts] Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin]

I am using the new `golang:1.22.0-alpine3.19` Alpine image to build and 
test a Golang 1.22.0 application. The test uses coverage like that `go test 
-v ./... -coverprofile=coverage.out -coverpkg=./internal/... -covermode 
count`. The test command seems to work fine, but the exit status is 1. The 
created coverage.out seems also fine, as I could use go tool cover with it, 
see below.

Golang version: 1.22.0
Container Image: golang:1.22.0-alpine3.19

Reproducer:

main.go:
package main

import (
  "example.com/m/internal"
  "fmt"
)

func main() {
  fmt.Println(internal.Helloer())
}


internal/helloer.go:
package internal

func Helloer() string {
  return "Hello, world!"
}

internal/helloer_test.go:
package internal

import "testing"

func TestHelloer(t *testing.T) {
  want := "Hello, world!"
  got := Helloer()
  t.Errorf("Helloer() = %v, want %v", got, want)
}

go.mod:
module example.com/m

go 1.22

Shell commands for testing:

apk add --no-cache build-base
go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... 
-covermode count || echo "flaky:$?"
go tool cover -html=coverage.out -o coverage.html
go tool cover -func=coverage.out


Is it a bug or exepected behaviour?



-- 
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/9fe031e4-7f3d-4508-b194-bd9074b3dcfcn%40googlegroups.com.

[go-nuts] 1.22.0 ServeMux HandleFunc infinite loop

[Péter Szarvas]

Hello,

I noticed if you set up a route like /something/{id}/{$}, it results in an 
infinite loop if I navigate to /someting/ (with the trailing slash). I got 
a redirect to Location: /something/, and so on. Finally the page breaks 
after multiple rounds.

Example:
mux := http.NewServeMux()
mux.HandleFunc("/something/{id}/{$}", func...))

Should I raise and issue or am I doing something wrong here?

Thanks,
Peter

-- 
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/a0126c12-9f79-4ad7-9352-18a3a03e5570n%40googlegroups.com.

Re: [go-nuts] Re: new range over int docs?

[Robert Griesemer]

On Wed, Feb 7, 2024 at 9:58 AM Jason E. Aten  wrote:

> Thanks Robert.  Succeess: I see the latest go1.22 spec now on
> https://go.dev/ref/spec
>
> Minor nit: As Rob pointed out, the year in the sub-title is off by one.
> (It says Jan 30, 2023, while almost surely the author of the update meant
> Jan 30, 2024).
>
The respective CL is pending submission (https://go.dev/cl/562320). Once
submitted it should fix the issue there as well.
Thanks.
- gri




>
> "The Go Programming Language Specification
> Language version go1.22 (Jan 30, 2023)" << 2024, no?
>
> On Wed, Feb 7, 2024 at 5:24 PM Robert Griesemer  wrote:
>
>> Spec is up-to-date at tip, now: https://tip.golang.org/ref/spec
>> https://golang.org/ref/spec should be updated soon, too.
>> Apologies for the confusion.
>> - gri
>>
>> On Wed, Feb 7, 2024 at 8:11 AM Jason E. Aten  wrote:
>>
>>> Thanks Peter.  I see the latest spec at tip.golang.org.
>>>
>>> p.s. Go Team: At least in the UK, the page served from
>>> https://go.dev/ref/spec   does not, at the moment, match that of
>>> https://tip.golang.org/ref/spec  , so somebody may need to do an update
>>> (if not of origin server, maybe of CDN caches?)
>>>
>>>
>>> On Wed, Feb 7, 2024 at 3:32 PM peterGo  wrote:
>>>
 Jason,

 As a temporary fix, try

 https://tip.golang.org/ref/spec#For_range

 Peter

 On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:

> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>
>> You are reading a specification dated Version of Aug 2, 2023. The
>> current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024
>> 10:08:15 PM EST.
>>
>
> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec,
> which is what the 1.22 release notes points to.
>
>
>
 --
 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/qGBpoyf1EB0/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/200fefc5-b0c0-4b4d-b876-b98b5795d35an%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/CAPNEFAZJqS3tPt0kBbbU6WuvLe0%3DhLqXdsRz9K22HCRGOhi21g%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/CAKy0tf4fRvvhP9RZ5d%2Bx2tjuHtpJnvWyys7tz_FqnXdKEczuSg%40mail.gmail.com.

[go-nuts] Re: Error on installing package

[Jason Phillips]

There's an application in the "internal/play" folder of that module. You 
can install it via:
  go install 154.pages.dev/google/internal/play@v1.4.0

As for how to use it, I have no idea, you'll have to reach out to the 
maintainer if there's no documentation.

On Wednesday, February 7, 2024 at 9:13:22 AM UTC-5 Smit K wrote:

> How to use this 154.pages.dev/goo...@v1.4.0 
> 
>
> On Tuesday, February 6, 2024 at 10:07:24 PM UTC+5:30 Jason Phillips wrote:
>
>> Perhaps you wanted "go get 154.pages.dev/goo...@v1.4.0 
>> "?
>>
>> On Tuesday, February 6, 2024 at 11:36:11 AM UTC-5 Jason Phillips wrote:
>>
>>> There's no Go package at the root of that repo/module, and thus nothing 
>>> to install. "go install" only works on main packages.
>>>
>>> On Tuesday, February 6, 2024 at 8:34:07 AM UTC-5 Smit K wrote:
>>>
 With this command: go install 154.pages.dev/goo...@v1.4.0 
 
 It is not installing: [image: Screenshot 2024-02-06 180047.png]
>>>
>>>

-- 
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/dc596563-7efb-4b62-b003-fd8c5b6acb70n%40googlegroups.com.

Re: [go-nuts] "yield" is backwards

[mspre...@gmail.com]

I see. I was thinking of it from the point of view of the author of this 
yield/consume function. From that party's perspective, this function 
expresses the consumption of the value, not its production. But since the 
new go lang feature will make that not an explicit function, that is not 
the most germane point of view.

(Yes, I know what Marvin mentioned.)

Thanks,
Mike

On Wednesday, February 7, 2024 at 1:18:00 PM UTC-5 Marvin Renich wrote:

> * mspre...@gmail.com  [240207 10:43]:
> > The go language is getting better and better for functional programming, 
> > and I am here for it. I have enjoyed using APL, Scheme, Python. I was 
> > excited to see https://go.dev/wiki/RangefuncExperiment . However, I am 
> > puzzled by the choice to name the function parameter that _receives_ a 
> > Seq's values "yield". That func does the _complement_ to "yield", it 
> > _receives_ the value. Compare with Python's "yield" statement, which 
> > _provides_ the value. Couldn't we call the func parameter that receives 
> a 
> > Seq's values something like "receive" or "consume"?
>
> In addition to what Axel said, note that "yield" is just an arbitrary
> function argument name; you may name it anything you choose. Try
> changing "yield" to "abc" and it will still work.
>
> ...Marvin
>
>

-- 
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/59e03cd0-9562-4359-ae28-d54bda412bbcn%40googlegroups.com.

Re: [go-nuts] "yield" is backwards

[Marvin Renich]

* mspre...@gmail.com  [240207 10:43]:
> The go language is getting better and better for functional programming, 
> and I am here for it. I have enjoyed using APL, Scheme, Python. I was 
> excited to see https://go.dev/wiki/RangefuncExperiment . However, I am 
> puzzled by the choice to name the function parameter that _receives_ a 
> Seq's values "yield". That func does the _complement_ to "yield", it 
> _receives_ the value. Compare with Python's "yield" statement, which 
> _provides_ the value. Couldn't we call the func parameter that receives a 
> Seq's values something like "receive" or "consume"?

In addition to what Axel said, note that "yield" is just an arbitrary
function argument name; you may name it anything you choose.  Try
changing "yield" to "abc" and it will still work.

...Marvin

-- 
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/ZcPJPw2X8IbABwpu%40basil.wdw.

[go-nuts] Re: Bound check optimization with "computed" index

['Keith Randall' via golang-nuts]

I'm not sure, but I suspect that the prove pass does not propagate known 
ranges through divides.

On Tuesday, February 6, 2024 at 7:39:56 AM UTC-8 Leonard Mittmann wrote:

> I am trying to optimize the loop performance by reducing the number of 
> bound checks. Inside the loop I compute a slice index and access two slice 
> indexes like this:
>
> j := i / 2
> s[j+1] = i
> s[j] = i // <- I want to get rid of this bound check
>
> I assumed that I can get rid of the second bound check, as the compiler 
> could already know that j+1 < len(s) and j >= 0. Am I missing something? 
> Any suggestions how to solve this?
>
> The full boiled down code to reproduce my issue is here: 
> https://go.godbolt.org/z/hsjPh3WT7
>

-- 
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/ab37e21f-0df2-49e5-a222-eb6dbb9cd12an%40googlegroups.com.

Re: [go-nuts] Re: new range over int docs?

[Jason E. Aten]

Thanks Robert.  Succeess: I see the latest go1.22 spec now on
https://go.dev/ref/spec

Minor nit: As Rob pointed out, the year in the sub-title is off by one. (It
says Jan 30, 2023, while almost surely the author of the update meant Jan
30, 2024).

"The Go Programming Language Specification
Language version go1.22 (Jan 30, 2023)" << 2024, no?

On Wed, Feb 7, 2024 at 5:24 PM Robert Griesemer  wrote:

> Spec is up-to-date at tip, now: https://tip.golang.org/ref/spec
> https://golang.org/ref/spec should be updated soon, too.
> Apologies for the confusion.
> - gri
>
> On Wed, Feb 7, 2024 at 8:11 AM Jason E. Aten  wrote:
>
>> Thanks Peter.  I see the latest spec at tip.golang.org.
>>
>> p.s. Go Team: At least in the UK, the page served from
>> https://go.dev/ref/spec   does not, at the moment, match that of
>> https://tip.golang.org/ref/spec  , so somebody may need to do an update
>> (if not of origin server, maybe of CDN caches?)
>>
>>
>> On Wed, Feb 7, 2024 at 3:32 PM peterGo  wrote:
>>
>>> Jason,
>>>
>>> As a temporary fix, try
>>>
>>> https://tip.golang.org/ref/spec#For_range
>>>
>>> Peter
>>>
>>> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>>>
 On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:

> You are reading a specification dated Version of Aug 2, 2023. The
> current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024
> 10:08:15 PM EST.
>

 Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec,
 which is what the 1.22 release notes points to.



>>> --
>>> 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/qGBpoyf1EB0/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/200fefc5-b0c0-4b4d-b876-b98b5795d35an%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/CAPNEFAZJqS3tPt0kBbbU6WuvLe0%3DhLqXdsRz9K22HCRGOhi21g%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/CAPNEFAYHcNNXDo0Mrhu9ZD6-N-Mh4CHd%2BiSujyh8egKwtxuQrQ%40mail.gmail.com.

Re: [go-nuts] Re: new range over int docs?

[Robert Griesemer]

Spec is up-to-date at tip, now: https://tip.golang.org/ref/spec
https://golang.org/ref/spec should be updated soon, too.
Apologies for the confusion.
- gri

On Wed, Feb 7, 2024 at 8:11 AM Jason E. Aten  wrote:

> Thanks Peter.  I see the latest spec at tip.golang.org.
>
> p.s. Go Team: At least in the UK, the page served from
> https://go.dev/ref/spec   does not, at the moment, match that of
> https://tip.golang.org/ref/spec  , so somebody may need to do an update
> (if not of origin server, maybe of CDN caches?)
>
>
> On Wed, Feb 7, 2024 at 3:32 PM peterGo  wrote:
>
>> Jason,
>>
>> As a temporary fix, try
>>
>> https://tip.golang.org/ref/spec#For_range
>>
>> Peter
>>
>> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>>
>>> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>>>
 You are reading a specification dated Version of Aug 2, 2023. The
 current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024
 10:08:15 PM EST.

>>>
>>> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec,
>>> which is what the 1.22 release notes points to.
>>>
>>>
>>>
>> --
>> 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/qGBpoyf1EB0/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/200fefc5-b0c0-4b4d-b876-b98b5795d35an%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/CAPNEFAZJqS3tPt0kBbbU6WuvLe0%3DhLqXdsRz9K22HCRGOhi21g%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/CAKy0tf4-RB_Qw%3DCxjGLGcns%2B_fQswDaPv3oav_0QKG1DpqMu3A%40mail.gmail.com.

Re: [go-nuts] "yield" is backwards

['Axel Wagner' via golang-nuts]

I'm not sure what you mean. The `yield` function does exactly the same as
Python's `yield` statement and in fact, that's part of why the name was
chosen.

Compare Python:

def vals(a):
for v in a:
yield v

for x in vals([1,2,3]):
print(x)

With Go:

func vals[T any](s []T) iter.Seq[T] {
return func(yield func(T) bool) {
for _, v := range s {
if !yield(v) { return }
}
}
}

func main() {
for v := range vals([]int{1,2,3}) {
fmt.Println(v)
}
}

Sure, there is a little bit more ceremony involved, as you need things to
be typed and need to return a closure. But ultimately, the generating
function (in Go, the closure) calls yield to… yield a value.

On Wed, Feb 7, 2024 at 4:43 PM mspre...@gmail.com 
wrote:

> The go language is getting better and better for functional programming,
> and I am here for it. I have enjoyed using APL, Scheme, Python. I was
> excited to see https://go.dev/wiki/RangefuncExperiment . However, I am
> puzzled by the choice to name the function parameter that _receives_ a
> Seq's values "yield". That func does the _complement_ to "yield", it
> _receives_ the value. Compare with Python's "yield" statement, which
> _provides_ the value. Couldn't we call the func parameter that receives a
> Seq's values something like "receive" or "consume"?
>
> Thanks,
> Mike
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/40005721-c187-48bf-b5c4-d66de2263185n%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/CAEkBMfF1mYn%3D1T52CJSnPdfsn8TQNWQKO_NMmnAAxeHXZgD77Q%40mail.gmail.com.

Re: [go-nuts] Re: new range over int docs?

[Jason E. Aten]

Thanks Peter.  I see the latest spec at tip.golang.org.

p.s. Go Team: At least in the UK, the page served from
https://go.dev/ref/spec   does not, at the moment, match that of
https://tip.golang.org/ref/spec  , so somebody may need to do an update (if
not of origin server, maybe of CDN caches?)


On Wed, Feb 7, 2024 at 3:32 PM peterGo  wrote:

> Jason,
>
> As a temporary fix, try
>
> https://tip.golang.org/ref/spec#For_range
>
> Peter
>
> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>
>> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>>
>>> You are reading a specification dated Version of Aug 2, 2023. The
>>> current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024
>>> 10:08:15 PM EST.
>>>
>>
>> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec,
>> which is what the 1.22 release notes points to.
>>
>>
>>
> --
> 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/qGBpoyf1EB0/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/200fefc5-b0c0-4b4d-b876-b98b5795d35an%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/CAPNEFAZJqS3tPt0kBbbU6WuvLe0%3DhLqXdsRz9K22HCRGOhi21g%40mail.gmail.com.

[go-nuts] "yield" is backwards

[mspre...@gmail.com]

The go language is getting better and better for functional programming, 
and I am here for it. I have enjoyed using APL, Scheme, Python. I was 
excited to see https://go.dev/wiki/RangefuncExperiment . However, I am 
puzzled by the choice to name the function parameter that _receives_ a 
Seq's values "yield". That func does the _complement_ to "yield", it 
_receives_ the value. Compare with Python's "yield" statement, which 
_provides_ the value. Couldn't we call the func parameter that receives a 
Seq's values something like "receive" or "consume"?

Thanks,
Mike

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

[go-nuts] Re: Error on installing package

[Smit K]

How to use this 154.pages.dev/google@v1.4.0

On Tuesday, February 6, 2024 at 10:07:24 PM UTC+5:30 Jason Phillips wrote:

> Perhaps you wanted "go get 154.pages.dev/goo...@v1.4.0 
> "?
>
> On Tuesday, February 6, 2024 at 11:36:11 AM UTC-5 Jason Phillips wrote:
>
>> There's no Go package at the root of that repo/module, and thus nothing 
>> to install. "go install" only works on main packages.
>>
>> On Tuesday, February 6, 2024 at 8:34:07 AM UTC-5 Smit K wrote:
>>
>>> With this command: go install 154.pages.dev/goo...@v1.4.0 
>>> 
>>> It is not installing: [image: Screenshot 2024-02-06 180047.png]
>>
>>

-- 
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/fdd25d21-e966-4dde-b60e-8995de152c85n%40googlegroups.com.

[go-nuts] Group Cache Behaviour

[Vallabh Chugh]

Hi folks, 
Fairly new to the k8s world. I am using group cache .I run a go routine to 
fetch all set of pods for a deployment and update my group cache pool if 
there is a change every 60 second. 
The problem i see is if that if there is a change in the pool (pods added) 
and if the incoming request goes to the newly added pod, sometimes it gives 
me a cache miss. and tries to reach the data source again. Is this normal? 
I was in the assumption that it should reach its peers 
The other strange thing is IT WORKS SOMETIMES, so is there a sync time 
needed? Sharing a small code snippet. 
Am i using pool.Set(podIPs...) in a wrong way?
func main() {
addr := os.Getenv("MY_POD_IP") + ":" + os.Getenv("MY_CONTAINER_PORT")
log.Println("Current Pod IP" + addr)
k8sClient, err := client.New(config.GetConfigOrDie(), client.Options{})
if err != nil {
panic(err)
}

namespace := "cache-poc"
var prevPodIPs []string
pool := groupcache.NewHTTPPool("http://; + addr)
// podIPs, err := getPodIPs(namespace, k8sClient)
// if err != nil {
// fmt.Println("Error getting pod IPs:", err)
// return
// }
// fmt.Println("Peers which are being set:", podIPs)
// pool.Set(podIPs...)

http.HandleFunc("/color", func(w http.ResponseWriter, r *http.Request) {
log.Println("Reached 1")
color := r.FormValue("name")
var b []byte
err := Group.Get(context.TODO(), color, groupcache.AllocatingByteSliceSink(&
b))
if err != nil {
http.Error(w, err.Error(), http.StatusNotFound)
return
}
w.Write(b)
w.Write([]byte{'\n'})
})

go func() {
for {
podIPs, err := getPodIPs(namespace, k8sClient)
if err != nil {
fmt.Println("Error getting pod IPs:", err)
return
}
if !reflect.DeepEqual(podIPs, prevPodIPs) {
fmt.Println("Pod IPs have changed:")
// Print or process the changes here
pool.Set(podIPs...)
prevPodIPs = podIPs
} else {
fmt.Println("No changes in Pod IPs.")
}

log.Printf("Pod IPs: %v\n", podIPs)

time.Sleep(60 * time.Second)
}

}()

http.HandleFunc("/set", setHandler)
//http.HandleFunc("/get", getHandler)
http.HandleFunc("/ack", ackMessage)

err = http.ListenAndServe(addr, nil)
if err != nil {
fmt.Println("Error starting server:", err)
}
}

-- 
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/4c082c51-b32e-4508-a3da-4be3cd577724n%40googlegroups.com.

Re: [go-nuts] Re: new range over int docs?

[peterGo]

Jason,

File an issue with the Go release team to clean up the mess.

Peter

On Wednesday, February 7, 2024 at 7:12:08 AM UTC-5 Brian Candler wrote:

> But the main point is, the canonical version published at 
> https://go.dev/ref/spec is still from Aug 2, 2023
>
> On Wednesday 7 February 2024 at 12:02:28 UTC Rob Pike wrote:
>
>> Ha ha, someone forgot to change the year. It should read Jan 30, 2024.
>>
>> That's confusing.
>>
>> -rob
>>
>>
>> On Wed, Feb 7, 2024 at 8:47 PM peterGo  wrote:
>>
>>> Jason,
>>>
>>> The Go 1.22 source code says:
>>>
>>> "Subtitle": "Language version go1.22 (Jan 30, 2023)",
>>>
>>> Blame
>>>
>>> #569 9289b9c gri@*.*** 2024-01-31 16:40
>>> [release-branch.go1.22] spec: clarify iteration variable type for range 
>>> over integer
>>> Change-Id: I4f1d220d5922c40a36264df2d0a7bb7cd0756bac
>>>
>>>
>>> https://cs.opensource.google/go/go/+/release-branch.go1.22:doc/go_spec.html
>>>
>>> I consider the Go source code to be the truth.
>>>
>>> What are you looking at?
>>>
>>> Peter
>>>
>>>
>>> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>>>
 On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:

> You are reading a specification dated Version of Aug 2, 2023. The 
> current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 
> 10:08:15 PM EST.
>

 Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, 
 which is what the 1.22 release notes points to.

  

>>> -- 
>>> 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/0e4fa760-1259-4b9c-9ff6-b60ba34413ccn%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/b93dbee9-9f61-4f85-96db-c79bb246b68dn%40googlegroups.com.

Re: [go-nuts] Re: Do we need to call multipart.Part.Close

[Pedro Luis Guzmán Hernández]

Thanks all,

I'll continue to call it for now, since that's what most engineers on my 
team would expect in that situation, but I'll happily reconsider if some 
documentation gets added at some point.

El miércoles, 7 de febrero de 2024 a las 0:44:13 UTC+1, Ian Lance Taylor 
escribió:

> On Tue, Feb 6, 2024 at 6:29 AM Pedro Luis Guzmán Hernández
>  wrote:
> >
> > Thanks Brian. That is an implementation detail though, so relying on it 
> with no mention in the documentation at all feels unsound. A Close method 
> usually means you have to defer it right after getting the resource, so I 
> would have expected the docs to be more clarifying on its usage.
>
> Yeah, the Close method doesn't seem to be documented at all. It would
> be nice if somebody sent a patch. Looks to me like you don't ever
> have to call Close, and that it should probably not have been
> exported. It is called by Reader.nextPart, and I don't immediately
> see any reason for it to be called anywhere else.
>
> Ian
>
>
> > El martes, 6 de febrero de 2024 a las 15:11:55 UTC+1, Brian Candler 
> escribió:
> >>
> >> 
> https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325
> >>
> >> All it does is read all the remainder of the part to io.Discard. So if 
> you're sure you've read each part before moving onto the next one, it looks 
> like you should be good.
> >>
> >> On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández 
> wrote:
> >>>
> >>> multipart.Part, returned by multipart.Reader's NextPart method, have a 
> Close() method. The only example here 
> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() 
> method at all, so what's it purpose? Can we safely ignore it?
> >>>
> >>> The reason I'm asking is that, calling defer part.Closer is a bit 
> annoying when you loop through a Reader (see the example mentioned above). 
> Calling the defer within the loop means all parts are closed at the end of 
> the function. The alternative would be to have an anonymous function within 
> the loop and call defer within it, but it feels so awkward.
> >
> > --
> > 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/6371b366-8474-46f0-99bc-510471fb879bn%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/782d4fcc-4c84-4680-800a-e84602a41584n%40googlegroups.com.

Re: [go-nuts] Re: new range over int docs?

['Brian Candler' via golang-nuts]

But the main point is, the canonical version published 
at https://go.dev/ref/spec is still from Aug 2, 2023

On Wednesday 7 February 2024 at 12:02:28 UTC Rob Pike wrote:

> Ha ha, someone forgot to change the year. It should read Jan 30, 2024.
>
> That's confusing.
>
> -rob
>
>
> On Wed, Feb 7, 2024 at 8:47 PM peterGo  wrote:
>
>> Jason,
>>
>> The Go 1.22 source code says:
>>
>> "Subtitle": "Language version go1.22 (Jan 30, 2023)",
>>
>> Blame
>>
>> #569 9289b9c gri@*.*** 2024-01-31 16:40
>> [release-branch.go1.22] spec: clarify iteration variable type for range 
>> over integer
>> Change-Id: I4f1d220d5922c40a36264df2d0a7bb7cd0756bac
>>
>>
>> https://cs.opensource.google/go/go/+/release-branch.go1.22:doc/go_spec.html
>>
>> I consider the Go source code to be the truth.
>>
>> What are you looking at?
>>
>> Peter
>>
>>
>> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>>
>>> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>>>
 You are reading a specification dated Version of Aug 2, 2023. The 
 current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 
 10:08:15 PM EST.

>>>
>>> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, 
>>> which is what the 1.22 release notes points to.
>>>
>>>  
>>>
>> -- 
>> 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/0e4fa760-1259-4b9c-9ff6-b60ba34413ccn%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/530cc20c-3125-42bc-87c7-906d9d7e31cen%40googlegroups.com.

Re: [go-nuts] Re: new range over int docs?

[Rob Pike]

Ha ha, someone forgot to change the year. It should read Jan 30, 2024.

That's confusing.

-rob


On Wed, Feb 7, 2024 at 8:47 PM peterGo  wrote:

> Jason,
>
> The Go 1.22 source code says:
>
> "Subtitle": "Language version go1.22 (Jan 30, 2023)",
>
> Blame
>
> #569 9289b9c gri@*.*** 2024-01-31 16:40
> [release-branch.go1.22] spec: clarify iteration variable type for range
> over integer
> Change-Id: I4f1d220d5922c40a36264df2d0a7bb7cd0756bac
>
> https://cs.opensource.google/go/go/+/release-branch.go1.22:doc/go_spec.html
>
> I consider the Go source code to be the truth.
>
> What are you looking at?
>
> Peter
>
>
> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>
>> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>>
>>> You are reading a specification dated Version of Aug 2, 2023. The
>>> current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024
>>> 10:08:15 PM EST.
>>>
>>
>> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec,
>> which is what the 1.22 release notes points to.
>>
>>
>>
> --
> 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/0e4fa760-1259-4b9c-9ff6-b60ba34413ccn%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/CAOXNBZQuLGgeWwDW4eb60Qd1W-%2B2HPPbGWU5tQXjg8kiE-tktw%40mail.gmail.com.

Re: [go-nuts] Re: new range over int docs?

[peterGo]

Jason,

The Go 1.22 source code says:

"Subtitle": "Language version go1.22 (Jan 30, 2023)",

Blame

#569 9289b9c gri@*.*** 2024-01-31 16:40
[release-branch.go1.22] spec: clarify iteration variable type for range 
over integer
Change-Id: I4f1d220d5922c40a36264df2d0a7bb7cd0756bac

https://cs.opensource.google/go/go/+/release-branch.go1.22:doc/go_spec.html

I consider the Go source code to be the truth.

What are you looking at?

Peter


On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:

> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>
>> You are reading a specification dated Version of Aug 2, 2023. The current 
>> specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM 
>> EST.
>>
>
> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, 
> which is what the 1.22 release notes points to.
>
>  
>

-- 
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/0e4fa760-1259-4b9c-9ff6-b60ba34413ccn%40googlegroups.com.

Re: [go-nuts] Re: new range over int docs?

[Jason E. Aten]

On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:

> You are reading a specification dated Version of Aug 2, 2023. The current
> specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM
> EST.
>

Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, which
is what the 1.22 release notes points to.

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

[go-nuts] Re: new range over int docs?

[peterGo]

Jason,

The Go specification "Length and capacity" section defines the len built-in 
function.

Peter

On Tuesday, February 6, 2024 at 11:36:21 PM UTC-5 peterGo wrote:

> Jason,
>
> The Go 1.22 specification, in part,
>
> For statements with range clause
>
> A "for" statement with a "range" clause iterates through all entries of an 
> array, slice, string or map, values received on a channel, or integer 
> values from zero to an upper limit [Go 1.22].
>
> For an integer value n, the iteration values 0 through n-1 are produced in 
> increasing order. If n <= 0, the loop does not run any iterations. 
>
> Peter
>
> On Tuesday, February 6, 2024 at 10:34:07 PM UTC-5 peterGo wrote:
>
>> Jason,
>>
>> The Go Programming Language Specification is reference documentation. It 
>> is intended to be read very carefully in its entirety.
>>
>> You are reading a specification dated Version of Aug 2, 2023. The current 
>> specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM 
>> EST.
>>
>> The specification has always said that len(10) is not somehow defined: 
>> "invalid 
>> argument: 10 (untyped int constant) for len".
>>
>> Peter
>>
>> On Tuesday, February 6, 2024 at 8:41:38 PM UTC-5 Jason E. Aten wrote:
>>
>>> The release notes https://go.dev/doc/go1.22 refer to the spec here
>>>
>>> https://go.dev/ref/spec#For_range
>>>
>>> but I do not see any details about the new for i := range 10 statement 
>>> there.
>>>
>>> This is strange. Have the docs simply not been updated yet?
>>>
>>> But I do see this oddly out of place statement, where I'm not sure at 
>>> all what x is referring to in the earlier paragraphs.
>>>
>>> "The range expression x is evaluated once before beginning the loop, 
>>> with one exception: if at most one iteration variable is present and 
>>> len(x) is constant , the 
>>> range expression is not evaluated."
>>>
>>> This would seem to say that, if x is the integer 10, as in the above 
>>> example, and if the len(10) is somehow defined (not sure it would be, but a 
>>> new reader might reasonably assume that an integer has constant length), 
>>> that the range expression would not be evaluated... which seems very odd. 
>>> I'm not sure what this sentence is talking about at all really.
>>>
>>

-- 
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/8b5ba931-2782-4538-bac2-78c5be735e33n%40googlegroups.com.

[go-nuts] Re: new range over int docs?

[peterGo]

Jason,

The Go 1.22 specification, in part,

For statements with range clause

A "for" statement with a "range" clause iterates through all entries of an 
array, slice, string or map, values received on a channel, or integer 
values from zero to an upper limit [Go 1.22].

For an integer value n, the iteration values 0 through n-1 are produced in 
increasing order. If n <= 0, the loop does not run any iterations. 

Peter

On Tuesday, February 6, 2024 at 10:34:07 PM UTC-5 peterGo wrote:

> Jason,
>
> The Go Programming Language Specification is reference documentation. It 
> is intended to be read very carefully in its entirety.
>
> You are reading a specification dated Version of Aug 2, 2023. The current 
> specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM 
> EST.
>
> The specification has always said that len(10) is not somehow defined: 
> "invalid 
> argument: 10 (untyped int constant) for len".
>
> Peter
>
> On Tuesday, February 6, 2024 at 8:41:38 PM UTC-5 Jason E. Aten wrote:
>
>> The release notes https://go.dev/doc/go1.22 refer to the spec here
>>
>> https://go.dev/ref/spec#For_range
>>
>> but I do not see any details about the new for i := range 10 statement 
>> there.
>>
>> This is strange. Have the docs simply not been updated yet?
>>
>> But I do see this oddly out of place statement, where I'm not sure at all 
>> what x is referring to in the earlier paragraphs.
>>
>> "The range expression x is evaluated once before beginning the loop, 
>> with one exception: if at most one iteration variable is present and 
>> len(x) is constant , the 
>> range expression is not evaluated."
>>
>> This would seem to say that, if x is the integer 10, as in the above 
>> example, and if the len(10) is somehow defined (not sure it would be, but a 
>> new reader might reasonably assume that an integer has constant length), 
>> that the range expression would not be evaluated... which seems very odd. 
>> I'm not sure what this sentence is talking about at all really.
>>
>

-- 
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/9dc3110b-a6a6-4db5-822c-b891be214982n%40googlegroups.com.

[go-nuts] Re: new range over int docs?

[peterGo]

Jason,

The Go Programming Language Specification is reference documentation. It is 
intended to be read very carefully in its entirety.

You are reading a specification dated Version of Aug 2, 2023. The current 
specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM 
EST.

The specification has always said that len(10) is not somehow defined: "invalid 
argument: 10 (untyped int constant) for len".

Peter

On Tuesday, February 6, 2024 at 8:41:38 PM UTC-5 Jason E. Aten wrote:

> The release notes https://go.dev/doc/go1.22 refer to the spec here
>
> https://go.dev/ref/spec#For_range
>
> but I do not see any details about the new for i := range 10 statement 
> there.
>
> This is strange. Have the docs simply not been updated yet?
>
> But I do see this oddly out of place statement, where I'm not sure at all 
> what x is referring to in the earlier paragraphs.
>
> "The range expression x is evaluated once before beginning the loop, with 
> one exception: if at most one iteration variable is present and len(x) is 
> constant , the range 
> expression is not evaluated."
>
> This would seem to say that, if x is the integer 10, as in the above 
> example, and if the len(10) is somehow defined (not sure it would be, but a 
> new reader might reasonably assume that an integer has constant length), 
> that the range expression would not be evaluated... which seems very odd. 
> I'm not sure what this sentence is talking about at all really.
>

-- 
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/4a4017cd-a312-4129-b302-9ed68beef4c4n%40googlegroups.com.