Re: [go-nuts] go test cache: include umask as a test input for caching?

[Ian Lance Taylor]

On Tue, Sep 17, 2024 at 4:08 AM twp...@gmail.com  wrote:
>
> However, I want to make go test cache's behavior more correct for a case 
> where it is currently incorrect for no measurable performance penalty. What 
> are the reasons for *not* doing this?

We do not want to record all aspects of the external environment that
could possibly affect the test.  That would be too much.  So we need
some way to know what should be recorded and what should not.  What
should that be?  Our current approach is simple: we record environment
variables that the test reads and we record files opened within the
module but not files opened outside of the module.  Note that if a
test opens some file outside of the module, we cache the test results
even if that file changes.

What approach should we use for test caching that will tell us that
umask should be cached?

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/CAOyqgcWFnA_T3QTq%3DHQ67MhP---OEzNU5-nsnVMd_PYRNZkNLQ%40mail.gmail.com.

Re: [go-nuts] go test cache: include umask as a test input for caching?

[Ian Lance Taylor]

On Tue, Sep 17, 2024 at 3:26 AM twp...@gmail.com  wrote:
>
> > Should work, AIUI, even with the issues you mention. Or is there something 
> > else going on that I'm unaware of?
>
> The problem is not running the tests. The problem is that the test cache is 
> not invalidated correctly.

We are suggesting that you change the umask in the test itself.

This is perfectly reliable as tests are not run in parallel (unless
you explicitly call t.Parallel).  The umask will not affect any code
other than the test code itself.

You can see an example of this in the Go standard library:
https://go.googlesource.com/go/+/refs/heads/master/src/os/os_unix_test.go#231

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/CAOyqgcVqeK7A%3DYTvZnZEVK0XNCrzM7%2BXDqCKw0PXqcPZKSUFgg%40mail.gmail.com.

Re: [go-nuts] go test cache: include umask as a test input for caching?

[Ian Lance Taylor]

On Fri, Sep 13, 2024 at 3:03 PM twp...@gmail.com  wrote:
>
> tl;dr: umask is a system-wide global that affects go tests and should be 
> considered when validating go test's cache.
>
>
> Motivation:
>
> I'm the author of a popular open source project that writes files to the 
> user's home directory and cares about getting exact file permissions correct. 
> The file permissions depend on the the current umask setting. As umask is a 
> process global variable, it cannot be set for individual tests, and so 
> separate tests are needed for different umasks.
>
> Currently changing the umask does not invalidate go test's cache, so I get 
> incorrect test results if I change the umask and re-run go test.
>
>
> Suggested solution:
>
> Include umask as an op in go test's id calculation.
>
>
> Next steps:
>
> * Is this something that the Go project would consider?
> * If so, I would be happy to submit a CL.

Personally, I would approach this kind of thing by writing a test that
sets the umask to various different values and invokes subtests with
each umask value.  That way the test is independent of the external
environment.

In general our approach has been that if your test intrinsically
depends on the external environment, then you should run it with
-test.run=1 to disable the test cache.

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/CAOyqgcXLcoQ95EzKD%3DyUtkSxf3Yu%2BWAoKS6j5c20dko7HcjfzQ%40mail.gmail.com.

Re: [go-nuts] Can a golang program be compiled to run with only ONE goroutine ?

[Ian Lance Taylor]

On Tue, Sep 10, 2024 at 6:54 AM 'Karolina GORNA' via golang-nuts
 wrote:
>
> Maybe the question has already been asked, but I would be glad to have your 
> feedback.
>
> Can a golang program be compiled to run with only one goroutine, or at least 
> one "OS thread" ?
>
> I am aware of using GOMAXPROCS(1) to have only one "OS thread" or to use 
> taskset -c 1 go build . to force having one "OS thread". These commands don't 
> really work in practice, since with trace execution tools, I can see that 
> many threads are used during the execution at the end.

For the standard Go implementation, no, this is not possible.  Go is
inherently multi-threaded.

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/CAOyqgcVqq%3DyBofB8J5gr1oQFLbMdb-__LK8jdnzhKx3zDP4wGg%40mail.gmail.com.

Re: [go-nuts] Re: Question about adding new feature to go (FreeBSD/netlink) and compliation

[Ian Lance Taylor]

On Fri, Sep 6, 2024 at 7:42 AM Martin Stiemerling
 wrote:
>
> I just wanted to get back to this and probably ask somebody out of the go 
> core team, if you guys have recently used the mkall.sh script under 
> src/syscall for freebsd/amd64?

No, we haven't.  The syscall package is all-but-frozen.  Only
unavoidable changes are made to it.  Those changes are generally made
manually.

Most programs should be using the golang.org/x/sys packages instead.
Those regeneration scripts are in better shape.

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/CAOyqgcUcqui5WrOmDnaCNs-4ZhwVZx8zcSX_s3nA8pscb1%2Bjvw%40mail.gmail.com.

Re: [go-nuts] Question about adding new feature to go (FreeBSD/netlink) and compliation

[Ian Lance Taylor]

On Tue, Sep 3, 2024 at 10:07 AM Martin Stiemerling
 wrote:
>
>
>
> > Am 03.09.2024 um 18:50 schrieb Ian Lance Taylor :
> >
> > On Tue, Sep 3, 2024 at 9:03 AM Martin Stiemerling
> >  wrote:
> >>
> >> FreeBSD has since a while also support for the netlink facility, similar 
> >> to Linux. For Linux there is support in go via the syscall pkg for working 
> >> with Linux's netlink, but not yet for FreeBSD
> >>
> >> I have started to add the FreeBSD part to go's syscall package and fixed 
> >> some errors, but run into troubles when compiling go. Though my approach 
> >> is by now copying a lot form syscall_linux, as a first naive approach. :-)
> >>
> >> When using make.bash these steps work:
> >> Building Go cmd/dist using /usr/local/go122. (go1.22.6 freebsd/amd64)
> >> Building Go toolchain1 using /usr/local/go122.
> >> Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1
> >>
> >> However, after "Building Go toolchain2 using go_bootstrap and Go 
> >> toolchain1" this error turns out:
> >> "go: cannot find GOROOT directory: /home/mls/goworks
> >> go tool dist: FAILED: 
> >> /home/mls/goworks/pkg/tool/freebsd_amd64/go_bootstrap install -pgo=off 
> >> cmd/asm cmd/cgo cmd/compile cmd/link cmd/preprofile: exit status 2"
> >
> > Where does the directory /home/mls/goworks come from?  Does it exist?
>
> /home/mls/goworks exists and under /home/mls/goworks/src is the go source 
> code.
>
> >
> > Do you have GOROOT set in the environment?
>
> Nope, no environment set, as described under 
> https://go.dev/doc/install/source#environment.
>
> Interestingly does the whole process just run through, with the same setting, 
> i.e., no GOROOT set, without my modifications (master branch).
>
> I guess something goes wrong and the binaries under /home/mls/goworks/bin are 
> not generated.
>
> Thus the assumed GOROOT of the build process, i.e., /home/mls/goworks and 
> $GOROOT/bin, doesn’t work.
>
> However, I cannot see any error message or warning...

Thanks.  My conclusion is that this must have something to do with
your changes.  I saw that you posted your complete tree, but is there
an easy way to see only what you changed?

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

Re: [go-nuts] Question about adding new feature to go (FreeBSD/netlink) and compliation

[Ian Lance Taylor]

On Tue, Sep 3, 2024 at 9:03 AM Martin Stiemerling
 wrote:
>
> FreeBSD has since a while also support for the netlink facility, similar to 
> Linux. For Linux there is support in go via the syscall pkg for working with 
> Linux's netlink, but not yet for FreeBSD
>
> I have started to add the FreeBSD part to go's syscall package and fixed some 
> errors, but run into troubles when compiling go. Though my approach is by now 
> copying a lot form syscall_linux, as a first naive approach. :-)
>
> When using make.bash these steps work:
> Building Go cmd/dist using /usr/local/go122. (go1.22.6 freebsd/amd64)
> Building Go toolchain1 using /usr/local/go122.
> Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1
>
> However, after "Building Go toolchain2 using go_bootstrap and Go toolchain1" 
> this error turns out:
> "go: cannot find GOROOT directory: /home/mls/goworks
> go tool dist: FAILED: /home/mls/goworks/pkg/tool/freebsd_amd64/go_bootstrap 
> install -pgo=off cmd/asm cmd/cgo cmd/compile cmd/link cmd/preprofile: exit 
> status 2"

Where does the directory /home/mls/goworks come from?  Does it exist?

Do you have GOROOT set in the environment?

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/CAOyqgcXxSys1KkjvNCRtOV-F%3DXVRDhN_bvvzuJDV_K5wr_DQOg%40mail.gmail.com.

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

[Ian Lance Taylor]

On Sun, Sep 1, 2024 at 1:08 AM Mike Schinkel  wrote:
>
> Ian — if you are reading this — does this rise enough to the level of a bug — 
> checking imports on a `go fmt` — that I should submit as an issue on GitHub?

This is, perhaps unfortunately, expected behavior.

The "go fmt" command is the "fmt" subcommand of the "go" command.  It
takes a list of packages.  If no package is listed, it applies to the
current directory.  Because it is part of the "go" command, it looks
at imports, finds packages, and does other things that the "go"
command does.  The docs are at
https://pkg.go.dev/cmd/go#hdr-Gofmt__reformat__package_sources.

The "gofmt" command is a simpler command that formats one or more
source files.  If no source files are listed, it reads a Go file on
standard input and emits the formatted version on standard output.
The "gofmt" command is invoked by "go fmt".  The "gofmt" command has
more options than the "go fmt" command, but on the other hand it won't
find packages for you.  The docs are at https://pkg.go.dev/cmd/gofmt.

This has been discussed before, for example
https://groups.google.com/g/golang-nuts/c/t-tSHt8RG-4,
https://go.dev/issue/33263, https://go.dev/issue/35258.

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

Re: [go-nuts] Iterators

[Ian Lance Taylor]

On Mon, Sep 2, 2024 at 4:36 PM vignes waran
 wrote:
>
> I have been trying to understand the concept of iterators introduced in the 
> new Go 1.23 release, but I’m struggling to comprehend how the iteration call 
> happens multiple times and where the boolean value for stopping the loop is 
> obtained. Here’s my code snippet for reference:
>
> package main
>
> import "fmt"
>
> func Countdown(v int) func(func(int) bool) {
> fmt.Println("v :", v) // This function runs only one time
> return func(f func(int) bool) {
> for i := v; i >= 0; i-- {
> if !f(i) {
> return
> }
> }
> }
> }
>
> func main() {
> // fmt.Println("Countdown :", Countdown(2))
> for x := range Countdown(2) {
> fmt.Println(x)
> }
> }
>
> I appreciate any help in understanding this concept better. Thanks in 
> advance!"

The compiler wraps the loop body into a function closure, more or less like:

func $loop(x int) bool {
fmt.Println(x)
return true
}

It then changes the for statement into Countdown(2)($loop).

For many more details, which are approximately but not precisely what
the Go 1.23 compiler does, see https://research.swtch.com/coro.

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/CAOyqgcUDTvH--O%3DYYmoC38e4Fcta76sZbU1GHDfyW2Y_eBCwww%40mail.gmail.com.

Re: [go-nuts] Concatenate iterators

[Ian Lance Taylor]

On Fri, Aug 30, 2024 at 10:33 AM costin  wrote:
>
> Is there a way to concatenate 2 iterators (other than writing my own 
> function)? There isn't any std function I could find. Would such a function 
> belong in the iter package (slices seems like the wrong place)?

It would probably start out in x/exp/xiters.

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/CAOyqgcWvobdqN9w8RxvgMdWFn4W4uuyKH2iRU2-Cy7z%3DkyJuMA%40mail.gmail.com.

Re: [go-nuts] Dialer and Named Services: clarification

[Ian Lance Taylor]

On Wed, Aug 28, 2024 at 6:08 AM Yinebeb Tariku  wrote:
>
> I've been diving into the Go standard library's net package and have some 
> questions about the Dialer function and named services.
>
> 1. Where exactly does Go perform the mapping between a service name (e.g., 
> "http") and its corresponding port number (e.g., 80)?

There are two places, depending on whether the program is using the Go
resolver or the cgo resolver (see https://pkg.go.dev/net for a
discussion of the different resolvers).

On Unix systems, the Go resolver reads the /etc/services file in the
readServices function in net/port_unix.go.  It looks up entries in the
goLookupPort function.  The Unix /etc/services file has a mapping from
http to port 80 on TCP.

On Unix systems, the cgo resolver calls the C getaddrinfo function.
This happens in cgoLookupServicePort in net/cgo_unix.go.  getaddrinfo
knows how to translate strings like "http" into port numbers like 80,
among other things.

>  2. Is there a significant advantage or disadvantage to using actual port 
> numbers directly instead of named services when dialing connections? If so, 
> could you share some insights or point me to relevant resources?

It's probably clearer to future readers to use the service names
rather than the port numbers.  I can't think of anything more
significant than that.

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

Re: [go-nuts] documentation for dlog output

[Ian Lance Taylor]

On Tue, Aug 27, 2024 at 11:32 AM Michael Mitchell
 wrote:
>
> At the end of dlog trace, we get the following.
> These seem like basic assembly instructions with addresses but I have no idea 
> what any of it means, and I can't find any documentation for it.  Can someone 
> take the time to go through the significance of each one by one, and that way 
> at least if anyone else does a google search this email chain might show up.
>
> rax0x104
>
> rbx0xd5a1e00
>
> rcx0x7ffee73232e8
>
> rdx0x1c00
>
> rdi0x9ff1998
>
> rsi0x1c011d00
>
> rbp0x7ffee7323390
>
> rsp0x7ffee73232e8
>
> r8 0x0
>
> r9 0xa0
>
> r100x0
>
> r110x246
>
> r120x9ff1958
>
> r130x16
>
> r140x1c011d00
>
> r150x1c00
>
> rip0x7fff20748cbe
>
> rflags 0x247
>
> cs 0x7
>
> fs 0x0
>
> gs 0x0


That is a register dump.  It is showing you a list of CPU registers
and the value in each register.

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/CAOyqgcWCy%3DR-JsGK1tHX1uF8FjeT%3DaK7r4jVC7c4%3DR2xX2p5zg%40mail.gmail.com.

Re: [go-nuts] Connectivity breakage from removal of TLS RSA KEX from default encryption suite

[Ian Lance Taylor]

On Mon, Aug 26, 2024 at 10:16 PM Robert Engels  wrote:
>
> Hmm. Aren’t the endpoints supposed to negotiate the available cryptographic 
> methods?
>
> So wouldn’t this affect non Go endpoints as well - which puts the burden back 
> on the side trying to use the latest Go version which is removing some of the 
> methods?
>
> Making it “if you upgrade to this version of Go you will no longer accept any 
> clients expecting to use TLS” - unless you do X?

Yes, that is my understanding.

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

Re: [go-nuts] Connectivity breakage from removal of TLS RSA KEX from default encryption suite

[Ian Lance Taylor]

On Mon, Aug 26, 2024 at 2:59 PM robert engels  wrote:
>
> I don’t think being concerned about the user is correct - I suspect that many 
> (most?) of the users have no idea the program is even written in Go…
>
> This is a builders responsibility imo to either fail at start-up with a user 
> understandable error, add mitigating code, or don’t build and release using 
> the latest release.

I think this case is more complex, because this involves a network
communication with two different sides.  It is possible for one or the
other side to be rebuilt when the other is not.

Ian



> > On Aug 26, 2024, at 4:45 PM, Ian Lance Taylor  wrote:
> >
> > On Mon, Aug 26, 2024 at 2:28 PM robert engels  wrote:
> >>
> >> Isn’t the version release notes 
> >> shttps://pkg.go.dev/net/http#Request.Hostufficient? Maybe add a "breaking 
> >> changes" section? https://tip.golang.org/doc/go1.23
> >
> > This change was indeed mentioned in the release notes
> > (https://go.dev/doc/go1.22#minor_library_changes, the crypto/tls
> > entry).  But there can be a pretty big gap between the person who
> > builds a program with a new version of Go and the user who encounters
> > a problem running that program.  Also that release note is, frankly,
> > pretty cryptic as to the consequences of the change.  We want to make
> > it as easy as possible for the user of the program to close that gap.
> >
> > Ian
> >
> >
> >
> >>> On Aug 26, 2024, at 4:20 PM, Ian Lance Taylor  wrote:
> >>>
> >>> On Mon, Aug 26, 2024 at 8:31 AM Creaky  wrote:
> >>>>
> >>>> Want to discuss the impacts from the implementation of the proposal 
> >>>> crypto/tls: disable RSA key exchange cipher suites by default #63413 and 
> >>>> possible ways forward beyond go change some code (whilst it may fix the 
> >>>> issue in the short term, has certain drawbacks, takes time, and is 
> >>>> impractical in some cases).
> >>>>
> >>>> This proposal was introduced in Go Version 1.22 for crypto/tls and 
> >>>> brought a significant behavioural change impacting client server 
> >>>> connectivity with very little announcement.
> >>>>
> >>>> People are seeing TLS handshake failures causing complete failure of 
> >>>> connectivity and not knowing where the issue is. As tooling starts to 
> >>>> take on the 1.22 / 1.23 Golang changes, the impacts from this change are 
> >>>> now bubbling to the surface.
> >>>>
> >>>> I can see why the motivation behind the change is from a good place. 
> >>>> There are weaknesses in using TLS with RSA encrypted key exchange. 
> >>>> However, the change as implemented is producing poor outcomes.
> >>>>
> >>>> From a high level perspective, it is far better to protect communication 
> >>>> with possibly vulnerable encryption than being completely in the clear. 
> >>>> However this breakage is encouraging some people to revert to in clear 
> >>>> connectivity for lacking (unknowing) a better option.
> >>>>
> >>>> Reading through the original proposal it appears considerations of 
> >>>> change impact narrowly focused on Internet connected clients and servers 
> >>>> and did not consider the various audience groups impacted by the 
> >>>> proposed (and now accepted) change.
> >>>>
> >>>> This change is now causing one of the more costly failure types, that 
> >>>> being in the field failures.
> >>>>
> >>>> What can be done now this proposal is implemented?
> >>>>
> >>>> Can the proposal and its implementation be reversed? Or removed and 
> >>>> reintroduced with better communication?
> >>>
> >>> Thanks for the detailed note.
> >>>
> >>> My takeaway here is that the Go team needs to provide better
> >>> communication about the consequences that people will see from this
> >>> kind of change, and how to better communicate those consequences and
> >>> how to work around them.  That is, I believe that the change is a good
> >>> one for the overall ecosystem.  But people can encounter this change
> >>> and not know what caused it and not know the relatively simple
> >>> workarounds that are available.
> >>>
> >>> As you know, those workarounds are described at
> >>> ht

Re: [go-nuts] Connectivity breakage from removal of TLS RSA KEX from default encryption suite

[Ian Lance Taylor]

On Mon, Aug 26, 2024 at 2:28 PM robert engels  wrote:
>
> Isn’t the version release notes 
> shttps://pkg.go.dev/net/http#Request.Hostufficient? Maybe add a "breaking 
> changes" section? https://tip.golang.org/doc/go1.23

This change was indeed mentioned in the release notes
(https://go.dev/doc/go1.22#minor_library_changes, the crypto/tls
entry).  But there can be a pretty big gap between the person who
builds a program with a new version of Go and the user who encounters
a problem running that program.  Also that release note is, frankly,
pretty cryptic as to the consequences of the change.  We want to make
it as easy as possible for the user of the program to close that gap.

Ian



> > On Aug 26, 2024, at 4:20 PM, Ian Lance Taylor  wrote:
> >
> > On Mon, Aug 26, 2024 at 8:31 AM Creaky  wrote:
> >>
> >> Want to discuss the impacts from the implementation of the proposal 
> >> crypto/tls: disable RSA key exchange cipher suites by default #63413 and 
> >> possible ways forward beyond go change some code (whilst it may fix the 
> >> issue in the short term, has certain drawbacks, takes time, and is 
> >> impractical in some cases).
> >>
> >> This proposal was introduced in Go Version 1.22 for crypto/tls and brought 
> >> a significant behavioural change impacting client server connectivity with 
> >> very little announcement.
> >>
> >> People are seeing TLS handshake failures causing complete failure of 
> >> connectivity and not knowing where the issue is. As tooling starts to take 
> >> on the 1.22 / 1.23 Golang changes, the impacts from this change are now 
> >> bubbling to the surface.
> >>
> >> I can see why the motivation behind the change is from a good place. There 
> >> are weaknesses in using TLS with RSA encrypted key exchange. However, the 
> >> change as implemented is producing poor outcomes.
> >>
> >> From a high level perspective, it is far better to protect communication 
> >> with possibly vulnerable encryption than being completely in the clear. 
> >> However this breakage is encouraging some people to revert to in clear 
> >> connectivity for lacking (unknowing) a better option.
> >>
> >> Reading through the original proposal it appears considerations of change 
> >> impact narrowly focused on Internet connected clients and servers and did 
> >> not consider the various audience groups impacted by the proposed (and now 
> >> accepted) change.
> >>
> >> This change is now causing one of the more costly failure types, that 
> >> being in the field failures.
> >>
> >> What can be done now this proposal is implemented?
> >>
> >> Can the proposal and its implementation be reversed? Or removed and 
> >> reintroduced with better communication?
> >
> > Thanks for the detailed note.
> >
> > My takeaway here is that the Go team needs to provide better
> > communication about the consequences that people will see from this
> > kind of change, and how to better communicate those consequences and
> > how to work around them.  That is, I believe that the change is a good
> > one for the overall ecosystem.  But people can encounter this change
> > and not know what caused it and not know the relatively simple
> > workarounds that are available.
> >
> > As you know, those workarounds are described at
> > https://go.dev/doc/godebug.  People working with an executable program
> > can set the GODEBUG variable in the environment.  People developing a
> > program from source can do that, and can also add a go:debug directive
> > to the main package and/or a godebug setting in a go.mod or go.work
> > file.  There are no plans to remove the tlsrsakex setting.
> >
> > Still you're absolutely right that the average user will see some sort
> > of failure to communicate, and will have no clear way to translate
> > that into what they need to do to change.  So the question is: how can
> > we communicate that better?  What are the right channels?  Would a Go
> > blog entry be sufficient?  Also, what kinds of errors will users see
> > in practice, and how can we get those errors to direct them to the
> > GODEBUG setting?
> >
> > Thanks.
> >
> > 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/CAOyqgcWTRwuFjZh_FEEAnJATS_io1VxP5c%2BS4Dv_oeshX-%2B0qA%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/CAOyqgcWXhnA6ZwsmvSMiPQ7C%2Bsbg7nUgbxG5DOcmkz6QS%2BUu5A%40mail.gmail.com.

Re: [go-nuts] Connectivity breakage from removal of TLS RSA KEX from default encryption suite

[Ian Lance Taylor]

On Mon, Aug 26, 2024 at 8:31 AM Creaky  wrote:
>
> Want to discuss the impacts from the implementation of the proposal 
> crypto/tls: disable RSA key exchange cipher suites by default #63413 and 
> possible ways forward beyond go change some code (whilst it may fix the issue 
> in the short term, has certain drawbacks, takes time, and is impractical in 
> some cases).
>
> This proposal was introduced in Go Version 1.22 for crypto/tls and brought a 
> significant behavioural change impacting client server connectivity with very 
> little announcement.
>
> People are seeing TLS handshake failures causing complete failure of 
> connectivity and not knowing where the issue is. As tooling starts to take on 
> the 1.22 / 1.23 Golang changes, the impacts from this change are now bubbling 
> to the surface.
>
> I can see why the motivation behind the change is from a good place. There 
> are weaknesses in using TLS with RSA encrypted key exchange. However, the 
> change as implemented is producing poor outcomes.
>
> From a high level perspective, it is far better to protect communication with 
> possibly vulnerable encryption than being completely in the clear. However 
> this breakage is encouraging some people to revert to in clear connectivity 
> for lacking (unknowing) a better option.
>
> Reading through the original proposal it appears considerations of change 
> impact narrowly focused on Internet connected clients and servers and did not 
> consider the various audience groups impacted by the proposed (and now 
> accepted) change.
>
> This change is now causing one of the more costly failure types, that being 
> in the field failures.
>
> What can be done now this proposal is implemented?
>
> Can the proposal and its implementation be reversed? Or removed and 
> reintroduced with better communication?

Thanks for the detailed note.

My takeaway here is that the Go team needs to provide better
communication about the consequences that people will see from this
kind of change, and how to better communicate those consequences and
how to work around them.  That is, I believe that the change is a good
one for the overall ecosystem.  But people can encounter this change
and not know what caused it and not know the relatively simple
workarounds that are available.

As you know, those workarounds are described at
https://go.dev/doc/godebug.  People working with an executable program
can set the GODEBUG variable in the environment.  People developing a
program from source can do that, and can also add a go:debug directive
to the main package and/or a godebug setting in a go.mod or go.work
file.  There are no plans to remove the tlsrsakex setting.

Still you're absolutely right that the average user will see some sort
of failure to communicate, and will have no clear way to translate
that into what they need to do to change.  So the question is: how can
we communicate that better?  What are the right channels?  Would a Go
blog entry be sufficient?  Also, what kinds of errors will users see
in practice, and how can we get those errors to direct them to the
GODEBUG setting?

Thanks.

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/CAOyqgcWTRwuFjZh_FEEAnJATS_io1VxP5c%2BS4Dv_oeshX-%2B0qA%40mail.gmail.com.

Re: [go-nuts] [compilation|gob] Is it possible to have multiple gob encoding instances?

[Ian Lance Taylor]

On Sat, Aug 24, 2024 at 2:51 AM gavraz  wrote:
>
> 1. I attempted to wrap gob with my own package and specify a distinct 
> toolchain, hoping it would result in a fully independent copy of the gob 
> package in the compiled code. Thanks for the clarification, this approach is 
> a no-go.
> 2. The challenge with forking the gob package is the import of 
> "internal/saferio" in decode.go, along with maintainability concerns raised 
> by the team. Any workarounds?

Well, you could copy the internal/saferio package also.  It's pretty
small and doesn't have any other dependencies.  I agree that this
approach is less maintainable.  Perhaps it would be an acceptable
approach if your new code will eventually displace the old code.

> 3. The problem we are facing is two-fold: first, we used Register instead of 
> RegisterName. Second, we have a primary decode flow that mistakenly uses 
> &target where target is an interface, which requires registering even trivial 
> structures. Developers have become accustomed to registering every structure, 
> and now we risk breaking the decode process during refactoring due to path 
> changes. Since I'm developing an independent module, I’d prefer to start 
> fresh and decouple this new module from these side effects.

It's not a problem for many different packages to call Register.  They
will all get the same results.  So the fact that there is a global
registry doesn't really matter as long as everybody only calls
Register, not RegisterName.  So one option is to just not worry about
this.

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

Re: [go-nuts] [compilation|gob] Is it possible to have multiple gob encoding instances?

[Ian Lance Taylor]

On Fri, Aug 23, 2024 at 4:26 PM gavraz  wrote:
>
> So gob has a Register function that mutates a "global" state. This implies 
> that a single program cannot have multiple instances with different 
> registrations.

True.

> I tried to create another module that wraps gob with its own go.mod with a 
> different toolchain then what my program uses hoping that gob.Register != 
> mygob.Register but no luck.
> I have a few questions
> 1. Why didn't the gob-wrap work?

I'm not clear on exactly what you did, but in general there can only
be one package with a given path in a binary.  And an entire Go
program must be compiled by a single toolchain.

> 2. Is there a proper way to get two instances of gob?

Well, you can copy the contents of encoding/gob to a different path,
and import from that path.  The two implementations will be
independent.

> 3. Why do you think gob/encoding was designed this way in the first place?

In general it doesn't matter whether different users of encoding/gob
use the gob.Register function.  It's no big deal if the two users both
register the same type.

On the other hand you can get failure if different parts of the
program try to use RegisterName with overlapping names.  I guess the
expectation was that that would not happen in practice.  encoding/gob
was designed and implemented quite a while ago, in 2010.  We might not
do it the same way today.

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

Re: [go-nuts] iterator method naming conventions

[Ian Lance Taylor]

On Thu, Aug 22, 2024 at 9:30 AM Adam Baratz  wrote:
>
> I've been reading the iter pkg docs and I'm trying to understand a 
> distinction drawn there.
>
> It says that the iterator method on a collection type is conventionally named 
> All (and returns a Seq). However, the maps and slices packages handle this a 
> little differently. They have All funcs that return a Seq2, and separate 
> Values funcs that return a Seq.
>
> How come there's this difference? Looking at making an update to some 
> collection types, wondering if it's more appropriate to have a Values method 
> if it's going to return a Seq.

For a container type that contains only values, not keys, All should
return an iter.Seq.

For a container type that contains both keys and values, All should
return an iter.Seq2.

Slices and maps are container types that contain both keys and values,
so maps.All and slices.All return iter.Seq2.

Whether a Values method/function makes sense is going to depend on the
container type.  For both slices and maps it does make sense (and, of
course, maps also has a Keys function).

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/CAOyqgcXr5Ett3LRYi33Oufv2HCeEx3-%2B-rVSg2MrFogXYX-4XQ%40mail.gmail.com.

Re: [go-nuts] go env doesn't seem to work well with GOTELEMETRY

[Ian Lance Taylor]

On Tue, Aug 20, 2024 at 7:00 PM Will Faught  wrote:
>
> Thanks, but it looks like that issue is only about enabling `go env -w 
> GOTELEMETRY=off`.
>
> Isn't it incorrect for `go env GOTELEMETRY` to work, yet `go env -u 
> GOTELEMETRY` prints `unknown go command variable GOTELEMETRY`? Shouldn't it 
> insead print something like `go command variable GOTELEMETRY cannot be set 
> with go env`?

I think every aspect of the GOTELEMETRY environment variable (if there
is going to be one) is fair game on that issue.

Ian


> On Tue, Aug 20, 2024 at 6:04 PM Ian Lance Taylor  wrote:
>>
>> On Tue, Aug 20, 2024 at 5:08 PM will@gmail.com
>>  wrote:
>> >
>> > Despite showing up an an env var, it's not treated consistently as one:
>> >
>> > ❯ go telemetry off
>> > # nothing printed
>> > # as expected
>> >
>> > ❯ go env | grep GOTELEMETRY=
>> > GOTELEMETRY='off'
>> > # as expected
>> >
>> > ❯ go env GOTELEMETRY
>> > off
>> > # as expected
>> >
>> > ❯ go env -changed
>> > # nothing printed
>> > # as expected
>> >
>> > ❯ go env -u GOTELEMETRY
>> > go: unknown go command variable GOTELEMETRY
>> > # expected nothing printed, success
>> >
>> > ❯ go env -w GOTELEMETRY=on
>> > go: unknown go command variable GOTELEMETRY
>> > # expected nothing printed, success
>> >
>> > ❯ go telemetry on
>> > # snip
>> > # as expected
>> >
>> > ❯ go env | grep GOTELEMETRY=
>> > GOTELEMETRY='on'
>> > # as expected
>> >
>> > ❯ go env GOTELEMETRY
>> > on
>> > # as expected
>> >
>> > ❯ go env -changed
>> > # nothing printed
>> > # expected to be printed: GOTELEMETRY='on'
>> >
>> > ❯ go env -u GOTELEMETRY
>> > go: unknown go command variable GOTELEMETRY
>> > # expected nothing printed, success
>> >
>> > ❯ go env -w GOTELEMETRY=off
>> > go: unknown go command variable GOTELEMETRY
>> > # expected nothing printed, success
>>
>> These issues are being discussed on https://go.dev/issue/68960.
>>
>> 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/CAOyqgcWkR17VKRC-Yd%2Bxbnkq6EFnRWUP9JTb4Hz0kehGpX%2BBDw%40mail.gmail.com.

Re: [go-nuts] go env doesn't seem to work well with GOTELEMETRY

[Ian Lance Taylor]

On Tue, Aug 20, 2024 at 5:08 PM will@gmail.com
 wrote:
>
> Despite showing up an an env var, it's not treated consistently as one:
>
> ❯ go telemetry off
> # nothing printed
> # as expected
>
> ❯ go env | grep GOTELEMETRY=
> GOTELEMETRY='off'
> # as expected
>
> ❯ go env GOTELEMETRY
> off
> # as expected
>
> ❯ go env -changed
> # nothing printed
> # as expected
>
> ❯ go env -u GOTELEMETRY
> go: unknown go command variable GOTELEMETRY
> # expected nothing printed, success
>
> ❯ go env -w GOTELEMETRY=on
> go: unknown go command variable GOTELEMETRY
> # expected nothing printed, success
>
> ❯ go telemetry on
> # snip
> # as expected
>
> ❯ go env | grep GOTELEMETRY=
> GOTELEMETRY='on'
> # as expected
>
> ❯ go env GOTELEMETRY
> on
> # as expected
>
> ❯ go env -changed
> # nothing printed
> # expected to be printed: GOTELEMETRY='on'
>
> ❯ go env -u GOTELEMETRY
> go: unknown go command variable GOTELEMETRY
> # expected nothing printed, success
>
> ❯ go env -w GOTELEMETRY=off
> go: unknown go command variable GOTELEMETRY
> # expected nothing printed, success

These issues are being discussed on https://go.dev/issue/68960.

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

Re: [go-nuts] segmention fault while upgrading from 1.20.6 to 1.22.3

[Ian Lance Taylor]

On Tue, Aug 20, 2024 at 5:34 AM M.Tarkeshwar Rao  wrote:
>
> As part of regular LCM activity we are doing GoLang LCM. Issue is:
>
> This is to bring to your immediate attention that while doing golang LCM ,
> we changed it to 1.22.3 but CI job failed on the same .
> Upon debugging  application it was deduced that there may be memory issue.
> But even after trying the same on different dev machines same issue occurred.
> Trying locally also it is failing with same error.
> This is application error applicaton Docker image building.
>
> This is a blocker for us. Kindly help us deducing how to proceed further.
>
> Error:
> Step 41/72 : RUN make build-go GO_BUILD_TAGS=${GO_BUILD_TAGS} 
> WIRE_TAGS=${WIRE_TAGS}
> ---> Running in 0c954cffd4a6
> (re)installing /root/go/bin/wire-v0.5.0
> go: downloading github.com/pmezard/go-difflib v1.0.0
> go: downloading github.com/google/subcommands v1.0.1
> go: downloading golang.org/x/tools v0.0.0-20190422233926-fe54fb35175b
> generate go files
> /root/go/bin/wire-v0.5.0 gen -tags oss ./pkg/server
> panic: runtime error: invalid memory address or nil pointer dereference 
> [recovered]
> panic: runtime error: invalid memory address or nil pointer 
> dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x57fd2f]
>
> goroutine 875 [running]:
> go/types.(*Checker).handleBailout(0xc000d09800, 0xc00636fca8)
> /usr/local/go/src/go/types/check.go:367 +0x88
>
> My query is that what should we do for this error. We need to revert back or 
> move to another version.

Is there a way that we can recreate the problem?

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/CAOyqgcWt3no867vP4BdL5HHxWJ%3DkVHsc5v-8LZmamO%3DpmD8pBw%40mail.gmail.com.

Re: [go-nuts] GOEXPERIMENT source code build

[Ian Lance Taylor]

On Fri, Aug 16, 2024 at 7:28 AM Leah Stapleton
 wrote:
>
> I have a question about building go source code to run the tests go swiss 
> maps experiments.
>
> first off,
> There are tests with the same name in map_swiss_test.go and 
> map_noswiss_test.go, and when I go test -run TestMapIterOrder, it is by 
> default running the test in map_noswiss_test.go, so I assume I need to build 
> the source code for this experiment.
>
> How do I indicate I want the go source code build to use swiss maps 
> experiment?
>
> I normally run just run /make.bash from the /src dir.

Set GOEXPERIMENT=swissmap in the environment when invoking the go
tool.  You don't have to run make.bash again.

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

Re: [go-nuts] Compiler error in Go 1.23 with generics, type aliases and indexing

[Ian Lance Taylor]

On Thu, Aug 15, 2024 at 2:26 PM 'Peter Hynes' via golang-nuts
 wrote:
>
> Thanks.
>
> https://github.com/golang/go/issues/68903

Thanks for reporting this.

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

Re: [go-nuts] Compiler error in Go 1.23 with generics, type aliases and indexing

[Ian Lance Taylor]

On Thu, Aug 15, 2024 at 9:59 AM 'Peter Hynes' via golang-nuts
 wrote:
>
> We have some code that works fine in Go 1.22, but throws a compiler error in 
> Go 1.23.

...

> Is this a compiler bug?

Yes.

Would you be able to file an issue at https://go.dev/issue?  Thanks.

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

Re: [go-nuts] After Disbanding the Python Team, Google’s Go Team Faces Turmoil: Technical Lead and 12-Year Project Leader Steps Down

[Ian Lance Taylor]

On Thu, Aug 15, 2024 at 1:10 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> The facts of the title are correct. See here:
> https://techcrunch.com/2024/05/01/google-lays-off-staff-from-flutter-dart-python-weeks-before-its-developer-conference/
> https://groups.google.com/g/golang-dev/c/0OqBkS2RzWw
> However, mentioning these in the same sentences seems to drum up a storm in a 
> water glass to me. They have very little in common.

I can't read the article either, but I have to agree.  The Go team is
not facing turmoil.  (To be clear, I'm on the Go team.)  We had this
kind of transition before, when Rob Pike handed lead responsibilities
to Russ Cox.  Now, 12 years later, we are having another transition,
this time to Austin Clements.  These kinds of transitions are normal
for a long-lasting software project.

Ian


> On Thu, 15 Aug 2024 at 08:51, Amnon  wrote:
>>
>> https://blog.stackademic.com/after-disbanding-the-python-team-googles-go-team-faces-turmoil-12-year-project-leader-steps-down-29c4248ceb85
>>
>> I could not read this article as it is behind a pay-wall.
>> But the title looks interesting, (and worrying if correct).
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/0255e670-86e5-4c37-845f-d64aba29608en%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/CAEkBMfE-8d3HCZ-uNKj%3DjPJbphX6ykO%2BjQ9S%3DNBJg%3DPt1zMXLg%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/CAOyqgcWo3KG8%2BMF%2B5yu8FamRy11XiR7%3DpjdRi1GONEquM%2BQWpw%40mail.gmail.com.

Re: [go-nuts] GOMAXPROCS?

[Ian Lance Taylor]

On Mon, Aug 12, 2024 at 6:17 AM Robert Engels  wrote:
>
> Revisiting an old thread 
> https://groups.google.com/g/golang-nuts/c/jPb_h3TvlKE/m/qdoHhxXeAwAJ
>
> Is it still the case that high disk IO throughput requires a GOMAXPROCS 
> seething higher than the number of cpus on the system?

It's true that we don't use the poller for local file operations on
most systems.  So if your program is overloading the file system, it
is possible for goroutines to be delayed waiting for file I/O to
finish.  Those delays won't be for long, as the scheduler will step in
and start new threads as needed.  However, it won't do that right
away; I think the delay can be up to 10ms.  In such a case it can be
useful to increase GOMAXPROCS to permit queuing up more file I/O more
quickly, or to do other non-I/O related activity.

> Are there any other cases where this might be required?

Not that I'm aware of.

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/CAOyqgcWDmT-8T4hZcyP9Oo0dD3bxWYb_7Q5fVOYbYx2BWahE8A%40mail.gmail.com.

Re: [go-nuts] Imitating tuple in golang

[Ian Lance Taylor]

On Sun, Aug 11, 2024 at 5:35 AM 'Brian Candler' via golang-nuts
 wrote:
>
> Are there many instances where interpretation (1) is useful?

Yes.

> I would also observe: if Go implemented case (2) for "==", this doesn't 
> prevent the user from implementing case (1) using a separate function, as 
> today.

Of course.  But it means that people who expect interpretation 1 will
be confused.  We want to avoid confusion where possible.

> Supplementary question: does the Go standard library even expose a function 
> for case (1), or would you have to do it yourself using e.g. 
> unsafe.SliceData?  Clearly case (2) is supported via bytes.Equal, 
> slices.Equal etc.

if len(a) == 0 {
  return (a == nil) == (b == nil)
} else {
  return len(a) == len(b) && &a[0] == &b[0]
}

Ian

> On Sunday 11 August 2024 at 05:08:26 UTC+6 Ian Lance Taylor wrote:
>>
>> On Fri, Aug 9, 2024 at 9:03 PM 'Brian Candler' via golang-nuts
>>  wrote:
>> >
>> > I would agree, except there is no == operator defined on slices, and I'm 
>> > not really sure why that is. The semantics I would expect are 
>> > straightforward: i.e. length is the same, and the first 'len' slice 
>> > elements compare as equal, recursively if necessary. (*)
>>
>> There is no == operator on slice types because there are two possible 
>> meanings:
>> 1) Two slices are equal if they have the same length and refer to the
>> same underlying array.
>> 2) Two slices are equal if they have the same length and each
>> individual element is itself equal.
>>
>> Because it's not clear which definition of equality people might mean,
>> the language doesn't define ==, and forces people to choose which
>> definition they want in any given situation.
>>
>> 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/62959bba-5170-4f1a-b8b4-f023a22848cen%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/CAOyqgcWBkSyfvL1kpVk%3DXkOiFPJ3U1_L9tm12P3A0uGGs_FjtA%40mail.gmail.com.

Re: [go-nuts] Imitating tuple in golang

[Ian Lance Taylor]

On Fri, Aug 9, 2024 at 9:03 PM 'Brian Candler' via golang-nuts
 wrote:
>
> I would agree, except there is no == operator defined on slices, and I'm not 
> really sure why that is. The semantics I would expect are straightforward: 
> i.e. length is the same, and the first 'len' slice elements compare as equal, 
> recursively if necessary. (*)

There is no == operator on slice types because there are two possible meanings:
1) Two slices are equal if they have the same length and refer to the
same underlying array.
2) Two slices are equal if they have the same length and each
individual element is itself equal.

Because it's not clear which definition of equality people might mean,
the language doesn't define ==, and forces people to choose which
definition they want in any given situation.

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/CAOyqgcXcg1Azd1-ggZyrnk6hu5WDQCHQOhO0xkR%2BQoPt7faO%2Bw%40mail.gmail.com.

Re: [go-nuts] Making a post call with multiple instances of the same struct

[Ian Lance Taylor]

On Mon, Aug 5, 2024 at 11:32 AM G K  wrote:
>
> I defined a global variable of the struct kind "Lock" as a slice - var Lock 
> []models.Lock
> But then every time I tried to unmarshal the data from the post call using 
> the the reference to &Lock, I was getting an error message that function 
> couldn't unmarshal the object into a Go value. It unmarshals fine you define 
> the var Lock model.Lock as just a struct.

Thanks, but rather than rephrasing into English, show us exactly what
you did, and exactly what happened.  Show us the exact code.  Tell us
the exact error message.  Thanks.

Ian


> On Monday, August 5, 2024 at 11:37:26 AM UTC-5 Ian Lance Taylor wrote:
>>
>> On Mon, Aug 5, 2024 at 6:55 AM G K  wrote:
>> >
>> > I'm trying to create an HTTP rest api end where a POST method will be able 
>> > to accept and deserialize (unmarshall) a same data structre into numerous 
>> > instances. For the sake of example, lets say I have json struct:
>> > type Lock struct
>> > {
>> > Key uint `json:"key"`
>> > }
>> > Nom Im trying to post unspecified amount of keys. I tried defying the type 
>> > as a slice but unmarshall function would not work. Does anyone have any 
>> > ideas how to go about this?
>>
>> Using a slice sounds like the right thing to do. What exactly did you
>> try and what exactly happened?
>>
>> 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/aab40be8-a26f-49f4-b762-d8527963ddcen%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/CAOyqgcXirXPVR9tZNgsw%2BVtmdnD%3DWJmQF_g4P6-bfWHRAe4%3DJA%40mail.gmail.com.

Re: [go-nuts] Making a post call with multiple instances of the same struct

[Ian Lance Taylor]

On Mon, Aug 5, 2024 at 6:55 AM G K  wrote:
>
>I'm trying to create an HTTP rest api end where a POST method will be able 
> to accept and deserialize (unmarshall) a same data structre into numerous 
> instances. For the sake of example, lets say I have json struct:
> type Lock struct
> {
>Key uint  `json:"key"`
> }
> Nom Im trying to post unspecified amount of keys. I tried defying the type as 
> a slice but unmarshall function would not work. Does anyone have any ideas 
> how to go about this?

Using a slice sounds like the right thing to do.  What exactly did you
try and what exactly happened?

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/CAOyqgcUOs8RsMey5jFHJT38DNKq6%3DALA55ghEyu2ryCa3dYg%2Bg%40mail.gmail.com.

Re: [go-nuts] mutex profile headers

[Ian Lance Taylor]

On Mon, Jul 29, 2024 at 12:53 PM Leah Stapleton
 wrote:
>
> Hi, can anyone explain what the headers (in bold) refer to in mutex  
> profiles? Is it documented somewhere?  Thank you
>
>
> 871400731000 26738165 @ 0x81c8d94 0x81c8d93 0x81c88d7 0x8444386 0x82353a1
> # 0x81c8d93 runtime.unlock+0x4b3 /go pprof format 
> cyclesusr/local/go/src/runtime/lock_sema.go:103
> # 0x81c8d92 runtime.chansend+0x4b2 /usr/local/go/src/runtime/chan.go:228
> # 0x81c88d6 runtime.chansend1+0x16 /usr/local/go/src/runtime/chan.go:145
> # 0x8444385 main.contended.func1+0x65 /Users/mm/go/src/github.com/
>
> 49297035 720 @ 0x8205ad7 0x8205ad6 0x8217091 0x8217087 0x82334da
> # 0x8205ad6 runtime.unlock+0x156 /usr/local/go/src/runtime/lock_sema.go:103
> # 0x8205ad5 runtime.goschedImpl+0x155 /usr/local/go/src/runtime/proc.go:4059
> # 0x8217090 runtime.gopreempt_m+0x3d0 /usr/local/go/src/runtime/proc.go:4082
> # 0x8217086 runtime.newstack+0x3c6 /usr/local/go/src/runtime/stack.go:1070
> # 0x82334d9 runtime.morestack+0x79 /usr/local/go/src/runtime/asm_amd64.s:616

I'm not sure whether this format is documented anywhere.

The first number is the approximate number of cycles accumulated for
this stack trace.  The second number is the approximate number of
times we've seen this stack trace.  Both numbers are scaled by the
sampling probability.  The remaining numbers, after the @,  are the
stack trace--you can see that they appear again, off by one, in the
stack trace lines.

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

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

[Ian Lance Taylor]

On Wed, Jul 24, 2024 at 2:58 PM Brendan Goldacker 
wrote:

>
> I took a look over the channels code
> .
> I can't say I follow it 100%, but it seems like there is a circular buffer
> which would be of size 128 in the larger buffer case. Then there are two
> offset pointers for the heads and tails of the queue. It seems like the
> heap grows unbounded since when receiving from the channel, it doesn't
> actually delete the item form the circular queue. Instead it just
> increments our head pointer. Therefore, a channel holds a reference to a
> chunk buffer (up to 128 of them) even if they've already been read/received
> by a worker. Thus, these 'old' buffers cannot be GC'ed. The reference is
> only removed from the circular queue once the channel gets enough sends to
> overwrite the slot.
>

That's interesting.  Would you mind filing an issue at https://go.dev/issue
so that the runtime team can take a look?  If you are describing the issue
correctly--I have no reason to think you aren't--perhaps it would be
relatively cheap to zero out the entry in the channel buffer after the
value is delivered to a goroutine.  Thanks.

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/CAOyqgcWvZLcM19cBt42jwNLeYe3B0FK2Cuztfj%2BHEroe0%2BFDAw%40mail.gmail.com.

Re: [go-nuts] When using cgo to generate Go structs, some fields are ignored in the definition.

[Ian Lance Taylor]

On Wed, Jul 24, 2024 at 5:29 AM 飞舟  wrote:
>
> I have a C struct, and when I use cgo to generate Go structs, some fields are 
> being ignored. I’m using go version go1.21.1 linux/amd64, and here is my env.

Please post code as plain text, rather than with a background.  Plain
text is much easier to read.  Thanks.

Also, please show us a complete, small, example.  I tried your
example.  I had to invent types for J_COLOR_SPACE and ImageFormat.  It
worked fine.

Does your actual code use anything like #pragma packed?  That will
cause this kind of problem, as Go does not currently have any way to
represent a packed struct.

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

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

[Ian Lance Taylor]

On Mon, Jul 22, 2024 at 1:05 PM Brendan Goldacker 
wrote:

> I've been using the 1 billion row challenge
>  as a way to learn
> go over the past few days. With my limited go experience, I've seem to hit
> a wall.
>
> I have my submission here . On my M1
> macbook pro with 16GB of memory, it runs in ~39s. I can get it a few
> seconds faster if I play around with some parameters (numWorkers and
> chunkSizes). I'm trying to make it a goal to get <20s. However, I'm stuck.
>
> I came across another submission from this blog post
> . I've
> copied over the submission to my repo (otherSubmission.go) and it runs in
> ~19s. I was looking over their solution and it appears very similar to mine
> in apprach. The only difference is that they use os.Read to read the file
> sequentially, and my submission uses MMap. Plus a few other minor
> differences. Overall, both approaches look to be about the same. However,
> theirs runs in about half the time. I can't find anything that stands out
> to why there would be such a large difference in runtime.
>
> I've been trying to use the profile and execution traces to figure out
> why. Below are my flameGraphs and execution traces
> [image: Screenshot 2024-07-22 at 1 19 40 PM]
> 
>  [image: Screenshot 2024-07-22 at 1 21 47 PM]
> 
>
> Below are the otherSubmission profile and execution traces:
> [image: Screenshot 2024-07-22 at 1 23 39 PM]
> 
>  [image: Screenshot 2024-07-22 at 1 22 47 PM]
> 
>
> The first thing that stands out to my are the # of GC collections. My
> submission seems to be running GC much more freq

Re: [go-nuts] Surprising behaviour in x/time/rate

[Ian Lance Taylor]

On Fri, Jul 19, 2024 at 1:52 PM 'James Lees' via golang-nuts
 wrote:
>
> Hi there,
> I've never posted here, so apologies if I'm breaching any etiquette, but the 
> contribution guide suggests posting here before creating an issue so I 
> thought I'd try.
>
> I was debugging an issue recently and saw some strange behaviour in the 
> x/time/rate package.
>
> The behaviour is exhibited in the following test
>
> func TestRateIssue(t *testing.T) {
> l := NewLimiter(0, 1)
> fmt.Println(l.Allow()) // should be true
> fmt.Println(l.Allow()) // should be false
>
> l.SetLimit(10)
>
> time.Sleep(1 * time.Second)
> fmt.Println(l.Allow()) // should be true but is false.
> }
>
> This code seems very strange to me. If the burst is 1, decrementing it here 
> means that the limiter becomes unusable even if the limit is subsequently 
> increased.
>
> This code appeared here but the conversation doesn't really reflect the code: 
> the comment says:
>
> > The opposite in fact needs to happen: lim.tokens must be reduced by the n 
> > consumed tokens?
>
> Which makes sense to me, but I'm not sure how we ended up decrementing the 
> burst. To me the solution to the reported problem (limiters not actually 
> being full) would be to set lim.tokens on the constructor, but I haven't 
> thought about that too deeply.
>
> I'm happy to propose a change/create an issue but hopefully you folks can 
> help me understand whether I'm missing something obvious!

I agree that this seems wrong.  Want to open a bug report or send a patch?

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

Re: [go-nuts] this code sometimes hangs

[Ian Lance Taylor]

On Fri, Jul 19, 2024 at 1:52 PM Laurence Guild  wrote:
>
>
>  Is there an article that says not to use sync.Cond ? This page seems to have 
> some fans of sync.Cond. I have xtensive software experience but I am new to 
> golang so I am just trying to learn
>
> https://github.com/golang/go/issues/21165

I would say that sync.Cond has its uses in Go, but they are rare.  In
Go one normally uses channels for the kinds of things for which other
languages use conditional variables.  It's probably a mistake to use
sync.Cond without a clear understanding of why channels won't work.

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/CAOyqgcWK6uZzgQRpQkqY9UHC9T6Goo_C-4-KpWYszQbGN1ggsg%40mail.gmail.com.

Re: [go-nuts] xrealwd() in unix.c in Go 1.4

[Ian Lance Taylor]

On Thu, Jul 18, 2024 at 9:38 PM Chris Guthrey  wrote:
>
> I'm trying to learn how the last version of Go that is bootstrapped from C 
> works and as a learning exercise, maybe try porting to a new OS (on x86 for 
> now)...
>
> So I'm trying to get my head around the xrealdwd() function  in 
> /src/cmd/dist/unix.c - I just can't grok why it is needed.
>
> A quick search indicates that xrealdwd() is only ever used by build.c, and 
> the comment in build.c says:
>
> // xgetwd might return a path with symlinks fully resolved, and if
> // there happens to be symlinks in goroot, then the hasprefix test
> // will never succeed. Instead, we use xrealwd to get a canonical
> // goroot/src before the comparison to avoid this problem.
>
> I guess my understanding and knowledge of symlinks is lacking, but I guess i 
> just don't understand why hasprefix() will never succeed if there happens to 
> be symlinks in goroot...

hasprefix is a simple string comparison.  If /home is a symlink to
/real/home, and GOROOT is /home/go, then xgetwd can return
/real/home/go which won't match /home/go.


> The windows.c file also has a similar (at least similar in logic but not in 
> OS calls) approach to xrealdwd() so I must assume that hasprefix() does not 
> like symlinks on Windows either?

Yes, again, hasprefix is a simple string comparison.

> I think if this were ported to an OS that doesnt have symlinks, I might be 
> able to get away with making xrealwd() always just return the current 
> directory without trying to get a canonical path to goroot/src...

Yes, I suppose.  But I don't recommend following the path of porting
Go 1.4.  Instead, port the current Go tip, and build it on a supported
machine, and then use that to cross-compile.  See bootstrap.bash.

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

Re: [go-nuts] question about HACKING.md

[Ian Lance Taylor]

On Thu, Jul 18, 2024 at 11:29 AM Leah Stapleton
 wrote:
>
> In the document HACKING.md 
> (https://github.com/golang/go/blob/master/src/runtime/HACKING.md), it states 
> that we can determine if we're running on the user or system stack by running 
> `getg() == getg().m.curg`.
>
> However if the output of that equality check is true, does that mean we're on 
> user or system stack?

The user stack.

> getg can return the current g but when executing on the system stack it 
> returns the current M's g0.
>
> I assume that a true means we're on the user stack because it says "To get 
> the current user g, use getg().m.curg". However, there's no where that I can 
> see that says that m.curg can't be the system stack, so please clarify.

As it says, getg().m.curg is the current user g.  It's never a g0.  A
g0 is never a user g.  Each g has its own stack.  A g0 has a fixed
system thread stack, a user g has a Go-managed user stack.

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

Re: [go-nuts] might be a hole in Golang specification regarding the definition of "addressable"

[Ian Lance Taylor]

On Tue, Jul 16, 2024 at 9:29 PM 王旭东  wrote:
>
> Hi, I have a question about "addressable."
>
> The following code illustrates my question (see the comments):
> https://go.dev/play/p/xpiPXuEqh0O?v=gotip
>
>
>
> I also posted question in the Gopher Slack channel, and @Axel Wagner provided 
> a detailed explanation, suggesting that this might be a gap in the Go 
> specification.
> @Jason Phillips recommended that I ask this question in the GitHub issues and 
> the golang-nuts mailing list.
>
> I really appreciate everyone’s help mentioned, but I still don’t have a clear 
> conclusion.
>
> To simplify: my question is why the result of myfunReturnPointer() is 
> addressable if we strictly follow the specification.


In https://go.dev/ref/spec#Selectors the spec explains that if the
type of x is a pointer, then the selector expression x.f is shorthand
for (*x).f.  That is the case in your playground example: the
expression myfunReturnPointer().i is short for
(*myfunReturnPointer()).i.  The pointer indirection
*myfunReturnPointer() is addressable according to
https://go.dev/ref/spec#Address_operators.  So this is a field
selector of an addressable struct operand.

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/CAOyqgcUL0D9a0nmXP%2BNJTPrax-ixWFUvRwuUAK5m1G-LtjzH7w%40mail.gmail.com.

Re: [go-nuts] Inquiry about gccgo Upgrade Timeline

[Ian Lance Taylor]

On Fri, Jul 12, 2024 at 6:12 AM Tanawatra Chantaranit
 wrote:
>
> I'm interested in using gccgo and was wondering if there's any information 
> available regarding its upgrade timeline. Is there a specific version or 
> feature set planned for the next upgrade?

Unfortunately I have had very little time to work on gccgo recently.
There is no particular schedule at this time.

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/CAOyqgcWB6x6C7%2BR%2BjicLZLZbXPqfjaEPHj0%3DZaP-TQMwJ%2B0xqw%40mail.gmail.com.

Re: [go-nuts] How does embedding without some specific methods work?

[Ian Lance Taylor]

On Fri, Jul 12, 2024 at 6:12 AM William Tang  wrote:
>
> I’m reading the current implementation of io.Copy for TCPConn. It has a 
> struct called tcpConnWithoutWriteTo 3, which will cause the WriterTo casting 
> from a io.Reader to fail 1. How and why does it work internally?

When there are two promoted methods with the same name, both methods
are ignored.  The language spec lists the rules at
https://go.dev/ref/spec#Selectors.

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/CAOyqgcX6p4-3USq6wQkHMtHofMcrgROpMPa4dqS6cYO%2Bsr0gMg%40mail.gmail.com.

Re: [go-nuts] Rangefunc in Go 1.23

[Ian Lance Taylor]

On Wed, Jul 10, 2024 at 4:17 PM Justin Scheiber  wrote:
>
> I'm trying to establish a mental model for what the compiler does with range 
> functions in Go 1.23.  It looks like the compiler creates a function based on 
> the for loop body, and calls it by looping over the values passed in.
>
> Meaning this code:
> func simpleIter(yield func(v int) bool) {
> if !yield(1) {
> return
> }
> if !yield(2) {
> return
> }
> }
>
> for x := range simpleIter {
> fmt.Println(x)
> }
>
> compiles into this code:
>
> {
> yield := func(v int) bool {
> fmt.Println(v) // loop body from the code above
> }
> for v := 1; v <= 2; v++ {
> if !yield(1) {
> goto end_loop
> }
> }
> end_loop:
> }
>
> Is that correct?

Sort of.  I 'm not sure where the "for v := 1; v <= 2; v++" comes
from.  Your yield function is more or less correct, but then the
compiler just calls "simpleIter(yield)".

It's a bit more complicated because the loop can contain break
statements, return statements, or panics.  Those cause the generated
yield function to return false.

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/CAOyqgcVmV8%3D9f6SbL-2u192NLONi35mbBE-gaEgGzSB15EYtmQ%40mail.gmail.com.

Re: [go-nuts] go tool cover vs go tool covdata

[Ian Lance Taylor]

On Wed, Jul 10, 2024 at 3:07 AM Akash Kumar  wrote:
>
> what is the difference between go tool cover and go tool covdata ?

See https://pkg.go/dev/cmd/cover and https://pkg.go.dev/cmd/covdata.

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/CAOyqgcUr%3DrR8cr1iaWtbttHdnNwVdq_LMBA%2BMg0mmknQXDHP1A%40mail.gmail.com.

Re: [go-nuts] Re: Is []rune(invalidUTF8str) underspecified?

[Ian Lance Taylor]

On Tue, Jul 9, 2024 at 5:24 PM 'David Anderson' via golang-nuts
 wrote:
>
> In practice, as you point out, the original Go implementation does the 
> obvious thing and reuses the range iteration behavior. Would it be reasonable 
> to nail down that `[]rune(foo)` must behave the same as range iteration in 
> all implementations?

It seems reasonable at first glance.  Want to open an issue for this?
Or just send a patch?  Thanks.

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

Re: [go-nuts] cgo: passing unsafe.Pointer of Slice without explicit pinning?

[Ian Lance Taylor]

On Mon, Jul 8, 2024 at 4:06 PM Antonio Caceres Cabrera
 wrote:
>
> Unless, the C function stores the pointer and it's kept after the call 
> returns, correct? That's what I mean by calling the function 
> keep_this_pointer in the second example. In this case, it would be necessary, 
> I'm assuming?

Ah, yes, in that case the pointer does have to be pinned.

Ian


> On Monday, July 8, 2024 at 11:56:30 PM UTC+2 Ian Lance Taylor wrote:
>>
>> On Mon, Jul 8, 2024 at 12:38 PM Antonio Caceres Cabrera
>>  wrote:
>> >
>> > Sorry, accidentally hit the wrong response button, so I'm posting it again:
>> >
>> > Thanks for the clarification, Ian.
>> >
>> > Is it also possible to pin memory to local go-arrays?
>> > The docs state
>> > >Go values created by calling new, by taking the address of a composite 
>> > >literal, or by taking the address of a local variable may also have their 
>> > >memory pinned using runtime.Pinner.
>> >
>> > In this example:
>> > ```
>> > var pin runtime.Pinner
>> > var buf [32]byte
>> > pin.Pin(&buf[0])
>> > C.keep_this_pointer(&buf[0])
>> > ```
>> >
>> > Is this ok since it counts as taking the address of a local variable or 
>> > would the array have to be created with `new([32]byte)` ?
>>
>> Yes, this is an example of taking the address of a local variable.
>> The runtime.Pinner is not required here.
>>
>> In general a runtime.Pinner is only required when passing the address
>> of a value that itself contains Go pointers. In that case the
>> internal Go pointers need to be explicitly pinned.
>>
>> 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/b3b3a36b-87ba-4271-b004-810670eb759an%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/CAOyqgcW-iNjU2EcRCNxr_p93jgbXic%2BU0vHqgjvW_Z3%3DrJkdnA%40mail.gmail.com.

Re: [go-nuts] cgo: passing unsafe.Pointer of Slice without explicit pinning?

[Ian Lance Taylor]

On Mon, Jul 8, 2024 at 12:38 PM Antonio Caceres Cabrera
 wrote:
>
> Sorry, accidentally hit the wrong response button, so I'm posting it again:
>
> Thanks for the clarification, Ian.
>
> Is it also possible to pin memory to local go-arrays?
> The docs state
> >Go values created by calling new, by taking the address of a composite 
> >literal, or by taking the address of a local variable may also have their 
> >memory pinned using runtime.Pinner.
>
> In this example:
> ```
> var pin runtime.Pinner
> var buf [32]byte
> pin.Pin(&buf[0])
> C.keep_this_pointer(&buf[0])
> ```
>
> Is this ok since it counts as taking the address of a local variable or would 
> the array have to be created with `new([32]byte)` ?

Yes, this is an example of taking the address of a local variable.
The runtime.Pinner is not required here.

In general a runtime.Pinner is only required when passing the address
of a value that itself contains Go pointers.  In that case the
internal Go pointers need to be explicitly pinned.

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

Re: [go-nuts] cgo: passing unsafe.Pointer of Slice without explicit pinning?

[Ian Lance Taylor]

On Sun, Jul 7, 2024 at 6:17 AM Antonio Caceres Cabrera
 wrote:
>
> I'm trying to use cgo for a C library, specifically a function which takes a 
> void pointer to a buffer, and I'm trying to pass a Go-Slice as this buffer.
>
> ```
> func Write(buf []byte) (int, error) {
> // var pin rumtime.Pinner
> // pin.Pin(&buf[0])
> // defer pin.Unpin()
> // is this necessary? Is it even safe?
> ...
> ret := C.lib_read(unsafe.Pointer(&buf[0]), C.int(len(buf))) // function 
> which reads from this buffer
> ...
> }
> ```
> Does this require explicit pinning of buf? And if so, is the commented part a 
> valid pinning of a slice? The documentation states that pointers passed to C 
> functions are implicitly pinned (on the top-level that is), but does this 
> also apply to slices, i.e. if I pass a (unsafe) pointer to the first element, 
> is the slice's entire backing array implicitly pinned?
>
> I know that there are some runtime checks for this, but I am worried that any 
> use of unsafe.Pointer might perhaps override these checks completely.

This kind of code does not require explicit pinning.  As you note,
passing a pointer to C implicitly pins the memory that the pointer
points to.  Further, the cgo docs say "When passing a pointer to an
element in an array or slice, the Go memory in question is the entire
array or the entire backing array of the slice."  In other words, yes,
the slice's entire backing array is implicitly pinned.  The cgo tool
is smart enough to ignore type conversions when deciding what memory
needs to be pinned.

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/CAOyqgcW-bAdqqnPKg1EY3GPGxRX8okdbh7_mxTby6uQf%3DgtukA%40mail.gmail.com.

Re: [go-nuts] Can't range over iter.Seq in text/template (go 1.22/dev)

[Ian Lance Taylor]

On Sat, Jul 6, 2024 at 2:21 PM Rory Campbell-Lange
 wrote:
>
> I don't seem to be able to range over an iter.Seq in a template.

...

> ...is an iter.Seq or iter.Seq2 not intended to be added there?


Yes, this is https://go.dev/issue/66107.

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/CAOyqgcWap%2B%2BWiKuL9-ubof0w0mR%2BTb7dxjp77BEd7%3D4aXR7ajA%40mail.gmail.com.

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

[Ian Lance Taylor]

On Sat, Jul 6, 2024 at 7:34 AM 'qiu laidongfeng2' via golang-nuts
 wrote:
>
> I know not to write code with data races?
> The problem is that I find that this code always outputs 1 on the amd64 
> machine,
> I am not sure what effect this data competition has on the execution result,
> whether it is an inevitable result of the amd64 machine to always output 1 or 
> I am lucky to encounter that it is always output 1, so I ask.

I would be surprised if that program ever prints anything other than 1
in practice.  But I am sometimes surprised.

Ian


> 在2024年7月6日星期六 UTC+8 22:20:57 写道：
>>
>> On Sat, Jul 6, 2024 at 7:04 AM 'qiu laidongfeng2' via golang-nuts
>>  wrote:
>> >
>> > Does data race in this program affect execution results?
>> > In amd64, it always output1.
>>
>> If you want to write code like this, use the sync/atomic package.
>> Don't write code with data races.
>>
>> 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/6a2c3ebf-b5e9-4a18-bcf3-d7a4b5fc24a4n%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/CAOyqgcWv7w%3DUEG0eZsZFYTpodX2cgXmXO_6QkgxeJ5A7VKDXAg%40mail.gmail.com.

Re: [go-nuts] errors.Join to return a single error if possible

[Ian Lance Taylor]

On Sat, Jul 6, 2024 at 7:04 AM Andrei Rusakov  wrote:
>
> So, what do you think it makes sense for the function to return a wrapped 
> error even if it contains only one error? Wouldn't it be more rational in 
> such cases for Join to return that single error?

Perhaps that would have made sense, but we can't make a change like
that now that errors.Join has its current behavior.

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/CAOyqgcW4id2S%3D6AhZYwJSVBkR%3DWddU3iTa45GY4v-z8f%3D7pirQ%40mail.gmail.com.

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

[Ian Lance Taylor]

On Sat, Jul 6, 2024 at 7:04 AM 'qiu laidongfeng2' via golang-nuts
 wrote:
>
> Does data race in this program affect execution results?
> In amd64, it always output1.

If you want to write code like this, use the sync/atomic package.
Don't write code with data races.

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/CAOyqgcUJb2L4NbC59u%3DRKD-DkeUA0jT4XXFx74Pc0Vrx4a%3DAWQ%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.21 / FIPS

[Ian Lance Taylor]

On Thu, Jul 4, 2024, 4:47 AM Michael Oguidan 
wrote:

> Hi Dagood,
> Please can you tell me what FIPS's for? And why we can't use it outside
> Google.
>

You can use GOEXPERIMENT=boringcrypto, as described in the README.
However, there is no promise that the Go team will fix any problems you
encounter.  It is not supported.

Ian



On Thursday, July 4, 2024 at 1:45:37 AM UTC dagood wrote:
>
>> Hi Devin,
>>
>> The FIPS functionality in Go (which, to be clear, is not supported for
>> use outside of Google) is documented here: 
>> go/src/crypto/internal/boring/README.md
>> at release-branch.go1.21 · golang/go (github.com)
>> ,
>> and it's used by setting GOEXPERIMENT=boringcrypto.
>>
>> The GOEXPERIMENT=systemcrypto is a feature of the Microsoft fork of Go,
>> not official Go.
>> https://github.com/microsoft/go/blob/microsoft/main/eng/doc/fips/README.md is
>> actually hosted in the microsoft/go repository, where that fork is
>> maintained. I work on it, and I'm happy to help. (And, if you have any more
>> questions related to this fork in the future, feel free to file a GitHub
>> issue on microsoft/go directly.)
>>
>> The issue doesn't seem related to Grafana, but rather because *wire *was
>> built with the Microsoft fork of Go but without specifying a backend, but
>> with GOFIPS=1. *wire* isn't able to be compatible with FIPS without a
>> backend, but it sees that FIPS is requested, so it fails safe. It isn't
>> clear what the caller's intent is and failing is an opportunity to catch a
>> mistake. You should either:
>>
>>1. not set GOFIPS=1 until after calling *wire* (if at all!) or
>>2. build *wire* with GOEXPERIMENT=systemcrypto.
>>
>> I would default to (1). But if you are trying to make a FIPS compliant
>> package build process, (2) would be the step towards that.
>>
>> Whether or not you need GOFIPS=1 at all depends on the purpose of your
>> script/build process.
>>
>> > using GOFIPS=1 worked just fine on Go 1.20.5, however appears not to be
>> the case anymore.
>>
>> Yes, we only added this failsafe as of 1.21 of Microsoft Go. The first
>> bullet in the 1.21 changelog
>> 
>>  has
>> some details.
>>
>> Hope that helps!
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/64e0eb63-0daa-4d5a-8fac-ad48dcb803dfn%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/CAOyqgcWsNz1ywa4A8n-f%3Ds620ghFSxbsJ%2B4p0YAst3JZPJnEWA%40mail.gmail.com.

Re: [go-nuts] Preserving special characters when reading Go POST request body

[Ian Lance Taylor]

On Tue, Jul 2, 2024 at 5:29 PM Hugh Myrie  wrote:

> When I change the %s to %q in the print function I see the special
> characters in their Hexadecimal representations.
>
> See below:
>
> 0011020240702\x1d0201758001030085245467021.00Y50072
> 202407020\x1cDG\x1cDI00\x1cE7\x1cG1200
> \x1cG2X \x1cG310\x1cG4E79   \x03
>
>
> I am using the original code (JSON).
>
> How do I then change them back to the actual characters?
>

If you see the characters with %q, then they are also there with %s.  But
since they aren't printable characters, you aren't seeing them.

To put it another way: what do you expect to see?

Ian




> On Tuesday, July 2, 2024 at 7:15:36 PM UTC-4 Ian Lance Taylor wrote:
>
>> 1) Please send Go code as plain text, not as an image.  Anybody can read
>> plain text.  Images are hard to read.  Thanks.
>>
>> 2) What do you see if you change the %s to %q in the fmt.Printf call?
>>
>> Ian
>>
>> On Tue, Jul 2, 2024 at 3:40 PM Hugh Myrie  wrote:
>>
>>> The original Go function is shown below. Initially, a JSON-encoded
>>> string is sent from the client. The first print function is used to view
>>> the output after decoding.
>>>
>>>
>>> func SendClaim(w http.ResponseWriter, r *http.Request) {
>>> //  strEcho := "Halo"
>>> servAddr := tcpAddress
>>>
>>> type Resp struct {
>>> Status string `json:"status"`
>>> Reply  string `json:"reply"`
>>> }
>>> type Claim struct {
>>> ClaimInfo string `json:"claiminfo"`
>>> }
>>>
>>> var params Claim
>>>
>>> erx := json.NewDecoder(r.Body).Decode(¶ms)
>>> if erx != nil {
>>> http.Error(w, erx.Error(), http.StatusBadRequest)
>>> fmt.Println("Error occurs here")
>>> log.Printf(erx.Error())
>>> return
>>> }
>>> fmt.Printf("Claims: %s \n", params)
>>> //  policy := params.CardNo //r.FormValue("cardno")
>>> //  log.Println("policy # ", policy)
>>>
>>> tcpAddr, err := net.ResolveTCPAddr("tcp", servAddr)
>>> if err != nil {
>>> println("ResolveTCPAddr failed:", err.Error())
>>> respondWithError(w, http.StatusBadRequest, err.Error())
>>> return
>>> }
>>>
>>> data := params.ClaimInfo
>>> //  printr := r.FormValue("printer")
>>>
>>> fmt.Println(data)
>>> conn, err := net.DialTCP("tcp", nil, tcpAddr)
>>> if err != nil {
>>> println("Dial failed:", err.Error())
>>> respondWithError(w, http.StatusBadRequest, err.Error())
>>> return
>>> }
>>>
>>> _, err = conn.Write([]byte(data))
>>> if err != nil {
>>> println("Write to server failed:", err.Error())
>>> respondWithError(w, http.StatusBadRequest, err.Error())
>>> return
>>> }
>>>
>>> reply := make([]byte, 1024)
>>>
>>> _, err = conn.Read(reply)
>>> if err != nil {
>>> println("Write to server failed:", err.Error())
>>> respondWithError(w, http.StatusBadRequest, err.Error())
>>> return
>>> }
>>>
>>> resp := Resp{}
>>> println("reply from server=", string(reply))
>>> resp.Status = "response"
>>> resp.Reply = string(reply)
>>>
>>> respondWithJSON(w, http.StatusOK, resp)
>>>
>>> conn.Close()
>>> }
>>>
>>>
>>> On Tuesday, July 2, 2024 at 9:28:01 AM UTC-4 Hugh Myrie wrote:
>>>
>>>> Copying the result to notepad confirms the missing special characters..
>>>>
>>>> I'll try your suggestion.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>>> Virus-free.www.avg.com
>>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>>>> <#m_-4475757952619024099_m_7810203444138361032_m_3329966587656473292_m_4334311486301273828_DAB4FAD8-2DD

Re: [go-nuts] cannot use a type parameter as RHS in type declaration

[Ian Lance Taylor]

On Tue, Jul 2, 2024 at 5:36 PM Diego Augusto Molina
 wrote:
>
> Hi everyone! I wanted to ask about the error in the title: "cannot use a type 
> parameter as RHS in type declaration".

...

> Considering the three approaches: (A) non-generic; (B) generic with struct; 
> (C) generic with an array of one element:
> 1. Can you explain why this error happens ? what problems it would create 
> that was allowed? Any oneliner pointing to docs or just "look for x" is 
> great! I may be missing something too obvious.
> 2. Are there other atlternatives you can think of, even dumb ones, and how 
> would they compare to the three above?
> 3. Are there other differences or concerns you can think of, that were not 
> addressed above?

See the discussion at https://go.dev/issue/43621.

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/CAOyqgcVTy__9ntwDNzJeXdoSp-LPQ43FrT580zMh4%2BWd2pRbKQ%40mail.gmail.com.

Re: [go-nuts] Preserving special characters when reading Go POST request body

[Ian Lance Taylor]

1) Please send Go code as plain text, not as an image.  Anybody can read
plain text.  Images are hard to read.  Thanks.

2) What do you see if you change the %s to %q in the fmt.Printf call?

Ian

On Tue, Jul 2, 2024 at 3:40 PM Hugh Myrie  wrote:

> The original Go function is shown below. Initially, a JSON-encoded string
> is sent from the client. The first print function is used to view the
> output after decoding.
>
>
> func SendClaim(w http.ResponseWriter, r *http.Request) {
> //  strEcho := "Halo"
> servAddr := tcpAddress
>
> type Resp struct {
> Status string `json:"status"`
> Reply  string `json:"reply"`
> }
> type Claim struct {
> ClaimInfo string `json:"claiminfo"`
> }
>
> var params Claim
>
> erx := json.NewDecoder(r.Body).Decode(¶ms)
> if erx != nil {
> http.Error(w, erx.Error(), http.StatusBadRequest)
> fmt.Println("Error occurs here")
> log.Printf(erx.Error())
> return
> }
> fmt.Printf("Claims: %s \n", params)
> //  policy := params.CardNo //r.FormValue("cardno")
> //  log.Println("policy # ", policy)
>
> tcpAddr, err := net.ResolveTCPAddr("tcp", servAddr)
> if err != nil {
> println("ResolveTCPAddr failed:", err.Error())
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
>
> data := params.ClaimInfo
> //  printr := r.FormValue("printer")
>
> fmt.Println(data)
> conn, err := net.DialTCP("tcp", nil, tcpAddr)
> if err != nil {
> println("Dial failed:", err.Error())
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
>
> _, err = conn.Write([]byte(data))
> if err != nil {
> println("Write to server failed:", err.Error())
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
>
> reply := make([]byte, 1024)
>
> _, err = conn.Read(reply)
> if err != nil {
> println("Write to server failed:", err.Error())
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
>
> resp := Resp{}
> println("reply from server=", string(reply))
> resp.Status = "response"
> resp.Reply = string(reply)
>
> respondWithJSON(w, http.StatusOK, resp)
>
> conn.Close()
> }
>
>
> On Tuesday, July 2, 2024 at 9:28:01 AM UTC-4 Hugh Myrie wrote:
>
>> Copying the result to notepad confirms the missing special characters..
>>
>> I'll try your suggestion.
>>
>> Thanks.
>>
>>
>> 
>> Virus-free.www.avg.com
>> 
>> <#m_3329966587656473292_m_4334311486301273828_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Tue, Jul 2, 2024 at 8:33 AM 'Dan Kortschak' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> On Mon, 2024-07-01 at 12:03 -0700, Hugh Myrie wrote:
>>> > I am trying to preserve special characters (group separators and
>>> > field separators) when reading the request body from a POST request.
>>> >
>>> > When I do a dumpRequest I am able to see the special characters (Hex
>>> > Format, for example: \x1c or \x03). I am sending the data from the
>>> > client as text/plain.
>>> >
>>> > I have tried sending the data as JSON and using the decoder in Go. I
>>> > have also tried using Base64 and decoding in go accordingly. I have
>>> > tried json.unmarshal to decode the incoming JSON data. However, in
>>> > every instance the special characters are removed.
>>> >
>>> > I need the special characters to be preserved so I can send the data
>>> > for further processing. I need the special characters not the
>>> > hexadecimal representation.
>>> >
>>> > I am able to see the actual data being sent to the Go server. I also
>>> > tried encoding the data from the client side.
>>> >
>>> > Your help would be greatly appreciated.
>>>
>>> This looks to be working as expected. https://go.dev/play/p/fqLPbsMKaOm
>>>
>>> How are you seeing the bytes being missing?
>>>
>>>
>>> --
>>> 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/8cLWTdxHQCI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/9cf1e4d31b68f7601839a450e1a9aa572458e756.camel%40kortschak.io
>>> .
>>>
>>
>>
>> --
>> http://www.jaxtr.com/blessed_hope
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discus

Re: [go-nuts] Should the phrasing about method sets in Go FAQ be slightly clarified?

[Ian Lance Taylor]

On Mon, Jul 1, 2024 at 8:12 AM Timur Sharapov  wrote:
>
> https://go.dev/doc/faq#different_method_sets
>
> I am referring to this paragraph that in my opinion answers one of the 
> trickiest questions for new Go developers.
>
> Even in cases where the compiler could take the address of a value to pass to 
> the method, if the method modifies the value the changes will be lost in the 
> caller. As an example, if the Write method of bytes.Buffer used a value 
> receiver rather than a pointer, this code:
>
> var buf bytes.Buffer
> io.Copy(buf, os.Stdin)
> would copy standard input into a copy of buf, not into buf itself. This is 
> almost never the desired behavior.
>
> Even though I understand the explanation, I think that it's a bit unclear.
> If the Write method used a value receiver, then the whole example doesn't 
> make sense and the part "Even in cases where the compiler could take the 
> address of a value" doesn't apply at all because the code works as is, and 
> the compiler doesn't really have to take any addresses.
>
> My bet is that the document meant "if the code above worked..."
>
> What do you think?

I agree that this isn't quite right.  It may read better if we put a
paragraph break between the "even in cases" sentence and the rest.

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/CAOyqgcUj8Ku2_UFCVwRcSG0aBFo9%2BKxkEK%2BX_Jq0DHVpNd5KeA%40mail.gmail.com.

Re: [go-nuts] Preserving special characters when reading Go POST request body

[Ian Lance Taylor]

On Mon, Jul 1, 2024 at 12:04 PM Hugh Myrie  wrote:
>
> I am trying to preserve special characters (group separators and field 
> separators) when reading the request body from a POST request.
>
> When I do a dumpRequest I am able to see the special characters (Hex Format, 
> for example: \x1c or \x03). I am sending the data from the client as 
> text/plain.
>
> I have tried sending the data as JSON and using the decoder in Go. I have 
> also tried using Base64 and decoding in go accordingly. I have tried 
> json.unmarshal to decode the incoming JSON data. However, in every instance 
> the special characters are removed.
>
> I need the special characters to be preserved so I can send the data for 
> further processing. I need the special characters not the hexadecimal 
> representation.
>
> I am able to see the actual data being sent to the Go server. I also tried 
> encoding the data from the client side.
>
> Your help would be greatly appreciated.

Can you provide a reasonably small, but complete, example that
demonstrates the problem?

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/CAOyqgcVT0Yr%2ByZKbMJw0Q%3DKXP%3Desu45y%2BERidgWRXxu3vcJOMQ%40mail.gmail.com.

Re: [go-nuts] is stop the world and restart the world overhead expensive?

[Ian Lance Taylor]

On Mon, Jul 1, 2024 at 5:45 AM 杨杰  wrote:
>
> i implement an goroutine profile which use frame pointer to get traceback.
>
> it need stop and restart the world with 100hz.
>
> is this operation expensive?

Yes.

Since the concern is profiling, I'll note that it will also
significantly affect the program's behavior, so a profile that is
constantly stopping and starting the world may not be a good
reflection of the performance of the program when that is not
happening.

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/CAOyqgcViro_A%3DH4ZMt6V-0%3Dh4Q3vsZS_4DENm8jyfu6yjsy2Zw%40mail.gmail.com.

Re: [go-nuts] Testing specific file in a package

[Ian Lance Taylor]

On Fri, Jun 28, 2024 at 3:25 PM Victor Manuel “Vitu” Giordano
 wrote:
>
> I struggle with performing all the tests written in a file that requires 
> symbols defined on other files of the same package.
>
> For example
> $ go test practice_resource_test.go
> # command-line-arguments [command-line-arguments.test]
> ./practice_resource_test.go:11:12: undefined: PracticeResource
> ./practice_resource_test.go:12:12: undefined: PracticeResource
> FAIL command-line-arguments [build failed]
> FAIL
>
> The symbol PracticeResource is defined in a file called practice_resource 
> present at the same package.
>
> ¿Is it possible to archieve this? If anyone know how  and can explain me I 
> will appreciate that.
> Thanks in advance.
>
> I haven't see how to do it in the official doc and in other doc as well.

When testing a package, you normally write "go test" or "go test
PACKAGEPATH" without listing any files.  Listing files is an unusual
case, only used for a standalone test that is not part of a package.

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/CAOyqgcVm0bj_OPO01eea5%2BKM45art8B%3DMS0uLRZWKeUknipt%2Bg%40mail.gmail.com.

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

[Ian Lance Taylor]

On Tue, Jun 25, 2024 at 9:37 PM 'Axel Wagner' via golang-nuts
 wrote:
>
> you might be interested to learn that Ian has filed a CL adding an FAQ entry.

Now committed at https://go.dev/doc/faq#zero_size_types .

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

Re: [go-nuts] why we still need lock file ?

[Ian Lance Taylor]

On Tue, Jun 25, 2024 at 11:58 PM Akash Kumar  wrote:
>
> As go is using minimum version selection strategy for creating reproducible 
> build list, so why we still need a lock file ? also is there plans to 
> deprecate lock file in future ?

What lock file are you talking about?

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

Re: [go-nuts] go clean -h isn't helpful

[Ian Lance Taylor]

On Sat, Jun 22, 2024, 6:21 PM Will Faught  wrote:

> I see. That doesn't seem very useful to me, so I won't be making a patch
> for it. Thanks anyways.
>

No worries.  We're trying to strike a balance between a reminder and full
documentation.  I don't think we need two different ways to get the full
docs, as long as people can find 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/CAOyqgcWUvqxt1-iOFMzyW7bZUt78Vo9RZd61KQzeXuZF8bdGSg%40mail.gmail.com.

Re: [go-nuts] go clean -h isn't helpful

[Ian Lance Taylor]

On Sat, Jun 22, 2024 at 5:45 PM Will Faught  wrote:
>
> Ian,refer>
> I see. I'm concerned that approach wouldn't scale to the number of clean and 
> build flags there are. I count 8 clean flags and 10+ build flags. That would 
> look like:
>
> > go clean [-i] [-n] [-r] [-x] [-cache] [-testcache] [-modcache] [-fuzzcache] 
> > [-C dir] [-a] [-p n] [-race] [-msan] [-asan] [-cover] [-covermode 
> > set,count,atomic] [-coverpkg pattern1,pattern2,pattern3] ...
>
> That doesn't seem too useful.

Agreed, which is why I did not suggest expanding the build flags.  I
wrote exactly what I think the output "go clean -h" should be.  We
already don't expand the build flags in most of the "go CMD -h"
output.

Ian


> On Sat, Jun 22, 2024 at 5:09 PM Ian Lance Taylor  wrote:
>>
>> On Sat, Jun 22, 2024 at 12:03 AM Will Faught  wrote:
>> >
>> > Sure thing.
>> >
>> > Just want to make sure we're on the same page. We would be changing the 
>> > clean command help message to document its clean and build flags like the 
>> > flags package does:
>> >
>> > usage: go clean [clean flags] [build flags] [packages]
>> >
>> >   -iremove the corresponding installed archive or binary (what 'go 
>> > install' would create)
>> >   -nprint the remove commands it would execute, but not run them
>> >   -rapply recursively to all the dependencies of the packages named by 
>> > the import paths
>> >   -a
>> > force rebuilding of packages that are already up-to-date.
>> >   -p n
>> > the number of programs, such as build commands or
>> > test binaries, that can be run in parallel.
>> > The default is GOMAXPROCS, normally the number of CPUs available.
>> >   -race
>> > enable data race detection.
>> > Supported only on linux/amd64, freebsd/amd64, darwin/amd64, 
>> > darwin/arm64, windows/amd64,
>> > linux/ppc64le and linux/arm64 (only for 48-bit VMA).
>> > [...]
>> >
>> > Run 'go help clean' for details.
>> >
>> > The clean and build flags would be mixed together and ordered 
>> > alphabetically, like flags does.
>> >
>> > Does that look right?
>>
>> No, I was thinking of something different.  The current pattern is
>> that "go CMD -h" prints a short summary of the flags.  For example
>>
>> > go fmt -h
>> usage: go fmt [-n] [-x] [packages]
>> Run 'go help fmt' for details.
>>
>> This is useful for a quick reminder for how to run the command, and
>> shows people who need more information how to get more information.
>> So I think "go clean -h" should print something like
>>
>> go clean [-i] [-r] [-cache] [-testcache] [-modcache] [-fuzzcache]
>> [build flags] [packages]
>> Run ' go help clean' for details
>>
>>
>>
>> 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/CAOyqgcWtVTZGNNmq%2B-cMZdyHs4caeyLGMfgW6RSfebz1vPKALQ%40mail.gmail.com.

Re: [go-nuts] go clean -h isn't helpful

[Ian Lance Taylor]

On Sat, Jun 22, 2024 at 12:03 AM Will Faught  wrote:
>
> Sure thing.
>
> Just want to make sure we're on the same page. We would be changing the clean 
> command help message to document its clean and build flags like the flags 
> package does:
>
> usage: go clean [clean flags] [build flags] [packages]
>
>   -iremove the corresponding installed archive or binary (what 'go 
> install' would create)
>   -nprint the remove commands it would execute, but not run them
>   -rapply recursively to all the dependencies of the packages named by 
> the import paths
>   -a
> force rebuilding of packages that are already up-to-date.
>   -p n
> the number of programs, such as build commands or
> test binaries, that can be run in parallel.
> The default is GOMAXPROCS, normally the number of CPUs available.
>   -race
> enable data race detection.
> Supported only on linux/amd64, freebsd/amd64, darwin/amd64, 
> darwin/arm64, windows/amd64,
> linux/ppc64le and linux/arm64 (only for 48-bit VMA).
> [...]
>
> Run 'go help clean' for details.
>
> The clean and build flags would be mixed together and ordered alphabetically, 
> like flags does.
>
> Does that look right?

No, I was thinking of something different.  The current pattern is
that "go CMD -h" prints a short summary of the flags.  For example

> go fmt -h
usage: go fmt [-n] [-x] [packages]
Run 'go help fmt' for details.

This is useful for a quick reminder for how to run the command, and
shows people who need more information how to get more information.
So I think "go clean -h" should print something like

go clean [-i] [-r] [-cache] [-testcache] [-modcache] [-fuzzcache]
[build flags] [packages]
Run ' go help clean' for details



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/CAOyqgcXkKGea%3DEfuGbVGS26MtwZdA2QU8TbRHpRbO2X8k3F%2BwQ%40mail.gmail.com.

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

[Ian Lance Taylor]

On Wed, Jun 19, 2024 at 9:59 AM Oliver Eikemeier
 wrote:
>
> I'm observing some strange behavior and could use some help understanding it.
>
> The specification says: “Pointers to distinct zero-size variables may or may 
> not be equal.”
>
> With the following program (Go Playground):
>
> var ( a struct{} b struct{} eq = &a == &b ) func f1() { println("&a:", &a) 
> println("&b:", &b) println("&a == &b:", eq) }
>
>
> I'll get
>
> &a: 0x537580 &b: 0x537580 &a == &b: false
>
>
> Okay, a and b are empty structs, do not escape, so they share the same 
> address - fine. Also, some optimizer sees that a and b are different 
> variables, so their addresses must be different, and decides to make &a == &b 
> a constant - wrong, but I can live with that.
>
> My question would be: Is this behavior expected, somehow defined by the 
> specification, or is it undefined behavior?

The specs says, as you say above, "Pointers to distinct zero-size
variables may or may not be equal.”  That means that you can't predict
the result of any given comparison of addresses of zero-sized
variables.  Could be true, could be false, could change each time you
do the comparison.  So this behavior is permitted by the spec.



> Let's try to confuse the optimizer a little (Go Playground):
>
> var ( a struct{} b struct{} aa = &a ba = &b eq = aa == ba ) func f1() { 
> println("&a:", aa) println("&b:", ba) println("&a == &b:", eq) }
>
> results in
>
> &a: 0x5375a0 &b: 0x5375a0 &a == &b: true
>
>
> Mission accomplished, too complicated to calculate in advance. But globals 
> are bad, so (Go Playground):
>
> func f2() { var ( a struct{} b struct{} aa = &a ba = &b eq = aa == ba ) 
> println("&a:", aa) println("&b:", ba) println("&a == &b:", eq) }
>
> &a: 0xc46740 &b: 0xc46740 &a == &b: false
>
>
> Seems like inlining helps generate false answers.
>
> The interesting part here is that I can create two pointers (which may or may 
> not be equal per specification), but depending on how I compare them I get 
> different results.

Yes, as the spec permits.

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

Re: [go-nuts] Why can't I concationate two slices of an interface and implemetation?

[Ian Lance Taylor]

On Tue, Jun 18, 2024 at 5:43 PM Ian Spence  wrote:
>
> I've encountered a limitation and I'd like to understand what's going on and 
> why it's not working the way I would expect.
>
> If I have a slice of an interface type, and another slice of a type that 
> implements that interface, I cannot concat these slices together using append 
> - but I can add each item one by one.
>
> I would expect that interface implementations would also apply to slices, but 
> it looks like it doesn't?

That is correct.  The language permits implicitly converting a single
value to an interface type.  It does not permit implicitly converting
a slice of some type to a slice of some interface type.  See the FAQ
entry https://go.dev/doc/faq#convert_slice_of_interface .

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/CAOyqgcUt4%3DpNX-ruDG9h2cCiFPG8U0uGZBAM%3DfdVt-Lo1yj%3DJA%40mail.gmail.com.

Re: [go-nuts] go clean -h isn't helpful

[Ian Lance Taylor]

On Mon, Jun 17, 2024 at 10:52 PM Will Faught  wrote:
>
> > People who already know what the command does can use that short summary to 
> > remind themselves of the available options.
>
> Which options do you mean? My point was that it doesn't document any options.

Oh, sorry, I see what you mean.  That's true, that isn't very helpful.
Want to send a patch?

Ian

> On Mon, Jun 17, 2024 at 5:57 PM Ian Lance Taylor  wrote:
>>
>> On Mon, Jun 17, 2024 at 5:28 PM will@gmail.com
>>  wrote:
>> >
>> > ❯ go clean -h
>> > usage: go clean [clean flags] [build flags] [packages]
>> > Run 'go help clean' for details.
>> >
>> > This just tells me to invoke another help command.
>> >
>> > The flags package has the opinion that command help should print the doc 
>> > for flags. Shouldn't we do that for go clean -h too?
>>
>> The intent is that "go clean -h" prints a short summary.  People who
>> already know what the command does can use that short summary to
>> remind themselves of the available options.  For people who don't know
>> what the command does, there is "go help clean".
>>
>> 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/CAOyqgcVBDMqrEVctMSykcrgD5uCR_y%2Beu1G8PPd691%3D8jDteRQ%40mail.gmail.com.

Re: [go-nuts] Re: Breaking an io.Pipe loop

[Ian Lance Taylor]

On Mon, Jun 17, 2024 at 7:49 PM Salvatore Domenick Desiano
 wrote:
>
> Here's a hopefully semantically identical minimal example:
>
> func main() {
>
> cmdName := "/bin/bash"
> cmdArgs := []string{"-c", "sleep 5"}
> cmdStdinR, cmdStdinW := io.Pipe()
> cmdStdoutR, cmdStdoutW := io.Pipe()
> go func() {
>
> defer cmdStdinW.Close()
>
> io.Copy(cmdStdinW, cmdStdoutR)
>
> }()
> cmd := exec.Command(cmdName, cmdArgs...)
> cmd.Stdout = cmdStdoutW
> cmd.Stdin = cmdStdinR
> if err := cmd.Run(); err != nil {
>
> fmt.Println(err)
>
> }
>
> }
>
> This program deadlocks after seconds. The three locked Go routines are the 
> io.Copy( (stuck inside io.Copy because cmdStdoutR doesn't close), the 
> exec.Command Go routine (also stuck in an io.Copy) and the main routine 
> (stuck in cmd.Wait()).


I haven't checked whether this is the problem, but as someone else
pointed out this is a strange place to use io.Pipe.  Much better to
use os.Pipe.  Much better still to use exec.Cmd.StdinPipe and
exec.Cmd.StdoutPipe.

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/CAOyqgcVtbc-77oZ5Pibm1Jg6DJKwgvCT7xXLyqU_fPz8%2B0F1dg%40mail.gmail.com.

Re: [go-nuts] go clean -h isn't helpful

[Ian Lance Taylor]

On Mon, Jun 17, 2024 at 5:28 PM will@gmail.com
 wrote:
>
> ❯ go clean -h
> usage: go clean [clean flags] [build flags] [packages]
> Run 'go help clean' for details.
>
> This just tells me to invoke another help command.
>
> The flags package has the opinion that command help should print the doc for 
> flags. Shouldn't we do that for go clean -h too?

The intent is that "go clean -h" prints a short summary.  People who
already know what the command does can use that short summary to
remind themselves of the available options.  For people who don't know
what the command does, there is "go help clean".

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/CAOyqgcUuhLsvy5gyub0i%3Dxr5nqnqHWF%2BJevdCn4cHFSf9j8buQ%40mail.gmail.com.

Re: [go-nuts] Fwd: cmd.Wait & io.Pipe & SIGKILL

[Ian Lance Taylor]

On Sun, Jun 16, 2024 at 3:20 PM Salvatore Domenick Desiano
 wrote:
>
> I'm hoping y'all can help me get the correct semantics for code that sets up 
> an external process, replaces Stdin, Stderr, Stdout, runs the command, calls 
> exec.Command.Wait() and handles SIGKILL correctly.
>
> I've read more than two dozen threads, PRs, and bug reports about how 
> exec.Command interacts with io.Pipe and SIGKILL/cmd.Kill(). I've seen 
> comments from Ian that some problems can't be solved and a few regrets about 
> the current design but nothing that describes a working approach.
>
> What I want is a function that does this:
>
> ctx, cancelCmd := context.WithCancel(context.Background())
> cmd := exec.CommandContext(ctx, cmdName, cmdArgs...)
> cmd.Stdin = stdinPipe
> cmd.Stdout = stdoutPipe
> cmd.Stderr = stderrPipe
> if err := cmd.Run(); err != nil {
>
> g.log.Warnf("Run error: %w", err)
>
> }
> return nil
>
> and that returns when the command exits, gets an (externally issued) SIGKILL, 
> or gets a cancelCmd(). Every combination I've tried hangs because the pipes 
> aren't closed. Although the pipes are monitored and drained (not shown), that 
> doesn't help because the command doesn't get a chance to close them.
>
> What am I missing? Do I need a goroutine to watch the process table?

First I'll ask what is keeping the pipes open?  if the child process
is killed, the child's copy of the pipes will be closed.  Is the child
passing them along to some other process?  Or is the parent process
keeping them open?  Can either of those be changed?

That said, Go 1.20 added new Cancel and WaitDelay fields to
os/exec.Cmd.  These fields may be used to control how the parent
process should behave when waiting for a child with open pipes.

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/CAOyqgcW%2B3-f8edProCsXSy0_ziYxV5bki%3Dsb5_eUHbF1SGJ2-w%40mail.gmail.com.

Re: [go-nuts] Does I/O in Goroutine blocks the underlying thread?

[Ian Lance Taylor]

On Mon, Jun 3, 2024 at 1:09 AM Haoyang Fan  wrote:
>
> Let's say if I'm writing a program in Golang that is similar to the "top" 
> command, which rapidly reads the files under /proc directory (e.g. every 1 
> second) and I'm launching goroutines to read different parts of that 
> directory. Since /proc is a virtual filesystem not actually stored on the 
> disk, can I assume in this case there won't be any thread blocked?

Technically the threads will block briefly as they read from the /proc
file system.  However, I would expect that the time they spend blocked
would be very short, imperceptible to a 1 second loop.

Ian


> On Friday, May 31, 2024 at 12:34:38 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, May 31, 2024 at 12:09 PM Haoyang Fan  wrote:
>> >
>> > I was always under the impression that Go solely uses async I/O under the 
>> > hood so that when invoking a seemingly blocking call like os.File.Read the 
>> > underlying thread won't be blocked. Go scheduler will save the context of 
>> > current goroutine and schedule other goroutines to run on that thread. 
>> > This understanding seems to be aligned with most material I can find on 
>> > the internet.
>>
>> That is how it works for most operations. That said, since you
>> specifically mentioned os.File.Read, if the os.File is a disk file,
>> then on most Unix systems the goroutine and the underlying thread will
>> indeed block for the duration of the I/O. That is because most Unix
>> systems have no mechanism for non-blocking I/O for disk files, so the
>> I/O does block the underlying thread. The underlying thread will not
>> block for I/O on a network connection or a pipe. As a practical
>> matter this is only relevant when using a networked file system, as
>> local file systems are fast.
>>
>> > However, recently when I was reading the slides 
>> > (https://go.dev/talks/2012/waza.slide#32), on slide 32 I notice it says 
>> > "When a goroutine blocks, that thread blocks but no other goroutine 
>> > blocks". This is contradictory and make me wonder does Go really perform 
>> > I/O in an asynchronous manner (e.g. like select/poll/epoll in Linux) under 
>> > the hood?
>> >
>> > Can somebody please clarify?
>>
>> That talk is from 2012. The network poller and scheduler have been
>> rewritten since then.
>>
>> 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/4e467662-c516-4956-aa76-06f3b244c656n%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/CAOyqgcWcv0ZTaOD7aDA31WD10bvPpvxDvEkE%2BSHtb30mCLc%3DYQ%40mail.gmail.com.

Re: [go-nuts] Changing Epoll mode for Golang runtime

[Ian Lance Taylor]

On Mon, Jun 3, 2024 at 12:42 PM armin afsharian  wrote:
>
> For my research project, I'm trying to change the Go runtime to use 
> "Epolloneshot" instead of the default "Edge-Triggered" mode. Based on what 
> I've gathered from the code, I've changed two functions in 
> src/runtime/netpoll_epoll.go.
>
> First, I updated the netpollopen function to use the Epolloneshot flag 
> instead of the Epollet flag. Second, I modified the netpollarm function, 
> which isn't used in Linux, to rearm notifications for Epolloneshot. I also 
> tweaked poll_runtime_pollWait() in src/runtime/netpoll.go to call netpollarm 
> for Linux.
>
> Now, I'm running into an issue where HTTP tests for compiling Go are failing. 
> Here's the error I'm seeing:
>
> "httptest.Server blocked in Close after 5 seconds, waiting for connections:
>
> *net.TCPConn 0xc000221520 127.0.0.1:51836 in state active
>
> panic: test timed out after 9m0s"
>
> I suspect that the rearming might be incorrect, causing the server to stall 
> indefinitely.
>
> Just so you know, I'm using Ubuntu 22.04 and Go 1.18.10.

I don't know what the problem is.

That said, look at how netpoll_solaris.go calls netpollupdate from netpoll.

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

Re: [go-nuts] Does I/O in Goroutine blocks the underlying thread?

[Ian Lance Taylor]

On Fri, May 31, 2024 at 12:09 PM Haoyang Fan  wrote:
>
> I was always under the impression that Go solely uses async I/O under the 
> hood so that when invoking a seemingly blocking call like os.File.Read the 
> underlying thread won't be blocked. Go scheduler will save the context of 
> current goroutine and schedule other goroutines to run on that thread. This 
> understanding seems to be aligned with most material I can find on the 
> internet.

That is how it works for most operations.  That said, since you
specifically mentioned os.File.Read, if the os.File is a disk file,
then on most Unix systems the goroutine and the underlying thread will
indeed block for the duration of the I/O.  That is because most Unix
systems have no mechanism for non-blocking I/O for disk files, so the
I/O does block the underlying thread.  The underlying thread will not
block for I/O on a network connection or a pipe.  As a practical
matter this is only relevant when using a networked file system, as
local file systems are fast.

> However, recently when I was reading the slides 
> (https://go.dev/talks/2012/waza.slide#32), on slide 32 I notice it says "When 
> a goroutine blocks, that thread blocks but no other goroutine blocks". This 
> is contradictory and make me wonder does Go really perform I/O in an 
> asynchronous manner (e.g. like select/poll/epoll in Linux) under the hood?
>
> Can somebody please clarify?

That talk is from 2012.  The network poller and scheduler have been
rewritten since then.

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/CAOyqgcVXYzWZZ881Si%2B6YcxVbsdme%3DcomqoiutGyx4o0g5SCBQ%40mail.gmail.com.

Re: [go-nuts] using runtime cgo.Handle passing struct types

[Ian Lance Taylor]

On Thu, May 16, 2024 at 12:57 AM Pavan  wrote:
>
> Thanks . Yes it works when C API takes uintptr_t. In my case, the C API 
> expects void * which i can not change, so I was trying to make it work with 
> the variant example stated above.

In C, unlike Go, you can convert between void* and uintptr_t.  When
using cgo, one approach is a little wrapper function in the cgo
comment that takes a uintptr_t and calls the real function with a
conversion to void*.

Ian

> On Thursday, May 16, 2024 at 5:28:55 AM UTC+5:30 Ian Lance Taylor wrote:
>>
>> On Tue, May 14, 2024 at 10:37 PM Pavan  wrote:
>> >
>> > I need to pass value of struct type, which has C strings and functions to 
>> > C function as void* argument. C layer would provide this struct type data 
>> > back to go function. Below is the sample program. It panics if the handle 
>> > used is returned from getH function. It works fine if the handle is 
>> > global. Can the handle be dynamically returned from getH and make it work. 
>> > Please correct if i missed something..
>> >
>> >
>> >
>> > package main
>> >
>> > /*
>> > struct dt {
>> > void *context;
>> > };
>> > typedef struct dt dt;
>> >
>> > extern void MyGoPrint(void *context);
>> > static inline void myprint(struct dt *a1) {
>> > MyGoPrint(a1->context);
>> > }
>> > */
>> > import "C"
>> > import (
>> > "context"
>> > "runtime/cgo"
>> > "unsafe"
>> > )
>> >
>> > //export MyGoPrint
>> > func MyGoPrint(context unsafe.Pointer) {
>> > h := *(*cgo.Handle)(context)
>> > val := h.Value().(accessTokenCB)
>> > println(val.id)
>> > h.Delete()
>> > }
>> >
>> > type At struct {
>> > Tok string
>> > }
>> >
>> > type accessTokenCB struct {
>> > ctx context.Context
>> > callback func(context.Context, *At) error
>> > id uint64
>> > ctoken *C.char
>> > cprivateKey *C.char
>> > }
>> >
>> > func getH() cgo.Handle {
>> > cb := func(ctx context.Context, tok *At) error {
>> > tok.Tok = "123"
>> > return nil
>> > }
>> > val := accessTokenCB{callback: cb, ctx: context.Background(), id: 32, 
>> > ctoken: nil, cprivateKey: nil}
>> > h := cgo.NewHandle(val)
>> > return h
>> >
>> > }
>> >
>> > var h cgo.Handle
>> >
>> > func main() {
>> > var h cgo.Handle // commenting this line runs the program successfully 
>> > else it panics. (cgo argument has Go pointer to unpinned Go pointer)
>> > h = getH()
>> > var poolCt C.dt
>> > poolCt.context = unsafe.Pointer(&h)
>> > C.myprint(&poolCt)
>> > // Output: 32
>> > }
>>
>> You aren't following the pattern shown at
>> https://pkg.go.dev/runtime/cgo#Handle. Pass the cgo.Handle value to C
>> code, not the address of the cgo.Handle value. Catch the cgo.Handle
>> value as a uintptr_t in C. The point of using cgo.Handle is to avoid
>> difficulties passing pointers between Go and C. When you pass a
>> pointer to a cgo.Handle, you just get those difficulties back again.
>>
>> 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/39afbb8b-8361-40a2-967f-0f462ef45994n%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/CAOyqgcXiL6%2Bm_HtF0SYuExy2Bu9_o%2B3pVAt-FCG3WX05zUOb1A%40mail.gmail.com.

Re: [go-nuts] using runtime cgo.Handle passing struct types

[Ian Lance Taylor]

On Tue, May 14, 2024 at 10:37 PM Pavan  wrote:
>
> I need to pass value of struct type, which has C strings and functions to C 
> function as void* argument.  C layer would provide this struct type data back 
> to go function. Below is the sample program. It panics if the handle used is 
> returned from getH function. It works fine if the handle is global. Can the 
> handle be dynamically returned from getH and make it work. Please correct if 
> i missed something..
>
>
>
> package main
>
> /*
> struct dt {
>   void *context;
> };
> typedef struct dt dt;
>
> extern void MyGoPrint(void *context);
> static inline void myprint(struct dt *a1) {
> MyGoPrint(a1->context);
> }
> */
> import "C"
> import (
> "context"
> "runtime/cgo"
> "unsafe"
> )
>
> //export MyGoPrint
> func MyGoPrint(context unsafe.Pointer) {
> h := *(*cgo.Handle)(context)
> val := h.Value().(accessTokenCB)
> println(val.id)
> h.Delete()
> }
>
> type At struct {
> Tok string
> }
>
> type accessTokenCB struct {
> ctx context.Context
> callbackfunc(context.Context, *At) error
> id  uint64
> ctoken  *C.char
> cprivateKey *C.char
> }
>
> func getH() cgo.Handle {
> cb := func(ctx context.Context, tok *At) error {
> tok.Tok = "123"
> return nil
> }
> val := accessTokenCB{callback: cb, ctx: context.Background(), id: 32, ctoken: 
> nil, cprivateKey: nil}
> h := cgo.NewHandle(val)
> return h
>
> }
>
> var h cgo.Handle
>
> func main() {
> var h cgo.Handle // commenting this line runs the program successfully else 
> it panics. (cgo argument has Go pointer to unpinned Go pointer)
> h = getH()
> var poolCt C.dt
> poolCt.context = unsafe.Pointer(&h)
> C.myprint(&poolCt)
> // Output: 32
> }

You aren't following the pattern shown at
https://pkg.go.dev/runtime/cgo#Handle.  Pass the cgo.Handle value to C
code, not the address of the cgo.Handle value.  Catch the cgo.Handle
value as a uintptr_t in C.  The point of using cgo.Handle is to avoid
difficulties passing pointers between Go and C.  When you pass a
pointer to a cgo.Handle, you just get those difficulties back again.

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

Re: [go-nuts] Permissions in ~/go/pkg

[Ian Lance Taylor]

On Fri, May 10, 2024 at 2:11 PM Tobias Klausmann
 wrote:
>
> On Fri, 10 May 2024, Ian Lance Taylor wrote:
> > This is a choice made by Go.  You can override with the -modcacherw
> > option to "go build", "go test", "go install", and similar code.  You
> > can make that option the default by setting GOFLAGS in the environment
> > or via "go env GOFLAGS=...".
> >
> > You can also remove the module cache using "go clean -modcache".
>
> Thanks for the explanation! What is the rationale for the read-only
> perms, though?

It's essential for supply chain security that builds with a specific
version of a package always use the same code.  It's natural for
debugging for people to look at the source code in the module cache.
Making that source code read-only removes a class of accidents in
which somebody looking at the code in the module cache modifies it,
without necessarily realizing that that will affect all builds on that
machine that use that package.

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/CAOyqgcX7x39RKShv%2ByJBt%3DztoQWs1MO%3DcZqiseDtXrsvjBNV3g%40mail.gmail.com.

Re: [go-nuts] Permissions in ~/go/pkg

[Ian Lance Taylor]

On Fri, May 10, 2024 at 10:43 AM Tobias Klausmann
 wrote:
>
> I test and try a whole load of Go tools and libraries, and as a result,
> my ~go/pkg dir quickly grows. While I'd love some kind of automatic
> expiry for that cache, I am fine with just occasionally running rm-rf on
> that dir myself.
>
> ... except it doesn't work. For some unclear reason, some of those
> directories and files are created with readonly permissions:
>
> ```
> $ rm -rf go/pkg
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/.gitattributes': 
> Permission denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/.gitignore': Permission 
> denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/LICENSE': Permission 
> denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/README.md': Permission 
> denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/bmp-string.go': 
> Permission denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/bmp-string_test.go': 
> Permission denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/crypto.go': Permission 
> denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/crypto_test.go': 
> Permission denied
> rm: cannot remove 
> 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/errors.go': Permission 
> denied
> [... lots more elided ...]
> $ stat go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/errors.go
>   File: go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/errors.go
>   Size: 751 Blocks: 8  IO Block: 4096   regular file
> Device: 0,36Inode: 7317588 Links: 1
> Access: (0444/-r--r--r--)  Uid: ( 1000/klausman)   Gid: ( 1000/klausman)
> Access: 2024-04-04 11:04:37.367542592 +0200
> Modify: 2024-04-04 11:04:37.367542592 +0200
> Change: 2024-04-04 11:04:37.367542592 +0200
>  Birth: 2024-04-04 11:04:37.367542592 +0200
> $
> ```
>
> Needless to say, this is annoying, and while I can 'fix' it by doing a
> find|xargs chmod, I'd rather the permissions weren't this restrictive in
> the first place.
>
> So I wonder why they look like that. Is it a umask issue? Or something
> in git's config? Or is Go at fault here?

This is a choice made by Go.  You can override with the -modcacherw
option to "go build", "go test", "go install", and similar code.  You
can make that option the default by setting GOFLAGS in the environment
or via "go env GOFLAGS=...".

You can also remove the module cache using "go clean -modcache".

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/CAOyqgcVAikLCXX0UAqhtK%3D5%3D2hqwkEQ%2BZSJhkhHg6EOTZ3a%2BXQ%40mail.gmail.com.

Re: [go-nuts] just started using modules, what have i missed? (continuation..)

[Ian Lance Taylor]

On Mon, May 6, 2024 at 9:40 AM 'simon place' via golang-nuts
 wrote:
>
> OK, i had thought, (without understanding why), you can't/don't install 
> non-main packages, as the error message says. ( as mentioned in previous post)
>
> simon@fedora:~$ go install github.com/vulkan-go/vulkan@latest
> package github.com/vulkan-go/vulkan is not a main package
>
> but it works sometimes? (still error message)
>
> simon@fedora:~$ go install github.com/xyproto/png2svg@latest
> go: downloading github.com/xyproto/png2svg v1.5.4
> go: downloading github.com/xyproto/tinysvg v1.1.0
> package github.com/xyproto/png2svg is not a main package
>
> and why not install the latest if not specified anyway?

It didn't work either time.  In the second case it just did some other
stuff before noticing.

Before modules, it made sense to "go install" a non-main package: that
would build the package and set it up to be imported by other
packages.  With modules, though, it doesn't make any sense.  The
go.mod file specifies exactly what version of a non-main package to
use.  And the compiled form of packages is stored in the package
cache.  Installing a non-main package isn't going to affect how
anything else is built.  For a while it was available essentially a
no-op.  Now it gets an error.

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

Re: [go-nuts] Unused local constants not a compiler error

[Ian Lance Taylor]

On Thu, May 2, 2024 at 2:48 PM will@gmail.com  wrote:
>
> Was this always the case? Is this a bug? Seems like it should be a compiler 
> error, like unused local variables.

Yes, it's always been the case.  It would probably  be painful to change it now.

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

Re: [go-nuts] understanding garbage collection logging

[Ian Lance Taylor]

On Thu, May 2, 2024 at 12:48 PM Doug Whitfield  wrote:
>
> I come from java-land, and am having some trouble figuring out gc logging in 
> go. I have been asked to contribute to a memory leak issue in Minio, which is 
> written in Go.

The first way to try to rack down a memory leak is heap profiling.
For example see https://go.dev/blog/pprof, the section on -memprofile.

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

Re: [go-nuts] loading Directives for ptest and pxtest

[Ian Lance Taylor]

On Wed, May 1, 2024 at 2:36 PM Menno van Rahden  wrote:
>
> Hello, I'm trying to tweak the Go stdlib test cmd a bit to support certain 
> directives, but hitting some resistance.
>
> I'd like to understand why the `load.Package.Internal.Build` instances for 
> `ptest` and `pxtest` (see: 
> https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/test/test.go;drc=0159150a4aa0b10f9845af94726cd67ffee93b75;l=)
>  don't contain the Directives, even though the fields 
> `load.Package.[EmbedPatterns|TestEmbedPatterns|XTestEmbedPatterns]` are 
> populated correctly.
> Print-out the values for embed patterns and Directives.
>
> Reproducing this is pretty simple:
> Create a project with a package with a test file and a test-package file (for 
> xtest). Add random directives (e.g. `//go:generate echo "hello world"` and 
> `//go embed `) and execute the tests with the freshly built binary.
>
> Does anybody by any change know how to achieve that these fields are set 
> consistently and can lead me in the right direction?

I haven't tried, but I would expect to find them in the TestDirectives
and XTestDirectives fields.

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/CAOyqgcUG%3D7s7QpGvbqzoz9huprArVuJ2wR-O9DyBStdJ_mjYpg%40mail.gmail.com.

Re: [go-nuts] tuples! tuples! tuples!

[Ian Lance Taylor]

On Sun, Apr 28, 2024 at 4:10 AM Andrew Harris  wrote:
>
> 1. Tuple types
> Outside of generics, tuple type syntax requires named fields.
>
> TupleType = "(" { IdentifierList Type [ ", " ] } ")" .
>
> // e.g.:
> type Point (X, Y int)
>
> More irregularly, the TupleType syntax is used exclusively to declare named 
> types, and these named tuple types cannot implement methods. As a result, a 
> named tuple type is entirely defined at the site of the type definition.

Thanks for writing this up.

This part of what you wrote seems too similar to a struct.  I don't
know whether we will ever add tuples to Go, but I'm certain that if we
add them they must be clearly distinct from structs.  If people ever
start wondering "should I use a struct or should I use a tuple," then
we have failed.  One of the goals of Go is that it should be a simple
language.  One of the characteristics of a simple language is that
people spend their time writing code.  They don't spend their time
considering which aspects of a language to use and how.

Go is also intended to be an orthogonal language.  That means that a
concept should apply wherever it is meaningful.  In particular, in Go,
any named type should be permitted to have methods.  To add a
restriction saying that certain kinds of types can't have methods is
to complicate the language and means that people have more to
remember.

Thanks.

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/CAOyqgcWuiBPhj%3D8wsXWXRKz6%2BdW%3D1jdLQObkc93GOiY5Hwg_3Q%40mail.gmail.com.

Re: [go-nuts] time.ParseDuration does not accept scientific notation

[Ian Lance Taylor]

On Fri, Apr 26, 2024 at 3:39 PM Scott Pakin  wrote:
>
> While parsing output from some third-party program, I discovered that 
> time.ParseDuration does not accept inputs expressed in scientific notation 
> even though strconv.ParseFloat does accept such inputs. Here’s an playground 
> example demonstrating this limitation: https://go.dev/play/p/G-1FveHxpZ3.
>
> Any chance ParseDuration could be enhanced to accept the same numerical 
> values as ParseFloat?

The first step would be to open a proposal for this change.  See
https://github.com/golang/proposal#readme.  Thanks.

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/CAOyqgcXGQPCBJN%3D-yK7qDmKTUfcLUHsO-Sd4Cj81ub-uWAVVaw%40mail.gmail.com.

Re: [go-nuts] generics question

[Ian Lance Taylor]

On Mon, Apr 22, 2024 at 11:01 PM Jochen Voss  wrote:
>
> This works, see my code below.  Followup question: is there a way to refer to 
> the new type without having to list both the element type and the pointer 
> type separately?

Unfortunately there is not.  At some point in the future the language
may support type inference for type arguments to types, for cases
where one type argument can be inferred from another type argument.
Currently that is not supported because there are some complex issues
involving cyclical types that need to be resolved or side-stepped.

In Go 1.23 I think it should be possible to simplify using these kinds
of types with a type alias as in "type X[E] = C[E, *E]".

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

Re: [go-nuts] generics question

[Ian Lance Taylor]

On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss  wrote:
>
> Using generics, can I somehow write a constraint which says that *T (instead 
> of T) implements a certain interface?  The following code illustrated what 
> I'm trying to do:
>
> type A int
>
> func (a *A) Set(x int) {
> *a = A(x)
> }
>
> type B string
>
> func (b *B) Set(x int) {
> *b = B(strconv.Itoa(x))
> }
>
> type C1 struct {
> Val []A
> }
>
> func (c *C1) Set(v int) {
> for i := range c.Val {
> c.Val[i].Set(v)
> }
> }
>
> type C2 struct {
> Val []B
> }
>
> func (c *C2) Set(v int) {
> for i := range c.Val {
> c.Val[i].Set(v)
> }
> }
>
> I would like to use generics to use a single definition for the methods which 
> here are func (c *C1) Set(v int) and func (c *C2) Set(v int).  (My real code 
> has many base types, instead of just A and B.)  How can I do this?
>
> I tried the naive approach:
>
> type C[T interface{ Set(int) }] struct {
> Val []T
> }
>
> but when I try to use the type C[A] now, I get the error message "A does not 
> satisfy interface{Set(int)} (method Set has pointer receiver)".


type C[P interface {
 *E
Set(int)
}, E any] struct {
Val []P
}

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/CAOyqgcXSqw6JOmNrjyJ1KWn9MB3p%2BDYUooC0byRP%2BqB0x7jpHg%40mail.gmail.com.

Re: [go-nuts] error : undefined: app.NewWindow

[Ian Lance Taylor]

On Mon, Apr 22, 2024 at 10:54 AM AndyPeng  wrote:
>
> Imported the "gioui.org/app" package,but got an error when compiling: 
> undefined: app.NewWindow.

Please tell us exactly what you did and exactly what happened.  Show
us the code.

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/CAOyqgcX9fwrqAM-ck_AYWYz3qc-j3hxzgJtyaHOGZFL-P1VM4g%40mail.gmail.com.

Re: [go-nuts] compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http package

[Ian Lance Taylor]

On Sat, Apr 20, 2024 at 7:34 PM Ron Hermsen  wrote:
>
> compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http 
> package
>
> I tried a number of earlier releases but looks only the latest two fail.
> (each build takes about 40min, so didn't try more options)
>
> 
> ok  net 8.598s
> panic: test timed out after 9m0s
> running tests:
> 
> FAILnet/http540.260s
> 
> FAIL
> go tool dist: Failed: exit status 1
>
>
> system details:
> TinyCoreLinux, CorePlus64-15.0
>
> $ uname -a
> Linux testapps 6.6.8-tinycore64 #666 SMP Sat Dec 23 16:41:21 UTC 2023 x86_64 
> GNU/Linux
>
> Both source version and the bootstrap are 1.22.2 (or both are 1.21.9).
>
> Tried source version 1.22.2 and bootstrap version 1.22.0 which failed the 
> net/http package the same way.


I don't know why the tests are taking so long on your system, but your
Go distribution is installed and working.  It is only failing during
the testing phase.

To explore what is happening with net/http, try running "go test
-test.short -test.v net/http".  On my laptop it takes just a few
seconds.  Using -test.v may show which test is hanging.

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/CAOyqgcWhdXE%3DhC5RHyTfsnJ3PqPwpqqjetwDrKZKpTE%3DptjruA%40mail.gmail.com.

Re: [go-nuts] TestCopyNWriteTo

[Ian Lance Taylor]

On Sun, Apr 14, 2024 at 8:05 PM Stephen  wrote:
>
> https://github.com/golang/go/blob/c0a0ba254c48fc855f9501b0bd3b78e6847ca923/src/io/io_test.go#L167
>
> I was walking through this code, and it didn't seem to hit [WriteTo] 
> (https://github.com/golang/go/blob/c0a0ba254c48fc855f9501b0bd3b78e6847ca923/src/io/io.go#L410-L412)
>  because of LimitReader
>
> Is this intended behavior?

The purpose of the test is to make sure that CopyN does the correct
thing even if the source type implements WriteTo.  So, yes, this is
intended behavior.

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/CAOyqgcXL%3DctU1qa%3DjdVpFudSEfGcH3aTt-c860mjoiyeEOBWnA%40mail.gmail.com.

Re: [go-nuts] Is it possible to "extract" the generic [T] from a reflected type ?

[Ian Lance Taylor]

On Tue, Apr 9, 2024 at 9:41 AM Mihai Barbu  wrote:
>
> I need to call some generic functions with types that are now known at 
> compile time. Is it possible to do this?
>  See the code below (vastly reduced).
>
> // fv is a function that returns an unknown type
> func Do(fv reflect.Value){
>  // get the first returned type by function fv
>   vt := fv.Type().Out(0)
>// how to call `Hello` with `v` ?
>   // Obviously the code below is incorrect
> Hello[vt]()
> }
>
> func Hello[T any](){
>  // do something with T
>  json.Marshal(new(T))
> }

This is not possible.  Sorry.

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

Re: [go-nuts] Failure in file seek

[Ian Lance Taylor]

On Mon, Apr 8, 2024, 3:33 PM Nikhilesh Susarla 
wrote:

> I wanted to seek around a file by opening it using read-only, but then I
> get this error called "Invalid argument"
>
> https://go-review.googlesource.com/c/go/+/14881
>
> I read the above link and they say it is not supported to seek around. I
> tried direct lseek in c language and it failed with same.
>
> Is there any way ?
>

What that link says is that if you open the file with O_APPEND then you
can't Seek.  Are you opening with O_APPEND?

If not you will need to provide more information, such as a small program
that demonstrates the problem.

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/CAOyqgcV21eomhHpPGAVBFdu-WsyOp%3DX4LN_Z0v3n_i4a0qjbzw%40mail.gmail.com.

Re: [go-nuts] user process instruction pointer symbol lookup

[Ian Lance Taylor]

On Tue, Apr 2, 2024 at 2:35 AM 'TheDiveO' via golang-nuts
 wrote:
>
> On Linux, given an arbitrary binary executable with symbol information in the 
> executable, how can I lookup an instruction pointer address to get the 
> corresponding symbol name?
>
> The binary (and its process) isn't a Go binary, but any arbitrary executable. 
> The stack unwinding has already been done, so I'm presented with a list of 
> instruction pointer addresses (return addresses) which I need to convert to 
> more useful symbol names.
>
> I've seen the stdlib's debug/elf package, but I lack the ELF knowledge to 
> press the elf package's knobs in the right order. Any examples of how to use 
> debug/elf, and is it even the right package to use in this case?

debug/elf is the package to use.  You'll want to call the Symbols
method and look through the Symbols for one whose Value is <= the PC
you want while Value+Size is > the PC you want.

If you are looking at runtime PC's from a stack trace, be aware that
on most systems these days programs are position-independent, so there
will be an offset between the addresses in the binary and the
addresses from the stack trace.  I don't know offhand of a standard
way to figure out that offset.

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

Re: [go-nuts] Re: <-ctx.Done() panic - link injecting bot?

[Ian Lance Taylor]

On Sat, Mar 30, 2024 at 3:21 AM Steven Hartland
 wrote:
>
> Johans account looks like a bot designed to inject links, possibly malicious, 
> is there an admin who can investigate and take the appropriate action?

Thanks for pointing that out.  I think I've banned 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/CAOyqgcUAmKLduKvuKreCiY8YM%3D5A7BBy8tnCiA2qg6RjdsfSTQ%40mail.gmail.com.

Re: [go-nuts] GO111MODULE=off go get deprecated?

[Ian Lance Taylor]

On Sat, Mar 23, 2024 at 12:20 PM Jeffery Carr  wrote:
>
> While doing that and looking at the code, there are lots of interesting and 
> good things in internal/ that can't be used. While I think I understand the 
> reasons for internal/, I wonder if the GO compiler might be more immune to 
> those normal reasons. In general: it's sage advice to never make the compiler 
> people unhappy. Usually then lots of strange things start not working!
>
> In that regard, s/internal/workshop/ would denote things not yet stable. The 
> compiler really only needing an example to demonstrate the usage

Our experience is that once something becomes publicly accessible, it
becomes very difficult to change.

It's already difficult to change runtime internal functions, because
packages out there reach into the runtime using //go:linkname
directives.  This is clearly and obviously unsupported.  Yet people do
it.  That forces us into the uncomfortable position of breaking
existing working packages or advancing the runtime.  It's not a great
position to be in.  That's why we have rules like internal packages
that are difficult to break.

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/CAOyqgcXOOtc-yacPu%3DcOVF9_jB9Ey38OowKHsyJFkX%3DtdoCpjg%40mail.gmail.com.

Re: [go-nuts] New goroutine to immediately acquire the lock when Lock in starving mode?

[Ian Lance Taylor]

On Sat, Mar 23, 2024 at 11:58 AM Wen Wei  wrote:
>
> Lock always calls runtime_SemacquireMutex(&m.sema, queueLifo, 1) -> 
> semacquire1 when in starving mode.
>
> ```go
> // src/runtime/sema.go
> func semacquire1(addr *uint32, lifo bool, profile semaProfileFlags, 
> skipframes int, reason waitReason) {
> gp := getg()
> if gp != gp.m.curg {
> throw("semacquire not on the G stack")
> }
>
> // Easy case.
> if cansemacquire(addr) {
> return
> }
>
> // ...
> }
>
> func semrelease1(addr *uint32, handoff bool, skipframes int) {
> root := semtable.rootFor(addr)
> atomic.Xadd(addr, 1) // The semaphore released here may be immediately 
> contended for by goroutines of other threads calling semacquire1.
> }
> ```
>
> Does a new goroutine immediately acquire the lock instead of queuing fairly 
> when in starving mode?

It does seem possible.

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

Re: [go-nuts] go vet not erroring waitgroup inc used after done

[Ian Lance Taylor]

On Mon, Mar 25, 2024 at 12:46 PM Nikhilesh Susarla
 wrote:
>
> Why isn't go vet complaining that wg.Add is happening after the usage. Where 
> as the document clearly says increment and then use it as the wg.Done may be 
> called an can run into negative/deadlock

First, please send Go code as plain text or as a link to the Go
playground.  The background on the text you sent makes it difficult to
read.  Thanks.

To answer your question, vet doesn't check for any possible error
condition.  As described at
https://cs.opensource.google/go/go/+/refs/tags/go1.22.1:src/cmd/vet/README,
vet checks for mistakes that are, among other things, common.   I'm
not sure the mistake you describe is common.

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

Re: [go-nuts] Discussion on runtime/compiler meeting: Struct packing/reordering

[Ian Lance Taylor]

‪On Thu, Mar 21, 2024 at 4:47 PM ‫محمد بومنذر‬‎
 wrote:‬
>
> I have been following the Go Runtime and Compiler team meeting notes for a 
> while. In the recent notes, I noticed something that got my attention 
> regarding memory layout optimization for structures.
> https://github.com/golang/go/issues/43930#issuecomment-2009816508
>
> I'm working on some code that interfaces with C libraries without directly 
> utilizing the CGo tool (for portability reasons). Currently, I'm adding 
> padding fields manually for C structs like
> struct {a int32; _ [4]byte}
>
> Would this behavior be affected?

Exactly because of this concern there is a proposal https://go.dev/issue/66408.

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

Re: [go-nuts] io.Reader can return (n, err), both non-zero

[Ian Lance Taylor]

On Tue, Mar 19, 2024 at 6:40 PM Nigel Tao  wrote:
>
> The ubiquitous io.Reader interface's Read method returns a (int,
> error). Surprisingly (for programmers coming from other languages with
> a built-in or idiomatic Result type), it's possible for both
> return values to be non-zero. There's (often overlooked??) commentary
> in https://pkg.go.dev/io#Reader that says:
>
> > Callers should always process the n > 0 bytes returned before considering 
> > the error err.
>
> So that (again, especially for programmers used to saying result? or
> "try result" or similar Result aware mechanisms in other
> languages), the following Go code is incorrect:
>
> n, err := r.Read(buffer, etc)
> if err != nil {
>   return err
> }
> doStuffWith(buffer[:n])
>
> ---
>
> Do any of the early Gophers remember the motivations for designing
> Read's semantics in that way? At the libc or syscall level (and my
> reading of FD.Read in internal/poll/fd_unix.go), I don't think
> read(fd, etc) can return both non-zero.
>
> Is it just that, if you've got a buffer of some sort (including the
> compress/* packages), it can be more efficient (1 Read call instead of
> 2) to return (positiveN, io.EOF)?


Some earlier discussions:

https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/jq8lAQhenaoJ
https://groups.google.com/g/golang-nuts/c/WGYJx3ICCW4/m/1L0WcN8eqmkJ

See in particular this message from Russ:
https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/sbbgr9MUo9QJ

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/CAOyqgcV1_rBwW2BcrV-1UkOFepvBq96bF7xfJRHp8tMiOsDpVQ%40mail.gmail.com.

Re: [go-nuts] Using new variable or updating existing variable in a loop

[Ian Lance Taylor]

On Tue, Mar 19, 2024 at 9:36 AM Mohamad Rostami  wrote:
>
> I've seen in many places in go source code re-declaring a variable with the 
> same name.
> e.g:
> for i < j {
>h := ...
> }
> Instead of
> var h int
> for i < j {
>h = ...
> }
>
> So I did a benchmark to check the differences. I didn't find any performance 
> related differences, but in terms of Stack Memory in use, the second approach 
> is better than the first one.
>
> Not sure if the way is in standard library is by intention or something that 
> should be ignored.

The two versions are basically equivalent.  How are you measuring
stack memory usage?  If they are different, there may be something to
fix in the compiler.

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

Re: [go-nuts] debug/gosym.PCToLine breaks on cgo enabled binaries

[Ian Lance Taylor]

On Wed, Mar 13, 2024 at 8:04 AM 'Grant Seltzer Richman' via
golang-nuts  wrote:
>
> I've been using the `Table.PCToLine` method to resolve program counters 
> (extracted via bpf) into functions with their file names and line numbers.
>
> It appears that this breaks when i'm testing it on a binary that has cgo 
> enabled. It does not fix it by compiling the binary statically.
>
> Another issue I have with this API is that creating the Table requires 
> passing the `.gosymtab` which of course is empty. Cgo binaries don't even 
> have it so I just pass an empty slice.
>
> Does anyone have alternatives to this package or possible explanations to why 
> these issues exist?

When using cgo the final executable is generated by the C linker.  If
that process uses -fpie, as is the default on some systems, PCToLine
may not work.

Have you tried using runtime.FuncForPC?

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/CAOyqgcVL1om9vxqe0d3SHKg8L0J-Djp5VSxA%2BB-fEjWaWQNN0A%40mail.gmail.com.