[go-nuts] Re: garbage collections on Windows and Mac

On Tuesday, January 9, 2024 at 10:21:26 PM UTC-5 Michael Mitchell wrote: Hi, I have noticed on my macbook pro that HeapInUse is always slightly above NextGC when the garbage collection occurs. According to mstats.go, the "garbage collector's goal is to keep HeapAlloc less than NextGC" and

[go-nuts] garbage collections on Windows and Mac

Hi, I have noticed on my macbook pro that HeapInUse is always slightly above NextGC when the garbage collection occurs. According to mstats.go, the "garbage collector's goal is to keep HeapAlloc less than NextGC" and also according to mstats.go, "HeapInUse minus HeapAlloc estimates the

[go-nuts] Cipher suite oddity

Something just pointed out to me(*) that I don't understand: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA is in tls.CipherSuites() TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is in tls.InsecureCipherSuites() Why is the SHA256 variant

Re: [go-nuts] Type parameter embedded field

I think that might work, yes. At least I don't see a major issue with it right now. On Tue, Jan 9, 2024 at 7:25 PM roger peppe wrote: > > > On Fri, 5 Jan 2024 at 05:58, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> Hi, >> >> I think the reason this has not

[go-nuts] cgo: passing an array of char* to Go function

Hello all, I have to admit that I am a C newbie. I want to use Go's slog mechanism with variable arguments (for example slog.Warn("message", "argument1", "value of argument1")) The Go function would be something like this: //export sdLogMessages func sdLogMessages(level *C.char, message

[go-nuts] Go 1.21.6 and Go 1.20.13 are released

Hello gophers, We have just released Go versions 1.21.6 and 1.20.13, minor point releases. View the release notes for more information: https://go.dev/doc/devel/release#go1.21.6 You can download binary and source distributions from the Go website: https://go.dev/dl/ To compile from source

Re: [go-nuts] Type parameter embedded field

On Fri, 5 Jan 2024 at 05:58, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi, > > I think the reason this has not happened is that it makes code using such > a type invalid, depending on the type-argument - in ways not captured by > the constraint. For example: > > type

[go-nuts] Re: Blog Article: Go Generics (and also mocking)

On Tuesday, January 9, 2024 at 2:28:08 AM UTC+1 Corin Lawson wrote: On Tuesday 9 January 2024 at 1:12:00 am UTC+11 TheDiveO wrote: One thing I notice is that your design assumes to specify the expected call sequence upon creation, or do I get this wrong? My expectation would be to specify this

Re: [go-nuts] Any interest in nat.mulRange simplification/optimization?

I wrote the single allocation version and added it to the issue, but Bakul is absolutely right that the recursive solution has merit when the input is large enough. By building up large values on each "side" of the recursion, Karatsuba gets used for the larger multiplies and the recursive version