Re: [go-nuts] mutex in slog/handler.go?

[Harris, Andrew]

The mutex field of the common handler struct became a pointer-to-mutex at some 
point IIRC - it is currently, so copying should be fine.

Get Outlook for iOS

From: golang-nuts@googlegroups.com  on behalf of 
Eli Lindsey 
Sent: Friday, May 24, 2024 7:18:51 AM
To: Jochen Voss 
Cc: golang-nuts 
Subject: Re: [go-nuts] mutex in slog/handler.go?

Git blame may be helpful, and specifically commit 847d40d6998. It looks like 
code drifted from the comment.

-eli

On May 24, 2024, at 9:25 AM, Jochen Voss  wrote:

Hello,

In the Go standard library, in the file log/slog/handler.go, I found the 
following code:

func (h *commonHandler) clone() *commonHandler {
// We can't use assignment because we can't copy the mutex.
return {
json:  h.json,
opts:  h.opts,
preformattedAttrs: slices.Clip(h.preformattedAttrs),
groupPrefix:   h.groupPrefix,
groups:slices.Clip(h.groups),
nOpenGroups:   h.nOpenGroups,
w: h.w,
mu:h.mu, // mutex shared among all clones of this handler
}
}

The first comment states that "we can't copy the mutex", but then the last line 
seems to copy the mutex anyway.  What is going on here?

Maybe this just an oversight from a time when every hander had its own mutex?  
Or is there something subtle going on here?

Many thanks,
Jochen


--
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/153e9898-f17e-44cc-ab2a-8570f916c0c3n%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/D370602F-6226-4AAC-B3EC-6BA164FEA4F9%40siliconsprawl.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/SJ0PR07MB97958715C77D9CCFC2C2C1CFA0F52%40SJ0PR07MB9795.namprd07.prod.outlook.com.

Re: [go-nuts] mutex in slog/handler.go?

[Eli Lindsey]

Git blame may be helpful, and specifically commit 847d40d6998. It looks like code drifted from the comment.-eli On May 24, 2024, at 9:25 AM, Jochen Voss  wrote:Hello,In the Go standard library, in the file log/slog/handler.go, I found the following code:func (h *commonHandler) clone() *commonHandler {	// We can't use assignment because we can't copy the mutex.	return {		json:              h.json,		opts:              h.opts,		preformattedAttrs: slices.Clip(h.preformattedAttrs),		groupPrefix:       h.groupPrefix,		groups:            slices.Clip(h.groups),		nOpenGroups:       h.nOpenGroups,		w:                 h.w,		mu:                h.mu, // mutex shared among all clones of this handler	}}The first comment states that "we can't copy the mutex", but then the last line seems to copy the mutex anyway.  What is going on here?Maybe this just an oversight from a time when every hander had its own mutex?  Or is there something subtle going on here?Many thanks,Jochen



-- 
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/153e9898-f17e-44cc-ab2a-8570f916c0c3n%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/D370602F-6226-4AAC-B3EC-6BA164FEA4F9%40siliconsprawl.com.

[go-nuts] mutex in slog/handler.go?

[Jochen Voss]

Hello,

In the Go standard library, in the file log/slog/handler.go, I found the 
following code:

func (h *commonHandler) clone() *commonHandler {
// We can't use assignment because we can't copy the mutex.
return {
json:  h.json,
opts:  h.opts,
preformattedAttrs: slices.Clip(h.preformattedAttrs),
groupPrefix:   h.groupPrefix,
groups:slices.Clip(h.groups),
nOpenGroups:   h.nOpenGroups,
w: h.w,
mu:h.mu, // mutex shared among all clones of this handler
}
}

The first comment states that "we can't copy the mutex", but then the last 
line seems to copy the mutex anyway.  What is going on here?

Maybe this just an oversight from a time when every hander had its own 
mutex?  Or is there something subtle going on here?

Many thanks,
Jochen

-- 
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/153e9898-f17e-44cc-ab2a-8570f916c0c3n%40googlegroups.com.

[go-nuts] multiple rangefunc iterators: restart?

[Rory Campbell-Lange]

I've been playing with with rangefunc experiment, with help from 
https://go.dev/wiki/RangefuncExperiment and the possible idioms that might come 
out of it (https://blog.perfects.engineering/go_range_over_funcs is a good 
read).

One somewhat eccentric use of nested iterators I built in the past in python 
was turning an SQL widerows or domain aggregate result into a set of nested 
objects, so one could use the results in something like the following way:

for p in people:
for c in p.cars:
for t in c.tickets:
print("person {} in car {} got ticket {}", p, c, t)

While I was able to get a very janky version of this type of behaviour with 
https://go.dev/play/p/gFUcKNSrbMV?v=gotip this only has an iterator on the left 
hand side and series of nested structs through slices. My attempts to use more 
iterators (for cars and tickets) fails as these of course stop after the first 
set of cars and tickets respectively have been yielded.

I realise this is a contrived example, but I wonder if there might be more 
general cases where iterators could be stopped and restarted. (The docs to 
iter.Pull suggest next() and stop() are non-resettable also.) Perhaps there 
could be hidden new iter.Seq constructors in the container for when the cars 
and tickets iterators are exhausted...hmm...

I'd be grateful for any thoughts about this casual and hypothetical case, 
although I guess it could be helpful for something like retrieving nested data 
from an sql cursor efficiently.

Cheers
Rory


That code above turns:

a a1 a2 b1 b2 b3 c1 c2 c3
a a1 a2 b1 b2 b3 c4 c5 c6
a a1 a2 b1 b2 b3 c7 c8 c9
a a1 a2 b4 b5 b6 c10 c11 c12
d d1 d2 e1 e2 e3 f1 f2 f3
d d1 d2 e1 e2 e3 f4 f5 f6
g g1 g2 h1 h2 h3 i1 i2 i3

into:

[a a1 a2]
>  [b1 b2 b3]
> >  [c1 c2 c3]
> >  [c4 c5 c6]
> >  [c7 c8 c9]
>  [b4 b5 b6]
> >  [c10 c11 c12]
[d d1 d2]
>  [e1 e2 e3]
> >  [f1 f2 f3]
> >  [f4 f5 f6]
[g g1 g2]
>  [h1 h2 h3]
> >  [i1 i2 i3]

called like this:

for a := range collection.Iter() { // iter.Seq
fmt.Println(a.r)
for _, b := range a.s {// slice -- could be iter.Seq?
fmt.Println("> ", b.r)
for _, c := range b.s {// slice -- could be 
iter.Seq?
fmt.Println("> > ", c.r)
}
}
}

-- 
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/Zk94CqLUJ6fJjmuA%40campbell-lange.net.

Re: [go-nuts] Re: Call the .net dlls into the golang

['Brian Candler' via golang-nuts]

"try building at the command line"

That's your clue. You'll most likely get a meaningful error message on 
stderr, which your IDE is hiding.

On Thursday 23 May 2024 at 13:47:10 UTC+1 Pavan Kumar A R wrote:

> Hello , 
>
> I am try to call the c program in the golang , but i am getting the issue 
> .  please see the error message :
> package main
>
> go list failed to return CompiledGoFiles. This may indicate failure to 
> perform cgo processing; try building at the command line. See 
> https://golang.org/issue/38990.go list
> View Problem (Alt+F8)
>
>
> //#cgo LDFLAGS: -L. -llibCWrapper-win64 -Wl,-rpath,.
> //#include "ealApiLib.h"
>
> import "C"
> import "fmt"
>
> func main() {
>
> result := C.Connect("192.168.1.1")
>
> fmt.Println("connection success" + result)
>
> }
>
>
>
> On Thursday 23 May 2024 at 02:53:12 UTC+5:30 peterGo wrote:
>
>> cgo command
>> https://pkg.go.dev/cmd/cgo
>> Cgo enables the creation of Go packages that call C code.
>>
>> On Wednesday, May 22, 2024 at 4:41:13 PM UTC-4 Carla Pfaff wrote:
>>
>>> Yes, you can call C functions from Go, it's called Cgo: 
>>> https://go.dev/blog/cgo
>>>
>>> On Wednesday 22 May 2024 at 18:04:19 UTC+2 Pavan Kumar A R wrote:
>>>

> Okay,  it's possible to call the C program to Golang. Because I also 
> have the C platform dlls and the C platform dlls  we using in the cross 
> platform mono and in the mono internally call the.net dlls function , 
> can I use the C program dlls in Golang?  
>


-- 
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/21db8561-176e-4857-a904-8bda3c226ab3n%40googlegroups.com.

Re: [go-nuts] Re: Call the .net dlls into the golang

[Pavan Kumar A R]

Hello , 

I am try to call the c program in the golang , but i am getting the issue 
.  please see the error message :
package main

go list failed to return CompiledGoFiles. This may indicate failure to 
perform cgo processing; try building at the command line. See 
https://golang.org/issue/38990.go list
View Problem (Alt+F8)


//#cgo LDFLAGS: -L. -llibCWrapper-win64 -Wl,-rpath,.
//#include "ealApiLib.h"

import "C"
import "fmt"

func main() {

result := C.Connect("192.168.1.1")

fmt.Println("connection success" + result)

}



On Thursday 23 May 2024 at 02:53:12 UTC+5:30 peterGo wrote:

> cgo command
> https://pkg.go.dev/cmd/cgo
> Cgo enables the creation of Go packages that call C code.
>
> On Wednesday, May 22, 2024 at 4:41:13 PM UTC-4 Carla Pfaff wrote:
>
>> Yes, you can call C functions from Go, it's called Cgo: 
>> https://go.dev/blog/cgo
>>
>> On Wednesday 22 May 2024 at 18:04:19 UTC+2 Pavan Kumar A R wrote:
>>
>>>
 Okay,  it's possible to call the C program to Golang. Because I also 
 have the C platform dlls and the C platform dlls  we using in the cross 
 platform mono and in the mono internally call the.net dlls function , 
 can I use the C program dlls in Golang?  

>>>

-- 
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/d8665110-07f3-4f0d-8e14-49900cd4b6abn%40googlegroups.com.

Re: [go-nuts] vet: Respect PATH

['wagner riiffel' via golang-nuts]

On 5/21/2024 12:48 PM, andrew.p...@gmail.com wrote:

Please simplify both of these, so that the user can simply run:

go vet -vettool=shadow

Or:

shadow ./...

> In other words, the user should be able to invoke gofmt on a large Go
> project with:
>
> gofmt ./...
>
> Same request for goimports.
>

The "./..." syntax matches packages, not files and that's why tools 
which work on files doesn't accept this syntax. The "go" program already 
has "fmt" sub-command that do exactly this, run gofmt recursively on all 
matched packages sources, so try "go fmt ./...". Analyzers already 
accept packages and not files, so "shadow ./..." should work.


I think taking files instead of packages is somewhat legacy, but I found 
it's useful, since we moved from GOPATH to go modules resolving packages 
is somehow slow, I definitely feel a delay when using programs that 
takes packages as an argument, that's very noticeable when you're in a 
slow filesystem or storage device, so gofmt not taking 5 seconds (unlike 
go fmt) to run is a good feature.


-w


--
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/f9cea397-3888-457a-a945-589f611c1ed7%40104d.net.

Re: [go-nuts] Re: Call the .net dlls into the golang

[peterGo]

cgo command
https://pkg.go.dev/cmd/cgo
Cgo enables the creation of Go packages that call C code.

On Wednesday, May 22, 2024 at 4:41:13 PM UTC-4 Carla Pfaff wrote:

> Yes, you can call C functions from Go, it's called Cgo: 
> https://go.dev/blog/cgo
>
> On Wednesday 22 May 2024 at 18:04:19 UTC+2 Pavan Kumar A R wrote:
>
>>
>>> Okay,  it's possible to call the C program to Golang. Because I also 
>>> have the C platform dlls and the C platform dlls  we using in the cross 
>>> platform mono and in the mono internally call the.net dlls function , 
>>> can I use the C program dlls in Golang?  
>>>
>>

-- 
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/3ca5ff36-58f5-42e2-910f-c2687c31af77n%40googlegroups.com.

Re: [go-nuts] Re: Call the .net dlls into the golang

['Carla Pfaff' via golang-nuts]

Yes, you can call C functions from Go, it's called 
Cgo: https://go.dev/blog/cgo

On Wednesday 22 May 2024 at 18:04:19 UTC+2 Pavan Kumar A R wrote:

>
>> Okay,  it's possible to call the C program to Golang. Because I also have 
>> the C platform dlls and the C platform dlls  we using in the cross platform 
>> mono and in the mono internally call the.net dlls function , can I use 
>> the C program dlls in Golang?  
>>
>

-- 
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/7282ba6c-8700-44f0-bd97-5a61807c963en%40googlegroups.com.

Re: [go-nuts] Errors trying to use external pkg z3

[Kenneth Miller]

I changed the terminal and then it worked.

On Wednesday, May 22, 2024 at 10:39:05 AM UTC-6 Brian Candler wrote:

> * Start in an empty directory
> * Run "go mod init example"
> * Create your main.go with that import statement in it
> * Run:
>
> go mod tidy
> go run .
>
> On Wednesday 22 May 2024 at 16:26:54 UTC+1 Kenneth Miller wrote:
>
>> I tried that, same error
>>
>> On Wednesday, May 22, 2024 at 9:12:58 AM UTC-6 Brian Candler wrote:
>>
>>> It's because the name of the module is "github.com/aclements/go-z3/z3", 
>>> not "z3"
>>>
>>> Only packages in the standard library have short names, like "fmt", 
>>> "strings" etc.
>>>
>>> On Wednesday 22 May 2024 at 15:46:30 UTC+1 robert engels wrote:
>>>
 If it is your own code, you have to use

 import “github.com/aclements/go-z3/z3”

 or you need a special go.mod file.

 On May 22, 2024, at 9:38 AM, robert engels  
 wrote:

 What are you trying to run? z3 is a library.

 On May 22, 2024, at 9:29 AM, Kenneth Miller  
 wrote:

 I did go get -u github.com/aclements/go-z3/z3

 but when I go run . I get

 main.go:5:2: package z3 is not in std

 the offending line is 

 import "z3"

 can someone help me please? I'm sure this has been asked before but I 
 couldn't find it

 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/d46b52fb-fa96-4544-914a-42bf83d75322n%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...@googlegroups.com.

 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.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/15cc3662-ecf3-4d8b-b75b-8a22bfcd231en%40googlegroups.com.

Re: [go-nuts] Errors trying to use external pkg z3

['Brian Candler' via golang-nuts]

* Start in an empty directory
* Run "go mod init example"
* Create your main.go with that import statement in it
* Run:

go mod tidy
go run .

On Wednesday 22 May 2024 at 16:26:54 UTC+1 Kenneth Miller wrote:

> I tried that, same error
>
> On Wednesday, May 22, 2024 at 9:12:58 AM UTC-6 Brian Candler wrote:
>
>> It's because the name of the module is "github.com/aclements/go-z3/z3", 
>> not "z3"
>>
>> Only packages in the standard library have short names, like "fmt", 
>> "strings" etc.
>>
>> On Wednesday 22 May 2024 at 15:46:30 UTC+1 robert engels wrote:
>>
>>> If it is your own code, you have to use
>>>
>>> import “github.com/aclements/go-z3/z3”
>>>
>>> or you need a special go.mod file.
>>>
>>> On May 22, 2024, at 9:38 AM, robert engels  wrote:
>>>
>>> What are you trying to run? z3 is a library.
>>>
>>> On May 22, 2024, at 9:29 AM, Kenneth Miller  
>>> wrote:
>>>
>>> I did go get -u github.com/aclements/go-z3/z3
>>>
>>> but when I go run . I get
>>>
>>> main.go:5:2: package z3 is not in std
>>>
>>> the offending line is 
>>>
>>> import "z3"
>>>
>>> can someone help me please? I'm sure this has been asked before but I 
>>> couldn't find it
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/d46b52fb-fa96-4544-914a-42bf83d75322n%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...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.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/75533bfc-b63b-41cc-9f66-0885d0c00c7cn%40googlegroups.com.

Re: [go-nuts] Re: Call the .net dlls into the golang

[Pavan Kumar A R]

>
> Okay,  it's possible to call the C program to Golang. Because I also have
> the C platform dlls and the C platform dlls  we using in the cross platform
> mono and in the mono internally call the.net dlls function , can I use
> the C program dlls in Golang?
>

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

Re: [go-nuts] Errors trying to use external pkg z3

[Kenneth Miller]

I tried that, same error

On Wednesday, May 22, 2024 at 9:12:58 AM UTC-6 Brian Candler wrote:

> It's because the name of the module is "github.com/aclements/go-z3/z3", 
> not "z3"
>
> Only packages in the standard library have short names, like "fmt", 
> "strings" etc.
>
> On Wednesday 22 May 2024 at 15:46:30 UTC+1 robert engels wrote:
>
>> If it is your own code, you have to use
>>
>> import “github.com/aclements/go-z3/z3”
>>
>> or you need a special go.mod file.
>>
>> On May 22, 2024, at 9:38 AM, robert engels  wrote:
>>
>> What are you trying to run? z3 is a library.
>>
>> On May 22, 2024, at 9:29 AM, Kenneth Miller  
>> wrote:
>>
>> I did go get -u github.com/aclements/go-z3/z3
>>
>> but when I go run . I get
>>
>> main.go:5:2: package z3 is not in std
>>
>> the offending line is 
>>
>> import "z3"
>>
>> can someone help me please? I'm sure this has been asked before but I 
>> couldn't find it
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/d46b52fb-fa96-4544-914a-42bf83d75322n%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...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.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/c4a72330-79c6-40cc-bcdc-e79dd382f4f6n%40googlegroups.com.

Re: [go-nuts] Errors trying to use external pkg z3

['Brian Candler' via golang-nuts]

It's because the name of the module is "github.com/aclements/go-z3/z3", not 
"z3"

Only packages in the standard library have short names, like "fmt", 
"strings" etc.

On Wednesday 22 May 2024 at 15:46:30 UTC+1 robert engels wrote:

> If it is your own code, you have to use
>
> import “github.com/aclements/go-z3/z3”
>
> or you need a special go.mod file.
>
> On May 22, 2024, at 9:38 AM, robert engels  wrote:
>
> What are you trying to run? z3 is a library.
>
> On May 22, 2024, at 9:29 AM, Kenneth Miller  wrote:
>
> I did go get -u github.com/aclements/go-z3/z3
>
> but when I go run . I get
>
> main.go:5:2: package z3 is not in std
>
> the offending line is 
>
> import "z3"
>
> can someone help me please? I'm sure this has been asked before but I 
> couldn't find it
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d46b52fb-fa96-4544-914a-42bf83d75322n%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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.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/ebeb05d6-5649-4ad4-b0d7-28ef36ee6dd7n%40googlegroups.com.

Re: [go-nuts] Errors trying to use external pkg z3

[robert engels]

If it is your own code, you have to use

import “github.com/aclements/go-z3/z3 ”

or you need a special go.mod file.

> On May 22, 2024, at 9:38 AM, robert engels  wrote:
> 
> What are you trying to run? z3 is a library.
> 
>> On May 22, 2024, at 9:29 AM, Kenneth Miller > > wrote:
>> 
>> I did go get -u github.com/aclements/go-z3/z3 
>> 
>> 
>> but when I go run . I get
>> 
>> main.go:5:2: package z3 is not in std
>> 
>> the offending line is 
>> 
>> import "z3"
>> 
>> can someone help me please? I'm sure this has been asked before but I 
>> couldn't find it
>> 
>> -- 
>> 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/d46b52fb-fa96-4544-914a-42bf83d75322n%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/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.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/AF8256CE-EF92-432C-95E0-4F6198B3EDA2%40ix.netcom.com.

Re: [go-nuts] Errors trying to use external pkg z3

[robert engels]

What are you trying to run? z3 is a library.

> On May 22, 2024, at 9:29 AM, Kenneth Miller  
> wrote:
> 
> I did go get -u github.com/aclements/go-z3/z3
> 
> but when I go run . I get
> 
> main.go:5:2: package z3 is not in std
> 
> the offending line is 
> 
> import "z3"
> 
> can someone help me please? I'm sure this has been asked before but I 
> couldn't find it
> 
> -- 
> 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/d46b52fb-fa96-4544-914a-42bf83d75322n%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/EE0FDF46-94C6-44D6-98C0-19D52C371C20%40ix.netcom.com.

[go-nuts] Errors trying to use external pkg z3

[Kenneth Miller]

I did go get -u github.com/aclements/go-z3/z3

but when I go run . I get

main.go:5:2: package z3 is not in std

the offending line is 

import "z3"

can someone help me please? I'm sure this has been asked before but I 
couldn't find it

-- 
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/d46b52fb-fa96-4544-914a-42bf83d75322n%40googlegroups.com.

[go-nuts] Re: Call the .net dlls into the golang

['Carla Pfaff' via golang-nuts]

You can't call .NET functions directly from Go. Go programs and .NET have 
two completely different runtimes. You would need some form of 
inter-process communication (IPC).

On Wednesday 22 May 2024 at 14:31:04 UTC+2 Pavan Kumar A R wrote:

> Hello ,
>
> I build the.net dlls in the target framework, which is.net-framework 2.0, 
> and inside the.net dlls are some functions. I want to call this function 
> in Golang. How can I call the.net function in Golang? Please help out 
> here. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6ca2d475-9fd3-4549-9f8e-576d92ed70b5n%40googlegroups.com.

[go-nuts] Call the .net dlls into the golang

[Pavan Kumar A R]

 

Hello ,

I build the.net dlls in the target framework, which is.net-framework 2.0, 
and inside the.net dlls are some functions. I want to call this function in 
Golang. How can I call the.net function in Golang? Please help out here. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/759a08e7-19de-49af-9bf6-bdcf7b45905en%40googlegroups.com.

[go-nuts] Re: Discover go-size-analyzer: Streamline Your Go Binary Insights

[Peter Galbavy]

Another thumbs up! Thanks

On Tuesday 21 May 2024 at 16:16:54 UTC+1 Zxilly Chou wrote:

> Hello go-nuts,
>
> I'm excited to share a new tool that has landed in our Go ecosystem: 
> go-size-analyzer. This utility is designed to give you a clear picture of 
> the size of your compiled Go binaries, with a focus on how dependencies 
> contribute to the overall footprint.
>
> It simplifies the process of binary size analysis and offers a range of 
> viewing options, from web interfaces to terminal UIs and text formats. It's 
> also highly customisable, so you can tailor the output to suit your needs.
>
> The project is open source and actively seeking contributions, so if 
> you're interested in this kind of tool, it's definitely worth a look.
>
> You can find more information and get started with go-size-analyzer on its 
> GitHub page: https://github.com/Zxilly/go-size-analyzer
>
> Happy coding!
>
> Best,
>
> Zxilly
>

-- 
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/c40129f5-9ae9-4ce2-a218-8943ad948cadn%40googlegroups.com.

[go-nuts] Re: replacement for filepath.HasPrefix?

[Jason E. Aten]

When I needed to follow symlinks and exclude application-specific 
directories, I ended
up copying and customizing Walk() and walk() from the filepath package. 
They are
short and it was a straightforward to adapt them to my needs.

https://cs.opensource.google/go/go/+/refs/tags/go1.22.3:src/path/filepath/path.go;l=555
https://cs.opensource.google/go/go/+/refs/tags/go1.22.3:src/path/filepath/path.go;l=476

-- 
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/5b6737dc-5783-4a45-afe9-1faa2d9cf5aan%40googlegroups.com.

[go-nuts] Re: Uses of reflect and unsafe packages

[Jason E. Aten]

I use "unsafe" for performance optimization and with Cgo[1][2][3]. 

I use "reflect" and "unsafe" for doing de-serialization in a serialization 
framework, 
and for cross-language work (Go <-> C, Go <-> scripting languages like 
Python, R, Lua, zygomys)[4][5][6]. 

If you are staying entirely within the Go language, then you aren't likely 
to need "reflect". It lets
you write very dynamic code to handle a Go struct whose layout you don't 
know about at compile
time.  You give up type safety. It is usually alot of painstaking work.

If you aren't profiling your code for performance tuning, you likely won't 
need to mess with "unsafe".
It does let you avoid certain redundant allocations if you can guarantee 
things about your memory's
access patterns.

Since, as the ancient maps used to say, "here be dragons," it is better to 
leave both of them alone until you really, really need them.

examples:

[1] 
https://github.com/glycerine/embedr/blob/96d03afc338c43add0f473ef1ea36ed7257b69f1/r2go.go#L762
[2] 
https://github.com/glycerine/embedr/blob/96d03afc338c43add0f473ef1ea36ed7257b69f1/embedr.go#L255
[3] 
https://github.com/glycerine/greenpack/blob/971e607bf20009e551605ed6a8480335629241f8/msgp/unsafe.go#L34
[4] 
https://github.com/glycerine/greenpack/blob/971e607bf20009e551605ed6a8480335629241f8/msgp/write.go#L775
[5] 
https://github.com/glycerine/zygomys/blob/b4e08088004ee5de19f294d53bb692122463aa10/zygo/callgo.go#L15
[6] https://github.com/glycerine/rmq/blob/master/src/rmq/rmq.go#L466

On Tuesday, May 21, 2024 at 1:44:27 PM UTC+1 Ketan Rathod wrote:

> I have seen many discussions using refflect and unsafe packages, so i am 
> curious to know their usecases and when it is useful to use this packages.

-- 
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/55e7d611-ca03-436c-a528-d95cb0ab3437n%40googlegroups.com.

Re: [go-nuts] Calling the .net dlls to the golang

[peterGo]

Kurtis Rader,

The OP's question: "I am new to Golang. I have the.net dlls, and I am 
trying to call the.net function in the dll in Golang. but its not working 
and i searching in the Google also i could not find the relavent 
information, please me out here and provide the sample program also"

The meaning of the question seemed obvious to me, but not to you. I 
wondered why. I also wondered whether AI would find the question obvious. 

Since .NET DLL is a Microsoft term, I asked Satya Nadella the question. 
Copilot replied, "Certainly! Calling a .NET DLL function from Go ..."

Since Google is the principal sponsor of Go, I asked Sundar Pichai the 
question. Gemini replied, "Calling directly from Go to a .NET DLL ..."

So it's true. Some people may be replaced by AI.

peter


On Tuesday, May 21, 2024 at 4:31:47 PM UTC-4 Kurtis Rader wrote:

> Since the question is incoherent and the link to the package you claim to 
> be using doesn't resolve to a valid host name I'm going to assume this is 
> spam and you're not really a person asking for help.
>
> P.S., Saying it "is not working" is meaningless. If you are a real person 
> asking for help show us the code you wrote and explain what you expected 
> and what actually happened when you compiled and ran your code.
>

-- 
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/ef095ee3-826f-426d-917c-d7dc55f7dae0n%40googlegroups.com.

Re: [go-nuts] Calling the .net dlls to the golang

[peterGo]

Kurtis Rader,

Please follow the Go Community Code of Conduct  
while posting here. In short:

   - Treat everyone with respect and kindness.
   - Be thoughtful in how you communicate.
   - Don’t be destructive or inflammatory.
   - 
   
You are fired from your self-appointed role as spam checker!

.NET for Beginners 
https://learn.microsoft.com/en-us/shows/dotnet-for-beginners/

Learn  .NET
Assemblies in .NET
https://learn.microsoft.com/en-us/dotnet/standard/assembly/

Assemblies take the form of executable (*.exe*) or dynamic link library (
*.dll*) files, and are the building blocks of .NET applications. They 
provide the common language runtime with the information it needs to be 
aware of type implementations.

peter

On Tuesday, May 21, 2024 at 4:31:47 PM UTC-4 Kurtis Rader wrote:

> Since the question is incoherent and the link to the package you claim to 
> be using doesn't resolve to a valid host name I'm going to assume this is 
> spam and you're not really a person asking for help.
>
> P.S., Saying it "is not working" is meaningless. If you are a real person 
> asking for help show us the code you wrote and explain what you expected 
> and what actually happened when you compiled and ran your code.
>

-- 
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/d8fa482d-bc9a-4151-9a95-3900c6389bf6n%40googlegroups.com.

Re: [go-nuts] Calling the .net dlls to the golang

[Kurtis Rader]

Since the question is incoherent and the link to the package you claim to
be using doesn't resolve to a valid host name I'm going to assume this is
spam and you're not really a person asking for help.

P.S., Saying it "is not working" is meaningless. If you are a real person
asking for help show us the code you wrote and explain what you expected
and what actually happened when you compiled and ran your code.

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

[go-nuts] Re: vet: Respect PATH

[andrew.p...@gmail.com]

Same request for goimports.

func GoImports(args ...string) error {
mg.Deps(CollectGoFiles)

for pth := range CollectedGoFiles {
cmd := exec.Command("goimports")
cmd.Args = append(cmd.Args, args...)
cmd.Args = append(cmd.Args, pth)
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr

if err := cmd.Run(); err != nil {
return err
}
}

return nil
}

Instead of the above nonsense, the user should be able to scan a large Go 
project with:

goimports ./...

Maybe these features have been added in recent Go versions. If so, please 
comment which specific Go versions finally added basic directory recursion 
to more of these tools.

On Tuesday, May 21, 2024 at 10:48:12 AM UTC-5 andrew.p...@gmail.com wrote:

> Similar request for gofmt. It should accept the ordinary ./... Go project 
> recursion syntax, instead of the awkward, explicit:
>
> func GoFmt(args ...string) error {
> mg.Deps(CollectGoFiles)
>
> for pth := range CollectedGoFiles {
> cmd := exec.Command("gofmt")
> cmd.Args = append(cmd.Args, args...)
> cmd.Args = append(cmd.Args, pth)
> cmd.Stdout = os.Stdout
> cmd.Stderr = os.Stderr
>
> if err := cmd.Run(); err != nil {
> return err
> }
> }
>
> return nil
> }
>
> In other words, the user should be able to invoke gofmt on a large Go 
> project with:
>
> gofmt ./...
>
> Looping over files is a simple enough concept for the tool to implement 
> itself, directly. Looping over files in wrapping scripts, such as shell 
> code, invites dragons.
>
> On Tuesday, May 21, 2024 at 10:45:14 AM UTC-5 andrew.p...@gmail.com wrote:
>
>> go vet fails to obey the standard PATH environment variable (POSIX, 
>> Windows). This makes it unnecessarily cumbersome to use go vet.
>>
>> Here is an example (Mage) script to scan Go projects for variable 
>> shadowing:
>>
>> func GoVetShadow(args ...string) error {
>> shadowPath, err := exec.LookPath("shadow")
>>
>> if err != nil {
>> return err
>> }
>>
>> return GoVet(fmt.Sprintf("-vettool=%s", shadowPath))
>> }
>>
>> The shadow tool is unable to recurse over Go projects with the ordinary 
>> ./... syntax; It relies on go vet. And even with the x/tools shadow 
>> installed and on PATH, go vet nevertheless requires an absolute path to the 
>> program.
>>
>> Please simplify both of these, so that the user can simply run:
>>
>> go vet -vettool=shadow
>>
>> Or:
>>
>> shadow ./...
>>
>> Which are easier to remember and lighter on the fingers.
>>
>> Some gophers will point out that we already have a working solution with 
>> Mage, and it's conceivable that equivalents are available in related build 
>> systems like make (POSIX, GNU, BSD, etc.) or sh (POSIX, bash, zsh, etc.) 
>> However, the requirement for the user to provide an absolute path tends to 
>> create maintenance hassles, fragile build scripts, many portability 
>> problems, and general resource waste. PATH already provides the 
>> information; please stop breaking basic things at the process level.
>>
>

-- 
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/537fe765-873c-417c-b74d-772e33c3dc23n%40googlegroups.com.

[go-nuts] Re: vet: Respect PATH

[andrew.p...@gmail.com]

Similar request for gofmt. It should accept the ordinary ./... Go project 
recursion syntax, instead of the awkward, explicit:

func GoFmt(args ...string) error {
mg.Deps(CollectGoFiles)

for pth := range CollectedGoFiles {
cmd := exec.Command("gofmt")
cmd.Args = append(cmd.Args, args...)
cmd.Args = append(cmd.Args, pth)
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr

if err := cmd.Run(); err != nil {
return err
}
}

return nil
}

In other words, the user should be able to invoke gofmt on a large Go 
project with:

gofmt ./...

Looping over files is a simple enough concept for the tool to implement 
itself, directly. Looping over files in wrapping scripts, such as shell 
code, invites dragons.

On Tuesday, May 21, 2024 at 10:45:14 AM UTC-5 andrew.p...@gmail.com wrote:

> go vet fails to obey the standard PATH environment variable (POSIX, 
> Windows). This makes it unnecessarily cumbersome to use go vet.
>
> Here is an example (Mage) script to scan Go projects for variable 
> shadowing:
>
> func GoVetShadow(args ...string) error {
> shadowPath, err := exec.LookPath("shadow")
>
> if err != nil {
> return err
> }
>
> return GoVet(fmt.Sprintf("-vettool=%s", shadowPath))
> }
>
> The shadow tool is unable to recurse over Go projects with the ordinary 
> ./... syntax; It relies on go vet. And even with the x/tools shadow 
> installed and on PATH, go vet nevertheless requires an absolute path to the 
> program.
>
> Please simplify both of these, so that the user can simply run:
>
> go vet -vettool=shadow
>
> Or:
>
> shadow ./...
>
> Which are easier to remember and lighter on the fingers.
>
> Some gophers will point out that we already have a working solution with 
> Mage, and it's conceivable that equivalents are available in related build 
> systems like make (POSIX, GNU, BSD, etc.) or sh (POSIX, bash, zsh, etc.) 
> However, the requirement for the user to provide an absolute path tends to 
> create maintenance hassles, fragile build scripts, many portability 
> problems, and general resource waste. PATH already provides the 
> information; please stop breaking basic things at the process level.
>

-- 
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/ba413feb-99d3-401f-b6b9-14c8dad7127dn%40googlegroups.com.

Re: [go-nuts] Discover go-size-analyzer: Streamline Your Go Binary Insights

[Luca Pascali]

Nice

PSK

On Tue, May 21, 2024 at 5:17 PM Zxilly Chou  wrote:

> Hello go-nuts,
>
> I'm excited to share a new tool that has landed in our Go ecosystem:
> go-size-analyzer. This utility is designed to give you a clear picture of
> the size of your compiled Go binaries, with a focus on how dependencies
> contribute to the overall footprint.
>
> It simplifies the process of binary size analysis and offers a range of
> viewing options, from web interfaces to terminal UIs and text formats. It's
> also highly customisable, so you can tailor the output to suit your needs.
>
> The project is open source and actively seeking contributions, so if
> you're interested in this kind of tool, it's definitely worth a look.
>
> You can find more information and get started with go-size-analyzer on its
> GitHub page: https://github.com/Zxilly/go-size-analyzer
>
> Happy coding!
>
> Best,
>
> Zxilly
>
> --
> 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/af78ab03-f793-40f2-8721-20ef3f3a5a13n%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/CAJNBTx%2BSZ5hZ9UTehuP8BuTOqAmCt7k-jOFKpNuNnLLMpFkdKQ%40mail.gmail.com.

[go-nuts] vet: Respect PATH

[andrew.p...@gmail.com]

go vet fails to obey the standard PATH environment variable (POSIX, 
Windows). This makes it unnecessarily cumbersome to use go vet.

Here is an example (Mage) script to scan Go projects for variable shadowing:

func GoVetShadow(args ...string) error {
shadowPath, err := exec.LookPath("shadow")

if err != nil {
return err
}

return GoVet(fmt.Sprintf("-vettool=%s", shadowPath))
}

The shadow tool is unable to recurse over Go projects with the ordinary 
./... syntax; It relies on go vet. And even with the x/tools shadow 
installed and on PATH, go vet nevertheless requires an absolute path to the 
program.

Please simplify both of these, so that the user can simply run:

go vet -vettool=shadow

Or:

shadow ./...

Which are easier to remember and lighter on the fingers.

Some gophers will point out that we already have a working solution with 
Mage, and it's conceivable that equivalents are available in related build 
systems like make (POSIX, GNU, BSD, etc.) or sh (POSIX, bash, zsh, etc.) 
However, the requirement for the user to provide an absolute path tends to 
create maintenance hassles, fragile build scripts, many portability 
problems, and general resource waste. PATH already provides the 
information; please stop breaking basic things at the process level.

-- 
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/d7c16676-9cc3-477e-a822-af5deba12e12n%40googlegroups.com.

[go-nuts] Discover go-size-analyzer: Streamline Your Go Binary Insights

[Zxilly Chou]

Hello go-nuts,

I'm excited to share a new tool that has landed in our Go ecosystem: 
go-size-analyzer. This utility is designed to give you a clear picture of 
the size of your compiled Go binaries, with a focus on how dependencies 
contribute to the overall footprint.

It simplifies the process of binary size analysis and offers a range of 
viewing options, from web interfaces to terminal UIs and text formats. It's 
also highly customisable, so you can tailor the output to suit your needs.

The project is open source and actively seeking contributions, so if you're 
interested in this kind of tool, it's definitely worth a look.

You can find more information and get started with go-size-analyzer on its 
GitHub page: https://github.com/Zxilly/go-size-analyzer

Happy coding!

Best,

Zxilly

-- 
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/af78ab03-f793-40f2-8721-20ef3f3a5a13n%40googlegroups.com.

[go-nuts] Uses of reflect and unsafe packages

[Ketan Rathod]

I have seen many discussions using refflect and unsafe packages, so i am 
curious to know their usecases and when it is useful to use this packages.

-- 
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/07589604-959f-4d62-94e8-2e12e27126f6n%40googlegroups.com.

[go-nuts] Calling the .net dlls to the golang

[Pavan Kumar A R]

Hello , 

I am new to Golang. I have the.net dlls, and I am trying to call the.net 
function in the dll in Golang. but its not working and i searching in the 
Google also i could not find the relavent information, please me out here 
and provide the sample program also

Thanks for the advance.

-- 
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/5aad3949-6a1a-4884-a27c-69fc7246724bn%40googlegroups.com.

[go-nuts] Re: Alternative text/template function libraries to github.com/Masterminds/sprig?

[twp...@gmail.com]

Just following up on this old message, there now seems to be at least:

https://github.com/go-sprout/sprout
https://github.com/chezmoi/templatefuncs

Regards,
Tom

On Monday, January 9, 2023 at 8:53:41 PM UTC+1 Tom Payne wrote:

> github.com/Masterminds/sprig is a popular library of template functions, 
> used by some popular projects, e.g. Kubernetes Helm.
>
> Unfortunately, Masterminds/sprig also has a number of inherent flaws:
> 1. The order of arguments to many of its functions is incompatible with 
> text/template's pipeline syntax.
> 2. Many of its functions do not handle strings, []bytes, variable numbers 
> of arguments, and other argument variations in a sensible way.
> 3. It has, at the time of writing, 78 open issues 
> , most of them unaddressed, 
> and has seen only minor maintenance activity over the last few years.
> 4. Its function names do not follow Go's naming conventions.
>
> #1 and #2 cannot be fixed in a backwards-compatible way. #3 means that 
> fixes aren't practically accepted anyway. #4 just means that templates 
> using Masterminds/sprig are ugly to Go developer eyes.
>
> Instead, I want a library of template functions that works well with 
> text/template, has decent ergonomics, follows Go's naming conventions, and 
> is actively maintained. I don't care about backwards compatibility with 
> sprig as this is impossible to achieve anyway.
>
> Before I start such a project, are there any existing good existing 
> alternatives to Masterminds/sprig?
>
> Many thanks,
> Tom
>

-- 
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/af98d89e-2aa7-4758-9597-0a4192574e64n%40googlegroups.com.

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

[Sudarshan Soma]

Thanks Ian, Yes i followed a similar approach and it's working fine..

On Sun, May 19, 2024 at 4:36 AM Ian Lance Taylor  wrote:

> 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()
> >> > C.myprint()
> >> > // 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/CAHJvL%3DYoTFAZ4o8Ep7%2Bgt7B5R82QY9JLEpCCqsBbFezHFHtdWg%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()
>> > C.myprint()
>> > // 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.

[go-nuts] Re: replacement for filepath.HasPrefix?

[peterGo]

Jochen,

"the first step is to define exactly what the function should do."

path/filepath: fix HasPrefix #18358
https://github.com/golang/go/issues/18358#issuecomment-497728574

Peter
On Thursday, May 16, 2024 at 7:15:45 AM UTC-4 Jochen Voss wrote:

> Dear all,
>
> filepath.HasPrefix is deprecated, because it doesn't alway work.  What 
> would be a replacement for this function, which at least respects path 
> boundaries, and maybe also ignores case when needed?
>
> All the best,
> Jochen
>
>

-- 
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/70b47126-1b97-4ef8-b8d0-90e8b6ede058n%40googlegroups.com.

[go-nuts] replacement for filepath.HasPrefix?

[Jochen Voss]

Dear all,

filepath.HasPrefix is deprecated, because it doesn't alway work.  What 
would be a replacement for this function, which at least respects path 
boundaries, and maybe also ignores case when needed?

All the best,
Jochen

-- 
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/4cca691c-ab0a-4081-9e60-2fa0b2155f62n%40googlegroups.com.

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

[Pavan]

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. 

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()
> > C.myprint()
> > // 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.

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()
> C.myprint()
> // 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] Re: programmatic way to find if application go binary is built with -cover flag ?

[肖华冬]

There is possibly a way to do this by parsing strings in the binary. Because when -cover is enabled, go will insert instrumentation statements into the source code, thus the resulting binary would contain these info.On May 14, 2024, at 17:19, Akash Kumar  wrote:I unable to find a flag from corresponds to -cover in the result returned from debug.buildInfoOn Monday, May 13, 2024 at 10:51:33 PM UTC+5:30 Tamás Gulácsi wrote:runtime/debug.ReadBuildInfo is a good source of truth:$ strings bin/godeb|grep '^build\s'build   -buildmode=exebuild   -compiler=gcbuild   DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1build   CGO_ENABLED=1build   CGO_CFLAGS=build   CGO_CPPFLAGS=build   CGO_CXXFLAGS=build   CGO_LDFLAGS=build   GOARCH=amd64build   GOOS=linuxbuild   GOAMD64=v1build   -buildmode=exebuild   -compiler=gcbuild   DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1build   CGO_ENABLED=1build   CGO_CFLAGS=build   CGO_CPPFLAGS=build   CGO_CXXFLAGS=build   CGO_LDFLAGS=build   GOARCH=amd64build   GOOS=linuxbuild   GOAMD64=v1Akash Kumar a következőt írta (2024. május 13., hétfő, 18:42:30 UTC+2):I am writing an external go program that will take the path to another go binary as argument, and checks if the binary was built with cover flag.`debug.ReadBuildInfo()` is meant for getting build info embedded in the running binary as > ReadBuildInfo returns the build information embedded in the running binary On Monday, May 13, 2024 at 6:37:46 PM UTC+5:30 Zxilly Chou wrote:try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.Settings在2024年5月13日星期一 UTC+8 20:56:51 写道：Is there a way in go to find whether a go binary is built with -cover flag ?



-- 
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/9fda396a-b79e-4b9e-9bc0-13a9cef2c921n%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/50BA2D36-E4D4-4BE1-9117-A7BA15E17446%40gmail.com.

[go-nuts] SFTPGo 2.6.0 Released

[Nicola Murino]

Hi all,

I'm pleased to announce SFTPGo 2.6.0!

SFTPGo is an event-driven file transfer solution. It support multiple 
protocols (SFTP, SCP, FTP/S, WebDAV, HTTP/S) and multiple storage backends.

Main new features:

- Rewritten WebClient and WebAdmin UIs: we hope you find these new user 
interfaces more modern and easier to use. They also include a dark mode.
- Documentation moved to sftpgo.github.io.
- Experimental support for internazionalization.
- Time-based access restrictions.
- Allow to require password change and two-factor authentication also for 
admins, before it was possible only for users.
- Allow to automatically disable or delete inactive users.

Full release notes:

https://github.com/drakkan/sftpgo/releases/tag/v2.6.0

Commercial support:

https://sftpgo.com/#pricing

Yours sincerely,
Nicola

-- 
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/16faf97a-e696-4aa4-b223-980ae7914c3cn%40googlegroups.com.

Re: [go-nuts] Re: raw bit types without arithmetic

['Kevin Chowski' via golang-nuts]

By the way - I definitely don't feel strongly about this, and I am just 
guessing that it's more likely to support new operators for existing types 
than it is to create new built-in types. I think bitsN types are fine, 
although again I don't know if I'd personally ever use them. But I am 
enjoying the conversation so far, so here are some more thoughts I had :)

I think the fact that you can compare huge byte arrays with == means that 
there is some desire inside the Go compiler team to support variable-length 
operations based on the type regardless of whether it can be "efficiently" 
compiled on all systems, so I don't see that aspect as being inconsistent 
with the existing language. As another example that is more dynamic (and 
therefore even more "surprising"), doing `string1 == string2` might take a 
very long time if string1 and string2 have the same contents and have a 
huge length. To me, those seem the same (or worse) as accepting that 
`byteArray1 | byteArray2` might take a long time if they are statically 
known to be long byte arrays; it seems pretty straightforward that doing an 
operation on `[N]byte` will be faster than an operation on `[N*1000]byte` 
and I think people will intuit that.

As for whether it would be weird to support some operations on some arrays 
but not others, technically this is already true: you can't use == on an 
array when the elements are not comparable. And people seem OK with that 
:)   there are also some other special cases for the byte type, e.g. you 
can convert a byte slice into a string (and viceversa) but not with an int 
slice. I personally don't see this inconsistency as an issue or learning 
impediment, but I can understand that someone may disagree with my 
perspective here.

(Another idea: how about both? e.g. if we had both `bitsN` types AND the 
ability to use bitwise operations on arrays of (only) bitsN types? Or 
something along those lines. That would open up the ability to express some 
SIMD operations in otherwise extremely idiomatic-looking code, while also 
supporting the smaller-scale operations you are suggesting.)

On Tuesday, May 14, 2024 at 12:27:01 PM UTC-6 jimmy frasche wrote:

> Arrays are arrays regardless of what they're arrays of. So it would be
> strange for arrays of certain things to have properties that other
> arrays don't have and bitwise ops don't make sense for arrays of, say,
> strings.
>
> Also some processors support these sizes natively but wouldn't support
> a [4096]byte natively. On processors that don't support all or some of
> these sizes it would need to fake it by doing m operations† but that's
> bounded and if, for example, the target processor supports 256 bit but
> not 512 bit values it can use two 256 ORs instead of four 64 bit ORs.
> Maybe that could be made to work in general and if so that would be
> great but it's not the only benefit of these types.
>
> † except for shifts, those would have to deal with carries. That may
> be a problem, but I think even then it should be fast enough to not be
> an issue the way faking div or something very expensive like that
> would be.
>
> On Mon, May 13, 2024 at 8:41 PM Kevin Chowski  wrote:
> >
> > Sorry, sent too early.
> >
> > Obviously that doesn't support the bitwise type conversion you 
> mentioned; I don't really have an opinion on that one, I don't really 
> convert from float to bits very often.
> >
> > It seems like the compiler optimizations you mention could happen with 
> or without these extra types, if such optimizations just worked on byte 
> arrays in general.
> >
> > On Monday, May 13, 2024 at 9:38:36 PM UTC-6 Kevin Chowski wrote:
> >>
> >> How about just allowing bitwise operations on byte arrays (of the same 
> length)?
> >>
> >> On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:
> >>>
> >>> I'm not 100% sure if this is a good idea but it's been knocking around
> >>> in my head all week so I thought I'd share in case it has any merit:
> >>>
> >>> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.
> >>>
> >>> These are similar to uintN but they are unordered and have no
> >>> arithmetic operations defined.
> >>>
> >>> They only have literals, comparison, and bitwise operations.
> >>> (fmt.Print and friends should render them in hex by default.)
> >>>
> >>> Conversions between the numeric types and the bitN are allowed, which,
> >>> for example, let's us rewrite math.Float64bits as simply
> >>>
> >>> func Float64bits(f float64) uint64 {
> >>> return uint64(bits64(f))
> >>> }
> >>>
> >>> Since there are no arithmetic operations, the 128+ sizes should be
> >>> fairly efficient to fake on architectures without special
> >>> instructions/registers.
> >>>
> >>> Potential uses:
> >>>
> >>> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.
> >>>
> >>> SIMD vectors could be created and stored easily, even if they need
> >>> assembly to operate on them efficiently.
> >>>
> >>> Same for int128/uint128 values or 

[go-nuts] Runtime error with golang 1.22.x

[Masanori Matsumoto]

Since updating golang to v1.22, I'm getting errors in my tests using 
pact-go.

So I raised issue to the pact-go repository:
https://github.com/pact-foundation/pact-go/issues/402

The error is as follows:
---
runtime: g 19: unexpected return pc for 
github.com/pact-foundation/pact-go/v2/internal/native.(*Interaction).GivenWithParameter
 
called from 0xe18a8f
stack: frame={sp:0xcb1bf8, fp:0xcb1d28} 
stack=[0xcb,0xcb2000)
...
fatal error: unknown caller pc
---

It only happens on amd64 when you run the test with the `-race` option.

My concern is that this is a golang issue, not pact-go, and I wonder if I 
should create a golang issue.

-- 
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/788005f9-5952-43cd-85dc-75f4c0ecfafcn%40googlegroups.com.

[go-nuts] tls.VerifyClientCertIfGiven

[Jochen Voss]

Hello,

In a server I use tls.Config.ClientAuth=tls.VerifyClientCertIfGiven.
If then a client manages to connect and I can see a certificate in
http.Request.TLS.PeerCertificates, does this just mean that the client
has the certificate, or does this also prove that the client has the 
associated private key?

Many thanks,
Jochen

-- 
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/7003fa55-2436-4b85-a5ab-eed2d54430d0n%40googlegroups.com.

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

[Pavan]

Hi, 
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()
C.myprint()
// Output: 32
}

-- 
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/1b34c3ba-cf4b-4663-b509-5ef84e9600c1n%40googlegroups.com.

Re: [go-nuts] Re: raw bit types without arithmetic

[jimmy frasche]

Arrays are arrays regardless of what they're arrays of. So it would be
strange for arrays of certain things to have properties that other
arrays don't have and bitwise ops don't make sense for arrays of, say,
strings.

Also some processors support these sizes natively but wouldn't support
a [4096]byte natively. On processors that don't support all or some of
these sizes it would need to fake it by doing m operations† but that's
bounded and if, for example, the target processor supports 256 bit but
not 512 bit values it can use two 256 ORs instead of four 64 bit ORs.
Maybe that could be made to work in general and if so that would be
great but it's not the only benefit of these types.

† except for shifts, those would have to deal with carries. That may
be a problem, but I think even then it should be fast enough to not be
an issue the way faking div or something very expensive like that
would be.

On Mon, May 13, 2024 at 8:41 PM Kevin Chowski  wrote:
>
> Sorry, sent too early.
>
> Obviously that doesn't support the bitwise type conversion you mentioned; I 
> don't really have an opinion on that one, I don't really convert from float 
> to bits very often.
>
> It seems like the compiler optimizations you mention could happen with or 
> without these extra types, if such optimizations just worked on byte arrays 
> in general.
>
> On Monday, May 13, 2024 at 9:38:36 PM UTC-6 Kevin Chowski wrote:
>>
>> How about just allowing bitwise operations on byte arrays (of the same 
>> length)?
>>
>> On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:
>>>
>>> I'm not 100% sure if this is a good idea but it's been knocking around
>>> in my head all week so I thought I'd share in case it has any merit:
>>>
>>> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.
>>>
>>> These are similar to uintN but they are unordered and have no
>>> arithmetic operations defined.
>>>
>>> They only have literals, comparison, and bitwise operations.
>>> (fmt.Print and friends should render them in hex by default.)
>>>
>>> Conversions between the numeric types and the bitN are allowed, which,
>>> for example, let's us rewrite math.Float64bits as simply
>>>
>>> func Float64bits(f float64) uint64 {
>>> return uint64(bits64(f))
>>> }
>>>
>>> Since there are no arithmetic operations, the 128+ sizes should be
>>> fairly efficient to fake on architectures without special
>>> instructions/registers.
>>>
>>> Potential uses:
>>>
>>> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.
>>>
>>> SIMD vectors could be created and stored easily, even if they need
>>> assembly to operate on them efficiently.
>>>
>>> Same for int128/uint128 values or even for more exotic numeric types
>>> like the various float16 definitions or "floating slash" rationals.
>>>
>>> It would also be handy to have larger bitsets that are easy to work with.
>
> --
> 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/1f0329c1-8b82-4683-999e-62b9a046c0a8n%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/CANG3jXLdcRs9AMS_xE15EEgqKmYFRgexgGBfpSxVA-%3D60A69sQ%40mail.gmail.com.

Re: [go-nuts] Bitmask is slower than modulo calculation

['Keith Randall' via golang-nuts]

Your test is benchmarking int->any conversions more than it is testing the 
underlying modulo/mask difference.
When you pass an integer to Enqueue, it is converted to any, which 
(usually) involves an allocation. That will swamp the cost of any single 
arithmetic operation.

There are a few ways to fix it. Probably the simplest is to make your ring 
buffers generic on the element type.
You could also fix the benchmark, by precomputing the any-typed elements 
you're going to enqueue before starting the timer.

When you get a surprising benchmark result, always run the benchmark with 
profiling on (-cpuprofile) and look at the resulting profile. This is a 
case where it would be obvious what the problem is.
On Sunday, May 12, 2024 at 10:18:38 PM UTC-7 robert engels wrote:

> Hi. This is still not correct. Use the “for.. in b.N” as discussed in the 
> blog in order to understand the per op difference - which will be more 
> accurate for a microbenchmark timing,
>
> But, if you really want to make a case that bit mask is slower than mod, 
> then a simpler test would be better - you can do these ops on in loop using 
> b.N to time the difference.
>
>
>
> On May 12, 2024, at 8:28 PM, Yuta MIYAKE  wrote:
>
> Thank you. 
>
> This is benchstat result. new test code follows:
>
> ❯ go test -test.bench BenchmarkTestSingleModulo -count=10 -cpu=1 > 
> modulo.txt
> ❯ go test -test.bench BenchmarkTestSingleBitMask -count=10 -cpu=1 > 
> bitmask.txt
> ❯ benchstat modulo.txt bitmask.txt
> goos: darwin
> goarch: arm64
> pkg: ringbuffer
>   │ modulo.txt │bitmask.txt│
>   │   sec/op   │   sec/opvs base   │
> TestSingleModulo6.648 ± 1%
> TestSingleBitMask6.694 ± 5%
> geomean 6.6486.694   ? ¹ ²
>
>
> new test code:
>
> const BufferSize = 2 * 1024 * 1024
>
> func benchmarkSingle(rb RingBuffer) {
>
>
> total := 50
> for i := 0; i < total; i++ {
> for j := 0; j < 1000; j++ {
> rb.Enqueue(j)
> }
> for j := 0; j < 1000; j++ {
> rb.Dequeue()
> }
> }
> }
>
>
> func BenchmarkTestSingleModulo(b *testing.B) {
> rb := NewRingBuffer0(BufferSize)
> b.ResetTimer()
> benchmarkSingle(rb)
> }
>
> func BenchmarkTestSingleBitMask(b *testing.B) {
> rb := NewRingBuffer1(BufferSize)
> b.ResetTimer()
> benchmarkSingle(rb)
> }
>
> On Monday, May 13, 2024 at 8:20:05 AM UTC+9 robert engels wrote:
>
>> Use the Go benchmarking facilities, see 
>> https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go
>>
>> On May 11, 2024, at 9:57 PM, leon  wrote:
>>
>> I'm trying to prove an optimization technique for ring buffer is 
>> effective. One of the technique is using bitmask instead of modulo to 
>> calculate a wrap around. However, in my environment, modulo is slightly 
>> faster in a test where 1 billion items are enqueued /dequeued by a single 
>> goroutine. What do you think could be the cause? 
>>
>> Full code:
>> https://go.dev/play/p/H933oqrhPI-
>>
>> Environment:
>> * go version go1.21.4 darwin/arm64
>> * Apple M1 Pro
>>
>> RingBuffer with modulo:
>> ```
>> type RingBuffer0 struct {
>> writeIdx uint64
>> readIdx  uint64
>> buffers  []any
>> size uint64
>> }
>>
>> func NewRingBuffer0(size uint64) *RingBuffer0 {
>> rb := {}
>> rb.init(size)
>> return rb
>> }
>>
>> func (rb *RingBuffer0) init(size uint64) {
>> rb.buffers = make([]any, size)
>> rb.size = size
>> }
>>
>> func (rb *RingBuffer0) Enqueue(item any) error {
>> if rb.writeIdx-rb.readIdx == rb.size {
>> return ErrBufferFull
>> }
>> rb.buffers[rb.writeIdx%rb.size] = item
>> rb.writeIdx++
>> return nil
>> }
>>
>> func (rb *RingBuffer0) Dequeue() (any, error) {
>> if rb.writeIdx == rb.readIdx {
>> return nil, ErrBufferEmpty
>> }
>> item := rb.buffers[rb.readIdx%rb.size]
>> rb.readIdx++
>> return item, nil
>> }
>> ```
>>
>> RingBuffer with bitmask:
>> change each module calculation to the code below
>> * rb.buffers[rb.writeIdx&(rb.size-1)] = item
>> * item := rb.buffers[rb.readIdx&(rb.size-1)]
>>
>> Test:
>> func TestSingle(rb RingBuffer) {
>> start := time.Now()
>> total := 50
>> for i := 0; i < total; i++ {
>> for j := 0; j < 1000; j++ {
>> rb.Enqueue(j)
>> }
>> for j := 0; j < 1000; j++ {
>> rb.Dequeue()
>> }
>> }
>> end := time.Now()
>> count := total * 2000
>> duration := end.Sub(start).Milliseconds()
>> fmt.Printf("%d ops in %d ms\n", count, duration)
>> }
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b9c4d2e0-4ab4-4d27-9359-abd8c090ae33n%40googlegroups.com
>>  
>> 
>> .
>>
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" 

[go-nuts] Re: programmatic way to find if application go binary is built with -cover flag ?

[Akash Kumar]

I unable to find a flag from corresponds to -cover in the result returned 
from debug.buildInfo
On Monday, May 13, 2024 at 10:51:33 PM UTC+5:30 Tamás Gulácsi wrote:

> runtime/debug.ReadBuildInfo is a good source of truth:
> $ strings bin/godeb|grep '^build\s'
>
> build   -buildmode=exe
> build   -compiler=gc
> build   
> DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
> build   CGO_ENABLED=1
> build   CGO_CFLAGS=
> build   CGO_CPPFLAGS=
> build   CGO_CXXFLAGS=
> build   CGO_LDFLAGS=
> build   GOARCH=amd64
> build   GOOS=linux
> build   GOAMD64=v1
> build   -buildmode=exe
> build   -compiler=gc
> build   
> DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
> build   CGO_ENABLED=1
> build   CGO_CFLAGS=
> build   CGO_CPPFLAGS=
> build   CGO_CXXFLAGS=
> build   CGO_LDFLAGS=
> build   GOARCH=amd64
> build   GOOS=linux
> build   GOAMD64=v1
>
> Akash Kumar a következőt írta (2024. május 13., hétfő, 18:42:30 UTC+2):
>
>> I am writing an external go program that will take the path to another go 
>> binary as argument, and checks if the binary was built with cover flag.
>>
>> `debug.ReadBuildInfo()` is meant for getting build info embedded in the 
>> running binary as 
>> > ReadBuildInfo returns the build information embedded in the running 
>> binary 
>>
>> On Monday, May 13, 2024 at 6:37:46 PM UTC+5:30 Zxilly Chou wrote:
>>
>>> try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.
>>> Settings
>>>
>>> 在2024年5月13日星期一 UTC+8 20:56:51 写道：
>>>
 Is there a way in go to find whether a go binary is built with -cover 
 flag ?
>>>
>>>

-- 
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/9fda396a-b79e-4b9e-9bc0-13a9cef2c921n%40googlegroups.com.

[go-nuts] Re: raw bit types without arithmetic

[Kevin Chowski]

Sorry, sent too early.

Obviously that doesn't support the bitwise type conversion you mentioned; I 
don't really have an opinion on that one, I don't really convert from float 
to bits very often.

It seems like the compiler optimizations you mention could happen with or 
without these extra types, if such optimizations just worked on byte arrays 
in general.

On Monday, May 13, 2024 at 9:38:36 PM UTC-6 Kevin Chowski wrote:

> How about just allowing bitwise operations on byte arrays (of the same 
> length)?
>
> On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:
>
>> I'm not 100% sure if this is a good idea but it's been knocking around 
>> in my head all week so I thought I'd share in case it has any merit: 
>>
>> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512. 
>>
>> These are similar to uintN but they are unordered and have no 
>> arithmetic operations defined. 
>>
>> They only have literals, comparison, and bitwise operations. 
>> (fmt.Print and friends should render them in hex by default.) 
>>
>> Conversions between the numeric types and the bitN are allowed, which, 
>> for example, let's us rewrite math.Float64bits as simply 
>>
>> func Float64bits(f float64) uint64 { 
>> return uint64(bits64(f)) 
>> } 
>>
>> Since there are no arithmetic operations, the 128+ sizes should be 
>> fairly efficient to fake on architectures without special 
>> instructions/registers. 
>>
>> Potential uses: 
>>
>> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte. 
>>
>> SIMD vectors could be created and stored easily, even if they need 
>> assembly to operate on them efficiently. 
>>
>> Same for int128/uint128 values or even for more exotic numeric types 
>> like the various float16 definitions or "floating slash" rationals. 
>>
>> It would also be handy to have larger bitsets that are easy to work with. 
>>
>

-- 
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/1f0329c1-8b82-4683-999e-62b9a046c0a8n%40googlegroups.com.

[go-nuts] Re: raw bit types without arithmetic

[Kevin Chowski]

How about just allowing bitwise operations on byte arrays (of the same 
length)?

On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:

> I'm not 100% sure if this is a good idea but it's been knocking around
> in my head all week so I thought I'd share in case it has any merit:
>
> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.
>
> These are similar to uintN but they are unordered and have no
> arithmetic operations defined.
>
> They only have literals, comparison, and bitwise operations.
> (fmt.Print and friends should render them in hex by default.)
>
> Conversions between the numeric types and the bitN are allowed, which,
> for example, let's us rewrite math.Float64bits as simply
>
> func Float64bits(f float64) uint64 {
> return uint64(bits64(f))
> }
>
> Since there are no arithmetic operations, the 128+ sizes should be
> fairly efficient to fake on architectures without special
> instructions/registers.
>
> Potential uses:
>
> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.
>
> SIMD vectors could be created and stored easily, even if they need
> assembly to operate on them efficiently.
>
> Same for int128/uint128 values or even for more exotic numeric types
> like the various float16 definitions or "floating slash" rationals.
>
> It would also be handy to have larger bitsets that are easy to work with.
>

-- 
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/d0507019-b796-47b6-a4e9-3e407879866cn%40googlegroups.com.

[go-nuts] raw bit types without arithmetic

[jimmy frasche]

I'm not 100% sure if this is a good idea but it's been knocking around
in my head all week so I thought I'd share in case it has any merit:

Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.

These are similar to uintN but they are unordered and have no
arithmetic operations defined.

They only have literals, comparison, and bitwise operations.
(fmt.Print and friends should render them in hex by default.)

Conversions between the numeric types and the bitN are allowed, which,
for example, let's us rewrite math.Float64bits as simply

func Float64bits(f float64) uint64 {
return uint64(bits64(f))
}

Since there are no arithmetic operations, the 128+ sizes should be
fairly efficient to fake on architectures without special
instructions/registers.

Potential uses:

UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.

SIMD vectors could be created and stored easily, even if they need
assembly to operate on them efficiently.

Same for int128/uint128 values or even for more exotic numeric types
like the various float16 definitions or "floating slash" rationals.

It would also be handy to have larger bitsets that are easy to work with.

-- 
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/CANG3jX%2B_%3DhjfGEVAaOTToTRHsOVVqTmWQEZz9kzD-uYT0jNosA%40mail.gmail.com.

[go-nuts] Re: programmatic way to find if application go binary is built with -cover flag ?

[Tamás Gulácsi]

runtime/debug.ReadBuildInfo is a good source of truth:
$ strings bin/godeb|grep '^build\s'

build   -buildmode=exe
build   -compiler=gc
build   
DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
build   CGO_ENABLED=1
build   CGO_CFLAGS=
build   CGO_CPPFLAGS=
build   CGO_CXXFLAGS=
build   CGO_LDFLAGS=
build   GOARCH=amd64
build   GOOS=linux
build   GOAMD64=v1
build   -buildmode=exe
build   -compiler=gc
build   
DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
build   CGO_ENABLED=1
build   CGO_CFLAGS=
build   CGO_CPPFLAGS=
build   CGO_CXXFLAGS=
build   CGO_LDFLAGS=
build   GOARCH=amd64
build   GOOS=linux
build   GOAMD64=v1

Akash Kumar a következőt írta (2024. május 13., hétfő, 18:42:30 UTC+2):

> I am writing an external go program that will take the path to another go 
> binary as argument, and checks if the binary was built with cover flag.
>
> `debug.ReadBuildInfo()` is meant for getting build info embedded in the 
> running binary as 
> > ReadBuildInfo returns the build information embedded in the running 
> binary 
>
> On Monday, May 13, 2024 at 6:37:46 PM UTC+5:30 Zxilly Chou wrote:
>
>> try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.
>> Settings
>>
>> 在2024年5月13日星期一 UTC+8 20:56:51 写道：
>>
>>> Is there a way in go to find whether a go binary is built with -cover 
>>> flag ?
>>
>>

-- 
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/aa819a76-2c8e-4b9a-b37d-92abd3ff2877n%40googlegroups.com.

Re: [go-nuts] Re: VCS Stamping - How To Use It? How to debug failures?

[Adam Kaplan]

I forgot to add one more detail - the go-toolset image defaults to running
as user "default" (UID 1001).

Adding `USER root` right after the `FROM` declaration is another way to
work around the issue I described, but from a security perspective I would
advise against it.

On Mon, May 13, 2024 at 12:24 PM Adam Kaplan  wrote:

> Great suggestion Jason - adding `git status` took me in a very unexpected
> direction, and ultimately a solution.
>
> tl;dr if your build's base container image does not use root/uid 0, git
> commands won't work unless you add the `--chown=` flag to your `COPY`
> instruction. Go builds need this if you want `-buildvcs=auto|true` to
> succeed.
>
> When I changed my build command to `RUN git status && go build` in the
> Dockerfile, I got the following output:
>
> ```
> $ podman build -t localhost/sclorg/hello-openshift:latest .
> [1/2] STEP 1/3: FROM registry.redhat.io/ubi9/go-toolset:1.20.12 AS builder
> [1/2] STEP 2/3: COPY . .
> --> 10a13b463199
> [1/2] STEP 3/3: RUN git status && go build -o /tmp/hello
> fatal: detected dubious ownership in repository at '/opt/app-root/src'
> To add an exception for this directory, call:
>
> git config --global --add safe.directory /opt/app-root/src
> Error: building at STEP "RUN git status && go build -o /tmp/hello": while
> running runtime: exit status 128
> ```
>
> This was a new and different error message for me - but same exit code as
> before. A quick Google search brought me to CVE-2022-24765 [1], whose fix
> introduced this "dubious ownership" message/protection.
>
> I was finally able to piece everything together with a few more debug
> builds and internet searches:
>
> 1. On Fedora 39, podman runs in "rootless" mode. Files owned by me show up
> as owned by "root" in containers.
> 2. For Linux containers, `COPY` commands in Dockerfiles copy files as
> UID/GID 0 unless the `--chown` flag is passed. [2].
> 3. As part of the mitigation for CVE-2022-24765, git commands will succeed
> only if:
>   a. The `.git` directory is owned by the same user executing the `.git`
> command OR
>   b. The parent directory marked "safe" in the git configuration.
>
> Using `COPY --chown=default . .` instead of `COPY . .` works for the UBI
> go-toolset image referenced previously in this thread. Your results may
> vary using other golang "builder" images.
>
> [1] https://github.blog/2022-04-12-git-security-vulnerability-announced/
> [2] https://docs.docker.com/reference/dockerfile/#copy---chown---chmod
>
>
> On Sat, May 11, 2024 at 11:43 AM Jason E. Aten  wrote:
>
>> > how can developers debug and find the root cause?
>>
>> If it was me, I would start by going into the container (whatever the
>> podman equivalent of docker exec -it containernumber bash) and try to run
>> 'git status' or 'git log' and see why the git query is giving an error.
>> You could also try strace to see what git command specifically is being
>> execed, then try to get that command working manually.
>>
>> --
>> 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/LZbM2WlZoJM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/ca680397-1497-4b3a-83ce-301c936308c1n%40googlegroups.com
>> 
>> .
>>
>
>
> --
>
> Adam Kaplan
>
> He/Him
>
> Principal Software Engineer
>
> Red Hat 
>
> 100 E. Davie Street
>
> adam.kap...@redhat.comT: 1-919-754-4843
> 
>
>

-- 

Adam Kaplan

He/Him

Principal Software Engineer

Red Hat 

100 E. Davie Street

adam.kap...@redhat.comT: 1-919-754-4843


-- 
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/CADmLb%2Bkfvd%3DYbnzW1QzgkTe93UUkOfW9TtCBf168DEi8YxWJ1w%40mail.gmail.com.

Re: [go-nuts] Re: VCS Stamping - How To Use It? How to debug failures?

[Adam Kaplan]

Great suggestion Jason - adding `git status` took me in a very unexpected
direction, and ultimately a solution.

tl;dr if your build's base container image does not use root/uid 0, git
commands won't work unless you add the `--chown=` flag to your `COPY`
instruction. Go builds need this if you want `-buildvcs=auto|true` to
succeed.

When I changed my build command to `RUN git status && go build` in the
Dockerfile, I got the following output:

```
$ podman build -t localhost/sclorg/hello-openshift:latest .
[1/2] STEP 1/3: FROM registry.redhat.io/ubi9/go-toolset:1.20.12 AS builder
[1/2] STEP 2/3: COPY . .
--> 10a13b463199
[1/2] STEP 3/3: RUN git status && go build -o /tmp/hello
fatal: detected dubious ownership in repository at '/opt/app-root/src'
To add an exception for this directory, call:

git config --global --add safe.directory /opt/app-root/src
Error: building at STEP "RUN git status && go build -o /tmp/hello": while
running runtime: exit status 128
```

This was a new and different error message for me - but same exit code as
before. A quick Google search brought me to CVE-2022-24765 [1], whose fix
introduced this "dubious ownership" message/protection.

I was finally able to piece everything together with a few more debug
builds and internet searches:

1. On Fedora 39, podman runs in "rootless" mode. Files owned by me show up
as owned by "root" in containers.
2. For Linux containers, `COPY` commands in Dockerfiles copy files as
UID/GID 0 unless the `--chown` flag is passed. [2].
3. As part of the mitigation for CVE-2022-24765, git commands will succeed
only if:
  a. The `.git` directory is owned by the same user executing the `.git`
command OR
  b. The parent directory marked "safe" in the git configuration.

Using `COPY --chown=default . .` instead of `COPY . .` works for the UBI
go-toolset image referenced previously in this thread. Your results may
vary using other golang "builder" images.

[1] https://github.blog/2022-04-12-git-security-vulnerability-announced/
[2] https://docs.docker.com/reference/dockerfile/#copy---chown---chmod


On Sat, May 11, 2024 at 11:43 AM Jason E. Aten  wrote:

> > how can developers debug and find the root cause?
>
> If it was me, I would start by going into the container (whatever the
> podman equivalent of docker exec -it containernumber bash) and try to run
> 'git status' or 'git log' and see why the git query is giving an error.
> You could also try strace to see what git command specifically is being
> execed, then try to get that command working manually.
>
> --
> 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/LZbM2WlZoJM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ca680397-1497-4b3a-83ce-301c936308c1n%40googlegroups.com
> 
> .
>


-- 

Adam Kaplan

He/Him

Principal Software Engineer

Red Hat 

100 E. Davie Street

adam.kap...@redhat.comT: 1-919-754-4843


-- 
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/CADmLb%2B%3DpPMFT5fnBpC4C8QuxD%3DFNTO1c74o6Nx6F6zL2eJALbg%40mail.gmail.com.

[go-nuts] Re: programmatic way to find if application go binary is built with -cover flag ?

[Akash Kumar]

I am writing an external go program that will take the path to another go 
binary as argument, and checks if the binary was built with cover flag.

`debug.ReadBuildInfo()` is meant for getting build info embedded in the 
running binary as 
> ReadBuildInfo returns the build information embedded in the running 
binary 

On Monday, May 13, 2024 at 6:37:46 PM UTC+5:30 Zxilly Chou wrote:

> try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.Settings
>
> 在2024年5月13日星期一 UTC+8 20:56:51 写道：
>
>> Is there a way in go to find whether a go binary is built with -cover 
>> flag ?
>
>

-- 
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/81a62099-4b33-4048-80a6-15b3332767d1n%40googlegroups.com.

[go-nuts] Re: programmatic way to find if application go binary is built with -cover flag ?

[Zxilly Chou]

try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.Settings

在2024年5月13日星期一 UTC+8 20:56:51 写道：

> Is there a way in go to find whether a go binary is built with -cover flag 
> ?

-- 
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/b78a192f-80f9-4a93-a1d6-bed613e56000n%40googlegroups.com.

[go-nuts] programmatic way to find if application go binary is built with -cover flag ?

[Akash Kumar]

Is there a way in go to find whether a go binary is built with -cover flag ?

-- 
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/e0a2d60f-9f86-48b9-a265-316a575a6427n%40googlegroups.com.

[go-nuts] Re: question about src/cmd/go/internal/script/cmds_posix.go and windows

[peterGo]

Hiroaki,

go/src/cmd/go/internal/test/test_nonunix.go

//go:build !unix

package test

func isETXTBSY(err error) bool {
// syscall.ETXTBSY is only meaningful on Unix platforms.
return false
}

peter

On Monday, May 13, 2024 at 4:32:38 AM UTC-4 hnak...@gmail.com wrote:

> Hi,
> I found that
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/script/cmds_posix.go
> has the build tag
> //go:build unix || windows
>
> Is windows really needed here? (I suppose not)
>
> isETXTBSY is also defined in
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/test/test_unix.go
> and its build tag is:
> //go:build unix
> which I think correct.
>
> Thanks,
> Hiroaki
>

-- 
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/b3a5600f-b748-436e-8d81-9682d4c7bc0an%40googlegroups.com.

[go-nuts] Re: question about src/cmd/go/internal/script/cmds_posix.go and windows

[peterGo]

Hiroaki,

go/src/syscall/zerrors_windows.go

// Invented values to support what package os and others expects.
const (
...
ETXTBSY
...
)

peter
On Monday, May 13, 2024 at 4:32:38 AM UTC-4 hnak...@gmail.com wrote:

> Hi,
> I found that
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/script/cmds_posix.go
> has the build tag
> //go:build unix || windows
>
> Is windows really needed here? (I suppose not)
>
> isETXTBSY is also defined in
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/test/test_unix.go
> and its build tag is:
> //go:build unix
> which I think correct.
>
> Thanks,
> Hiroaki
>

-- 
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/de181ed7-e9c8-4683-8f1d-8b9cabe665cdn%40googlegroups.com.

[go-nuts] question about src/cmd/go/internal/script/cmds_posix.go and windows

[hnak...@gmail.com]

Hi,
I found that
https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/script/cmds_posix.go
has the build tag
//go:build unix || windows

Is windows really needed here? (I suppose not)

isETXTBSY is also defined in
https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/test/test_unix.go
and its build tag is:
//go:build unix
which I think correct.

Thanks,
Hiroaki

-- 
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/8de9aed7-a2ad-4e94-a8ce-ec405b8e0da9n%40googlegroups.com.

Re: [go-nuts] Bitmask is slower than modulo calculation

[robert engels]

Hi. This is still not correct. Use the “for.. in b.N” as discussed in the blog 
in order to understand the per op difference - which will be more accurate for 
a microbenchmark timing,

But, if you really want to make a case that bit mask is slower than mod, then a 
simpler test would be better - you can do these ops on in loop using b.N to 
time the difference.



> On May 12, 2024, at 8:28 PM, Yuta MIYAKE  wrote:
> 
> Thank you. 
> 
> This is benchstat result. new test code follows:
> 
> ❯ go test -test.bench BenchmarkTestSingleModulo -count=10 -cpu=1 > modulo.txt
> ❯ go test -test.bench BenchmarkTestSingleBitMask -count=10 -cpu=1 > 
> bitmask.txt
> ❯ benchstat modulo.txt bitmask.txt
> goos: darwin
> goarch: arm64
> pkg: ringbuffer
>   │ modulo.txt │bitmask.txt│
>   │   sec/op   │   sec/opvs base   │
> TestSingleModulo6.648 ± 1%
> TestSingleBitMask6.694 ± 5%
> geomean 6.6486.694   ? ¹ ²
> 
> 
> new test code:
> 
> const BufferSize = 2 * 1024 * 1024
> 
> func benchmarkSingle(rb RingBuffer) {
>   total := 50
>   for i := 0; i < total; i++ {
>   for j := 0; j < 1000; j++ {
>   rb.Enqueue(j)
>   }
>   for j := 0; j < 1000; j++ {
>   rb.Dequeue()
>   }
>   }
> }
> 
> func BenchmarkTestSingleModulo(b *testing.B) {
>   rb := NewRingBuffer0(BufferSize)
>   b.ResetTimer()
>   benchmarkSingle(rb)
> }
> 
> func BenchmarkTestSingleBitMask(b *testing.B) {
>   rb := NewRingBuffer1(BufferSize)
>   b.ResetTimer()
>   benchmarkSingle(rb)
> }
> 
> On Monday, May 13, 2024 at 8:20:05 AM UTC+9 robert engels wrote:
> Use the Go benchmarking facilities, see 
> https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go 
> 
> 
> 
>> On May 11, 2024, at 9:57 PM, leon > > wrote:
>> 
> 
>> I'm trying to prove an optimization technique for ring buffer is effective. 
>> One of the technique is using bitmask instead of modulo to calculate a wrap 
>> around. However, in my environment, modulo is slightly faster in a test 
>> where 1 billion items are enqueued /dequeued by a single goroutine. What do 
>> you think could be the cause? 
>> 
>> Full code:
>> https://go.dev/play/p/H933oqrhPI- 
>> 
>> Environment:
>> * go version go1.21.4 darwin/arm64
>> * Apple M1 Pro
>> 
>> RingBuffer with modulo:
>> ```
>> type RingBuffer0 struct {
>>  writeIdx uint64
>>  readIdx  uint64
>>  buffers  []any
>>  size uint64
>> }
>> 
>> func NewRingBuffer0(size uint64) *RingBuffer0 {
>>  rb := {}
>>  rb.init(size)
>>  return rb
>> }
>> 
>> func (rb *RingBuffer0) init(size uint64) {
>>  rb.buffers = make([]any, size)
>>  rb.size = size
>> }
>> 
>> func (rb *RingBuffer0) Enqueue(item any) error {
>>  if rb.writeIdx-rb.readIdx == rb.size {
>>  return ErrBufferFull
>>  }
>>  rb.buffers[rb.writeIdx%rb.size] = item
>>  rb.writeIdx++
>>  return nil
>> }
>> 
>> func (rb *RingBuffer0) Dequeue() (any, error) {
>>  if rb.writeIdx == rb.readIdx {
>>  return nil, ErrBufferEmpty
>>  }
>>  item := rb.buffers[rb.readIdx%rb.size]
>>  rb.readIdx++
>>  return item, nil
>> }
>> ```
>> 
>> RingBuffer with bitmask:
>> change each module calculation to the code below
>> * rb.buffers[rb.writeIdx&(rb.size-1)] = item
>> * item := rb.buffers[rb.readIdx&(rb.size-1)]
>> 
>> Test:
>> func TestSingle(rb RingBuffer) {
>>  start := time.Now()
>>  total := 50
>>  for i := 0; i < total; i++ {
>>  for j := 0; j < 1000; j++ {
>>  rb.Enqueue(j)
>>  }
>>  for j := 0; j < 1000; j++ {
>>  rb.Dequeue()
>>  }
>>  }
>>  end := time.Now()
>>  count := total * 2000
>>  duration := end.Sub(start).Milliseconds()
>>  fmt.Printf("%d ops in %d ms\n", count, duration)
>> }
>> 
>> 
> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b9c4d2e0-4ab4-4d27-9359-abd8c090ae33n%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 
> 

Re: [go-nuts] Bitmask is slower than modulo calculation

[Yuta MIYAKE]

Thank you. 

This is benchstat result. new test code follows:

❯ go test -test.bench BenchmarkTestSingleModulo -count=10 -cpu=1 > 
modulo.txt
❯ go test -test.bench BenchmarkTestSingleBitMask -count=10 -cpu=1 > 
bitmask.txt
❯ benchstat modulo.txt bitmask.txt
goos: darwin
goarch: arm64
pkg: ringbuffer
  │ modulo.txt │bitmask.txt│
  │   sec/op   │   sec/opvs base   │
TestSingleModulo6.648 ± 1%
TestSingleBitMask6.694 ± 5%
geomean 6.6486.694   ? ¹ ²


new test code:

const BufferSize = 2 * 1024 * 1024

func benchmarkSingle(rb RingBuffer) {
total := 50
for i := 0; i < total; i++ {
for j := 0; j < 1000; j++ {
rb.Enqueue(j)
}
for j := 0; j < 1000; j++ {
rb.Dequeue()
}
}
}

func BenchmarkTestSingleModulo(b *testing.B) {
rb := NewRingBuffer0(BufferSize)
b.ResetTimer()
benchmarkSingle(rb)
}

func BenchmarkTestSingleBitMask(b *testing.B) {
rb := NewRingBuffer1(BufferSize)
b.ResetTimer()
benchmarkSingle(rb)
}

On Monday, May 13, 2024 at 8:20:05 AM UTC+9 robert engels wrote:

> Use the Go benchmarking facilities, see 
> https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go
>
> On May 11, 2024, at 9:57 PM, leon  wrote:
>
> I'm trying to prove an optimization technique for ring buffer is 
> effective. One of the technique is using bitmask instead of modulo to 
> calculate a wrap around. However, in my environment, modulo is slightly 
> faster in a test where 1 billion items are enqueued /dequeued by a single 
> goroutine. What do you think could be the cause? 
>
> Full code:
> https://go.dev/play/p/H933oqrhPI-
>
> Environment:
> * go version go1.21.4 darwin/arm64
> * Apple M1 Pro
>
> RingBuffer with modulo:
> ```
> type RingBuffer0 struct {
> writeIdx uint64
> readIdx  uint64
> buffers  []any
> size uint64
> }
>
> func NewRingBuffer0(size uint64) *RingBuffer0 {
> rb := {}
> rb.init(size)
> return rb
> }
>
> func (rb *RingBuffer0) init(size uint64) {
> rb.buffers = make([]any, size)
> rb.size = size
> }
>
> func (rb *RingBuffer0) Enqueue(item any) error {
> if rb.writeIdx-rb.readIdx == rb.size {
> return ErrBufferFull
> }
> rb.buffers[rb.writeIdx%rb.size] = item
> rb.writeIdx++
> return nil
> }
>
> func (rb *RingBuffer0) Dequeue() (any, error) {
> if rb.writeIdx == rb.readIdx {
> return nil, ErrBufferEmpty
> }
> item := rb.buffers[rb.readIdx%rb.size]
> rb.readIdx++
> return item, nil
> }
> ```
>
> RingBuffer with bitmask:
> change each module calculation to the code below
> * rb.buffers[rb.writeIdx&(rb.size-1)] = item
> * item := rb.buffers[rb.readIdx&(rb.size-1)]
>
> Test:
> func TestSingle(rb RingBuffer) {
> start := time.Now()
> total := 50
> for i := 0; i < total; i++ {
> for j := 0; j < 1000; j++ {
> rb.Enqueue(j)
> }
> for j := 0; j < 1000; j++ {
> rb.Dequeue()
> }
> }
> end := time.Now()
> count := total * 2000
> duration := end.Sub(start).Milliseconds()
> fmt.Printf("%d ops in %d ms\n", count, duration)
> }
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/b9c4d2e0-4ab4-4d27-9359-abd8c090ae33n%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/efe2618f-c520-4b53-b233-a724fe9b77d5n%40googlegroups.com.

Re: [go-nuts] Bitmask is slower than modulo calculation

[leon]

Thank you so much. 

2024年5月13日月曜日 12:58:09 UTC+9 Kurtis Rader:

> On my Apple Studio system the difference in speed is barely measurable and 
> sometimes the bitmask implementation is faster:
>
>  macpro  ~/experiment  > go run ring.go
> 10 ops in 5092 ms
> 10 ops in 5140 ms
>  macpro  ~/experiment  > go run ring.go
> 10 ops in 5080 ms
> 10 ops in 5122 ms
>  macpro  ~/experiment  > go run ring.go
> 10 ops in 5166 ms
> 10 ops in 5133 ms
>
>
> Micro-benchmarks of this nature are notoriously sensitive to noise and 
> unexpected factors such as the location of code and variables in memory. 
> Those examples show a +0.94%, +0.83%, and -0,64% change in execution time 
> respectively. I would not be surprised if a huge number of runs showed the 
> modulo variant is consistently faster on the order of 0.5% to 1.0%. 
> Figuring out why will likely require examining the actual instruction 
> sequences being executed and a very detailed understanding of the CPU 
> architecture.
>
> P.S., the code in the Go Playground can't be run as-is and was very 
> different from the code in your email. If you want people to help you 
> should make it easier for people to test the behavior of your code.
>
> On Sat, May 11, 2024 at 9:58 PM leon  wrote:
>
>> I'm trying to prove an optimization technique for ring buffer is 
>> effective. One of the technique is using bitmask instead of modulo to 
>> calculate a wrap around. However, in my environment, modulo is slightly 
>> faster in a test where 1 billion items are enqueued /dequeued by a single 
>> goroutine. What do you think could be the cause? 
>>
>> Full code:
>> https://go.dev/play/p/H933oqrhPI-
>>
>> Environment:
>> * go version go1.21.4 darwin/arm64
>> * Apple M1 Pro
>>
>> RingBuffer with modulo:
>> ```
>> type RingBuffer0 struct {
>> writeIdx uint64
>> readIdx  uint64
>> buffers  []any
>> size uint64
>> }
>>
>> func NewRingBuffer0(size uint64) *RingBuffer0 {
>> rb := {}
>> rb.init(size)
>> return rb
>> }
>>
>> func (rb *RingBuffer0) init(size uint64) {
>> rb.buffers = make([]any, size)
>> rb.size = size
>> }
>>
>> func (rb *RingBuffer0) Enqueue(item any) error {
>> if rb.writeIdx-rb.readIdx == rb.size {
>> return ErrBufferFull
>> }
>> rb.buffers[rb.writeIdx%rb.size] = item
>> rb.writeIdx++
>> return nil
>> }
>>
>> func (rb *RingBuffer0) Dequeue() (any, error) {
>> if rb.writeIdx == rb.readIdx {
>> return nil, ErrBufferEmpty
>> }
>> item := rb.buffers[rb.readIdx%rb.size]
>> rb.readIdx++
>> return item, nil
>> }
>> ```
>>
>> RingBuffer with bitmask:
>> change each module calculation to the code below
>> * rb.buffers[rb.writeIdx&(rb.size-1)] = item
>> * item := rb.buffers[rb.readIdx&(rb.size-1)]
>>
>> Test:
>> func TestSingle(rb RingBuffer) {
>> start := time.Now()
>> total := 50
>> for i := 0; i < total; i++ {
>> for j := 0; j < 1000; j++ {
>> rb.Enqueue(j)
>> }
>> for j := 0; j < 1000; j++ {
>> rb.Dequeue()
>> }
>> }
>> end := time.Now()
>> count := total * 2000
>> duration := end.Sub(start).Milliseconds()
>> fmt.Printf("%d ops in %d ms\n", count, duration)
>> }
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b9c4d2e0-4ab4-4d27-9359-abd8c090ae33n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4c543c1f-46eb-433e-9058-1504bf5a44een%40googlegroups.com.

Re: [go-nuts] Bitmask is slower than modulo calculation

[Kurtis Rader]

On my Apple Studio system the difference in speed is barely measurable and
sometimes the bitmask implementation is faster:

 macpro  ~/experiment  > go run ring.go
10 ops in 5092 ms
10 ops in 5140 ms
 macpro  ~/experiment  > go run ring.go
10 ops in 5080 ms
10 ops in 5122 ms
 macpro  ~/experiment  > go run ring.go
10 ops in 5166 ms
10 ops in 5133 ms


Micro-benchmarks of this nature are notoriously sensitive to noise and
unexpected factors such as the location of code and variables in memory.
Those examples show a +0.94%, +0.83%, and -0,64% change in execution time
respectively. I would not be surprised if a huge number of runs showed the
modulo variant is consistently faster on the order of 0.5% to 1.0%.
Figuring out why will likely require examining the actual instruction
sequences being executed and a very detailed understanding of the CPU
architecture.

P.S., the code in the Go Playground can't be run as-is and was very
different from the code in your email. If you want people to help you
should make it easier for people to test the behavior of your code.

On Sat, May 11, 2024 at 9:58 PM leon  wrote:

> I'm trying to prove an optimization technique for ring buffer is
> effective. One of the technique is using bitmask instead of modulo to
> calculate a wrap around. However, in my environment, modulo is slightly
> faster in a test where 1 billion items are enqueued /dequeued by a single
> goroutine. What do you think could be the cause?
>
> Full code:
> https://go.dev/play/p/H933oqrhPI-
>
> Environment:
> * go version go1.21.4 darwin/arm64
> * Apple M1 Pro
>
> RingBuffer with modulo:
> ```
> type RingBuffer0 struct {
> writeIdx uint64
> readIdx  uint64
> buffers  []any
> size uint64
> }
>
> func NewRingBuffer0(size uint64) *RingBuffer0 {
> rb := {}
> rb.init(size)
> return rb
> }
>
> func (rb *RingBuffer0) init(size uint64) {
> rb.buffers = make([]any, size)
> rb.size = size
> }
>
> func (rb *RingBuffer0) Enqueue(item any) error {
> if rb.writeIdx-rb.readIdx == rb.size {
> return ErrBufferFull
> }
> rb.buffers[rb.writeIdx%rb.size] = item
> rb.writeIdx++
> return nil
> }
>
> func (rb *RingBuffer0) Dequeue() (any, error) {
> if rb.writeIdx == rb.readIdx {
> return nil, ErrBufferEmpty
> }
> item := rb.buffers[rb.readIdx%rb.size]
> rb.readIdx++
> return item, nil
> }
> ```
>
> RingBuffer with bitmask:
> change each module calculation to the code below
> * rb.buffers[rb.writeIdx&(rb.size-1)] = item
> * item := rb.buffers[rb.readIdx&(rb.size-1)]
>
> Test:
> func TestSingle(rb RingBuffer) {
> start := time.Now()
> total := 50
> for i := 0; i < total; i++ {
> for j := 0; j < 1000; j++ {
> rb.Enqueue(j)
> }
> for j := 0; j < 1000; j++ {
> rb.Dequeue()
> }
> }
> end := time.Now()
> count := total * 2000
> duration := end.Sub(start).Milliseconds()
> fmt.Printf("%d ops in %d ms\n", count, duration)
> }
>
> --
> 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/b9c4d2e0-4ab4-4d27-9359-abd8c090ae33n%40googlegroups.com
> 
> .
>


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

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

Re: [go-nuts] Bitmask is slower than modulo calculation

[robert engels]

Use the Go benchmarking facilities, see 
https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go

> On May 11, 2024, at 9:57 PM, leon  wrote:
> 
> I'm trying to prove an optimization technique for ring buffer is effective. 
> One of the technique is using bitmask instead of modulo to calculate a wrap 
> around. However, in my environment, modulo is slightly faster in a test where 
> 1 billion items are enqueued /dequeued by a single goroutine. What do you 
> think could be the cause? 
> 
> Full code:
> https://go.dev/play/p/H933oqrhPI-
> 
> Environment:
> * go version go1.21.4 darwin/arm64
> * Apple M1 Pro
> 
> RingBuffer with modulo:
> ```
> type RingBuffer0 struct {
>   writeIdx uint64
>   readIdx  uint64
>   buffers  []any
>   size uint64
> }
> 
> func NewRingBuffer0(size uint64) *RingBuffer0 {
>   rb := {}
>   rb.init(size)
>   return rb
> }
> 
> func (rb *RingBuffer0) init(size uint64) {
>   rb.buffers = make([]any, size)
>   rb.size = size
> }
> 
> func (rb *RingBuffer0) Enqueue(item any) error {
>   if rb.writeIdx-rb.readIdx == rb.size {
>   return ErrBufferFull
>   }
>   rb.buffers[rb.writeIdx%rb.size] = item
>   rb.writeIdx++
>   return nil
> }
> 
> func (rb *RingBuffer0) Dequeue() (any, error) {
>   if rb.writeIdx == rb.readIdx {
>   return nil, ErrBufferEmpty
>   }
>   item := rb.buffers[rb.readIdx%rb.size]
>   rb.readIdx++
>   return item, nil
> }
> ```
> 
> RingBuffer with bitmask:
> change each module calculation to the code below
> * rb.buffers[rb.writeIdx&(rb.size-1)] = item
> * item := rb.buffers[rb.readIdx&(rb.size-1)]
> 
> Test:
> func TestSingle(rb RingBuffer) {
>   start := time.Now()
>   total := 50
>   for i := 0; i < total; i++ {
>   for j := 0; j < 1000; j++ {
>   rb.Enqueue(j)
>   }
>   for j := 0; j < 1000; j++ {
>   rb.Dequeue()
>   }
>   }
>   end := time.Now()
>   count := total * 2000
>   duration := end.Sub(start).Milliseconds()
>   fmt.Printf("%d ops in %d ms\n", count, duration)
> }
> 
> 
> -- 
> 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/b9c4d2e0-4ab4-4d27-9359-abd8c090ae33n%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/042B0E0B-459D-479D-B538-4B53FFAF55F5%40ix.netcom.com.

[go-nuts] Bitmask is slower than modulo calculation

[leon]

I'm trying to prove an optimization technique for ring buffer is effective. 
One of the technique is using bitmask instead of modulo to calculate a wrap 
around. However, in my environment, modulo is slightly faster in a test 
where 1 billion items are enqueued /dequeued by a single goroutine. What do 
you think could be the cause? 

Full code:
https://go.dev/play/p/H933oqrhPI-

Environment:
* go version go1.21.4 darwin/arm64
* Apple M1 Pro

RingBuffer with modulo:
```
type RingBuffer0 struct {
writeIdx uint64
readIdx  uint64
buffers  []any
size uint64
}

func NewRingBuffer0(size uint64) *RingBuffer0 {
rb := {}
rb.init(size)
return rb
}

func (rb *RingBuffer0) init(size uint64) {
rb.buffers = make([]any, size)
rb.size = size
}

func (rb *RingBuffer0) Enqueue(item any) error {
if rb.writeIdx-rb.readIdx == rb.size {
return ErrBufferFull
}
rb.buffers[rb.writeIdx%rb.size] = item
rb.writeIdx++
return nil
}

func (rb *RingBuffer0) Dequeue() (any, error) {
if rb.writeIdx == rb.readIdx {
return nil, ErrBufferEmpty
}
item := rb.buffers[rb.readIdx%rb.size]
rb.readIdx++
return item, nil
}
```

RingBuffer with bitmask:
change each module calculation to the code below
* rb.buffers[rb.writeIdx&(rb.size-1)] = item
* item := rb.buffers[rb.readIdx&(rb.size-1)]

Test:
func TestSingle(rb RingBuffer) {
start := time.Now()
total := 50
for i := 0; i < total; i++ {
for j := 0; j < 1000; j++ {
rb.Enqueue(j)
}
for j := 0; j < 1000; j++ {
rb.Dequeue()
}
}
end := time.Now()
count := total * 2000
duration := end.Sub(start).Milliseconds()
fmt.Printf("%d ops in %d ms\n", count, duration)
}

-- 
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/b9c4d2e0-4ab4-4d27-9359-abd8c090ae33n%40googlegroups.com.

[go-nuts] Re: VCS Stamping - How To Use It? How to debug failures?

[Jason E. Aten]

> how can developers debug and find the root cause?

If it was me, I would start by going into the container (whatever the 
podman equivalent of docker exec -it containernumber bash) and try to run 
'git status' or 'git log' and see why the git query is giving an error.  
You could also try strace to see what git command specifically is being 
execed, then try to get that command working manually.

-- 
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/ca680397-1497-4b3a-83ce-301c936308c1n%40googlegroups.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.

[go-nuts] Re: var errors stdlib

['Brian Candler' via golang-nuts]

On Friday 10 May 2024 at 17:03:46 UTC+1 Sebastian Bogan wrote:

Would something like the following work (and be less risky)?:

  type ConstError string
  func (e ConstError) Error() string {
return string(e)
  }
  const ErrNotExist = ConstError("file does not exist")


If you compare an error value against this constant, and the error value 
has the correct type, then you're actually doing a character-by-character 
comparison of the string text, not unique object identity.

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

-- 
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/7cafdb37-9e29-4ab5-8bab-49d7b9fc59fcn%40googlegroups.com.

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

[Tobias Klausmann]

Hi! 

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? 

Best,
Tobias

-- 
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/d127858e-a161-4f71-8fc8-4df4c602bf92%40skade.local.

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] var errors stdlib

['Dan Kortschak' via golang-nuts]

On Fri, 2024-05-10 at 04:24 -0700, Sebastian Bogan wrote:
> Hello Everyone,
> 
> I was wondering, what was / is the reason for exposing errors as
> public vars - rather than constants? Doesn't that impose some risk?
> 
> For example:
> 
>   fs.ErrNotExist = errors.New("foo")
>   _, err = os.ReadFile("./invalid")
>   if !errors.Is(err, fs.ErrNotExist) {
>     fmt.Println("is NOT fs.ErrNotExist")
>   }
> 
> Would something like the following work (and be less risky)?:
> 
>   type ConstError string
>   func (e ConstError) Error() string {
>     return string(e)
>   }
>   const ErrNotExist = ConstError("file does not exist")
> 

Interface values cannot be consts per the spec. But to address the
concern, if some malicious or misguided package in your imports
reassigns a value to an exported error var, the example you show would
still work since the value is still common to all users of the var. If
the check were against the string returned by the Error method there
would be a problem, but that is advised against already. It could
potentially be a source of race conditions if the import made the
change after init and the read were happening in goroutine.

There are issues in the tracker that discuss const values,
https://go.dev/issue/6386 is probably a good place to start.

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

[go-nuts] VCS Stamping - How To Use It? How to debug failures?

[Adam Kaplan (He / Him / His)]

My team recently started using podman and the UBI9 go-toolset image to 
containerize our golang apps [1]. We found that if our Dockerfile copied 
the entire source tree in (including the .git directory), `go build` would 
fail unless we set the `-buildvcs=false` flag [2].

Since this wasn't happening on my local machine (Fedora 39), I tried to 
debug further only to find a surprising lack of documentation on this 
feature. I couldn't find anything in the `go` command documentation beyond 
the short note on what the `-buildvcs` flag does [3]. Nor could I easily 
find information on how developers can consume the VCS stamp information. 
My hope is that this feature would/could replace the `-ldflags` technique 
many golang developers have used to inject source control information into  
applications.

Is there any documentation that exists here? And for instances when 
`-buildvcs=auto|true` fails, how can developers debug and find the root 
cause?

Pertinent version information for those who want to investigate further:

Go version (in the container): go1.20.12 linux/amd64
Git version (container): 2.39.3
Podman version (Fedora 39): 
Client:   Podman Engine
Version:  4.9.4
API Version:  4.9.4
Go Version:   go1.21.8
Built:Tue Mar 26 05:39:52 2024
OS/Arch:  linux/amd64

[1] 
https://catalog.redhat.com/software/containers/ubi9/go-toolset/61e5c00b4ec9945c18787690?q=go%20toolset=amd64=6627073123047dd3dc857edb
[2] https://issues.redhat.com/browse/RHEL-36097
[3] https://pkg.go.dev/cmd/go

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/21a0a261-9194-462e-8bc0-c5151543d0d8n%40googlegroups.com.

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

[Tobias Klausmann]

Hi!

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?


Best,
Tobias

-- 
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/Zj5chzqyVg_h87jw%40skade.schwarzvogel.de.

[go-nuts] var errors stdlib

[Sebastian Bogan]

Hello Everyone,

I was wondering, what was / is the reason for exposing errors as public 
vars - rather than constants? Doesn't that impose some risk?

For example:

  fs.ErrNotExist = errors.New("foo")
  _, err = os.ReadFile("./invalid")
  if !errors.Is(err, fs.ErrNotExist) {
fmt.Println("is NOT fs.ErrNotExist")
  }

Would something like the following work (and be less risky)?:

  type ConstError string
  func (e ConstError) Error() string {
return string(e)
  }
  const ErrNotExist = ConstError("file does not exist")

Thanks
Seb

-- 
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/45805816-9264-4312-a524-3fba6e3a77d2n%40googlegroups.com.

[go-nuts] strange perf sample when trying to understand the cause of high minor page fault

['Zhao Weng' via golang-nuts]

Hi gophers,

We have a web service running with high minor page fault and I'm trying to 
understand why. I start by using linux perf:
```bash
sudo perf record -e minor-faults -c 1 -C 0-2 -ag -- sleep 15
sudo perf script > perf.out
```
and in the output file perf.out, I found many strange trace records:
```
tsproducer-prod 390772 [002] 2661398.756621:  1 minor-faults:
  ea8a10 memcpy+0x24 (/usr/local/bin/tsproducer-prod)
```
and they are the majority of all records.
these records surprise me that it contains no stack trace between, seem 
like it's calling memcpy from nowhere, and i can not understand how this 
could happen base one my knowledge. I would expect something like 
"runtime.goexit.abi0" or "runtime.asmcgocall.abi0" before "memcpy".

By the way, this code is compiled using go 1.22.2
I should attach a flame graph generated base on perf.out.
please advise me on how to further understand this, maybe I miss some doc?

Thanks a lot, 
Zhao Weng

-- 
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/2cc16e0f-176b-4f33-8798-bba239a4ec1cn%40googlegroups.com.

[go-nuts] x/text Missing maintenance

[mr....@gmail.com]

I submitted CL to x/text, but no one seems to have any to review it at the 
moment. I also checked the recent CL for x/text. again, no one is taking 
care of it.
text has a several year old problem that has been resolved by the 
corresponding CL, but has not been merged. I'd like to support if text is 
being maintained. Thank you.

Here are the relevant links

https://go-review.googlesource.com/c/text/+/584095
https://github.com/golang/go/issues/67249
https://github.com/golang/go/issues/62697
https://go-review.googlesource.com/c/text/+/529255

-- 
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/70d25300-7b10-4122-ab23-fe3a1c41eb1dn%40googlegroups.com.

RE: [go-nuts] Re: Slice conversion function not working on big endian platform

['Pokala Srinivas' via golang-nuts]

I am using generics here to work for other types as well, it 's not only for 
converting int32[] slice to int64[], it is generic function to work for any 
conversion like BytestoInt64/32/16/8,  BytestoFloat32/64  etc.
It is failing for other conversion like BytestoInt64 , BytestoFloat64 etc on 
big-endian machine but working on little endian .

From: 'Pokala Srinivas' via golang-nuts 
Sent: 08 May 2024 15:39
To: golang-nuts ; Brian Candler 

Subject: [EXTERNAL] Re: [go-nuts] Re: Slice conversion function not working on 
big endian platform

There is typo mistake while entering, below is the code snippest: package main 
import ( "fmt" "unsafe" ) type slice struct { ptr unsafe. Pointer len int cap 
int } func Slice[To, From any](data []From) []To { var zf From var
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

Report Suspicious

ZjQcmQRYFpfptBannerEnd
There is typo mistake while entering, below is the code snippest:
package main

import (
  "fmt"
  "unsafe"
)

type slice struct {
  ptr unsafe.Pointer
  len int
  cap int
}

func Slice[To, From any](data []From) []To {
  var zf From
  var zt To
  var s = (*slice)(unsafe.Pointer())
  s.len = int((uintptr(s.len) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
  s.cap = int((uintptr(s.cap) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
  x := *(*[]To)(unsafe.Pointer(s))
  return x
}
func main() {
  a := make([]uint32, 4, 13)
  a[0] = 1
  a[1] = 0
  a[2] = 2
  a[3] = 0
  // 1 0 2 0
  b := Slice[int64](a)
  //Expecxted : []int64[]{0x 0001,  0x 0002}
  //Got: []int64{0x0001 , 0x0002 000}
  if b[0] != 1 {
fmt.Printf("wrong value at index 0: want=1 got=0x%x \n", b[0])
  }
  if b[1] != 2 {
fmt.Printf("wrong value at index 1: want=2 got=0x%x\n", b[0])
  }

}

Please try this code

From: 'Brian Candler' via golang-nuts 
Sent: 08 May 2024 15:25
To: golang-nuts 
Subject: [EXTERNAL] [go-nuts] Re: Slice conversion function not working on big 
endian platform

That code doesn't even compile in go 1. 22 or go. 1. 21: https: //go. 
dev/play/p/mPCBUQizSVo ./prog. go: 20: 14: cannot convert unsafe. Pointer(s) 
(value of type unsafe. Pointer) to type []To What's the underlying requirement? 
In the test case it looks
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

Report Suspicious

ZjQcmQRYFpfptBannerEnd
That code doesn't even compile in go 1.22 or go.1.21:
https://go.dev/play/p/mPCBUQizSVo
./prog.go:20:14: cannot convert unsafe.Pointer(s) (value of type 
unsafe.Pointer) to type []To

What's the underlying requirement? In the test case it looks like you want to 
take a slice of int32's, in whatever their internal in-memory representation 
is, and re-represent them as a slice of half as many int64's?? Then of *course* 
each pair of int32's will become one int64, and the order of the hi/lo halves 
will depend entirely on the system's internal representation of int64's. It 
*is* working, in the sense that it's doing exactly what you told it to do. 
There's a reason why the "unsafe" package is called "unsafe"!

It would be straightforward to write a function which takes a slice containing 
pairs of int32's and assembles them into int64's in a consistent way. What 
you've not explained is:
- why you need to do this with generics (for example, what behaviour would you 
expect from other types?)
- why you need to do this in-place with "unsafe"

On Wednesday 8 May 2024 at 10:24:30 UTC+1 Srinivas Pokala wrote:
Hello gopher's,

I have simple go program which convert slice of one type to slice of other type 
using go generics for handling all the supported types.
Below is the code snippest for this:
package main

import "fmt"
import "unsafe"

type slice struct {
ptr unsafe.Pointer
len int
cap int
}

func Slice[To, From any](data []From) []To {
var zf From
var zt To
var s = (*slice)(unsafe.Pointer())
s.len = int((uintptr(s.len) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
s.cap = int((uintptr(s.cap) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
x := ([]To)(unsafe.Pointer(s))
return x
}
func main() {
a := make([]uint32, 4, 13)
a[0] = 1
a[1] = 0
a[2] = 2
a[3] = 0
// 1 0 2 0
b := Slice[int64](a)
//Expecxted : 

Re: [go-nuts] Re: Slice conversion function not working on big endian platform

['Pokala Srinivas' via golang-nuts]

There is typo mistake while entering, below is the code snippest:
package main

import (
  "fmt"
  "unsafe"
)

type slice struct {
  ptr unsafe.Pointer
  len int
  cap int
}

func Slice[To, From any](data []From) []To {
  var zf From
  var zt To
  var s = (*slice)(unsafe.Pointer())
  s.len = int((uintptr(s.len) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
  s.cap = int((uintptr(s.cap) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
  x := *(*[]To)(unsafe.Pointer(s))
  return x
}
func main() {
  a := make([]uint32, 4, 13)
  a[0] = 1
  a[1] = 0
  a[2] = 2
  a[3] = 0
  // 1 0 2 0
  b := Slice[int64](a)
  //Expecxted : []int64[]{0x 0001,  0x 0002}
  //Got: []int64{0x0001 , 0x0002 000}
  if b[0] != 1 {
fmt.Printf("wrong value at index 0: want=1 got=0x%x \n", b[0])
  }
  if b[1] != 2 {
fmt.Printf("wrong value at index 1: want=2 got=0x%x\n", b[0])
  }

}

Please try this code

From: 'Brian Candler' via golang-nuts 
Sent: 08 May 2024 15:25
To: golang-nuts 
Subject: [EXTERNAL] [go-nuts] Re: Slice conversion function not working on big 
endian platform

That code doesn't even compile in go 1. 22 or go. 1. 21: https: //go. 
dev/play/p/mPCBUQizSVo ./prog. go: 20: 14: cannot convert unsafe. Pointer(s) 
(value of type unsafe. Pointer) to type []To What's the underlying requirement? 
In the test case it looks
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

Report Suspicious

ZjQcmQRYFpfptBannerEnd
That code doesn't even compile in go 1.22 or go.1.21:
https://go.dev/play/p/mPCBUQizSVo
./prog.go:20:14: cannot convert unsafe.Pointer(s) (value of type 
unsafe.Pointer) to type []To

What's the underlying requirement? In the test case it looks like you want to 
take a slice of int32's, in whatever their internal in-memory representation 
is, and re-represent them as a slice of half as many int64's?? Then of *course* 
each pair of int32's will become one int64, and the order of the hi/lo halves 
will depend entirely on the system's internal representation of int64's. It 
*is* working, in the sense that it's doing exactly what you told it to do. 
There's a reason why the "unsafe" package is called "unsafe"!

It would be straightforward to write a function which takes a slice containing 
pairs of int32's and assembles them into int64's in a consistent way. What 
you've not explained is:
- why you need to do this with generics (for example, what behaviour would you 
expect from other types?)
- why you need to do this in-place with "unsafe"

On Wednesday 8 May 2024 at 10:24:30 UTC+1 Srinivas Pokala wrote:
Hello gopher's,

I have simple go program which convert slice of one type to slice of other type 
using go generics for handling all the supported types.
Below is the code snippest for this:
package main

import "fmt"
import "unsafe"

type slice struct {
ptr unsafe.Pointer
len int
cap int
}

func Slice[To, From any](data []From) []To {
var zf From
var zt To
var s = (*slice)(unsafe.Pointer())
s.len = int((uintptr(s.len) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
s.cap = int((uintptr(s.cap) * unsafe.Sizeof(zf)) / unsafe.Sizeof(zt))
x := ([]To)(unsafe.Pointer(s))
return x
}
func main() {
a := make([]uint32, 4, 13)
a[0] = 1
a[1] = 0
a[2] = 2
a[3] = 0
// 1 0 2 0
b := Slice[int64](a)
//Expecxted : []int64[]{0x 0001,  0x 0002}
//Got: []int64{0x0001 , 0x0002 000}
if b[0] != 1 {
fmt.Printf("wrong value at index 0: want=1 got=0x%x \n", b[0])
}
if b[1] != 2 {
fmt.Printf("wrong value at index 1: want=2 got=0x%x\n", b[0])
}

}

This is working fine on little endian architectures(amd64,arm64 etc), but when 
i run on big endian machine(s390x) it is not working , it is resulting wrong 
data
//Expecxted : []int64[]{0x 0001,  0x 0002}
 //Got: []int64{0x0001 , 0x0002 000}
Can somepoint point me how do we write such scenario which should work on both 
little/endian platforms.
Any leads on this?

Thanks,
Srinivas

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

[go-nuts] Re: Slice conversion function not working on big endian platform

['Brian Candler' via golang-nuts]

That code doesn't even compile in go 1.22 or go.1.21:
https://go.dev/play/p/mPCBUQizSVo
./prog.go:20:14: cannot convert unsafe.Pointer(s) (value of type 
unsafe.Pointer) to type []To

What's the underlying requirement? In the test case it looks like you want 
to take a slice of int32's, in whatever their internal in-memory 
representation is, and re-represent them as a slice of half as many 
int64's?? Then of *course* each pair of int32's will become one int64, and 
the order of the hi/lo halves will depend entirely on the system's internal 
representation of int64's. It *is* working, in the sense that it's doing 
exactly what you told it to do. There's a reason why the "unsafe" package 
is called "unsafe"!

It would be straightforward to write a function which takes a slice 
containing pairs of int32's and assembles them into int64's in a consistent 
way. What you've not explained is:
- why you need to do this with generics (for example, what behaviour would 
you expect from other types?)
- why you need to do this in-place with "unsafe"

On Wednesday 8 May 2024 at 10:24:30 UTC+1 Srinivas Pokala wrote:

> Hello gopher's,
>
> I have simple go program which convert slice of one type to slice of other 
> type using go generics for handling all the supported types.
> Below is the code snippest for this:
> package main
>
> import "fmt"
> import "unsafe"
>
> type slice struct {
> ptr unsafe.Pointer
> len int 
> cap int 
> }
>
> func Slice[To, From any](data []From) []To {
> var zf From
> var zt To
> var s = (*slice)(unsafe.Pointer())
> s.len = int((uintptr(s.len) * unsafe.Sizeof(zf)) / 
> unsafe.Sizeof(zt))
> s.cap = int((uintptr(s.cap) * unsafe.Sizeof(zf)) / 
> unsafe.Sizeof(zt))
> x := ([]To)(unsafe.Pointer(s))
> return x
> }
> func main() {
> a := make([]uint32, 4, 13) 
> a[0] = 1 
> a[1] = 0 
> a[2] = 2 
> a[3] = 0 
> // 1 0 2 0
> b := Slice[int64](a)
> //Expecxted : []int64[]{0x 0001,  0x 0002}
> //Got: []int64{0x0001 , 0x0002 000}
> if b[0] != 1 { 
> fmt.Printf("wrong value at index 0: want=1 got=0x%x \n", 
> b[0])
> }
> if b[1] != 2 { 
> fmt.Printf("wrong value at index 1: want=2 got=0x%x\n", 
> b[0])
> }
>
> }
>
> This is working fine on little endian architectures(amd64,arm64 etc), but 
> when i run on big endian machine(s390x) it is not working , it is resulting 
> wrong data
> //Expecxted : []int64[]{0x 0001,  0x 0002}
>  //Got: []int64{0x0001 , 0x0002 000}
> Can somepoint point me how do we write such scenario which should work on 
> both little/endian platforms.
> Any leads on this?
>
> Thanks,
> Srinivas
>

-- 
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/a5b6f6fd-f3ec-4532-8579-179282610aban%40googlegroups.com.

[go-nuts] Slice conversion function not working on big endian platform

['Srinivas Pokala' via golang-nuts]

Hello gopher's,

I have simple go program which convert slice of one type to slice of other 
type using go generics for handling all the supported types.
Below is the code snippest for this:
package main

import "fmt"
import "unsafe"

type slice struct {
ptr unsafe.Pointer
len int 
cap int 
}

func Slice[To, From any](data []From) []To {
var zf From
var zt To
var s = (*slice)(unsafe.Pointer())
s.len = int((uintptr(s.len) * unsafe.Sizeof(zf)) / 
unsafe.Sizeof(zt))
s.cap = int((uintptr(s.cap) * unsafe.Sizeof(zf)) / 
unsafe.Sizeof(zt))
x := ([]To)(unsafe.Pointer(s))
return x
}
func main() {
a := make([]uint32, 4, 13) 
a[0] = 1 
a[1] = 0 
a[2] = 2 
a[3] = 0 
// 1 0 2 0
b := Slice[int64](a)
//Expecxted : []int64[]{0x 0001,  0x 0002}
//Got: []int64{0x0001 , 0x0002 000}
if b[0] != 1 { 
fmt.Printf("wrong value at index 0: want=1 got=0x%x \n", 
b[0])
}
if b[1] != 2 { 
fmt.Printf("wrong value at index 1: want=2 got=0x%x\n", 
b[0])
}

}

This is working fine on little endian architectures(amd64,arm64 etc), but 
when i run on big endian machine(s390x) it is not working , it is resulting 
wrong data
//Expecxted : []int64[]{0x 0001,  0x 0002}
 //Got: []int64{0x0001 , 0x0002 000}
Can somepoint point me how do we write such scenario which should work on 
both little/endian platforms.
Any leads on this?

Thanks,
Srinivas

-- 
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/4282aff6-0c61-4105-8032-f7c92ff341d1n%40googlegroups.com.

[go-nuts] [security] Go 1.22.3 and Go 1.21.10 are released

[Cherry Mui]

Hello gophers,

We have just released Go versions 1.22.3 and 1.21.10, minor point releases.

These minor releases include 2 security fixes following the security policy
:

   -

   cmd/go: arbitrary code execution during build on darwin

   On Darwin, building a Go module which contains CGO can trigger arbitrary
   code execution when using the Apple version of ld, due to usage of the
   -lto_library flag in a "#cgo LDFLAGS" directive.

   Thanks to Juho Forsén of Mattermost for reporting this issue.

   This is CVE-2024-24787 and Go issue https://go.dev/issue/67119.

   -

   net: malformed DNS message can cause infinite loop

   A malformed DNS message in response to a query can cause the Lookup
   functions to get stuck in an infinite loop.

   Thanks to @long-name-let-people-remember-you on GitHub for reporting
   this issue, and to Mateusz Poliwczak for bringing the issue to our
   attention.

   This is CVE-2024-24788 and Go issue https://go.dev/issue/66754.


View the release notes for more information:
https://go.dev/doc/devel/release#go1.22.3

You can download binary and source distributions from the Go website:
https://go.dev/dl/

To compile from source using a Git clone, update to the release with
git checkout go1.22.3 and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
David, Cherry, and Roland for the Go team

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

[go-nuts] question about TestPageAllocAlloc, AllFree1

[Leah Stapleton]

I have a question about scavenging arising one of the runtime tests in 
runtime/mpagealloc.go. The test in question is the " AllFree1" test case in 
TestPageAllocAlloc.

According to my understanding, in the runtime, there is a distinction 
between reclaiming memory and scavenging memory.  Reclaiming memory is 
reusing free memory for allocations while scavenging is returning memory 
back to the OS that is no longer needed by the application.

Step 1. the test starts off by setting up some scavenging state by 
scavening one page at index 0, and two pages starting at index two

scav: map[ChunkIdx][]BitRange{
BaseChunkIdx: {{0, 1}, {2, 2}},
},
If you inspect the bitmap, you can see the scavenged pages set starting at 
the appropriate index

1101

Step 2. It then allocates 5 pages in succession
for iter, i := range v.5hits {
   address, scav := b.Alloc(i.npages)
}

Step 3. Afterwards, if you print the bits you can see the five allocations 
in the first positions

The 5 allocations

0001


The corresponding scavenged bit map is all set to 0, so the allocations 
used the scavenged pages:





So my question isis that "scavenging" or more properly "reclaiming"? 
The allocations occupy the positions that were previously scavenged, so I'm 
guessing the memory has been re-used (in the logic of the test) rather than 
returned to the OS. 


-- 
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/1f889217-2c39-4aef-8fac-5f0cdd9a1176n%40googlegroups.com.

[go-nuts] Re: IOPS profiling

[Jason E. Aten]

try https://github.com/felixge/fgprof

On Monday, May 6, 2024 at 9:42:22 PM UTC+1 Ethan Reesor wrote:

> I'm seeing some pretty strong indications that my application (which is 
> running on AWS EC2) is bottlenecked by IOPS (I/O operations per second).
>
> Is there anything like `go test -profile=...` and `go tool pprof ...` for 
> IOPS? We're looking at optimizing the database we're using, but I'd much 
> prefer to capture real world data so we're not optimizing blindly.
>

-- 
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/3e06d6a8-b824-476d-a653-24d0242ef741n%40googlegroups.com.

Re: [go-nuts] variable set in a loop but unused not failing compilation

[Tiago de Bem Natel de Moura]

Hi Axel,

Thanks for the explanation, it makes sense. Yes, I think it would be a good 
case for a `vet` warning.

On Monday 6 May 2024 at 15:35:02 UTC+1 Axel Wagner wrote:

> Hi,
>
> I'll note that this has nothing, really, to do with the loop, but with the 
> fact that you are assigning a struct field.
> For a simpler example, compare this: https://go.dev/play/p/MmR-AhOUQH3 
> with this: https://go.dev/play/p/Y1uoI8thYuV
> If you only write to the entire variable, the compiler complains about 
> that variable not being used. But if you set a field, the failure goes away.
>
> This compilation error is based on this sentence from the spec 
> :
> > Implementation restriction: A compiler may make it illegal to declare a 
> variable inside a function body 
>  if the variable is never 
> used. 
> Note that it says "may" make it illegal. It's also not really defined what 
> it means for a variable to be "never used".
>
> TBH I don't really like these implementation-defined compilation failures. 
> But it would be difficult to make them more strict. Perhaps this case could 
> be a vet warning.
>
> On Mon, May 6, 2024 at 4:20 PM Tiago de Bem Natel de Moura <
> t.natel...@gmail.com> wrote:
>
>> Hello,
>>
>> We had the bug below in production:
>> https://go.dev/play/p/-jewy7e7UcZ
>>
>> Look at the `opt` variable inside `listGithubPullReviews`, it's set 
>> multiple times (inside the loop) but never used... it was supposed to be 
>> passed as the last argument of `ListReviews()`.
>>
>> Why Go compiler is not giving an error for this case? AFAICS all of those 
>> `opt.Page = resp.NextPage` inside the loop cannot make any side effects, 
>> then it looks safe to assume the variable is only set and never used?
>>
>> So, simplifying the problem, this is the non-failing case: 
>> https://go.dev/play/p/FLAIlVx_sSG
>>
>> But if you change from a struct to a plain int, then the compiler gives: 
>> `./prog.go:6:2: 
>> a declared and not used`
>>
>> Luckily, we were using a `ctx` with timeout otherwise it would be an 
>> infinite loop. The thing was tested but only for cases where all results 
>> came in a single page, then the loop aborted in the first iteration. I 
>> think this could be detected by the compiler, no?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9a2b5179-f083-4365-b0c6-e876f3fe6950n%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/1c3a3b8c-beff-4328-9a11-60a6901cabben%40googlegroups.com.

[go-nuts] IOPS profiling

[Ethan Reesor]

I'm seeing some pretty strong indications that my application (which is 
running on AWS EC2) is bottlenecked by IOPS (I/O operations per second).

Is there anything like `go test -profile=...` and `go tool pprof ...` for 
IOPS? We're looking at optimizing the database we're using, but I'd much 
prefer to capture real world data so we're not optimizing blindly.

-- 
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/eaf9b1ff-e553-4544-9da5-e7969d2fee98n%40googlegroups.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.

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

['simon place' via golang-nuts]

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.4go: downloading 
github.com/xyproto/tinysvg v1.1.0package github.com/xyproto/png2svg is not 
a main package*

and why not install the latest if not specified anyway?

-- 
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/2f1d8dc7-ecd7-4aa4-87c3-60b5e6abefebn%40googlegroups.com.

Re: [go-nuts] variable set in a loop but unused not failing compilation

['Axel Wagner' via golang-nuts]

Hi,

I'll note that this has nothing, really, to do with the loop, but with the
fact that you are assigning a struct field.
For a simpler example, compare this: https://go.dev/play/p/MmR-AhOUQH3 with
this: https://go.dev/play/p/Y1uoI8thYuV
If you only write to the entire variable, the compiler complains about that
variable not being used. But if you set a field, the failure goes away.

This compilation error is based on this sentence from the spec
:
> Implementation restriction: A compiler may make it illegal to declare a
variable inside a function body
 if the variable is never
used.
Note that it says "may" make it illegal. It's also not really defined what
it means for a variable to be "never used".

TBH I don't really like these implementation-defined compilation failures.
But it would be difficult to make them more strict. Perhaps this case could
be a vet warning.

On Mon, May 6, 2024 at 4:20 PM Tiago de Bem Natel de Moura <
t.nateldemo...@gmail.com> wrote:

> Hello,
>
> We had the bug below in production:
> https://go.dev/play/p/-jewy7e7UcZ
>
> Look at the `opt` variable inside `listGithubPullReviews`, it's set
> multiple times (inside the loop) but never used... it was supposed to be
> passed as the last argument of `ListReviews()`.
>
> Why Go compiler is not giving an error for this case? AFAICS all of those
> `opt.Page = resp.NextPage` inside the loop cannot make any side effects,
> then it looks safe to assume the variable is only set and never used?
>
> So, simplifying the problem, this is the non-failing case:
> https://go.dev/play/p/FLAIlVx_sSG
>
> But if you change from a struct to a plain int, then the compiler gives: 
> `./prog.go:6:2:
> a declared and not used`
>
> Luckily, we were using a `ctx` with timeout otherwise it would be an
> infinite loop. The thing was tested but only for cases where all results
> came in a single page, then the loop aborted in the first iteration. I
> think this could be detected by the compiler, no?
>
> --
> 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/9a2b5179-f083-4365-b0c6-e876f3fe6950n%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/CAEkBMfECnnFQkdwSn3gqzRxHL7MnkfoUvABFg8xr0B-9jTkSjQ%40mail.gmail.com.

[go-nuts] variable set in a loop but unused not failing compilation

[Tiago de Bem Natel de Moura]

Hello,

We had the bug below in production:
https://go.dev/play/p/-jewy7e7UcZ

Look at the `opt` variable inside `listGithubPullReviews`, it's set 
multiple times (inside the loop) but never used... it was supposed to be 
passed as the last argument of `ListReviews()`.

Why Go compiler is not giving an error for this case? AFAICS all of those 
`opt.Page = resp.NextPage` inside the loop cannot make any side effects, 
then it looks safe to assume the variable is only set and never used?

So, simplifying the problem, this is the non-failing 
case: https://go.dev/play/p/FLAIlVx_sSG

But if you change from a struct to a plain int, then the compiler gives: 
`./prog.go:6:2: 
a declared and not used`

Luckily, we were using a `ctx` with timeout otherwise it would be an 
infinite loop. The thing was tested but only for cases where all results 
came in a single page, then the loop aborted in the first iteration. I 
think this could be detected by the compiler, no?

-- 
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/9a2b5179-f083-4365-b0c6-e876f3fe6950n%40googlegroups.com.

[go-nuts] Re: Upgrading to last version of dependency without upgrading toolchain?

['TheDiveO' via golang-nuts]

As I cannot edit the title anymore: it's about upgrading to the last 
version that can be used without toolchain change, which is not necessarily 
the "latest" version of a dependency.

On Monday, May 6, 2024 at 10:42:17 AM UTC+2 TheDiveO wrote:

> FYI, go-mod-upgrade runs the following command under its hood:
>
> go list -u -mod=readonly -f '{{if (and (not (or .Main .Indirect)) 
> .Update)}}{{.Path}}: {{.Version}} -> {{.Update.Version}}{{end}}' -m all
>
> On Monday, May 6, 2024 at 10:36:08 AM UTC+2 TheDiveO wrote:
>
>> Up front, I have to admit that I'm struggling with the newly introduced 
>> download-your-go-toolchain-on-the-fly when it comes to:
>>
>>1. having reproducible builds in a CI/CD pipeline without getting 
>>downloaded a different toolchain as installed at the stage start,
>>2. being a module maintained as opposed to being a "leaf" app 
>>maintainer without downstream users, while maintaining the N,N-1 go 
>> (minor) 
>>version guarantee.
>>
>> Over the years, I've found https://github.com/oligot/go-mod-upgrade to 
>> be very useful to me in maintaining my (intermediate) module dependencies. 
>> Unfortunately, this tool now breaks down and the author of go-mod-upgrade 
>> at this time considers the situation to be a go toolchain upstream problem (
>> https://github.com/oligot/go-mod-upgrade/issues/52#issuecomment-2093537300
>> ).
>>
>> What happens is when I'm on a go 1.21.x toolchain in order to ensure the 
>> N,N-1 guarantee, a go-mod-upgrade on a module with a k8s.io/api  
>> "crashes" with the following error, caused by the go command used from 
>> go-mod-upgrade under its hood:
>>
>>
>> *Error running go command to discover modules: exit status 1 stderr=go: 
>> loading module retractions for k8s.io/a...@v0.26.2 
>> : module k8s.io/a...@v0.30.0 
>>  requires go >= 1.22.0 (running go 1.21.7; 
>> GOTOOLCHAIN=local)*
>>
>> Is there a way in the go command to upgrade to the "latest" dependency 
>> that doesn't trigger this error? Manually 
>> , I can see that there is a 
>> 0.29.4 available. Unfortunately, even a single dependency like this causes 
>> go-mod-upgrade to fail completely, so it's back for me to maintaining each 
>> and ever of my many deps individually ... which absolutely sucks from the 
>> UX perspective as I'm sure you can follow along with. Remember, I simply 
>> cannot switch toolchains on a whim, not least due to CI/CD policies.
>>
>> How to deal with this situation? Is there a way to use the go tool so 
>> that it would return only upgrades without toolchain changes? How might the 
>> go-mod-upgrade tool work around this situation?
>>
>>

-- 
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/07810048-2b9d-47f2-8694-5cc741e09884n%40googlegroups.com.

[go-nuts] Re: Upgrading to last version of dependency without upgrading toolchain?

['TheDiveO' via golang-nuts]

FYI, go-mod-upgrade runs the following command under its hood:

go list -u -mod=readonly -f '{{if (and (not (or .Main .Indirect)) 
.Update)}}{{.Path}}: {{.Version}} -> {{.Update.Version}}{{end}}' -m all

On Monday, May 6, 2024 at 10:36:08 AM UTC+2 TheDiveO wrote:

> Up front, I have to admit that I'm struggling with the newly introduced 
> download-your-go-toolchain-on-the-fly when it comes to:
>
>1. having reproducible builds in a CI/CD pipeline without getting 
>downloaded a different toolchain as installed at the stage start,
>2. being a module maintained as opposed to being a "leaf" app 
>maintainer without downstream users, while maintaining the N,N-1 go 
> (minor) 
>version guarantee.
>
> Over the years, I've found https://github.com/oligot/go-mod-upgrade to be 
> very useful to me in maintaining my (intermediate) module dependencies. 
> Unfortunately, this tool now breaks down and the author of go-mod-upgrade 
> at this time considers the situation to be a go toolchain upstream problem (
> https://github.com/oligot/go-mod-upgrade/issues/52#issuecomment-2093537300
> ).
>
> What happens is when I'm on a go 1.21.x toolchain in order to ensure the 
> N,N-1 guarantee, a go-mod-upgrade on a module with a k8s.io/api  
> "crashes" with the following error, caused by the go command used from 
> go-mod-upgrade under its hood:
>
>
> *Error running go command to discover modules: exit status 1 stderr=go: 
> loading module retractions for k8s.io/a...@v0.26.2 
> : module k8s.io/a...@v0.30.0 
>  requires go >= 1.22.0 (running go 1.21.7; 
> GOTOOLCHAIN=local)*
>
> Is there a way in the go command to upgrade to the "latest" dependency 
> that doesn't trigger this error? Manually 
> , I can see that there is a 
> 0.29.4 available. Unfortunately, even a single dependency like this causes 
> go-mod-upgrade to fail completely, so it's back for me to maintaining each 
> and ever of my many deps individually ... which absolutely sucks from the 
> UX perspective as I'm sure you can follow along with. Remember, I simply 
> cannot switch toolchains on a whim, not least due to CI/CD policies.
>
> How to deal with this situation? Is there a way to use the go tool so that 
> it would return only upgrades without toolchain changes? How might the 
> go-mod-upgrade tool work around this situation?
>
>

-- 
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/35dcd7f7-ef73-41d8-9f04-b36aa04fc94en%40googlegroups.com.

[go-nuts] Upgrading to last version of dependency without upgrading toolchain?

['TheDiveO' via golang-nuts]

Up front, I have to admit that I'm struggling with the newly introduced 
download-your-go-toolchain-on-the-fly when it comes to:

   1. having reproducible builds in a CI/CD pipeline without getting 
   downloaded a different toolchain as installed at the stage start,
   2. being a module maintained as opposed to being a "leaf" app maintainer 
   without downstream users, while maintaining the N,N-1 go (minor) version 
   guarantee.

Over the years, I've found https://github.com/oligot/go-mod-upgrade to be 
very useful to me in maintaining my (intermediate) module dependencies. 
Unfortunately, this tool now breaks down and the author of go-mod-upgrade 
at this time considers the situation to be a go toolchain upstream problem 
(https://github.com/oligot/go-mod-upgrade/issues/52#issuecomment-2093537300).

What happens is when I'm on a go 1.21.x toolchain in order to ensure the 
N,N-1 guarantee, a go-mod-upgrade on a module with a k8s.io/api  "crashes" 
with the following error, caused by the go command used from go-mod-upgrade 
under its hood:


*Error running go command to discover modules: exit status 1 stderr=go: 
loading module retractions for k8s.io/api@v0.26.2: module 
k8s.io/api@v0.30.0 requires go >= 1.22.0 (running go 1.21.7; 
GOTOOLCHAIN=local)*

Is there a way in the go command to upgrade to the "latest" dependency that 
doesn't trigger this error? Manually 
, I can see that there is a 
0.29.4 available. Unfortunately, even a single dependency like this causes 
go-mod-upgrade to fail completely, so it's back for me to maintaining each 
and ever of my many deps individually ... which absolutely sucks from the 
UX perspective as I'm sure you can follow along with. Remember, I simply 
cannot switch toolchains on a whim, not least due to CI/CD policies.

How to deal with this situation? Is there a way to use the go tool so that 
it would return only upgrades without toolchain changes? How might the 
go-mod-upgrade tool work around this situation?

-- 
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/b7ec48e6-4f74-4c9e-8fb9-1442aed2178bn%40googlegroups.com.

Re: [go-nuts] Re: understanding garbage collection logging

[Douglas A. Whitfield]

On Fri, 3 May 2024 at 13:05, Alexander Pavlov 
wrote:

> Please note the https://pkg.go.dev/runtime/trace package, its
> documentation and following article (
> https://go.dev/blog/execution-traces-2024) provide good examples to start
> logging the GC.
>

Thank you! This is exactly what I needed!

-- 
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/CAJ9PG8U3i57HupBa6%3Dsj-00obFTwBnDjZEZHE7d3Asij1uP61Q%40mail.gmail.com.

[go-nuts] Re: understanding garbage collection logging

[Alexander Pavlov]

Please note the https://pkg.go.dev/runtime/trace package, its documentation 
and following article (https://go.dev/blog/execution-traces-2024) provide 
good examples to start logging the GC.

-- 
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/dd7a31c6-4b6b-4ed0-b0f6-b13576efd467n%40googlegroups.com.

Re: [go-nuts] generics question

['Kevin Chowski' via golang-nuts]

Sorry for the noise - looks like you meant when passing around objects by 
this type, not just creating objects.

On Friday, May 3, 2024 at 11:02:37 AM UTC-6 Kevin Chowski wrote:

> If you are just unhappy about the A and A* while using a literal for C: 
> note that if you are willing/able to write a wrapper function instead of 
> using a literal, type inference works well today:
>
> func NewC[E any, P Settable[E]](val []E) C[E, P] {
> return C[E, P]{Val: val}
> }
> var c = NewC([]A{1, 2, 3})
>
> Full: https://go.dev/play/p/JIk1L4rBXEs
>
> On Tuesday, April 23, 2024 at 11:35:03 AM UTC-6 Ian Lance Taylor wrote:
>
>> 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/0791f433-23f2-45d9-961a-28c90bed6d77n%40googlegroups.com.

Re: [go-nuts] generics question

['Kevin Chowski' via golang-nuts]

If you are just unhappy about the A and A* while using a literal for C: 
note that if you are willing/able to write a wrapper function instead of 
using a literal, type inference works well today:

func NewC[E any, P Settable[E]](val []E) C[E, P] {
return C[E, P]{Val: val}
}
var c = NewC([]A{1, 2, 3})

Full: https://go.dev/play/p/JIk1L4rBXEs

On Tuesday, April 23, 2024 at 11:35:03 AM UTC-6 Ian Lance Taylor wrote:

> 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/3d18ca3a-eae4-4ea7-9a9b-c6d347c38683n%40googlegroups.com.

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

[Marcello H]

In golanglint_ci, there's a 'unused' linter, which will detect unused const 
vars too.

Op vrijdag 3 mei 2024 om 00:18:02 UTC+2 schreef 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/90684dd6-7d05-4a61-8209-1b0f9fcc828an%40googlegroups.com.

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

['simon place' via golang-nuts]

On Thursday 2 May 2024 at 22:45:55 UTC+1 burak serdar wrote:

You can simply clone the github repo. You don't need go get for this. 
When you're ready, import it and then go mod tidy. 


ummm, could be the best way, i'll compare with the script, (dummy) route.

-- 
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/359502f0-a1e3-4af8-a851-5b5e9cf72520n%40googlegroups.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.