Re: [go-nuts] keyword= support for function calls

The net.dialer solution you mention uses a struct which does not simplify. How does this get programmers out of the add another function mentality? GOLANG and C/C++ programmers have the same solution because it's not convenient to use a struct. Compare charts in C++ versus JavaScript. C++ solution

Re: [go-nuts] keyword= support for function calls

On Wed, Aug 16, 2023 at 6:44 PM Jon Perryman wrote: > Struct does not solve the basic problem. In what way are you suggesting to > solve the described os.open() changes? Should each API be seperate from > os.open where it must be used with every read/write? > I guess I don't understand what you

Re: [go-nuts] weird "index out of range" in strconv.formatBits

Insufficient information. Version of Go? Since formatBits is private we need to see the actual code of a call to a public API that resulted in the call to formatBits that failed. Also, show us the literal panic stack. Showing us the assembly code with no context is not useful. If your program

Re: [go-nuts] keyword= support for function calls

Have a look at net.Dialer . It is essentially a struct that adds optional, keyword arguments to net.Dial . On Thu, Aug 17, 2023 at 3:44 AM Jon Perryman wrote: > Struct does not solve the basic problem. In what way are you suggesting to

Re: [go-nuts] weird "index out of range" in strconv.formatBits

On Wed, 2023-08-16 at 20:31 -0700, metronome wrote: > Hi, > > We ran into a weird out of range issue of strconv.formatBits, hope > someone can shed a light on what could be the root cause, any comment > is highly appreciated. > > problem description: >       random out of range at code, most of

[go-nuts] weird "index out of range" in strconv.formatBits

Hi, We ran into a weird *out of range* issue of *strconv.formatBits*, hope someone can shed a light on what could be the root cause, any comment is highly appreciated. problem description: * random out of range at code

Re: [go-nuts] Go modules question

On Wed, Aug 16, 2023 at 7:10 PM joseph.p...@gmail.com < joseph.p.mcguc...@gmail.com> wrote: > I’m reading a GO book for beginners. They’re always naming their module > in the form: > github.com/username/program > > Is the ‘github.com’ portion of the module name mandatory? I really have > no

[go-nuts] Go modules question

I’m reading a GO book for beginners. They’re always naming their module in the form: github.com/username/program Is the ‘github.com’ portion of the module name mandatory? I really have no intention of saving my code to github. If i’m saving my code locally, can i use an arbitrary module

Re: [go-nuts] keyword= support for function calls

Struct does not solve the basic problem. In what way are you suggesting to solve the described os.open() changes? Should each API be seperate from os.open where it must be used with every read/write? On Wed, Aug 16, 2023 at 6:14 PM Kurtis Rader wrote: > Personally, and I say this as a happy

Re: [go-nuts] keyword= support for function calls

Personally, and I say this as a happy user of Python, I dislike keyword parameters. Note that in Python keyword parameters are (or should be) seldom used for anything other than optional arguments. And if your API has so many parameters that they need names the API probably needs refactoring.

[go-nuts] keyword= support for function calls

Do you feel your GOLANG API implementations allows your API's and functions to evolve and grow? Personally, positional args has pissed me off for years when a proven simple solution has never been adopted by most Unix programming languages (except Javascript). Most notably, it's missing from

Re: [go-nuts] why the go install package download from official website of go1.21 is less than go1.20?

I think that for 1.21 the biggest difference is that we aren't including debug info with the binaries in $GOROOT/pkg/tool/$GOOS_$GOARCH. That change was made in https://go.dev/cl/475378. Ian Ian On Wed, Aug 16, 2023 at 12:46 PM Jeremy Cattone wrote: > > Looks like on-going work, finally

[go-nuts] Re: Test coverage: joint unit test and integration test coverage

Hmm, my previous response got deleted for no reason. So here we go: the new mechanism is more general, and as you can see in my example I actually run the "same" unit tests twice. The reason is because some code paths might be only exercised when not being run as root, especially error

Re: [go-nuts] why the go install package download from official website of go1.21 is less than go1.20?

Looks like on-going work, finally completed in 1.21? https://github.com/golang/go/issues/27151 On Tuesday, August 15, 2023 at 9:31:41 PM UTC-7 Kurtis Rader wrote: > All of the packages are significantly smaller -- not just those for macOS. > So this isn't due to anything specific to the macOS

[go-nuts] Re: Test coverage: joint unit test and integration test coverage

Thanks, that's very helpful! I was doing something similar , but I was extracting the temporary coverage directory created by Go because I didn't know about the --test.gocoverdir flag. Still it feels wrong

[go-nuts] Re: Test coverage: joint unit test and integration test coverage

Maybe similar to this? https://github.com/thediveo/lxkns/blob/cef5a31d7517cb126378f81628f51672cb793527/scripts/cov.sh#L28 On Wednesday, August 16, 2023 at 1:54:48 PM UTC+2 Jan wrote: > hi all, > > After reading the documentation > , I managed to

Re: [go-nuts] (minor) broken link in the Go 1.21 release notes.

Thanks for reporting. Sent https://go-review.googlesource.com/c/website/+/520215 with a fix On Wed, Aug 16, 2023 at 1:59 AM Jochen Voss wrote: > Hello, > > Not really important, but there is a somewhat broken link in the Go 1.21 > release notes. The introduction says "See “Go versions” in the

Re: [go-nuts] Re: [rfc] build bug in type abstraction?

Hi Brian, Thanks for the review. Your basic conclusion matches mine, that the ./main/main.go:46 and ./types.go are proven in the "go run" case, and disproven in the "go build" case. Best, John On Wed, Aug 16, 2023 at 9:58 AM Brian Candler wrote: > On Wednesday, 16 August 2023 at 14:05:49

[go-nuts] Re: [rfc] build bug in type abstraction?

On Wednesday, 16 August 2023 at 14:05:49 UTC+1 John Pritchard wrote: I have a disparity between "go run" [ https://go.dev/play/p/5mr5M0luZ9k?v=goprev] and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third]. Using go version 1.21.0. I don't quite understand where "go

[go-nuts] Re: [rfc] build bug in type abstraction?

A few things: * As illustrated by the output in your README, it appears your "make list" command is only compiling "main/main.go", rather than both "main/main.go" and "main/run.go" * There can only be one main function per main package in Go, so I'm not sure how main/run.go and main/main.go

[go-nuts] [rfc] build bug in type abstraction?

Hi, I have a disparity between "go run" [ https://go.dev/play/p/5mr5M0luZ9k?v=goprev] and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third]. Using go version 1.21.0. A fairly simple structure of type abstraction works on play.go.dev, but fails to build. Comments? Issue?

[go-nuts] Test coverage: joint unit test and integration test coverage

hi all, After reading the documentation , I managed to set up a process in which I compile and run my integration tests, and get coverage from them in the `$GOCOVERDIR` subdirectory. Now I would like to have a combined unit tests + integration

Re: [go-nuts] Go Toolchain Management from 1.21.0 onwards

On Wednesday, 16 August 2023 at 10:15:50 UTC+1 Christoph Berger wrote: I would assume that GOTOOLCHAIN=local does what you want. The doc says, > When GOTOOLCHAIN is set to local, the go command always runs the bundled Go toolchain. That's the conclusion I came

Re: [go-nuts] Go Toolchain Management from 1.21.0 onwards

I would assume that GOTOOLCHAIN=local does what you want. The doc says, > When GOTOOLCHAIN is set to local, the go command always runs the bundled Go > toolchain. The author of this proposal in

[go-nuts] (minor) broken link in the Go 1.21 release notes.

Hello, Not really important, but there is a somewhat broken link in the Go 1.21 release notes. The introduction says "See “Go versions” in the “Go Toolchains” documentation for details", and this links to https://go.dev/doc/toolchain#versions The link goes to the beginning of the page,

[go-nuts] Re: Go Toolchain Management from 1.21.0 onwards

On Wednesday, 16 August 2023 at 08:47:36 UTC+1 Christoph Berger wrote: Thank you for replying. What prevents you from using the new toolchains mechanism? Nothing really. I suppose it's just that I don't really understand what it is or what it's for. The current method of dealing with the

[go-nuts] Re: Go Toolchain Management from 1.21.0 onwards

As far as I understand the Toolchains document, Go projects made with Go 1.21 or later can demand a particular toolchain for compiling a module (through the go and toolchain directives). If you disable downloading toolchains as needed, the new behavior of the go and toolchain directives might

Re: [go-nuts] I need confirmation about whether I'm in front of a linter false positive.

The linter complains because the second err occurs in a different scope. "if err = f(); err != nil" scopes this err instance to the if block. It re-uses the err from the outer scope, which might not be intended. If you only use either of "err = f(); if err..." or "if err = f(); err..."