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

[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] 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] Re: range-over-func has two more alloc than direct-call-func Why?

[peterGo]

qiulaidongfeng,

-gcflags=-m=2

peter

On Tuesday, March 12, 2024 at 7:06:21 AM UTC-4 qiulaidongfeng wrote:

> For the following code
>
>
> https://go.dev/play/p/ynn7ihKXrp0?v=gotip
>
>
> I got the benchmark
>
>
> BenchmarkBelow3-16 9523 147772 ns/op 17 B/op 2 allocs/op
>
> BenchmarkBelow3direct-16 1 107335 ns/op 0 B/op 0 allocs/op
>
>
> range-over-func has two more alloc than direct-call-func.
>
>
> Why?
>

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

[go-nuts] Re: Why is more memory being used when encoding a slice of structs with smaller length

[peterGo]

Also posted on Stack Overflow:

Why is more memory being used when encoding a slice of structs with smaller 
length 
https://stackoverflow.com/questions/78136093/why-is-more-memory-being-used-when-encoding-a-slice-of-structs-with-smaller-leng



  





On Monday, March 11, 2024 at 12:39:56 PM UTC-4 Kwaku Biney wrote:

> Go version
>
> go version devel go1.23-e8b5bc63be linux/amd64
>
> When using binary.Write for encoding a slice of structs, I encountered 
> some weird behaviour where memory allocations in a particular path was more 
> than I expected.
>
> I wrote some benchmarks in the standard library's encoding/binary package 
> to demonstrate this.
> func BenchmarkWriteSlice1000Structs(b *testing.B) { slice := 
> make([]Struct, 1000) buf := new(bytes.Buffer) var w io.Writer = buf 
> b.SetBytes(int64(Size(slice))) b.ResetTimer() for i := 0; i < b.N; i++ { 
> buf.Reset() Write(w, BigEndian, slice) } b.StopTimer() } func 
> BenchmarkWriteSlice10Structs(b *testing.B) { slice := make([]Struct, 10) 
> buf := new(bytes.Buffer) var w io.Writer = buf 
> b.SetBytes(int64(Size(slice))) b.ResetTimer() for i := 0; i < b.N; i++ { 
> buf.Reset() Write(w, BigEndian, slice) } b.StopTimer() } 
>
> I ran both benchmarks and these are the results:
>
>- Encoding a slice with 1000 struct elements
>
> root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# ../../../bin/go 
> test -run='^$' -memprofile memprofile.out -benchmem -bench 
> BenchmarkWriteSlice1000Structs -count=10 
> root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# ../../../bin/go 
> tool pprof memprofile.out File: binary.test Type: alloc_space Time: Mar 9, 
> 2024 at 3:27pm (UTC) Entering interactive mode (type "help" for commands, 
> "o" for options) (pprof) top Showing nodes accounting for 1305.40MB, 99.84% 
> of 1307.48MB total Dropped 8 nodes (cum <= 6.54MB) flat flat% sum% cum cum% 
> 1302.13MB 99.59% 99.59% 1304.21MB 99.75% encoding/binary.Write 3.27MB 0.25% 
> 99.84% 1307.48MB 100% encoding/binary.BenchmarkWriteSlice1000Structs 0 0% 
> 99.84% 1305.31MB 99.83% testing.(*B).launch 0 0% 99.84% 1307.48MB 100% 
> testing.(*B).runN 
>
>- Encoding a slice with 10 struct elements
>
> root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# > 
> ../../../bin/go test -run='^$' -memprofile memprofile.out -benchmem -bench 
> BenchmarkWriteSlice10Structs -count=10 warning: GOPATH set to GOROOT 
> (/root/go) has no effect 
> root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# ../../../bin/go 
> tool pprof memprofile.out warning: GOPATH set to GOROOT (/root/go) has no 
> effect File: binary.test Type: alloc_space Time: Mar 9, 2024 at 4:24pm 
> (UTC) Entering interactive mode (type "help" for commands, "o" for options) 
> (pprof) top Showing nodes accounting for 905.58MB, 100% of 905.58MB total 
> flat flat% sum% cum cum% 792.58MB 87.52% 87.52% 905.58MB 100% 
> encoding/binary.Write 113MB 12.48% 100% 113MB 12.48% 
> reflect.(*structType).Field 0 0% 100% 905.58MB 100% 
> encoding/binary.BenchmarkWriteSlice10Structs 0 0% 100% 113MB 12.48% 
> encoding/binary.dataSize 0 0% 100% 113MB 12.48% encoding/binary.sizeof 0 0% 
> 100% 113MB 12.48% reflect.(*rtype).Field 0 0% 100% 905.58MB 100% 
> testing.(*B).launch 0 0% 100% 905.58MB 100% testing.(*B).runN (pprof) 
>
> Per the benchmarks, there is a rise in total memory allocated incurred at 
> reflect.(*structType).Field when encoding a slice of 10 struct elements 
> compared to a slice of 1000 struct elements. I expected to see the memory 
> incurred to be at worst, the same if not less when encoding a slice of 
> structs with lesser length. I draw my conclusion from here since we are 
> calling sizeof on the same struct type regardless of the length of the 
> slice.
>
>
> https://github.com/golang/go/blob/74726defe99bb1e19cee35e27db697085f06fda1/src/encoding/binary/binary.go#L483
>
> Also, looking at the primary source of the allocations, per the line 
> below, since we are working with the same struct type, I expect the number 
> of allocations here to be the same regardless since both benchmarks are 
> working with the same struct type and hence have the same fields.(
> https://github.com/golang/go/blob/74726defe99bb1e19cee35e27db697085f06fda1/src/reflect/type.go#L1061
> ) 
>
> I am just wondering if this change is due to the random sampling used by 
> the profiler and hence it is nothing to worry about or if there is some 
> sort of logical explanation? I might be misinterpreting these results.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e9ea5c9a-d9e3-43f6-b804-2d3f26e775cfn%40googlegroups.com.

[go-nuts] Re: Why Go opt for using * in signature of function that returns a pointer instead of using &?

[peterGo]

Matheus,

Rewire your brain.

The return value or values may be explicitly listed in the "return" 
statement. Each expression must be single-valued and assignable to the 
corresponding element of the function's result type.

The Go Programming Language Specification
https://go.dev/ref/spec#Return_statements

The return {X, Y} statement is an implicit assignment to a value of 
type *Vertex.

type Vertex struct {
X, Y int
}

func NewVertex(X, Y int) (v *Vertex) {
// return {X, Y}
v = {X, Y}
return v
}

func main() {
x, y := 3, 5
var v *Vertex = NewVertex(x, y)
fmt.Println(x, y, *v)
}

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

peter


On Tuesday, March 5, 2024 at 11:33:46 PM UTC-5 Matheus Fassis Corocher 
wrote:

> I was studying about pointers and struct in Golang and one thing that I 
> don't understand is why using * in return of signature of function instead 
> of & if the return of function is an address of variable?
>
> The correct version that works:
>
> func NewVertex(X, Y int) **Vertex* {
>   ...
>   return {X, Y}
> }
>
> The version in my mind should be correct:
>
> func NewVertex(X, Y int) ** {
>   ...
>   return {X, Y}
> }
>
>

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

[go-nuts] Re: 64 Tiny Algorithmic Puzzles in Go

[peterGo]

qiulaidongfeng,

A simpler, solution:

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

peter

On Saturday, March 2, 2024 at 8:25:33 PM UTC-5 qiulaidongfeng wrote:

> I wrote a correct one, as shown here:
> https://go.dev/play/p/IDJP_iIsGDE
>
> On Sunday, March 3, 2024 at 1:42:51 AM UTC+8 BUGFIX 66 wrote:
>
>> https://BUGFIX-66.com
>>
>> Solve each puzzle by making a tiny change to a short piece of Go code.
>> Edited code is compiled and tested on the host server.
>> Each puzzle is a useful little algorithm or idea.
>> Unfortunately, most users can't solve puzzle #3 and give up.
>> Enjoy.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1f2d2c9b-0b07-4030-8f49-37f22210be8en%40googlegroups.com.

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

[peterGo]

Jason,

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

Peter

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

> But the main point is, the canonical version published at 
> https://go.dev/ref/spec is still from Aug 2, 2023
>
> On Wednesday 7 February 2024 at 12:02:28 UTC Rob Pike wrote:
>
>> Ha ha, someone forgot to change the year. It should read Jan 30, 2024.
>>
>> That's confusing.
>>
>> -rob
>>
>>
>> On Wed, Feb 7, 2024 at 8:47 PM peterGo  wrote:
>>
>>> Jason,
>>>
>>> The Go 1.22 source code says:
>>>
>>> "Subtitle": "Language version go1.22 (Jan 30, 2023)",
>>>
>>> Blame
>>>
>>> #569 9289b9c gri@*.*** 2024-01-31 16:40
>>> [release-branch.go1.22] spec: clarify iteration variable type for range 
>>> over integer
>>> Change-Id: I4f1d220d5922c40a36264df2d0a7bb7cd0756bac
>>>
>>>
>>> https://cs.opensource.google/go/go/+/release-branch.go1.22:doc/go_spec.html
>>>
>>> I consider the Go source code to be the truth.
>>>
>>> What are you looking at?
>>>
>>> Peter
>>>
>>>
>>> On Wednesday, February 7, 2024 at 1:17:25 AM UTC-5 Jason E. Aten wrote:
>>>
>>>> On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:
>>>>
>>>>> You are reading a specification dated Version of Aug 2, 2023. The 
>>>>> current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 
>>>>> 10:08:15 PM EST.
>>>>>
>>>>
>>>> Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, 
>>>> which is what the 1.22 release notes points to.
>>>>
>>>>  
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/0e4fa760-1259-4b9c-9ff6-b60ba34413ccn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/0e4fa760-1259-4b9c-9ff6-b60ba34413ccn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

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

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

[peterGo]

Jason,

The Go 1.22 source code says:

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

Blame

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

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

I consider the Go source code to be the truth.

What are you looking at?

Peter


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

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

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

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

[peterGo]

Jason,

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

Peter

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8b5ba931-2782-4538-bac2-78c5be735e33n%40googlegroups.com.

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

[peterGo]

Jason,

The Go 1.22 specification, in part,

For statements with range clause

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

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

Peter

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

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

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

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

[peterGo]

Jason,

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

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

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

Peter

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

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

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

Re: [go-nuts] Re: Passing 2d arrays from Go to C using runtime.Pinner

[peterGo]

Michael,

Here is a Go solution to the OP's problem. It uses Go memory and Go 
pointers passed to C in Go memory point to pinned Go memory.

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

Peter

On Monday, January 29, 2024 at 12:21:18 PM UTC-5 Michael Knyszek wrote:

> Thanks for the reproducer. I think I've puzzled out what's going wrong and 
> it's pretty subtle.
>
> TL;DR: You can work around this by either calling `calloc` or just 
> allocating `inRows` as Go memory and pinning that as well. The latter will 
> be safer and faster overall. It's not totally clear to me at this moment 
> whether just using `calloc` instead should be sufficient. Read on for more 
> details.
>
> Writing pointers into C memory from Go may invoke a write barrier. The 
> current write barrier is a hybrid barrier: it writes down the pointers that 
> are both being written, and those that are being deleted in the write.
>
> In this particular case, we're writing a Go pointer into C memory *from 
> Go*. If that C memory isn't zeroed *and* it points to some dead Go 
> memory, we have a problem. That appears to be what's happening here. If I 
> use calloc instead of malloc to create inRows, the problem goes away. Also, 
> if I create inRows in Go and pin it, that also works.
>
> I think this is actually documented in the cgo pointer passing rules (
> https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers), but we all missed it:
>
> Note: the current implementation has a bug. While Go code is permitted to 
> write nil or a C pointer (but not a Go pointer) to C memory, the current 
> implementation may sometimes cause a runtime error if the contents of the C 
> memory appear to be a Go pointer. Therefore, avoid passing uninitialized C 
> memory to Go code if the Go code is going to store pointer values in it. 
> Zero out the memory in C before passing it to Go.
>
>
> AFAICT, the rest of the page does not say one way or the other whether Go 
> code writing a Go pointer into C memory is allowed (note that, 
> counterintuitively, *C.float is a Go pointer, because it may point to Go 
> memory).
>
> One question that I have to wonder about is whether it's OK to write a Go 
> pointer into C memory at all and if we should just restrict that like we 
> did before. The text above already implies that it is not OK, in which case 
> the code in this thread is invalid and inRows basically must be allocated 
> on the Go side. However, I think this may also just be an oversight from 
> when I was updating the documentation for pinning; I think my original 
> intent was to say that it's OK for Go code to write pinned Go pointers to C 
> memory.
>
> Anyway, this needs more thought, since allowing Go code to write Go 
> pointers to C memory (pinned or not) may end up restricting GC 
> implementations in a way we don't want to. I filed 
> https://github.com/golang/go/issues/65349 to track this.
>
> On Mon, Jan 29, 2024 at 11:17 AM peterGo  wrote:
>
>> Michael,
>>
>> The OP appears to have lost interest in debugging. Here's my minimal, 
>> reproducible example that produces the same fatal errror:
>>
>> https://go.dev/play/p/flEmSh1euqR (run locally)
>>
>> If the runtime.GC() statement is uncommented then the fatal error does 
>> not occur.
>>
>> The use of this profligate, inefficient algorithm is for debugging 
>> purposes only. The use of runtime.Pinner is not required. A single 
>> implicitly pinned C wrapper function argument pointing to contiguous 
>> underlying slice data arrays would suffice. 
>>
>> Peter
>>
>>
>> On Friday, January 26, 2024 at 12:05:38 PM UTC-5 Michael Knyszek wrote:
>>
>>> Ignoring more efficient ways to pass memory to C for a moment, 
>>> superficially I do think your code using Pinner should work. Do you have a 
>>> full reproducer? It's hard to tell from just looking at your code if your 
>>> code is the problem, or its just enough to trigger some other cgo issue 
>>> elsewhere in your codebase. There's a slim chance this is a bug in the 
>>> Pinner implementation, but that would be surprising to me. The Pinner 
>>> trivially keeps all pointers passed to it live by just holding onto their 
>>> references.
>>>
>>> Also, have you tried running your code with GODEBUG=cgocheck=1 and/or 
>>> building your code with GOEXPERIMENT=cgocheck2? That might help identify 
>>> what the issue is.
>>> On Friday, January 26, 2024 at 7:05:45 AM UTC-5 Tamás Gulácsi wrote:
>>>
>>>> To convert a Go slice to C array is easy with unsafe.Slice.
>>>>
>>>> The problem is that the multi-dimensional C array is an array of 
>>

[go-nuts] Re: Passing 2d arrays from Go to C using runtime.Pinner

[peterGo]

Michael,

The OP appears to have lost interest in debugging. Here's my minimal, 
reproducible example that produces the same fatal errror:

https://go.dev/play/p/flEmSh1euqR (run locally)

If the runtime.GC() statement is uncommented then the fatal error does not 
occur.

The use of this profligate, inefficient algorithm is for debugging purposes 
only. The use of runtime.Pinner is not required. A single implicitly pinned 
C wrapper function argument pointing to contiguous underlying slice data 
arrays would suffice. 

Peter


On Friday, January 26, 2024 at 12:05:38 PM UTC-5 Michael Knyszek wrote:

> Ignoring more efficient ways to pass memory to C for a moment, 
> superficially I do think your code using Pinner should work. Do you have a 
> full reproducer? It's hard to tell from just looking at your code if your 
> code is the problem, or its just enough to trigger some other cgo issue 
> elsewhere in your codebase. There's a slim chance this is a bug in the 
> Pinner implementation, but that would be surprising to me. The Pinner 
> trivially keeps all pointers passed to it live by just holding onto their 
> references.
>
> Also, have you tried running your code with GODEBUG=cgocheck=1 and/or 
> building your code with GOEXPERIMENT=cgocheck2? That might help identify 
> what the issue is.
> On Friday, January 26, 2024 at 7:05:45 AM UTC-5 Tamás Gulácsi wrote:
>
>> To convert a Go slice to C array is easy with unsafe.Slice.
>>
>> The problem is that the multi-dimensional C array is an array of pointers 
>> (*(*float64))
>> which cannot travel between the C/Go barrier.
>>
>> In your example, you flatten your slice, and recreate the pointers in 
>> that one big slice.
>> You could go on with that example, but from the Go side:
>>
>> 1. have a "flat" []float64 wihich is N*M
>> 2. have the [][]float64 as subslices of that one big flattened []float64: 
>> flat[i*M:i*(M+1)]
>> 3. send that flat slice to the C side with unsafe.Slice
>> 4. have the C side implement the same subslicing: create a []*float64 
>> array and have each point to the corredt [i*M].
>> 5. profit
>>
>>
>> Denis a következőt írta (2024. január 26., péntek, 1:18:59 UTC+1):
>>
>>> I am trying to pass 2d array from Go to some C function void foo(in 
>>> **float, out *double). Since I want to have wrapper for this C 
>>> function, I'd like that Go function has definition like func 
>>> FooWrapper([][]float32) []float64. The easiest but not efficient 
>>> implementation is allocating all memory through C that listed below:
>>>
>>> func FooWrapper(values [][]float32) []float64 {
>>> totalObj := len(values)
>>> totalParams := len(values[0])
>>> results := make([]float64, totalObj)
>>>
>>> ptrArrLength := uintptr(totalObj) * cPointerSize
>>> paramArrLength := uintptr(totalParams) * cFloatSize
>>>
>>> ptr := C.malloc(C.size_t(ptrArrLength + 
>>> paramArrLength*uintptr(totalObj)))
>>> defer C.free(ptr)
>>>
>>> ptrSlice := unsafe.Slice((**C.float)(ptr), totalObj)
>>> for i, obj := range values {
>>> paramArrPtr := (*C.float)(unsafe.Add(ptr, 
>>> ptrArrLength+uintptr(i)*paramArrLength))
>>> ptrSlice[i] = paramArrPtr
>>>
>>> paramSlice := unsafe.Slice(paramArrPtr, totalParams)
>>> for j, param := range obj {
>>> paramSlice[j] = (C.float)(param)
>>> }
>>> }
>>>
>>> C.foo((**C.float)(ptr), (*C.double)([0]))
>>>
>>> return results
>>> }
>>>
>>> Is that safe implementation? Can I pass pointer of result data? As far 
>>> as I know, this pointer will be pinned because it passed to C function.
>>>
>>> But I want to allocate less memory just reusing Go memory, I've learned 
>>> about runtime.Pinner that make pointer pinned until 
>>> runtime.Pinner.Unpin() invocation. I tried to write another 
>>> implementation using pinner:
>>>
>>> func FooWrapper(values [][]float32) []float64 {
>>> length := len(values)
>>> results := make([]float64, length)
>>>
>>> pinner := runtime.Pinner{}
>>> defer pinner.Unpin()
>>>
>>> arr := (**C.float)(C.malloc(C.size_t(uintptr(length) * 
>>> cPointerSize)))
>>> defer C.free(unsafe.Pointer(arr))
>>> slice := unsafe.Slice(arr, length)
>>> for i, v := range values {
>>> pinner.Pin([0])
>>> slice[i] = (*C.float)([0])
>>> }
>>>
>>> C.foo(arr, (*C.double)([0]))
>>>
>>> return results
>>> }
>>>
>>> But, unfortunately, this code doesn't work
>>>
>>> runtime: pointer 0xc016ecbfc0 to unused region of span 
>>> span.base()=0xc016eca000 span.limit=0xc016ecbfa0 span.state=1
>>> fatal error: found bad pointer in Go heap (incorrect use of unsafe or 
>>> cgo?)
>>>
>>> Do I use runtime.Pinner wrong (as far as I know, I can pin slice data)? 
>>> Or there is another error in this code. Are there some implementations for 
>>> passing 3d (4d and so on) array to C function except for allocatiing and 
>>> copying all data to C memory?
>>>
>>

-- 
You received this message because you are 

[go-nuts] Re: It seems that go 1.22 has optimized the implementation of string to byte slicing and no longer requires memory allocation.

[peterGo]

Assigning Benchmark results to package variables:

var (
str string
byt []byte
)

BenchmarkString
str = string(byteSli)

BenchmarkUnsafe
str = *(*string)(unsafe.Pointer())

BenchmarkByteStyle
byt = []byte(str)

BenchmarkWithUnsafe
byt = *(*[]byte)(unsafe.Pointer())

$ go1.21 test nuts_test.go -run=! -bench=. -benchmem
BenchmarkTest1-12  2250727250.72 ns/op   192 B/op  1 allocs/op
BenchmarkTest2-12  2710559249.92 ns/op   192 B/op  1 allocs/op
BenchmarkTest3-12  2500698341.32 ns/op   160 B/op  1 allocs/op
BenchmarkTest4-12  10   1.158 ns/op0 B/op  0 allocs/op

$ go1.22 test nuts_test.go -run=! -bench=. -benchmem
BenchmarkTest1-12  1738662465.79 ns/op   192 B/op  1 allocs/op
BenchmarkTest2-12  1860346362.30 ns/op   192 B/op  1 allocs/op
BenchmarkTest3-12  2374163457.76 ns/op   160 B/op  1 allocs/op
BenchmarkTest4-12  10   1.157 ns/op0 B/op  0 allocs/op

peter

On Monday, November 27, 2023 at 7:12:54 AM UTC-5 fliter wrote:

> It seems that go 1.22 has optimized the implementation of string to byte 
> slicing and no longer requires memory allocation.
>
>
> But why not optimize byte slicing to string conversion together?
>
>
> ```go
> package main
>
> import (
> "reflect"
> "testing"
> "unsafe"
> )
>
>
> func BenchmarkString(b *testing.B) {
> byteSli := []byte{123, 34, 100, 101, 102, 97, 117, 108, 116, 34, 58, 123, 
> 34, 99, 111, 109, 109, 111, 110, 34, 58, 123, 34, 112, 101, 116, 34, 58, 
> 123, 34, 102, 105, 118, 101, 34, 58, 34, 230, 150, 145, 230, 150, 145, 34, 
> 44, 34, 102, 111, 117, 114, 34, 58, 34, 231, 154, 174, 231, 147, 156, 231, 
> 147, 156, 34, 44, 34, 111, 110, 101, 34, 58, 34, 229, 188, 165, 229, 188, 
> 165, 230, 135, 181, 34, 44, 34, 116, 104, 114, 101, 101, 34, 58, 34, 229, 
> 145, 134, 229, 145, 134, 34, 44, 34, 116, 119, 111, 34, 58, 34, 233, 187, 
> 132, 230, 169, 153, 230, 169, 153, 34, 125, 44, 34, 114, 101, 108, 97, 116, 
> 105, 111, 110, 34, 58, 123, 34, 102, 97, 116, 104, 101, 114, 34, 58, 34, 
> 99, 117, 105, 120, 120, 120, 120, 120, 120, 120, 34, 44, 34, 109, 111, 116, 
> 104, 101, 114, 34, 58, 34, 121, 105, 110, 120, 120, 120, 120, 120, 34, 44, 
> 34, 119, 105, 102, 101, 34, 58, 34, 112, 101, 110, 103, 120, 120, 34, 125, 
> 125, 125, 125}
>
> _ = string(byteSli)
>
> }
>
> func BenchmarkUnsafe(b *testing.B) {
> byteSli := []byte{123, 34, 100, 101, 102, 97, 117, 108, 116, 34, 58, 123, 
> 34, 99, 111, 109, 109, 111, 110, 34, 58, 123, 34, 112, 101, 116, 34, 58, 
> 123, 34, 102, 105, 118, 101, 34, 58, 34, 230, 150, 145, 230, 150, 145, 34, 
> 44, 34, 102, 111, 117, 114, 34, 58, 34, 231, 154, 174, 231, 147, 156, 231, 
> 147, 156, 34, 44, 34, 111, 110, 101, 34, 58, 34, 229, 188, 165, 229, 188, 
> 165, 230, 135, 181, 34, 44, 34, 116, 104, 114, 101, 101, 34, 58, 34, 229, 
> 145, 134, 229, 145, 134, 34, 44, 34, 116, 119, 111, 34, 58, 34, 233, 187, 
> 132, 230, 169, 153, 230, 169, 153, 34, 125, 44, 34, 114, 101, 108, 97, 116, 
> 105, 111, 110, 34, 58, 123, 34, 102, 97, 116, 104, 101, 114, 34, 58, 34, 
> 99, 117, 105, 120, 120, 120, 120, 120, 120, 120, 34, 44, 34, 109, 111, 116, 
> 104, 101, 114, 34, 58, 34, 121, 105, 110, 120, 120, 120, 120, 120, 34, 44, 
> 34, 119, 105, 102, 101, 34, 58, 34, 112, 101, 110, 103, 120, 120, 34, 125, 
> 125, 125, 125}
>
> _ = *(*string)(unsafe.Pointer())
> }
>
> func BenchmarkByteStyle(b *testing.B) {
>
> str := 
> `{"default":{"common":{"pet":{"five":"aa","four":"bb","one":"cc","three":"dd","two":"黄ee"},"relation":{"father":"ff","mother":"mm","wife":"ww"`
>
> _ = []byte(str)
>
> }
>
> func BenchmarkWithUnsafe(b *testing.B) {
>
> str 
> := 
> `{"default":{"common":{"pet":{"five":"aa","four":"bb","one":"cc","three":"dd","two":"黄ee"},"relation":{"father":"ff","mother":"mm","wife":"ww"`
>
> sh := (*reflect.StringHeader)(unsafe.Pointer())
> bh := reflect.SliceHeader{
> Data: sh.Data,
> Len:  sh.Len,
> Cap:  sh.Len,
> }
> _ = *(*[]byte)(unsafe.Pointer())
>
> }
> ```
>
> ```bench_test.go
> package main
>
> import (
> "testing"
> )
>
>
> func BenchmarkTest1(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkString(b)
> }
> }
>
> func BenchmarkTest2(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkUnsafe(b)
> }
> }
>
> func BenchmarkTest3(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkByteStyle(b)
> }
> }
>
> func BenchmarkTest4(b *testing.B) {
> for i := 0; i < b.N; i++ {
> BenchmarkWithUnsafe(b)
> }
> }
> ```
>
> when go version is 1.21
>
> ```shell
>  go version
> go version go1.21.0 darwin/arm64
>
> goos: darwin
> goarch: arm64
> pkg: bc
> BenchmarkTest1-83707800832.45 ns/op  192 
> B/op  1 allocs/op
> BenchmarkTest2-81441068409.181 ns/op   0 
> B/op  0 allocs/op
> BenchmarkTest3-83897337528.94 ns/op  192 
> B/op  1 allocs/op
> BenchmarkTest4-810   0.3130 ns/op  0 
> B/op  0 allocs/op
> PASS
> ok  bc  6.038s
>
> 

[go-nuts] Re: GO language best practice document

[peterGo]

Go Style | styleguide
https://google.github.io/styleguide/go/index   

peter

On Friday, September 8, 2023 at 9:05:12 AM UTC-4 Alexandre Roy wrote:

> Hi,
>
> I want to start a new web application using GO with AWS Lambda, but first 
> I want to learn the GO language. I mostly have C / Python experience. 
>
> I started reading https://go.dev/doc/effective_go, but as mentioned in 
> the following issue https://github.com/golang/go/issues/28782, this 
> documentation is deprecated with new best practice.
>
> Since the issue is still open and no new document is available, what do 
> you recommend to learn GO the right way (best practice) in 2023?
>
> Thanks for your help and your time,
>
> Alexandre
>

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

Re: [go-nuts] Best IDE for GO ?

[peterGo]

On Saturday, August 19, 2023 at 6:23:39 AM UTC-4 TheDiveO wrote:

Nothing better than an IBM card puncher as my IDE!  

 I prefer a Teletype Model 33 ASR.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2cc6ff26-e1cf-481b-972f-9f110ec78a0dn%40googlegroups.com.

[go-nuts] Re: Misleading documentation for time.Timer?

[peterGo]

Johan,

For https://play.golang.com/p/Kdg-xwmquQO, timer has expired and Reset 
schedules f to run again and returns false.

Documentation reference: https://pkg.go.dev/time#Timer.Reset

Reset changes the timer to expire after duration d. It returns true if the 
timer had been active, false if the timer had expired or been stopped.

For a Timer created with AfterFunc(d, f), Reset either reschedules when f 
will run, in which case Reset returns true, or schedules f to run again, in 
which case it returns false.

Peter

On Wednesday, July 5, 2023 at 5:33:46 PM UTC-4 Johan Bolmsjö wrote:

> Hello,
>
> By accident I came across the statement "Timer type represents a single 
> event" when seeking inspiration for a timer implementation.
> I wonder if this is true with the Timer.Reset method in mind, illustrated 
> by https://play.golang.com/p/Kdg-xwmquQO.
>
> This is probably the least important topic of the year but I hesitated 
> creating a ticket for it as I'm not sure my idea of an event is what the 
> comment refers to.
>
> Documentation reference: https://pkg.go.dev/time#Timer
>
> All the best,
> Johan B
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ae4bbc0a-d97f-4c27-894c-1968d0a97f16n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[peterGo]

It's a simple typo. Send in a fix.

peter

On Saturday, June 3, 2023 at 4:07:15 PM UTC-4 Kamil Ziemian wrote:

> As burak serdar said, 9 = 3 * 3 is not a prime number, all other elements 
> in the slice are prime numbers. It looks like authors of Go Spec want to 
> make a joke or check how well people read examples in it.
>
> Best regards,
> Kamil
> sobota, 3 czerwca 2023 o 21:52:37 UTC+2 burak serdar napisał(a):
>
>> On Sat, Jun 3, 2023 at 1:40 PM peterGo  wrote:
>>
>>>
>>> Kamil Ziemian,
>>>
>>> // list of prime numbers 
>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>>
>>> The variable prime is a list of some prime numbers starting with the 
>>> lowest and ending with the highest prime numbers that can safely be 
>>> represented an int. An int may either 32 or 64 bits.
>>>
>>> Please explain the joke.
>>>
>>
>> Could it be that 9 is not prime?
>>  
>>
>>>
>>>
>>> Note: “Explaining a joke is like dissecting a frog. You understand it 
>>> better but the frog dies in the process.”
>>> ― E.B. White
>>>
>>> peter
>>> On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote:
>>>
>>>> Is this example found in the "Composite literals" section of Go Spec a 
>>>> joke?
>>>> // list of prime numbers 
>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>>>
>>>> I checked on the internet and 2147483647 <(214)%20748-3647> is a prime 
>>>> number (https://en.wikipedia.org/wiki/2,147,483,647), so this element 
>>>> is fine.
>>>>
>>>> Best regards
>>>> Kamil
>>>>
>>>> czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a):
>>>>
>>>>> You convince me to your point Axel Wagner. At the same time if we look 
>>>>> at examples in Go Spec, I think their can be improved.
>>>>> "A0, A1, and []string 
>>>>> A2 and struct{ a, b int } 
>>>>> A3 and int A4, func(int, float64) *[]string, and A5 
>>>>>
>>>>> B0 and C0 
>>>>> D0[int, string] and E0 
>>>>> []int and []int 
>>>>> struct{ a, b *B5 } and struct{ a, b *B5 } 
>>>>> func(x int, y float64) *[]string, func(int, float64) (result 
>>>>> *[]string), and A5"
>>>>> I mean, first we need to check that A0, A1 and []string are the same 
>>>>> type and after few examples like D0[int, string] is the same as E0, we 
>>>>> have 
>>>>> stated []int and []int are the same type. If you convince yourself that 
>>>>> A0 
>>>>> is the same as A1 and both are the same as []string, checking that []int 
>>>>> has the same type as []int is quite trivial. I would prefer that examples 
>>>>> would start from basic cases like []int is []int and []A3 is []int (if 
>>>>> this 
>>>>> one is true) and progress to more convoluted like D0[int, string] is E0.
>>>>>
>>>>> Best regards,
>>>>> Kamil
>>>>>
>>>>> czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a):
>>>>>
>>>>>> Personally, I'd rather add more examples of "self-evidently equal 
>>>>>> types". In my opinion, all the type aliases in that block confuse 
>>>>>> matters 
>>>>>> quite a bit.
>>>>>>
>>>>>> "[]int and []int are identical" is not actually self-evident at all. 
>>>>>> It is self-evident that any sensible definition of type identity 
>>>>>> *should* 
>>>>>> make them identical. But it's not self-evident that the given definition 
>>>>>> *does*. Spelling that out in the example, means you are nudged to look 
>>>>>> at 
>>>>>> the definition and see how their identity follows (by finding "Two slice 
>>>>>> types are identical if they have identical element types").
>>>>>>
>>>>>> In fact, whenever you define an equivalence relation, proving that it 
>>>>>> is reflexive is the very first step. And it's not always trivial. For 
>>>>>> example, `==` on `float64` is *not* reflexive. It seems obvious that NaN 
>>>>>> == 
>>>>>> NaN *should* hold from how it's

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[peterGo]

Kamil Ziemian,

// list of prime numbers 
primes := []int{2, 3, 5, 7, 9, 2147483647}

The variable prime is a list of some prime numbers starting with the lowest 
and ending with the highest prime numbers that can safely be represented an 
int. An int may either 32 or 64 bits.

Please explain the joke. 

Note: “Explaining a joke is like dissecting a frog. You understand it 
better but the frog dies in the process.”
― E.B. White

peter
On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote:

> Is this example found in the "Composite literals" section of Go Spec a 
> joke?
> // list of prime numbers 
> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>
> I checked on the internet and 2147483647 <(214)%20748-3647> is a prime 
> number (https://en.wikipedia.org/wiki/2,147,483,647), so this element is 
> fine.
>
> Best regards
> Kamil
>
> czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a):
>
>> You convince me to your point Axel Wagner. At the same time if we look at 
>> examples in Go Spec, I think their can be improved.
>> "A0, A1, and []string 
>> A2 and struct{ a, b int } 
>> A3 and int A4, func(int, float64) *[]string, and A5 
>>
>> B0 and C0 
>> D0[int, string] and E0 
>> []int and []int 
>> struct{ a, b *B5 } and struct{ a, b *B5 } 
>> func(x int, y float64) *[]string, func(int, float64) (result *[]string), 
>> and A5"
>> I mean, first we need to check that A0, A1 and []string are the same type 
>> and after few examples like D0[int, string] is the same as E0, we have 
>> stated []int and []int are the same type. If you convince yourself that A0 
>> is the same as A1 and both are the same as []string, checking that []int 
>> has the same type as []int is quite trivial. I would prefer that examples 
>> would start from basic cases like []int is []int and []A3 is []int (if this 
>> one is true) and progress to more convoluted like D0[int, string] is E0.
>>
>> Best regards,
>> Kamil
>>
>> czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a):
>>
>>> Personally, I'd rather add more examples of "self-evidently equal 
>>> types". In my opinion, all the type aliases in that block confuse matters 
>>> quite a bit.
>>>
>>> "[]int and []int are identical" is not actually self-evident at all. It 
>>> is self-evident that any sensible definition of type identity *should* make 
>>> them identical. But it's not self-evident that the given definition *does*. 
>>> Spelling that out in the example, means you are nudged to look at the 
>>> definition and see how their identity follows (by finding "Two slice types 
>>> are identical if they have identical element types").
>>>
>>> In fact, whenever you define an equivalence relation, proving that it is 
>>> reflexive is the very first step. And it's not always trivial. For example, 
>>> `==` on `float64` is *not* reflexive. It seems obvious that NaN == NaN 
>>> *should* hold from how it's spelled - but it doesn't.
>>>
>>> So, I disagree that the examples should limit themselves to cases where 
>>> it's non-obvious that the two types should be identical.
>>>
>>> On Thu, May 4, 2023 at 12:35 PM Kamil Ziemian  
>>> wrote:
>>>
 There is a second such example just below "[]int and []int", but to 
 understand it we need some more type declarations, I listed them below.
 `type (
 A0 = []string
 A1 = A0
 A2 = struct{ a, b int }
 A3 = int
 A4 = func(A3, float64) *A0
 A5 = func(x int, _ float64) *[]string

 B0 A0
 B1 []string
 B2 struct{ a, b int }
 B3 struct{ a, c int }
 B4 func(int, float64) *B0
 B5 func(x int, y float64) *A1

 // Unimportant part.
 )`
 The line in question is
 "struct{ a, b *B5 } and struct{ a, b *B5 }"
 which is true, but again feel out of place. I only start grasping rules 
 of types identity, but I make guess that it should be something like
 "struct{ a, b *A5 } and struct{ a, b *B5 }"

 Of course it my just be that I'm just stupid. Feel free to inform me 
 that indeed I have no idea what is going on in the Go Spec.

 Best regards,
 Kamil
 czwartek, 4 maja 2023 o 12:20:35 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> In the section "Type identity" of Go Spec we read a list of type 
> declarations
> `type (
> A0 = []string
> A1 = A0
> A2 = struct{ a, b int }
> A3 = int
> A4 = func(A3, float64) *A0
> A5 = func(x int, _ float64) *[]string
>
> // Part unimportant for my point.
> )`
> and then we have list of types that are identical. Among them we can 
> find text
> "[]int and []int"
> It is obviously true, but feel out of place. I make a humble guess 
> that authors intended something along the lines
> "[]A3 and []int"
> Can someone look at this part of Go Spec? I feel that someone make a 
> mistake, but at the same time humble me saying that there is any mistake 
> in 
> the Go Spec is something 

Re: [go-nuts] Re: https://go-talks.appspot.com still working?

[peterGo]

https://api.github.com/repos/jum/htempl

takes me to

{
  "id": 205554689,
  "node_id": "MDEwOlJlcG9zaXRvcnkyMDU1NTQ2ODk=",
  "name": "htempl",
  "full_name": "jum/htempl",
  "private": false,
  "owner": {
"login": "jum",
"id": 33510,
"node_id": "MDQ6VXNlcjMzNTEw",
"avatar_url": "https://avatars.githubusercontent.com/u/33510?v=4;,
"gravatar_id": "",
"url": "https://api.github.com/users/jum;,
"html_url": "https://github.com/jum;,
"followers_url": "https://api.github.com/users/jum/followers;,
"following_url": "
https://api.github.com/users/jum/following{/other_user};,
"gists_url": "https://api.github.com/users/jum/gists{/gist_id};,
"starred_url": "https://api.github.com/users/jum/starred{/owner}{/repo}
",
"subscriptions_url": "https://api.github.com/users/jum/subscriptions;,
"organizations_url": "https://api.github.com/users/jum/orgs;,
    "repos_url": "https://api.github.com/users/jum/repos;,
"events_url": "https://api.github.com/users/jum/events{/privacy};,
"received_events_url": "https://api.github.com/users/jum/received_events
",
"type": "User",
"site_admin": false
  },


peter


On Sat, May 13, 2023 at 10:46 AM peterGo  wrote:

> It is your error.
>
> https://go-talks.appspot.com/github.com/jum/htempl/slides/htempl.slide
>
> takes me to
>
> https://go-talks.appspot.com/github.com/jum/htempl/slides/htempl.slide#1
>
> the slide deck.
>
> peter
> On Saturday, May 13, 2023 at 10:17:18 AM UTC-4 Jens-Uwe Mager wrote:
>
>> I tried an older URL of mine and I do get with this URL:
>>
>> https://go-talks.appspot.com/github.com/jum/htempl/slides/htempl.slide
>>
>> This error:
>>
>> Error accessing api.github.com. 403: (
>> https://api.github.com/repos/jum/htempl)
>>
>> Is this my error or is go-talks not working any more?
>>
>> --
> 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/leJ8rtmgtN8/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/47f7a84f-96f7-4ac0-8ca4-6fd182a2bb92n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/47f7a84f-96f7-4ac0-8ca4-6fd182a2bb92n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

[go-nuts] Re: https://go-talks.appspot.com still working?

[peterGo]

It is your error.

https://go-talks.appspot.com/github.com/jum/htempl/slides/htempl.slide

takes me to

https://go-talks.appspot.com/github.com/jum/htempl/slides/htempl.slide#1

the slide deck.

peter
On Saturday, May 13, 2023 at 10:17:18 AM UTC-4 Jens-Uwe Mager wrote:

> I tried an older URL of mine and I do get with this URL:
>
> https://go-talks.appspot.com/github.com/jum/htempl/slides/htempl.slide
>
> This error:
>
> Error accessing api.github.com. 403: (
> https://api.github.com/repos/jum/htempl)
>
> Is this my error or is go-talks not working any more?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/47f7a84f-96f7-4ac0-8ca4-6fd182a2bb92n%40googlegroups.com.

[go-nuts] Re: RLIM_INFINITY for loong64 has a special type.

[peterGo]

The issue seems clear. syscall.RLIM_INFINITY for loong64 does not have a 
special type. syscall.RLIM_INFINITY for loong64 (0x) is a 
reasonable ordinary value for type rlim_t (uint64). Prometheus has a bug.

---

The Open Group Base Specifications Issue 7, 2018 edition
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_resource.h.html 
   

sys/resource.h - definitions for XSI resource operations

rlim_t
Unsigned integer type used for limit values.

RLIM_INFINITY
A value of rlim_t indicating no limit.

---

The Go Programming Language
https://github.com/golang/go

go/src/syscall/zerrors_linux_loong64.go:

const RLIM_INFINITY = 0x

go/src/syscall/zerrors_linux_amd64.go:

const RLIM_INFINITY = -0x1

These operating system and architecture dependent values are generated 
(mkerrors.sh) from the respective C header (#include ) 
files.

---

Prometheus
https://github.com/prometheus/prometheus

https://github.com/prometheus/prometheus/blob/main/util/runtime/limits_default.go#L27

// syscall.RLIM_INFINITY is a constant and its default type is int.
// It needs to be converted to an int64 variable to be compared with uint64 
values.
// See https://golang.org/ref/spec#Conversions
var unlimited int64 = syscall.RLIM_INFINITY

func limitToString(v uint64, unit string) string {
if v == uint64(unlimited) {
return "unlimited"
}
return fmt.Sprintf("%d%s", v, unit)
}

For const RLIM_INFINITY = 0x, a bug:

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

cannot use RLIM_INFINITY as int64 value (overflows)

---

A fix for the Prometheus bug.

The RLIM_INFINITY C constant integer values generate Go constant untyped 
values which convert to Go constant type uint64 values.

const unlimited uint64 = syscall.RLIM_INFINITY & 0x

func limitToString(v uint64, unit string) string {
if v == unlimited {
return "unlimited"
}
return fmt.Sprintf("%d%s", v, unit)
}

https://go.dev/play/p/SZEJj9gSQ-t

A test for const RLIM_INFINITY = 0x

https://go.dev/play/p/2t95X_-QRWj

18446744073709551615 unlimited

A test for const RLIM_INFINITY = -1

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

18446744073709551615 unlimited

peter

On Monday, April 3, 2023 at 9:57:05 PM UTC-4 莫胜文 wrote:

> This is indeed a problem. Although there is no essential difference 
> between useing `-0x1` or `0x`, but `-1` is usually used to 
> represent infinity for developers.
>
> Now there are two different types on the linux platform, this seems 
> unnecessary.
> 在2023年4月4日星期二 UTC+8 03:40:33 写道：
>
>> POSIX specifies that RLIM_INFINITY in C has type rlim_t and that type 
>> rlim_t is an “unsigned integral type”, so the `uint64` value seems 
>> appropriate.
>> (
>> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/resource.h.html
>> )
>>
>> And it appears that syscall.RLIM_INFINITY has the correct (unsigned) 
>> value on most non-Linux platforms already. I wonder why the other Linux 
>> architectures use a signed value for an unsigned type? 樂
>>
>> On Friday, March 24, 2023 at 1:14:45 PM UTC-4 莫胜文 wrote:
>>
>>> RLIM_INFINITY is a constant generated by mkerrors.sh. Its value is 
>>> 0x (uint64) in loong64 but -0x1(int64) in other 
>>> architectures.
>>>
>>> I'm not sure if it is necessary but it will cause some troubles for 
>>> applications such as prometheus 
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0f66cf85-abda-4876-81c5-688dfe36152an%40googlegroups.com.

[go-nuts] Re: Naming conventions in go?

[peterGo]

Lenny,'

Go Code Review Comments
Variable Names
https://github.com/golang/go/wiki/CodeReviewComments#variable-names

Google Style Guides
Go Style
Variable names
https://google.github.io/styleguide/go/decisions#variable-names

What's in a name?
https://talks.golang.org/2014/names.slide

Names
https://research.swtch.com/names

Notes on Programming in C
http://doc.cat-v.org/bell_labs/pikestyle
Variable names

peter

On Saturday, March 4, 2023 at 8:49:46 PM UTC-5 Lenny wrote:

> The effective go documentation doesn't really go into detail of whether or 
> not I should try to name my variables as short as possible even though that 
> is discouraged because of readability

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ec81d1b2-8eb7-4b82-88bb-7544bd702dd0n%40googlegroups.com.

[go-nuts] Re: heap profiling does not work on M2 MacBook air?

[peterGo]

On Thursday, March 2, 2023 at 2:03:22 AM UTC-5 Jochen Voss wrote:

Hi Peter,

Thanks a lot, giving the "-alloc_space" option makes all the difference!  
With this option, it also works for me.

I wonder whether it meant to be the way that you have to give this option.  
Maybe something broke?  In the blog entry https://go.dev/blog/pprof they 
didn't need this option to get the profile output.


The Go blog post at https://go.dev/blog/pprof was written in 2011; it is 
now 2023. For up-to-date information, see the latest pprof package 
documentation at https://pkg.go.dev/runtime/pprof@latest.

The pprof package documentation is incorrect: 

To add equivalent [go test] profiling support to a standalone program, add 
code like the following to your main function:

// ...
runtime.GC() // get up-to-date statistics
if err := pprof.WriteHeapProfile(f); err != nil {
log.Fatal("could not write memory profile: ", err)
}
// ...

To obtain equivalent results, replace the above code with:

// ...
runtime.GC() // get up-to-date statistics
if allocs := pprof.Lookup("allocs"); allocs == nil {
log.Fatal("could not lookup memory profile: ")
} else if err := allocs.WriteTo(f, 0); err != nil {
log.Fatal("could not write memory profile: ", err)
}
// ...

For your example,

yyy.go: https://go.dev/play/p/epy4c3et1Io

$ go build yyy.go && ./yyy
$ go tool pprof mem.prof
File: yyy
Type: alloc_space
Time: Mar 2, 2023 at 10:02am (EST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 6975.42MB, 98.93% of 7050.77MB total
Dropped 62 nodes (cum <= 35.25MB)
Showing top 10 nodes out of 18
  flat  flat%   sum%cum   cum%
 3564.88MB 50.56% 50.56%  3564.88MB 50.56% 
 golang.org/x/exp/slices.Insert[...] (inline)
 3122.14MB 44.28% 94.84%  3122.14MB 44.28% 
 seehuhn.de/go/layout.(*Skip).Minus
  117.01MB  1.66% 96.50%   117.01MB  1.66% 
 seehuhn.de/go/layout.(*Skip).Clone (inline)
  115.51MB  1.64% 98.14%  6919.54MB 98.14% 
 seehuhn.de/go/layout.(*knuthPlassLineBreaker).Run
   52.89MB  0.75% 98.89%65.63MB  0.93%  compress/flate.NewWriter
2.50MB 0.035% 98.92%  6926.54MB 98.24% 
 seehuhn.de/go/layout.(*Engine).EndParagraph
0.50MB 0.0071% 98.93%  7050.27MB   100%  main.main
 0 0% 98.93%65.63MB  0.93%  compress/flate.NewWriterDict
 0 0% 98.93%65.63MB  0.93%  compress/zlib.(*Writer).Write
 0 0% 98.93%65.63MB  0.93% 
 compress/zlib.(*Writer).writeHeader
(pprof) quit
$ 

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/01d529ad-4a05-470f-b9d8-802e308972dbn%40googlegroups.com.

[go-nuts] Re: heap profiling does not work on M2 MacBook air?

[peterGo]

Jochen Voss,

On linux/amd64

xxx.go: https://go.dev/play/p/Wq_OU49LVQZ

$ go build xxx.go && ./xxx

$ go tool pprof xxx mem.prof
File: xxx
Type: inuse_space
Time: Mar 1, 2023 at 11:03pm (EST)
No samples were found with the default sample value type.
Try "sample_index" command to analyze different sample values.
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) quit

$ go tool pprof -alloc_space xxx mem.prof
File: xxx
Type: alloc_space
Time: Mar 1, 2023 at 11:03pm (EST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 6919.54MB, 98.93% of 6994.32MB total
Dropped 77 nodes (cum <= 34.97MB)
Showing top 10 nodes out of 18
  flat  flat%   sum%cum   cum%
 3564.91MB 50.97% 50.97%  3564.91MB 50.97% 
 golang.org/x/exp/slices.Insert[...] (inline)
 3073.64MB 43.94% 94.91%  3073.64MB 43.94% 
 seehuhn.de/go/layout.(*Skip).Minus
  123.51MB  1.77% 96.68%   123.51MB  1.77% 
 seehuhn.de/go/layout.(*Skip).Clone (inline)
  104.50MB  1.49% 98.17%  6866.56MB 98.17% 
 seehuhn.de/go/layout.(*knuthPlassLineBreaker).Run
   48.48MB  0.69% 98.87%60.68MB  0.87%  compress/flate.NewWriter
4.50MB 0.064% 98.93%  6878.06MB 98.34% 
 seehuhn.de/go/layout.(*Engine).EndParagraph
 0 0% 98.93%60.68MB  0.87%  compress/flate.NewWriterDict
 0 0% 98.93%60.68MB  0.87%  compress/zlib.(*Writer).Write
 0 0% 98.93%60.68MB  0.87% 
 compress/zlib.(*Writer).writeHeader
 0 0% 98.93%56.12MB   0.8%  fmt.Fprintln
(pprof) quit
$ 

Peter

On Wednesday, March 1, 2023 at 8:55:30 AM UTC-5 Jochen Voss wrote:

> Dear all,
>
> I'm trying to profile memory use of a program, following the instructions 
> at https://go.dev/blog/pprof , but I can't get memory profiling to work.  
> Am I doing things wrong, or is this broken?
>
> Simplified code is at https://go.dev/play/p/Wq_OU49LVQZ .  (The code 
> doesn't run on the playground, but you can download it and run it locally.)
>
> Following the advice from https://pkg.go.dev/runtime/pprof I added the 
> following code to the end of my main() function:
>
> f, err := os.Create("mem.prof")
> if err != nil {
> log.Fatal("could not create memory profile: ", err)
> }
> runtime.GC() // get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> log.Fatal("could not write memory profile: ", err)
> }
> err = f.Close()
> if err != nil {
> log.Fatal(err)
> }
>
> When I run the code, this gives me a "mem.prof" file (5084 bytes).  But 
> when I start "go tool pprof" on this file, I get
>
> >>> go tool pprof xxx mem.prof
> File: xxx
> Type: inuse_space
> Time: Mar 1, 2023 at 1:15pm (GMT)
> No samples were found with the default sample value type.
> Try "sample_index" command to analyze different sample values.
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top10
> Showing nodes accounting for 0, 0% of 0 total
>   flat  flat%   sum%cum   cum%
>
> There seem to be no samples in this file.
>
> What am I doing wrong?
>
> 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/c5e8ef6d-fad1-417a-8619-b271688dc7a8n%40googlegroups.com.

Re: [go-nuts] Remove digits from string

[peterGo]

Brian,   

The Bikeshed email  
http://phk.freebsd.dk/sagas/bikeshed/   

Regular Expressions: Now You Have Two Problems   
https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/ 
  

MustCompile is like Compile but panics if the expression cannot be parsed. 
It simplifies safe initialization of global variables holding compiled 
regular expressions.
https://pkg.go.dev/regexp@go1.19.4#MustCompile 

You use MustCompile for a local variable.
https://go.dev/play/p/WxKPohZhbrE

BenchmarkBrianLocal-4 501051  2407 ns/op797 B/op  12 allocs/op

Using MustCompile for a global variable.

BenchmarkBrianGlobal-4   1243546   965.9 ns/op   32 B/op   3 allocs/op

I used strings.Map.
https://go.dev/play/p/F6gNFWjRzGO

BenchmarkPeter-410065352   111.8 ns/op   16 B/op   1 allocs/op

peter

On Friday, December 30, 2022 at 6:35:10 AM UTC-5 Brian Candler wrote:

> 
> https://go.dev/play/p/WxKPohZhbrE
> 
>
> On Thursday, 29 December 2022 at 22:12:47 UTC peterGo wrote:
>
>> https://go.dev/play/p/F6gNFWjRzGO
>>
>>
>> On Thursday, December 29, 2022 at 12:50:34 PM UTC-5 Mitul sharma wrote:
>>
>>> Hello,
>>>
>>> I'm stuck in below code snippet, looking to have a output as string 
>>> without any digits.
>>> Input : "H1e5ll0o"
>>> Output: "Hello"
>>>
>>> I tried with *output := strings.Replace(str, "1", "", -1)*, but it can 
>>> replace only single digit at a time 
>>>
>>> I'm looking for suggestions for below code snippet , tried to implement 
>>> a logic where string converted to rune and rune provided 
>>> as a input to IsDigit(), if it is digit it should replace the digit with 
>>> "" and print the string , i'm not sure what mistake am i doing in providing 
>>> parameter 
>>> and printing output?
>>>
>>> var output string
>>>
>>> var r rune
>>> for _, r = range input {
>>> break 
>>> }
>>>
>>> if unicode.IsDigit(rune(r)) {
>>> output = strings.Replace(input, "", "", -1)
>>> fmt.Println(output)
>>> }else{
>>> fmt.Println(input)
>>> }
>>>
>>>
>>>
>>> On Saturday, 15 January 2011 at 01:31:08 UTC+5:30 Russ Cox wrote:
>>>
>>>> There is also strings.Map.
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/890564c0-0ed5-46a7-bbfa-ee5ed0cc28ccn%40googlegroups.com.

Re: [go-nuts] Remove digits from string

[peterGo]

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


On Thursday, December 29, 2022 at 12:50:34 PM UTC-5 Mitul sharma wrote:

> Hello,
>
> I'm stuck in below code snippet, looking to have a output as string 
> without any digits.
> Input : "H1e5ll0o"
> Output: "Hello"
>
> I tried with *output := strings.Replace(str, "1", "", -1)*, but it can 
> replace only single digit at a time 
>
> I'm looking for suggestions for below code snippet , tried to implement a 
> logic where string converted to rune and rune provided 
> as a input to IsDigit(), if it is digit it should replace the digit with 
> "" and print the string , i'm not sure what mistake am i doing in providing 
> parameter 
> and printing output?
>
> var output string
>
> var r rune
> for _, r = range input {
> break 
> }
>
> if unicode.IsDigit(rune(r)) {
> output = strings.Replace(input, "", "", -1)
> fmt.Println(output)
> }else{
> fmt.Println(input)
> }
>
>
>
> On Saturday, 15 January 2011 at 01:31:08 UTC+5:30 Russ Cox wrote:
>
>> There is also strings.Map.
>>
>

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

[go-nuts] Re: glog - Security Vulnerability Report

[peterGo]

Please follow the Go Security Policy: https://go.dev/security/policy

All security bugs in the Go distribution should be reported by email to 
secur...@golang.org. This mail is delivered to the Go Security team.



On Tuesday, December 6, 2022 at 6:44:37 PM UTC-5 Marco Arboleda wrote:

> Good afternoon,
>
>  
>
> My company is using the glog library  as 
> a dependency in some of our code.
>
>  
>
> However, one of my pipelines for a project I’m working on started failing 
> today. It was due to a security issue flagged by our static code analysis 
> tool.
>
> The relevant lines of code were lines 117 & 118 in glog_file.go 
>  of 
> the glog package.
>
>  
>
> Could someone take a look at this and look into fixing the security 
> vulnerability?
>
>  
>
> Here are some more details about the security issue:
>
>  
>
> Unsanitized input from a CLI argument flows into os.Remove, where it is 
> used as a path. This may result in a Path Traversal vulnerability and allow 
> an attacker to delete arbitrary files.
>
> Found in: *vendor/github.com/golang/glog/glog_file.go 
>  (line : 117)*
>
>  
>
> Unsanitized input from a CLI argument flows into os.Symlink, where it is 
> used as a path. This may result in a Path Traversal vulnerability and allow 
> an attacker to create arbitrary symlinks.
>
> Found in: *vendor/github.com/golang/glog/glog_file.go 
>  (line : 118)*
>
>  
>
> And here’s an article I found about the security issue in more detail 
> (code CWE-23): https://cwe.mitre.org/data/definitions/23.html 
>
>  
>
> Marco Arboleda  | Developer 1
>
> Applied Systems Canada
>
> *marb...@appliedsystems.com*
>
> 24/7 Customer Support: 800.617.4666 <(800)%20617-4666> |
> *sup...@appliedsystems.com*
>
> [image: Applied Net 2022] 
> 
>
>
>
> *This message is for the designated recipient only and may contain 
> confidential, proprietary, or otherwise private information. If you have 
> received this message in error, please notify the sender immediately and 
> delete the original. Any other use or distribution of this information is 
> prohibited.*
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4af2245f-121b-46c0-9abb-7f826c4fe7c0n%40googlegroups.com.

[go-nuts] Re: Go Memory Model question

[peterGo]

Programs that modify data being simultaneously accessed by multiple 
goroutines must serialize such access.   
https://go.dev/ref/mem   

$ go run -race racer.go
00
==
WARNING: DATA RACE
Write at 0x0054d5f8 by goroutine 6:
  main.main.func1()
  /home/peter/racer.go:7 +0x29

Previous read at 0x0054d5f8 by main goroutine:
  main.main()
  /home/peter/racer.go:9 +0x3c

Goroutine 6 (running) created at:
  main.main()
  /home/peter/racer.go:6 +0x30
==
Found 1 data race(s)
exit status 66
$ 

peter

On Friday, December 2, 2022 at 7:13:09 AM UTC-5 nobis...@gmail.com wrote:

> > So the second read can observe x = 0 even if the first read observes x = 
> 0.
>
> Sorry, I meant "So the second read can observe x = 0 even if the first 
> read observes x = 1." here.
>
> 2022年12月2日(金) 21:10 のびしー :
>
>> Hello, I have another question regarding the Go Memory Model. 
>>
>> (1) Can this program print "10", according to the Memory Model?
>> (2) If that is forbidden, which part of the Go Memory Model excludes such 
>> behavior?
>>
>> https://go.dev/play/p/Fn5I0fjSiKj
>>
>> ```go
>> package main
>>
>> var x int = 0
>>
>> func main() {
>> go func() {
>> x = 1
>> }()
>> print(x) // first read: 1
>> print(x) // second read: 0
>> }
>> ```
>>
>> I draw a picture of the happens-before relation of this program here:
>>
>>
>> https://gist.github.com/nobishino/8150346c30101e2ca409ed83c6c25add?permalink_comment_id=4388680#gistcomment-4388680
>>
>> I think the answer to (1) is yes. 
>> Both reads are concurrent with x = 1, so each read can observe both x = 0 
>> and x = 1.
>> And there is no constraint between the results of the first read and the 
>> second read.
>> So the second read can observe x = 0 even if the first read observes x = 
>> 0.
>>
>> But I'm not very sure. Is this understanding correct?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6fae3e5e-2a09-4d54-82aa-54b2ef9a3a8cn%40googlegroups.com.

[go-nuts] NSA recommends using memory safe languages like Go

[peterGo]

FYI

The US National Security Agency (NSA) published guidance today to help 
software developers and operators prevent and mitigate software memory 
safety issues, which account for a large portion of exploitable 
vulnerabilities.

https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/

National Security Agency | Cybersecurity Information Sheet
Software Memory Safety

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

Memory safe languages

Using a memory safe language can help prevent programmers from introducing 
certain
types of memory-related issues. Memory is managed automatically as part of 
the
computer language; it does not rely on the programmer adding code to 
implement
memory protections. The language institutes automatic protections using a 
combination
of compile time and runtime checks. These inherent language features 
protect the
programmer from introducing memory management mistakes unintentionally. 
Examples
of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. 

peter

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7d7c8c81-014d-44c6-9f84-19ed288c3e34n%40googlegroups.com.

Re: [go-nuts] Goroutine to thread mapping

[peterGo]

piotr,

Goroutines are now asynchronously preemptible. As a result, loops without 
function calls no longer potentially deadlock the scheduler or 
significantly delay garbage collection. February 2020,  
https://go.dev/doc/go1.14#runtime

peter


On Tuesday, November 8, 2022 at 3:31:25 AM UTC-5 piotr.w...@gmail.com wrote:

> I mean the Plan 9 assembler. Also assume the function is a leaf function, 
> just a long one. Can such a function be preempted by Go runtime and 
> re-assigned to another thread or can the reassignment happen only 
> cooperatively, in a number of roughly predictable selected places? 
>
> poniedziałek, 7 listopada 2022 o 18:46:42 UTC+1 ren...@ix.netcom.com 
> napisał(a):
>
>> Do you mean Go assembly or an assembly function called via CGo?
>>
>> On Nov 7, 2022, at 11:28 AM, Piotr Wyderski  wrote:
>>
>> 
>>
>> Hello,
>>
>> A goroutine needs ultimately to be assigned to an OS thread. If a 
>> goroutine calls an assembly function F, can the thread assignment change 
>> during the execution of F? 
>> In other words, is F guaranteed to return on the same thread it was 
>> called?
>>
>>Best regards, Piotr
>>  
>>
>> -- 
>> You received this message because you are subscribed 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/03f2cf25-7e52-41ca-ac20-a04877d5df9dn%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/69436177-2cee-452f-8df9-837353a4e742n%40googlegroups.com.

Re: [go-nuts] Re: How to make the first character in a string lowercase?

[peterGo]

Prithu Adhikary,

As I pointed out earlier, your code only works when the first character is 
ASCII. For example, it does not work for the Greek alphabet, it does not 
work for an empty string.

https://groups.google.com/g/golang-nuts/c/WfpmVDQFecU/m/CQiT04mRAQAJ

Peter

On Friday, November 4, 2022 at 7:57:36 PM UTC-4 Prithu Adhikary wrote:

> May be this?
>
> func main() {
> myString := "LikeThis"
> print(strings.ToLower(myString[:1]) + myString[1:])
> }
> On Friday, 19 June 2020 at 01:48:23 UTC+5:30 leonidas...@gmail.com wrote:
>
>>
>>
>> package main
>>
>> import (
>> "fmt"
>> "unicode"
>>
>> )
>>
>> func main() {
>> fmt.Println(MakeFirstLowerCase("LikeThis")) 
>>
>> }
>>
>> func MakeFirstLowerCase(s string) string {
>> if len(s)==0 {
>>return s
>> }   
>> 
>> r := []rune(s)
>> r[0] = unicode.ToLower(r[0])
>> return string(r)   
>> }
>>
>> On Thu, Jun 18, 2020 at 10:38 AM  wrote:
>>
>>> I think all other solutions works fine, but String Builder struct exists 
>>> for the same reason.
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "strings"
>>>
>>> )
>>>
>>> func ToLowerCase(str string) string {
>>>
>>> var b strings.Builder
>>>
>>> b.WriteString(strings.ToLower(string(str[0])))
>>> b.WriteString(str[1:])
>>> 
>>> return b.String()
>>>
>>> }
>>>
>>> func main() {
>>> var str string = "GoLang"
>>> fmt.Println(ToLowerCase(str))
>>> }
>>>
>>>
>>>
>>> Playground here: https://play.golang.org/p/aAyBGnM5p2x
>>>
>>> On Saturday, 24 November 2012 11:51:23 UTC+1, Nikolai wrote:

 Hi!

 What is the easiest way to make a string "LikeThis" --> "likeThis"?

>>> -- 
>>>
>> You received this message because you are subscribed 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/59ede7f8-bfb9-44a0-9fa7-cef1d7288983o%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/63dc3d5f-bbc2-4dec-a653-9f74544fa5aen%40googlegroups.com.

[go-nuts] Re: There is a passage in book that is difficult to understand, can anyone help explain it?

[peterGo]

Guanyun,

I tried to think of a simple example.

type Average struct {
sum   float64
count int64
mxsync.Mutex
}

https://go.dev/play/p/4SLCLuqG246

1. An invariant represents a condition that does not change while the 
process progresses - Niklaus Wirth.

2. The additional invariant--Average = sum / count--is specific to the data 
structure that the mutex mx guards.

3. The shared variables sum and count are part of an invariant.

4. The Add method temporarily violates the invariant by updating sum but 
restores the invariant by updating count.

Peter

On Wednesday, November 2, 2022 at 12:49:41 AM UTC-4 name@gmail.com 
wrote:

> Hello,
>
> This is a passage in book :
>
> 
> There is a good reason Go’s mutexes are not re-entrant.
>
> The purpose of a mutex is to ensure that certain invariants of the shared 
> variables are
> maintained at critical points during program execution.
>
> One of the invariants is "no goroutine is accessing the shared variables", 
> but there may be additional invariants specific to the data structures that 
> the mutex guards.
>
> When a goroutine acquires a mutex lock, it may assume that the invariants 
> hold. While it holds the lock, it may update the shared variables so that 
> the invariants are temporarily violated.
>
> However, when it releases the lock, it must guarantee that order has been 
> restored
> and the invariants hold once again.
>
> Although a re-entrant mutex would ensure that no other goroutines are 
> accessing the shared variables, it cannot protect the additional invariants 
> of those variables.
>
>  
> 
>
> This passage is difficult for me to understand:
> 1. How to understand invariants "invariants"?
> 2. What kind of scenarios does “additional invariants” refer to?
> 3. What is the relationship between "shared variables" and "invariants"?
> 4. What does "...guarantee that order has been restored..." mean?
>
> Thanks,
> Guanyun
>

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

[go-nuts] Re: Issue with go-git API

[peterGo]

Follow the instructions in the error messages: see `go help modules`.

On Monday, October 10, 2022 at 1:35:38 AM UTC-4 princ...@gmail.com wrote:

> I am trying to use this git api(*https://github.com/go-git/go-git 
> *), but before that I tried to run the 
> provided example (i.e. cloning the repo by golang). So I run the program 
> *https://github.com/go-git/go-git/blob/master/_examples/clone/main.go 
> *
>
> So when I run this program I used to get this error:
> sample.go:7:2: no required module provides package 
> github.com/go-git/go-git/v5: go.mod file not found in current directory 
> or any parent directory; see 'go help modules'
>
> sample.go:8:2: no required module provides package 
> github.com/go-git/go-git/v5/_examples: go.mod file not found in current 
> directory or any parent directory; see 'go help modules'
>
> *Please help me, how I can execute this?*
>
> I am using the following:
> Go version: go version go1.18.1 linux/amd64
> Platform:  Ubuntu 22.04.1 LTS

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/390f1b49-22d4-44ec-ab6a-79cb6aec83efn%40googlegroups.com.

Re: [go-nuts] Re: Question on 'cmd/compile: handle partially overlapping assignments' behavior on ARM64.

[peterGo]

Jan,

An obvious typo. Read my original message: "I am unable to reproduce your 
results on AMD64" 

peter

On Tuesday, September 20, 2022 at 12:14:32 PM UTC-4 Jan Mercl wrote:

> On Tue, Sep 20, 2022 at 6:02 PM peterGo  wrote:
>
> > Yes, I read that too. A fundamental tenet of science is reproducibility. 
> I was able to reproduce the AMD64 results and documented it. A step forward.
>
> 5:24 PM (45 minutes ago) > I am unable to reproduce your results on AMD64.
> 6:02 PM (7 minutes ago) > I was able to reproduce the AMD64 results
> and documented 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/348a4b1d-da1f-4ab9-86e3-1bde022718d5n%40googlegroups.com.

[go-nuts] Re: Question on 'cmd/compile: handle partially overlapping assignments' behavior on ARM64.

[peterGo]

Brian,

Yes, I read that too. A fundamental tenet of science is reproducibility. I 
was able to reproduce the AMD64 results and documented it. A step forward.

peter

On Tuesday, September 20, 2022 at 11:35:58 AM UTC-4 Brian Candler wrote:

> On Tuesday, 20 September 2022 at 16:24:41 UTC+1 peterGo wrote:
>
>> I am unable to reproduce your results on AMD64. I don't see any 
>> regression.
>
>
> That's expected: the original post also said "I don't see the [...] the 
> perfromance degradation on AMD64". The report is specific to ARM64.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fd9e4d76-6aea-4e20-bd6b-aa6470f7bed3n%40googlegroups.com.

[go-nuts] Re: Question on 'cmd/compile: handle partially overlapping assignments' behavior on ARM64.

[peterGo]

I am unable to reproduce your results on AMD64. I don't see any regression.

Run your benchmarks with option -benchmem.

Version: devel go1.20-1eeb257b88 Tue Sep 20 02:58:09 2022 +
Sizeof(Array{}): 16
Sizeof(int(0)): 8
goarch: amd64
BenchmarkSliceOfInt-4391646  2583 ns/op   8192 B/op  1 allocs/op
BenchmarkSliceOfArray-4  236977  4869 ns/op  16384 B/op  1 allocs/op

Version: go1.17.13
Sizeof(Array{}): 16
Sizeof(int(0)): 8
goarch: amd64
BenchmarkSliceOfInt-4426343  2383 ns/op   8192 B/op  1 allocs/op
BenchmarkSliceOfArray-4  233817  4771 ns/op  16384 B/op  1 allocs/op

The difference is type int is 8 bytes and type [2]int (type Array) is 16 
bytes.

Change the type of Array to 8 bytes (type [1]int).

Version: devel go1.20-1eeb257b88 Tue Sep 20 02:58:09 2022 +
Sizeof(Array{}): 8
Sizeof(int(0)): 8
goarch: amd64
BenchmarkSliceOfInt-4405793  2562 ns/op  8192 B/op  1 allocs/op
BenchmarkSliceOfArray-4  46  2540 ns/op  8192 B/op  1 allocs/op

Version: go1.17.13
Sizeof(Array{}): 8
Sizeof(int(0)): 8
goarch: amd64
BenchmarkSliceOfInt-4440340  2378 ns/op  8192 B/op  1 allocs/op
BenchmarkSliceOfArray-4  481071  2400 ns/op  8192 B/op  1 allocs/op

There is no significant difference.

peter

On Monday, September 19, 2022 at 10:01:37 PM UTC-4 jpsw...@gmail.com wrote:

> I stumbled across a performance regression on ARM64 for go 1.18.6 and 
> 1.19.1 that wasn't present in earlier releases. In the following benchmark, 
> you can see `BenchmarkSliceOfArray` experiences a 70% increase in 
>
> execution time while `BenchmarkSliceOfInt` remains unchanged. 
>
>
> BenchmarkSliceOfArray 413121 2855 ns/op
>
> BenchmarkSliceOfArray 216478 4881 ns/op
>
>
> Through the use of `pprof` and `GOSSAFUNC go build`, it was observed that 
> the latest release employs `runtime.memmove` and accounts for the change in 
> performance. I don't see the invocation of `memmove` or the perfromance 
> degradation on AMD64.
>
>
> I believe this can be traced back to - 
> https://go-review.googlesource.com/c/go/+/425234. 
>
>
> Is this new behavior in this scenario correct or unindented? 
>
>
> Should I open an issue for this? 
>
>
> I am a newbie, so forgive me if there are errors in my approach. 
>
>
> 
>
> go version go1.19 darwin/arm64
>
> % GOMAXPROCS=1 go1.19 test -cpuprofile cpu.prof -bench .  
>
> goos: darwin
>
> goarch: arm64
>
> pkg: foo/bar
>
> BenchmarkSliceOfInt 572226 2066 ns/op
>
> BenchmarkSliceOfArray 413121 2855 ns/op
>
> PASS
>
> ok foo/bar 3.488s
>
> 
>
> go version go1.19.1 darwin/arm64
>
> % GOMAXPROCS=1 go test -cpuprofile cpu.prof -bench .   
>
> goos: darwin
>
> goarch: arm64
>
> pkg: foo/bar
>
> BenchmarkSliceOfInt 527084 2065 ns/op
>
> BenchmarkSliceOfArray 216478 4881 ns/op
>
> PASS
>
> ok foo/bar 2.468s
>
> ok foo/bar 3.538s
>
> 
>
> package datamove
>
>
> type Array [2]int
>
>
> func moveSliceOfArrayData(s []Array) []Array {
>
> for i := 1; i < len(s); i++ {
>
> s[i-1], s[i] = s[i], s[i-1]
>
> }
>
> return s
>
> }
>
>
> func moveSliceOfIntData(s []int) []int {
>
> for i := 1; i < len(s); i++ {
>
> s[i-1], s[i] = s[i], s[i-1]
>
> }
>
> return s
>
> }
>
> 
>
> package datamove
>
>
> import (
>
> "testing"
>
> )
>
>
> var resultInt []int
>
> var resultArray []Array
>
>
> func BenchmarkSliceOfInt(b *testing.B) {
>
> var r []int
>
> for n := 0; n < b.N; n++ {
>
> s := make([]int, 1000)
>
> r = moveSliceOfIntData(s)
>
> }
>
> resultInt = r
>
> }
>
>
> func BenchmarkSliceOfArray(b *testing.B) {
>
> var r []Array
>
> for n := 0; n < b.N; n++ {
>
> s := make([]Array, 1000)
>
> r = moveSliceOfArrayData(s)
>
> }
>
> resultArray = 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/73f49ef0-5e4e-4bb8-9976-534894ffde38n%40googlegroups.com.

[go-nuts] Re: private go documentation server similar to https://pkg.go.dev

[peterGo]

https://go.googlesource.com/pkgsite/

On Saturday, September 10, 2022 at 5:28:35 PM UTC-4 brainman wrote:

> Hello Everyone,
>
> I would like to run go documentation server that have access to my private 
> code.
>
> Is it possible to do?
>
> I am happy to run the server myself, if it is easy to setup, and if it 
> requires no maintenance.
>
> I am also happy to use external company if they provide that kind of 
> service. Are there companies that do that?
>
> I looked for the source code for
>
> https://pkg.go.dev
>
> and I cannot find it.
>
> Thank you.
>
> Alex
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/80e83a7d-b757-4b28-971b-619d24233eccn%40googlegroups.com.

[go-nuts] Re: Benchmarks in https://github.com/golang/go

[peterGo]

For example,

~$ git clone https://github.com/golang/go --depth 1 $HOME/bench
Cloning into '/home/peter/bench'...
# . . .
~$ cd $HOME/bench/src
~/bench/src$ ./make.bash
# . . .
Installed Go for linux/amd64 in /home/peter/bench
Installed commands in /home/peter/bench/bin
~/bench/src$ cd $HOME/bench/src/math
~/bench/src/math$ $HOME/bench/bin/go version
go version devel go1.20-0c4db1e Sat Aug 6 15:20:00 2022 + linux/amd64
~/bench/src/math$ $HOME/bench/bin/go test -run=! -bench=.
# . . .
BenchmarkAcos-4  10053410611.59 ns/op
BenchmarkAcosh-4 5803739219.77 ns/op
BenchmarkAsin-4  111.48 ns/op
BenchmarkAsinh-4 4236522827.55 ns/op
BenchmarkAtan-4  197030109 6.023 ns/op
BenchmarkAtanh-4 5392676422.24 ns/op
BenchmarkAtan2-4 110.83 ns/op
# . . .
BenchmarkFloat64bits-4   10 0.3137 ns/op
BenchmarkFloat64frombits-4   10 0.3281 ns/op
BenchmarkFloat32bits-4   10 0.3326 ns/op
BenchmarkFloat32frombits-4   10 0.3341 ns/op
BenchmarkFMA-4   900370222 1.312 ns/op
PASS
ok  math90.562s
~/bench/src/math$ 

Installing Go from source: https://go.dev/doc/install/source

Peter





On Sunday, August 7, 2022 at 7:58:00 AM UTC-4 Amarjeet Anand wrote:

> Hi Nikolay
>
> Did you find a way to achieve this?
>
> On Thursday, December 17, 2020 at 11:03:43 PM UTC+5:30 
> nikolay.d...@gmail.com wrote:
>
>> Hello,
>>
>> I am trying to find a dashboard with current benchmarks of go core 
>> routines (e.g. math, sort, reflect, etc.). For example, among others, I 
>> would like to see these benchmarks: 
>> https://github.com/golang/go/blob/master/src/math/all_test.go#L3196
>>
>> I tried to run it with `go test -bench=. ./...` from the root of "go" 
>> repo, but getting errors like for case of "math":
>>
>> ```
>> package std/math
>> exp_asm.go:9:8: use of internal package internal/cpu not allowed
>> package std/math/big
>> big/arith_amd64.go:9:8: use of internal package internal/cpu not 
>> allowed
>> ```
>>
>> I think I am doing something wrong or I am missing some public dashboard. 
>> Thus, few questions:
>>
>> 1. How to run benchmarks from `https://github.com/golang/go` 
>> ?
>> 2. Is there a public official dashboard with benchmarks?
>> 3. Any resources on how benchmarks have changed over last couple of years 
>> releases of go?
>>
>> Thanks,
>>
>> - Nikolay
>>
>

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

[go-nuts] Re: goroutine private / local var/const

[peterGo]

Are you looking for somthing like this?

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

peter

On Tuesday, July 19, 2022 at 12:14:14 PM UTC-4 agra...@googlemail.com wrote:

> hi,
>
> for i=0;i<10;i++ { go func () { /* const c=i OR var v=i */
>  fmt.Println("f:beg i=",i) // here c or v instead 
> // action 
>  fmt.Println("f:end i=",i) // here c or v instead 
> }}
> when this routines get interrupted then beg-i and end-i differ
> now i want at the beginning of the routine a const copy `const c int = i`
> but its not allowed and `var v int = i` does not work, too.
>
> does an instance of a go-routine has no own stack-frame like a normal 
> function (c i.e) and therein local/private variables ? 
>
> thanks in 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/e38abe5a-01b2-44c5-a1ce-0bbf43652426n%40googlegroups.com.

[go-nuts] Re: Is Go 1.19 the last 1.x release?

[peterGo]

Natasha,

No.
 
Planning Go 1.20
https://groups.google.com/g/golang-dev/c/Lu5pEF8iwV0/m/62gDPmzaBwAJ

Peter
On Saturday, July 16, 2022 at 8:19:58 AM UTC-4 natasha.s...@gmail.com wrote:

> As once somewhat hinted by Russ Cox .
>

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

[go-nuts] Re: fmt package documentation

[peterGo]

Other flags is fixed in Go 1.19: https://pkg.go.dev/fmt@go1.19beta1

Peter

On Tuesday, July 5, 2022 at 5:47:55 PM UTC-4 ben...@gmail.com wrote:

> At the default URL https://pkg.go.dev/fmt the same thing happens for me 
> too. However, at https://pkg.go.dev/fmt@master it formats correctly 
> (pre-formatted block like in the source). So I assume this has been fixed 
> and the default will be updated soon (when 1.19 comes out?).
>
> -Ben
>
> On Tuesday, July 5, 2022 at 12:28:33 PM UTC+12 aetr...@gmail.com wrote:
>
>> The documentation of the formatting language 
>> inhttps://cs.opensource.google/go/go/+/master:src/fmt/doc.go;l=132 doesn't 
>> render the "other flags" section well. It all runs together:
>> source: 
>> Other flags: 
>>'+'always print a sign for numeric values; 
>>guarantee ASCII-only output for %q (%+q) 
>>'-'pad with spaces on the right rather than the left (left-justify 
>> the field) 
>>'#'alternate format: add leading 0b for binary (%#b), 0 for octal 
>> (%#o), 
>>0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); 
>>for %q, print a raw (backquoted) string if strconv.CanBackquote 
>>returns true; 
>>always print a decimal point for %e, %E, %f, %F, %g and %G; 
>>do not remove trailing zeros for %g and %G; 
>>write e.g. U+0078 'x' if the character is printable for %U (%#U). 
>>' '(space) leave a space for elided sign in numbers (% d); 
>>put spaces between bytes printing strings or slices in hex (% x, % 
>> X) 
>>'0'pad with leading zeros rather than spaces; 
>>for numbers, this moves the padding after the sign; 
>>ignored for strings, byte slices and byte arrays
>> 
>> rendered-
>> Other flags:
>>
>>- always print a sign for numeric values; guarantee ASCII-only output 
>>for %q (%+q)
>>- pad with spaces on the right rather than the left (left-justify the 
>>field) # alternate format: add leading 0b for binary (%#b), 0 for octal 
>>(%#o), 0x or 0X for hex (%#x or %#X); suppress 0x for %p (%#p); for %q, 
>>print a raw (backquoted) string if strconv.CanBackquote returns true; 
>>always print a decimal point for %e, %E, %f, %F, %g and %G; do not remove 
>>trailing zeros for %g and %G; write e.g. U+0078 'x' if the character is 
>>printable for %U (%#U). ' ' (space) leave a space for elided sign in 
>>numbers (% d); put spaces between bytes printing strings or slices in hex 
>>(% x, % X) 0 pad with leading zeros rather than spaces; for numbers, this 
>>moves the padding after the sign
>>
>> -
>>
>> Maybe there's already an issue open for this: it's hard to query for 
>> src/fmt/doc.go: the terms are too common.
>>
>> -- Allen
>>
>

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

[go-nuts] Re: what is tab itab short for?

[peterGo]

Go Data Structures: Interfaces - Russ Cox

https://research.swtch.com/interfaces

"The first word in the interface value points at what I call an interface 
table or itable (pronounced i-table; in theruntime sources, the C 
implementation name is Itab)."

Peter
On Thursday, June 23, 2022 at 4:20:31 AM UTC-4 cuiw...@gmail.com wrote:

>
> https://github.com/golang/go/blob/bfbb288574841f2db2499a580d7bf985a5df4556/src/runtime/runtime2.go#L203
> what is tab/itab short for?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fa3c2a81-e2ac-4c68-b19a-6fa4ac611d1cn%40googlegroups.com.

[go-nuts] Re: what is //go:build difference from //+build?

[peterGo]

This information is in the release notes.

Go 1.17 Release Notes
https://go.dev/doc/go1.17

//go:build lines

The go command now understands //go:build lines and prefers them over // 
+build lines. The new syntax uses boolean expressions, just like Go, and 
should be less error-prone. As of this release, the new syntax is fully 
supported, and all Go files should be updated to have both forms with the 
same meaning. To aid in migration, gofmt now automatically synchronizes the 
two forms. For more details on the syntax and migration plan, see 
https://golang.org/design/draft-gobuild.

Go 1.18 Release Notes
https://go.dev/doc/go1.18

//go:build lines

Go 1.17 introduced //go:build lines as a more readable way to write build 
constraints, instead of // +build lines. As of Go 1.17, gofmt adds 
//go:build lines to match existing +build lines and keeps them in sync, 
while go vet diagnoses when they are out of sync.

Since the release of Go 1.18 marks the end of support for Go 1.16, all 
supported versions of Go now understand //go:build lines. In Go 1.18, go 
fix now removes the now-obsolete // +build lines in modules declaring go 
1.18 or later in their go.mod files.

For more information, see https://go.dev/design/draft-gobuild.

Peter


On Wednesday, June 15, 2022 at 10:37:16 PM UTC-4 cuiw...@gmail.com wrote:

> about when these feature add to golang?
> and is all we can do with //go:build can do with //+build, and vice versa?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/642fcba9-8d2d-4323-823b-71d537f98b0an%40googlegroups.com.

[go-nuts] Re: what is //go:build difference from //+build?

[peterGo]

Bug-resistant build constraints — Draft Design

Russ Cox
June 30, 2020

https://go.googlesource.com/proposal/+/master/design/draft-gobuild.md

Peter


On Wednesday, June 15, 2022 at 10:37:16 PM UTC-4 cuiw...@gmail.com wrote:

> about when these feature add to golang?
> and is all we can do with //go:build can do with //+build, and vice versa?
>

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

[go-nuts] Re: biostuff: computational biology packages for Go

[peterGo]

Amit,

I know of a university professor and a university lecturer who use Go for 
computational biology. They solve some interesting computer science 
problems.

You say your code is efficient: 
https://pkg.go.dev/github.com/fluhus/biostuff

I looked at your code and picked something simple: 

package align 

func (SubstitutionMatrix) GoString.

I made some simple revisions to improve efficiency and ran a Go benchmark.

BenchmarkAL-4   6807   160245 ns/op   35941 B/op   1344 allocs/op
BenchmarkPG-4   7929   137172 ns/op   17354 B/op   1101 allocs/op

Your code (AL) appears to be less efficient than my revised version (PG).

peter

On Monday, May 9, 2022 at 8:16:56 AM UTC-4 amitl...@gmail.com wrote:

> Sharing a package suite that I've written for my computational biology 
> research and may be useful for others.
>
> Hope it helps!
>
> https://pkg.go.dev/github.com/fluhus/biostuff
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/513a63de-6ed7-4f15-888a-52d656c2e837n%40googlegroups.com.

[go-nuts] Re: testing examples printing to stdout not working for global var

[peterGo]

Please follow the Go Community Code of Conduct while posting here.   
https://go.dev/conduct

On Monday, May 2, 2022 at 11:00:14 AM UTC-4 psi@gmail.com wrote:

> #1 the two functions need to behave identically according to the syntax of 
> the language.
>
> #2 this is how working code operates, so testing needs to be able to 
> handle it.
>
> at a guess; 'testing' would appear to have some non-compliant reflection 
> going on, in this edge-case.
>
> but anyway; your reply has no relevance i can decern, and replying like 
> this can put off useful comments. please don't get huffy i don't have the 
> time/interest, just don't comment anymore.
>
> On Monday, 2 May 2022 at 03:32:46 UTC+1 peterGo wrote:
>
>> It looks like you have a bug in your code.
>>
>> "In tests, standard output is accumulated during execution and dumped to 
>> standard output when done."
>>
>> "Example functions may include a concluding line comment that begins with 
>> "Output:" and is compared with the standard output of the function when the 
>> tests are run."
>>
>> In ExampleMain(), you improperly used the os.Stdout variable value as of 
>> the testing package initialization. 
>>
>> In ExampleMain2(), you properly used the os.Stdout variable value as of 
>> when the function was run.
>>
>> testing package   
>> https://pkg.go.dev/testing@latest
>>
>> Peter
>>
>> On Sunday, May 1, 2022 at 8:03:29 PM UTC-4 psi@gmail.com wrote:
>>
>>> this caught me out, is it a bug?
>>>
>>> https://go.dev/play/p/atJb8dZHoqi
>>>
>>

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

[go-nuts] Re: testing examples printing to stdout not working for global var

[peterGo]

It looks like you have a bug in your code.

"In tests, standard output is accumulated during execution and dumped to 
standard output when done."

"Example functions may include a concluding line comment that begins with 
"Output:" and is compared with the standard output of the function when the 
tests are run."

In ExampleMain(), you improperly used the os.Stdout variable value as of 
the testing package initialization. 

In ExampleMain2(), you properly used the os.Stdout variable value as of 
when the function was run.

testing package   
https://pkg.go.dev/testing@latest

Peter

On Sunday, May 1, 2022 at 8:03:29 PM UTC-4 psi@gmail.com wrote:

> this caught me out, is it a bug?
>
> https://go.dev/play/p/atJb8dZHoqi
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f264f884-0e72-4095-a583-17ea65f10fa8n%40googlegroups.com.

Re: [go-nuts] Possible fuzz testing issue on Windows

[peterGo]

On Monday, April 25, 2022 at 2:12:35 AM UTC-4 kortschak wrote:

> I have sent https://go-review.googlesource.com/c/go/+/402074 to address 
> this. 
>
>  
 Dan,

For the second and subsequent lines, 

for _, line := range lines[1:] {
line = bytes.TrimSpace(line)
// ...
}

Did you consider being consistent and adopting that solution for the first 
line? For example,

line0 := bytes.TrimSpace(lines[0])
if string(line0) != encVersion1 {
// . . .
}

Peter

Dan 
>  

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

Re: [go-nuts] Generics faster than native float64?

[peterGo]

As Ian has pointed out, software and hardware optimizations may distort the 
results of microbenchmarks.

If I run the original benchmarks using go1.18 and go1.19 the Copy and CopyG 
ns/op results are reversed.

# Original: https://go.dev/play/p/m1ClnbdbdWi

~/x$ go1.18 version && go1.18 test x_0_test.go -bench=.
go version go1.18.1 linux/amd64
BenchmarkCopy-8 3820009310.7 ns/op
BenchmarkCopyG-87552230158.3 ns/op

~/x$ go version && go test x_0_test.go -bench=.
go version devel go1.19-a11a885cb5 Mon Apr 18 23:57:00 2022 + 
linux/amd64
BenchmarkCopy-8 7577499158.2 ns/op
BenchmarkCopyG-83870822309.7 ns/op

If I run the benchmarks with a ResetTimer() using go1.18 and go1.19 the 
Copy and CopyG ns/op results are effectively the same.

# ResetTimer: https://go.dev/play/p/hansq5ARrSh

~/x$ go1.18 version && go1.18 test x_1_test.go -bench=.
go version go1.18.1 linux/amd64
BenchmarkCopy-8 7581037158.0 ns/op
BenchmarkCopyG-87590849157.9 ns/op

~/x$ go version && go test x_1_test.go -bench=.
go version devel go1.19-a11a885cb5 Mon Apr 18 23:57:00 2022 + 
linux/amd64
BenchmarkCopy-8 7525525158.5 ns/op
BenchmarkCopyG-87521787158.5 ns/op

If I run the original benchmarks on a Celeron N3450 using go1.18 and go1.19 
the Copy and CopyG ns/op results are effectively the same. I run benchmarks 
on a Celeron N3450 because Intel disables many hardware optimizations on 
cheap hardware.
 
# Original: https://go.dev/play/p/m1ClnbdbdWi

$ go1.18 version && go1.18 test x_0_test.go -bench=.
go version go1.18.1 linux/amd64
BenchmarkCopy-4 2773934   428.0 ns/op
BenchmarkCopyG-42783043   429.7 ns/op

$  go version && go test x_0_test.go -bench=.
go version devel go1.19-a11a885cb5 Mon Apr 18 23:57:00 2022 + 
linux/amd64
BenchmarkCopy-4 2781676   428.6 ns/op
BenchmarkCopyG-42765179   429.0 ns/op


Peter

On Tuesday, April 19, 2022 at 12:37:48 AM UTC-4 Ian Lance Taylor wrote:

> On Mon, Apr 18, 2022 at 1:14 PM Feng Tian  wrote:
> >
> > Hi, I have the following simple benchmark code,
> >
> > https://go.dev/play/p/m1ClnbdbdWi
> >
> > I run this on my laptop since Go playground does not run benchmark code. 
> The strange thing is that Copy of float64 is slower than copy using 
> generics. I can imagine generics may add no overhead, but how can it be 
> faster?
> >
> > ftian@DESKTOP-16FCU43:~/tmp$ go test -bench=.
> > goos: linux
> > goarch: amd64
> > pkg: a
> > cpu: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz
> > BenchmarkCopy-8 5693944 221.7 ns/op
> > BenchmarkCopyG-8 8885454 137.1 ns/op
> > PASS
> > ok a 2.838s
>
> The numbers for this kind of micro-benchmark can be deceptive. For
> example, they can be highly affected by alignment of the instruction
> loop. I don't know exactly what is happening for you. I compiled the
> code with "go test -c" and disassembled it: both benchmark functions
> contained exactly the same instructions.
>
> 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/2347d30b-c517-450e-97e2-361b6f01929fn%40googlegroups.com.

[go-nuts] Re: MaxDiskSize MaxLogCount for glog?

[peterGo]

On Thursday, April 7, 2022 at 2:27:06 PM UTC-4 Jack Li wrote:

> Hi group,
>
> Can glog support the options like how many disk size (ie. 10%, 1.8G, etc.) 
> all the log files may use in total, and the count (ie. 10) of log files it 
> can save. For example, logfile1.txt, logfile2.txt, ..., logfile10.txt. 
> These 10 files is 18G in total. And there is no logfile11.txt, its content 
> will overwrite logfile1.txt.
>


glog 
https://github.com/golang/glog#glog   

"The code in this repo is for export only and is not itself under 
development. Feature requests will be ignored."

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/93de7324-da98-4193-9d04-cae02b740db2n%40googlegroups.com.

[go-nuts] Re: Convert string to time.Duration

[peterGo]

func addHours(t time.Time, hours string) (time.Time, error) {
i, err := strconv.ParseInt(hours, 10, 64)
if err != nil {
return time.Time{}, err
}
return t.Add(time.Hour * time.Duration(i)), nil
}

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

Peter

On Sunday, April 3, 2022 at 6:48:54 PM UTC-4 vika...@gmail.com wrote:

> I am looking to convert a *string* (say 4) to type *time.Duration*.
>
> I've looked around but could not find a way to do so.
>
> // https://go.dev/play/p/EUuDAY-Qx8N
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> // var addHours string = 4
> fmt.Println(time.Now().Local())
> timeAdd := time.Now().Local().Add(time.Hour * 4) // I want to use 4 
> from a string variable here
> fmt.Println(timeAdd)
> }
>

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

Re: [go-nuts] Re: "\x7f"

[peterGo]

Unicode Standard
http://www.unicode.org/versions/latest/

C0 Controls and Basic Latin Range: –007F
https://unicode.org/charts/PDF/U.pdf

Control character 007F  = DELETE

Peter

On Thursday, March 31, 2022 at 1:40:53 AM UTC-4 zachmc...@gmail.com wrote:

> 9 years in the future:
>
> This is why I cared: https://go.dev/play/p/F4GlQBQL7UC
>
> It's the only ASCII character showing as Unicode. When testing, I was 
> alarmed thinking I had an error, but it was inaccurately represented as 
> Unicode.  
> The length is accurate.  
>   fmt.Printf("Byte 127 len: %d\n", len([]byte{127}))
>
>
> On Wednesday, June 26, 2013 at 1:16:42 PM UTC-6 gus...@niemeyer.net wrote:
>
>> On Wed, Jun 26, 2013 at 4:08 PM, Rob Pike  wrote: 
>> > It is arbitrary. Why do you care? That implies a non-arbitrary thought 
>> process. 
>>
>> Even if I agree, my brain tends to appreciate non-arbitrariness for 
>> whatever reason. If I feed it things that look alike, it tends to spot 
>> their meaning more quickly. 
>>
>>
>> gustavo @ http://niemeyer.net 
>>
>

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

[go-nuts] Re: about keyword constraint?

[peterGo]

For background information, 

Featherweight Go
The Go language famously lacks generics. Our paper introduces a core formal 
model of Go, Featherweight Go (FG), and explores a design of generics for 
FG featuring structural typing (Featherweight Generic Go). The semantics of 
generics are defined via monomorphisation into FG. 

https://www.youtube.com/watch?v=62xlcsJ0AUs   


Featherweight Go Paper DOI: https://doi.org/10.1145/3428217 

 
Presented at OOPSLA, part of SPLASH 2020 By Robert Griesemer, Raymond Hu, 
Wen Kokke, Julien Lange, Ian Lance Taylor, Bernardo Toninho, Philip Wadler, 
Nobuko Yoshida

https://dl.acm.org/doi/10.1145/3428217   
https://dl.acm.org/doi/pdf/10.1145/3428217   

Peter

On Sunday, March 20, 2022 at 1:28:39 AM UTC-4 cuiw...@gmail.com wrote:

> in the period of typeparam development, we have try to add a keyword 
> constraint, why we remove it finally, i am trying to understand why to add 
> it and why to remove int finally.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2793f88f-521e-4dd0-bf9d-d5ce81b8f9a4n%40googlegroups.com.

[go-nuts] Re: Goroutines - handles, signals, and signal handlers

[peterGo]

Go1.18 has a new Mutex TryLock method.   
https://pkg.go.dev/sync@go1.18#Mutex.TryLock

Petr

On Wednesday, March 16, 2022 at 9:36:50 PM UTC-4 mumbling...@gmail.com 
wrote:

> I'm currently working on a project where I emulate a RISC-V processor for 
> the purpose of using Go when teaching concepts of operating systems.
> I'd like for the emulator to resemble a "real" processor to the point that 
> a realistic operating system can be implemented with most of the 
> interesting challenges that this encompasses.
> One of these challenges is the management of translation caches across 
> multiple cores which may sometimes require TLB shootdowns.
>
> A quick summary of TLB shootdowns: process P has two threads T1 and T2 
> that run on cores A and B respectively.
> When T1 makes a request to deallocate a page, core A has to ensure that T2 
> on core B invalidates some cached translations before it marks the page as 
> free, lest B (executing T2) might find the translation in cache and write 
> to a page that T2 no longer should have access to.
>
> My current approach to this is that instead of using a `sync.Mutex` and 
> `Lock()`, I have created a custom `UntilLock(f func())` which takes in a 
> function that should be repeatedly executed until the lock is acquired.
>
> Current implementation: https://pastecord.com/hofoloxuru.go
>
> Notice that every mutex where a `Lock`-`Unlock`-pair might wrap an 
> interrupt, has to use the `UntilLock` as a `Lock` might cause the 
> goroutine to block and never check interrupts.
> The issue is further complicated if one resource R might be locked in 
> function F and another resource S is locked in function G.
> In this case, goroutine A might enter F, successfully acquire R, then 
> signal goroutine B.
> At the same time, B enters G, successfully acquires S, then signals 
> goroutine A.
> We have a deadlock.
> This is pretty easily resolved though as we just add the interrupt check 
> to the loop where F and G wait for the other goroutine to execute their 
> handlers.
>
> An idea came to me though...
> Life would be much easier if Go had signalling between goroutines.
> One could extend the syntax as `h := go f() handler` where `handler`
> would have the signature: `func handler(signal int)`
> You would then signal it with something like `s := sig h 1` to send a 
> signal of 1 to the goroutine associated with h.
>
> Idea for how code would look with signalling: 
> https://pastecord.com/qunyqejexo.go
>
> This would completely eliminate the issue I am currently facing and though 
> I'm no expert in the field, I believe Go's scheduler could make the 
> implementation require very little effort and the overhead would be 
> practically non-existent.
> This signalling would look a lot like OS signals and is a powerful feature 
> that isn't too complex in my opinion.
>

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

[go-nuts] Re: Parsing a time as a prefix of a larger string

[peterGo]

On Tuesday, March 15, 2022 at 11:35:06 PM UTC-4 Ben wrote:

> We're making a log processing program that needs to parse times from the 
> prefix of a larger string, in this case in a log line such as:
>
> 2006-01-02 15:04:05 INFO this is a log message
>
> We need to parse the "2006-01-02 15:04:05" part as a timestamp. 
> Unfortunately, time.Parse always returns an error if there's extra text 
> after the timestamp.
>
> If the timestamp were in a fixed format (like the one above) we could just 
> hard-code it to grab the first two fields, or even the first N characters. 
> However, in our case the format of the timestamp is user-controlled, so 
> we're planning to let the user specify a custom time.Parse layout for their 
> logs.
>
> Ben
>
> Ben,
 
How does the user control the format of the timestamp? How do you get the 
time.Parse layout?

Peter
  

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2b5f0902-99a6-4478-bb70-0d3a055c52c8n%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[peterGo]

Kurtis Rader,

Stop it. When you are in a hole, stop digging.

When you don't understand a question or topic, don't launch ad hominem 
attacks, calling people's questions silly. That's nasty and it's against 
the Go Code of Conduct.

Like Jan, Rob, and Volker, I found it to be an interesting question, worthy 
of an answer. I wrote a program and looked at the executable code. Are we 
silly too?

Peter

On Thursday, March 10, 2022 at 12:29:54 AM UTC-5 Kurtis Rader wrote:

> On Wed, Mar 9, 2022 at 9:12 PM shan...@gmail.com  
> wrote:
>
>> Um
>>
>> Really?
>>
>> Which of these things are you specifically trying to prevent happening
>>  - Curiousity
>>  - Creativity
>>  - Asking questions
>>  - Some combination of the above
>>
>> I mean, I appreciate that you think that people should *know* whatever it 
>> is you think you know, but that's a really *really* poor response
>>
>
> Yes, your question was silly. The limit is going to be both platform 
> dependent and dependent on the resources (e.g., memory) available on the 
> platform. Your question is silly because regardless of the fundamental 
> limits imposed by the Go language or the platform it runs on absolutely no 
> one will ever write a function that gets within many orders of magnitude of 
> the limit. So your question is interesting in a hypothetical sense but not 
> in a practical sense. For the former I suggest you start a research project 
> and write a paper for review that explains why, or why not, the existing 
> limit is a problem.
>  
>
>> On Thursday, March 10, 2022 at 4:08:02 PM UTC+11 Kurtis Rader wrote:
>>
>>> On Wed, Mar 9, 2022 at 8:38 PM Jan Mercl <0xj...@gmail.com> wrote:
>>>
 A linked list, for example, consists of pointers to pointers to 
 pointers...

 Why should any limit exist to the length of the list except resources 
 available?

>>>
>>> Yes, but the O.P. was asking about a silly example. Specifically, when 
>>> defining a function that receives pointers how many levels of indirection 
>>> are allowed in the declaration. In practice 99.9% of the time a single 
>>> level of indirection is specified and 0.09% of the time two levels are 
>>> specified. Etcetera.  For example, if
>>>
>>> func wtf(i int) {
>>> }
>>>
>>> is supported, which has eight levels of indirection, why isn't 16? 32? 
>>> 64? Etcetera levels of indirection supported when defining a function. It's 
>>> a silly question that shows the O.P. doesn't understand how compilers work. 
>>> Let alone how people use languages like Go in real life.
>>>  
>>>
 On Thu, Mar 10, 2022, 03:59 shan...@gmail.com  
 wrote:

> This morning someone asked about dereferincing a pointer to a pointer 
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer, but 
> some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b := 
> c := 
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum * 
> is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
>
> -- 
> You received this message because you are subscribed 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/60cf1568-31d3-426e-bfdc-0b4b98b53acdn%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/CAA40n-WZwmcC6aVyvO3H42c9WeuL%2BPEimApdOPgR20cS_nPU%2Bw%40mail.gmail.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...@googlegroups.com.
>>
> 

Re: [go-nuts] Re: DataRace with slice, should i fix it or ignore it?

[peterGo]

Pelen Li,

Boehm covers your specific case: "there is no reason to believe that a
currently working program with “benign races” will continue to work when it
is recompiled. Perhaps most surprisingly, this includes even the case of
potentially concurrent writes of the same value by different threads."

Peter

On Wed, Feb 9, 2022 at 9:17 AM peterGo  wrote:

> Pelen Li,
>
> Always fix your data races. You should consider the results of data races
> as undefined.
>
> Dmitry Vyukov, who implemented the Go race detector, once wrote an
> interesting article with the title: "Benign data races: what could possibly
> go wrong?"
>
> https://twitter.com/dvyukov/status/288858957827682304
>
> The Go Blog: Introducing the Go Race Detector
> Dmitry Vyukov and Andrew Gerrand
> 26 June 2013
>
> https://go.dev/blog/race-detector
>
> Hans-J. Boehm wrote: "there is no reason to believe that a currently
> working program with “benign races” will continue to work when it is
> recompiled."
>
> How to miscompile programs with “benign” data races
> Hans-J. Boehm
> HP Laboratories
>
> https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf
>
> Nonetheless many programmers clearly believe, along with [15] that certain
> kinds of data races can be safely ignored in practice because they will
> produce expected results with all reasonable implementations. Here we show
> that all kinds of C or C++ source-level “benign” races discussed in the
> literature can in fact lead to incorrect execution as a result of perfectly
> reasonable compiler transformations, or when the program is moved to a
> different hardware platform. Thus there is no reason to believe that a
> currently working program with “benign races” will continue to work when it
> is recompiled. Perhaps most surprisingly, this includes even the case of
> potentially concurrent writes of the same value by different threads.
>
> And so on.
>
> Peter
>
> On Wednesday, February 9, 2022 at 3:21:26 AM UTC-5 penglo...@gmail.com
> wrote:
>
>> I want to set a value with the index of the slice. I don't really care if
>> there are multiple goroutines cover the value with each other, because the
>> value is same.
>>
>> Can i just ignore this DataRace Warning? I don't know if this will cause
>> panic.
>>
>> *Here's my example:*
>> I defined a structure with slice, and a Add() function for it. sample
>> like this:
>> ```go
>> package test_slice
>>
>> type SliceObj struct {
>> set []uint
>> }
>>
>> func New(length int64) *SliceObj {
>> return {
>> set: make([]uint, length),
>> }
>> }
>>
>> func (b *SliceObj) Add(i uint) {
>> b.set[i] = i
>> }
>> ```
>>
>> And then i make a main file to test it, like this:
>> ```go
>> package main
>>
>> import (
>> "time"
>>
>> "test_slice"
>> )
>>
>> func main() {
>> s := test_slice.New(100)
>> go func() {
>> s.Add(10)
>> }()
>> s.Add(10)
>>
>> time.Sleep(3 * time.Second)
>> }
>> ```
>>
>> *And data race is detected:*
>> *(*I know the reason of this warning, but I don't know if I can ignore it
>> *)*
>> ==
>> WARNING: DATA RACE
>> Write at 0x00c000180050 by goroutine 18:
>>   test_slice.(*SliceObj).Add()
>>   test_slice.go:27 +0x68
>>   main.main.func1()
>>   test.go:25 +0x36
>>
>> Previous write at 0x00c000180050 by main goroutine:
>>   test_slice.(*SliceObj).Add()
>>   test_slice.go:27 +0xfd
>>   main.main()
>>   test.go:27 +0xcb
>>
>> Goroutine 18 (running) created at:
>>   main.main()
>>   test.go:24 +0xca
>> ==
>> Found 1 data race(s)
>> exit status 66
>>
> --
> 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/ai0eQtnas7A/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/2594a018-872a-4d54-8ede-c769042e99b5n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/2594a018-872a-4d54-8ede-c769042e99b5n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

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

[go-nuts] Re: DataRace with slice, should i fix it or ignore it?

[peterGo]

Pelen Li,

Always fix your data races. You should consider the results of data races 
as undefined.

Dmitry Vyukov, who implemented the Go race detector, once wrote an 
interesting article with the title: "Benign data races: what could possibly 
go wrong?" 

https://twitter.com/dvyukov/status/288858957827682304

The Go Blog: Introducing the Go Race Detector
Dmitry Vyukov and Andrew Gerrand
26 June 2013

https://go.dev/blog/race-detector

Hans-J. Boehm wrote: "there is no reason to believe that a currently 
working program with “benign races” will continue to work when it is 
recompiled."

How to miscompile programs with “benign” data races
Hans-J. Boehm
HP Laboratories

https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf

Nonetheless many programmers clearly believe, along with [15] that certain 
kinds of data races can be safely ignored in practice because they will 
produce expected results with all reasonable implementations. Here we show 
that all kinds of C or C++ source-level “benign” races discussed in the 
literature can in fact lead to incorrect execution as a result of perfectly 
reasonable compiler transformations, or when the program is moved to a 
different hardware platform. Thus there is no reason to believe that a 
currently working program with “benign races” will continue to work when it 
is recompiled. Perhaps most surprisingly, this includes even the case of 
potentially concurrent writes of the same value by different threads.

And so on.

Peter

On Wednesday, February 9, 2022 at 3:21:26 AM UTC-5 penglo...@gmail.com 
wrote:

> I want to set a value with the index of the slice. I don't really care if 
> there are multiple goroutines cover the value with each other, because the 
> value is same.
>
> Can i just ignore this DataRace Warning? I don't know if this will cause 
> panic.
>
> *Here's my example:*
> I defined a structure with slice, and a Add() function for it. sample like 
> this:
> ```go
> package test_slice
>
> type SliceObj struct {
> set []uint
> }
>
> func New(length int64) *SliceObj {
> return {
> set: make([]uint, length),
> }
> }
>
> func (b *SliceObj) Add(i uint) {
> b.set[i] = i
> }
> ```
>
> And then i make a main file to test it, like this:
> ```go
> package main
>
> import (
> "time"
>
> "test_slice"
> )
>
> func main() {
> s := test_slice.New(100)
> go func() {
> s.Add(10)
> }()
> s.Add(10)
>
> time.Sleep(3 * time.Second)
> }
> ```
>
> *And data race is detected:*
> *(*I know the reason of this warning, but I don't know if I can ignore it
> *)*
> ==
> WARNING: DATA RACE
> Write at 0x00c000180050 by goroutine 18:
>   test_slice.(*SliceObj).Add()
>   test_slice.go:27 +0x68
>   main.main.func1()
>   test.go:25 +0x36
>
> Previous write at 0x00c000180050 by main goroutine:
>   test_slice.(*SliceObj).Add()
>   test_slice.go:27 +0xfd
>   main.main()
>   test.go:27 +0xcb
>
> Goroutine 18 (running) created at:
>   main.main()
>   test.go:24 +0xca
> ==
> Found 1 data race(s)
> exit status 66
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2594a018-872a-4d54-8ede-c769042e99b5n%40googlegroups.com.

[go-nuts] Re: golang-announce is blocked in Google Groups?

[peterGo]

Jochen,

I get that message too.

https://groups.google.com/g/golang-announce

Google is also trying to lock me out of my gmail accounts, but they do that 
all the time.

I don't think Google puts their best people on security.

Peter

On Thursday, January 20, 2022 at 6:38:20 AM UTC-5 joche...@gmail.com wrote:

> Hello,
>
> It seems that golang-announce is blocked in Google Groups.  When I try to 
> access the group, I only get the following message:
>
> Banned content warning
> golang-announce has been identified as containing spam, malware or 
> other malicious content.
> For more information about content policies on Google Groups, see ...
>
> Anybody knows what this is about?
>
> 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/113efe51-64c0-4a53-9631-8177ca8ed8fcn%40googlegroups.com.

[go-nuts] Re: Q about defer

[peterGo]

The Go Programming Language Specification

https://go.dev/ref/spec

Defer statements  

https://go.dev/ref/spec#Defer_statements

Peter

On Friday, December 24, 2021 at 8:34:58 AM UTC-5 muhorto...@gmail.com wrote:

> https://play.golang.com/p/lypWMc6Kuff
> Why do we get 2 in test() and 1 in anotherTest()? Is it related to the 
> definition of the variable in the output? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2ef0cabe-ae0b-4c67-b92b-a7fbe8239c2an%40googlegroups.com.

Re: [go-nuts] Why runtime force gc every 2 minutes?

[peterGo]

Getting to Go: The Journey of Go's Garbage Collector
Rick Hudson
12 July 2018

https://go.dev/blog/ismmkeynote

Peter



On Tuesday, December 14, 2021 at 9:05:09 AM UTC-5 peterGo wrote:

> There is no right answer to your question. Optimiation is often a 
> balancing act between competing goals, for example, cpu vs menory, speed vs 
> memory safety, different workloads, avoiding worst cases, and so on.
>
> Here's a peek at the problem in 2018: 
> https://go.dev/blog/ismmkeynote.Since then, there have been other 
> refinements. In 2018,, a primary goal was to reduce gc latency. Once you 
> fix that, other issues come to the fore.
>
> Peter
>
> On Tuesday, December 14, 2021 at 4:14:14 AM UTC-5 kurnia...@gmail.com 
> wrote:
>
>> oh, maybe they just trying random configuration (1min, 5min, or something 
>> else)
>> and 2min is the best result
>>
>> On Tuesday, December 14, 2021 at 4:13:05 PM UTC+7 Kurnia D Win wrote:
>>
>>> okay, thanks for the explanation, 
>>> suggesting me to change language to rust/c is not answering my curiosity
>>> I ask it because I'm trying to learn the runtime, and the "why" behind 
>>> some decision that already made
>>> for now, I will just follow it blindly, because the go developers 
>>> already made that decision
>>>
>>> thank you
>>>
>>> On Tuesday, December 14, 2021 at 3:27:18 PM UTC+7 Brian Candler wrote:
>>>
>>>> On Tuesday, 14 December 2021 at 03:28:26 UTC kurnia...@gmail.com wrote:
>>>>
>>>>> the problem with it, when you have a large live heap but with 
>>>>> efficient code (most of the hot code is zero alloc), the runtime will be 
>>>>> wasting CPU time every 2 minutes just to find out that there is no 
>>>>> garbage 
>>>>> to collect
>>>>>
>>>>
>>>> Let's say it wastes, say, 10 milliseconds every 2 minutes - and it 
>>>> doesn't even stop the program for that time but runs GC in a separate 
>>>> thread. Is that a big deal, in order to give reasonable behaviour across a 
>>>> wide range of programs?
>>>>
>>>> If you need such fine low-level control, then maybe a different 
>>>> language like Rust (or even C) might be better for your application.
>>>>
>>>>>

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

Re: [go-nuts] Why runtime force gc every 2 minutes?

[peterGo]

There is no right answer to your question. Optimiation is often a balancing 
act between competing goals, for example, cpu vs menory, speed vs memory 
safety, different workloads, avoiding worst cases, and so on.

Here's a peek at the problem in 2018: https://go.dev/blog/ismmkeynote.Since 
then, there have been other refinements. In 2018,, a primary goal was to 
reduce gc latency. Once you fix that, other issues come to the fore.

Peter

On Tuesday, December 14, 2021 at 4:14:14 AM UTC-5 kurnia...@gmail.com wrote:

> oh, maybe they just trying random configuration (1min, 5min, or something 
> else)
> and 2min is the best result
>
> On Tuesday, December 14, 2021 at 4:13:05 PM UTC+7 Kurnia D Win wrote:
>
>> okay, thanks for the explanation, 
>> suggesting me to change language to rust/c is not answering my curiosity
>> I ask it because I'm trying to learn the runtime, and the "why" behind 
>> some decision that already made
>> for now, I will just follow it blindly, because the go developers already 
>> made that decision
>>
>> thank you
>>
>> On Tuesday, December 14, 2021 at 3:27:18 PM UTC+7 Brian Candler wrote:
>>
>>> On Tuesday, 14 December 2021 at 03:28:26 UTC kurnia...@gmail.com wrote:
>>>
 the problem with it, when you have a large live heap but with efficient 
 code (most of the hot code is zero alloc), the runtime will be wasting CPU 
 time every 2 minutes just to find out that there is no garbage to collect

>>>
>>> Let's say it wastes, say, 10 milliseconds every 2 minutes - and it 
>>> doesn't even stop the program for that time but runs GC in a separate 
>>> thread. Is that a big deal, in order to give reasonable behaviour across a 
>>> wide range of programs?
>>>
>>> If you need such fine low-level control, then maybe a different language 
>>> like Rust (or even C) might be better for your application.
>>>


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

[go-nuts] Re: how to control the timezone of time.Now()

[peterGo]

Andrei,

For database times enforce the use of these convenience functions:

func DBNow() time.Time {
return DBTime(time.Now())
}

func DBTime(t time.Time) time.Time {
return t.UTC()
}

Peter


On Tuesday, October 26, 2021 at 2:58:16 PM UTC-4 Andrei Matei wrote:

> Hello Go friends,
>
> I'm finding it difficult to satisfactorily control the timezone used by 
> the time.Now() function. The Go team have taken positions in the past that 
> seem to not make this easy; I'd like to see if I can gather sympathy for 
> changes, or perhaps if there's some obvious idea that I'm missing.
>
> In CockroachDB, we like all our timestamps to have the UTC timezone. This 
> is important for printing them out similarly across a cluster of 
> geographically-distributed processes, and also because time.Now() 
> timestamps sometimes end up exposed as SQL values, where the time zone 
> matters in various ways.
>
> If you accept that you want all the time.Now() calls in the process to 
> return UTC timestamps, the question is how to achieve that. We want a 
> solution that is confined to our program; we don't want to rely on the 
> environment having set the TZ envvar.
>
> For the longest time, we used a utility function like:
>
> func Now() time.Time {
>   return time.Now().UTC()
> }
>
> and we had a linter disallowing direct use of time.Now(). The problem with 
> this is that the UTC() call strips out the monotonic clock part 
> .
>  
> I don't fully understand the reason for this; the UTC() call seems to 
> have been bucketed 
>  in 
> with other calls like Truncate() which want to strip the mono part. So, we 
> lose the benefits of the monotonic clock, and also the time.Since() calls 
> become twice as expensive because an optimization 
> 
>  
> is disabled when there's no mono.
> Would it be feasible at all to get a flavor of UTC() that does not do the 
> stripping?
>
> If not, let's see what we can do to avoid the UTC() call. One possibility 
> is os.Setenv("TZ", ""). The problem with that, I think, is that it needs to 
> be done before initLocal() 
> 
>  
> runs, which is not easy to control.
>
> Another way to do it is by setting the time.Local global. I thought that 
> the reason why this global variable exists is precisely for setting it in 
> func init()'s, but then I got a bit disillusioned.
> First I tried 
>
> func init() {
>   time.Local = time.UTC
> }
>
> A problem with doing this is that you end up violating what appears to be 
> a documented invariant of time.Time:
> // All UTC times are represented with loc==nil, never loc== 
> 
>
> Setting time.Local = time.UTC results in time.Now() producing timestamps 
> with local ==  
> .
>  
> I don't know if violating that invariant actually has any consequences for 
> the time library, but at the very least it breaks the round-tripping of UTC 
> values through marshall/unmarshall (e.g. json), in the sense that 
> reflect.DeepEqual() no longer considers the un-marhsalled value equal to 
> the original. The difficulties with round-tripping time.Time have 
>  been  reported 
> several times and were not accepted; still, time.Now().UTC() used to 
> round-trip fine - which was making our tests happy.
>
> One weird trick that works is setting time.Local = nil. That does what I 
> want, but seems to be straying even further from intended uses of the API.
>
> Reading around, I see that the invariant violation above was rejected 
>  as a 
> bug report in the past. More generally, I see that the whole idea of 
> controlling the process-wide timezone was rejected 
>  (also 
> here ). 
> And yet time.Local is exported (and mutable), so I do wonder why that is.
>
> So, would anyone have another suggestion about how to enforce process-wide 
> UTC timezones while preserving the monotonic clock readings?
> Or, any chance for re-litigating introducing a SetLocal() function?
>
> Thanks!
>
> - Andrei
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this 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] Re: Questions about documentation of Go standard library

[peterGo]

Kamil,

A Go interface implements a particular behavior. For example, io.Reader is 
the interface that wraps the basic Read method.

type Reader interface {
Read(p []byte) (n int, err error)
}

The outcome of the Read method ranges from good to catastrophic failure. 
The outcome is reported in the err error type return value. The err return 
value for good is nil. For a finite stream of data, a particular outcome of 
interest is end-of-file.

var EOF = errors.New("EOF")

io.EOF is the error returned by Read when no more input is available.

See package io.
https://pkg.go.dev/io

Peter

On Wednesday, October 6, 2021 at 5:35:11 PM UTC-4 kziem...@gmail.com wrote:

> Hello,
>
> I currently read about "io" package and again I read that "io.EOF" is not 
> treated as error, since it is what you expect to end file, which is almost 
> tautology. At the same time it satisfies error interface and is created 
> busing errors.New function.
>
> I understand why this is done, doing it other way would probably make 
> serious mess in the code, but pedantic said of me is unsettled by this. 
> Does any experience Gopher can give my advice how to think about situation 
> when some object satisfy interface, but it is exception that proves the 
> rule? I should just get used to it, or is it some better way of thinking?
>
> Best
> Kamil
>
> sobota, 4 września 2021 o 23:28:20 UTC+2 Brian Candler napisał(a):
>
>> Ah, I missed the bit where it says "Flag syntax is xyz (set) 
>> or -xyz (clear) or xy-z (set xy, clear z)."  You're quite right, there's a 
>> much simpler way:
>> https://play.golang.org/p/upupUQUcsR8
>>
>> On Saturday, 4 September 2021 at 20:51:53 UTC+1 kziem...@gmail.com wrote:
>>
>>> Thank you for your answer and opinion Briana Candler.
>>>
>>> I ask about unset only because of the cryptic text, at least to me, in 
>>> the description of RE2 (https://github.com/google/re2/wiki/Syntax). 
>>> From practical point of view, your solutions look good.
>>>
>>> I try to google about changes in examples in Go's stdlib, maybe this can 
>>> be done?
>>>
>>> Best
>>> Kamil
>>>
>>> pt., 3 wrz 2021 o 21:42 Brian Candler  napisał(a):
>>>
>>>> I believe (?m) applies to the current group only; if you want to 
>>>> "unset" it then start a separate group.
>>>> https://play.golang.org/p/wT_ZTrUSABL
>>>>
>>>> And I think you're right, there's no need to have capture groups for 
>>>> FindIndex.
>>>>
>>>> On Friday, 3 September 2021 at 20:33:14 UTC+1 kziem...@gmail.com wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> My struggles with regexp is going and I have another problem. I read 
>>>>> closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax) 
>>>>> and I still not sure if I understand one example from regexp package.
>>>>>
>>>>> In example in method func (*Regexp) FindIndex (
>>>>> https://pkg.go.dev/reg...@go1.17#Regexp.FindIndex 
>>>>> <https://pkg.go.dev/regexp@go1.17#Regexp.FindIndex>) we have line
>>>>>
>>>>> pattern := regexp.MustCompile(`(?m)(?P\w+):\s+(?P\w+)$`)
>>>>>
>>>>> Does (?m) set value of flag m to true and if I want set it to false I 
>>>>> should write (?-m) or not? By default m should be false, but as example 
>>>>> it 
>>>>> is fine.
>>>>>
>>>>> As a side note, this regular expression is used in other examples, 
>>>>> when we need  and , but looks unnecessary complex for method 
>>>>> FindIndex. I guess
>>>>> `(?m)\w+:\s+\w+$`
>>>>> would work fine. Am I wrong?
>>>>>
>>>>> Best
>>>>> Kamil
>>>>>
>>>>> środa, 1 września 2021 o 12:29:58 UTC+2 Kamil Ziemian napisał(a):
>>>>>
>>>>>> Kurtis Rader, peterGo thank you for the answers. I probably need to 
>>>>>> learn more about RPC protocols, for now I can only expand acronym. But 
>>>>>> this 
>>>>>> point with ignoring leading zeros is clear enough. And probalby more 
>>>>>> "elementary (and stupid)?" questions is comming.
>>>>>>
>>>>>> Kamil
>>>>>> poniedziałek, 30 sierpnia 2021 o 03:02:51 UTC+2 peterGo napisał(a):
>>>>>>
>>>>>>>
>>>>>>>
>&g

Re: [go-nuts] How to check whether a variable is unreachable?

[peterGo]

$ go vet ch.go
# command-line-arguments
./ch.go:19:28: possible misuse of unsafe.Pointer
$ 

https://play.golang.org/p/n9A_sR1yuXC

Peter

On Thursday, September 23, 2021 at 2:23:47 AM UTC-4 chole...@gmail.com 
wrote:

> Thanks, I see. How about this one? I use a temp variable to store sh.Data, 
> sh/ds/data are all no longer mentioned at the point when unsafe.Slice is 
> called. Do I need to use runtime.KeepAlive? 
>
> package main
>
> import (
> "fmt"
> "reflect"
> "runtime"
> "unsafe"
> )
>
> var b []byte
>
> func f(data interface{}) {
> switch ds := data.(type) {
> case []int32:
> sh := (*reflect.SliceHeader)(unsafe.Pointer())
> l := len(ds)
> d := sh.Data
> runtime.GC()
> b = unsafe.Slice((*byte)(unsafe.Pointer(d)), l*4)
> }
> // runtime.KeepAlive(data)
> }
>
> func main() {
> f([]int32{1, 2})
> runtime.GC()
> fmt.Println(b)
> }
>
> 在2021年9月23日星期四 UTC+8 上午6:11:48 写道：
>
>> On Wed, Sep 22, 2021 at 1:22 AM Cholerae Hu  wrote: 
>> > 
>> > https://play.golang.org/p/WJTH-lUukeb 
>> > 
>> > Do I need to uncomment line 23? IMHO, variable data and ds will not be 
>> used after line 16, so they can be collected in runtime.GC. But running it 
>> with gccheckmark=1 and clobberfree=1 doesn't show any problems. 
>> > 
>> > Are there any documents about the details or behavior of liveness 
>> analysis? 
>>
>> I don't see any reason why that program should need runtime.KeepAlive. 
>>
>> The local variable sh will point to data (aka ds), so the object will 
>> stay alive. This is not different than p :=  After that point, 
>> if data is no longer mentioned, then the variable data is no longer 
>> live, but the value that p points to will remain alive. 
>>
>> 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/54e0983c-da9b-487c-bcaa-6bb0051c2909n%40googlegroups.com.

[go-nuts] Re: What is up with memo.com?

[peterGo]

Ian,

I received some gmail from memo.com for a golang-nuts conversation that I 
participated in. I marked the gmail messages as spam.

Peter

On Tuesday, September 21, 2021 at 12:11:31 PM UTC-4 Ian Lance Taylor wrote:

> I'm seeing random repeats of golang-nuts messages sent from memo.com
> with bad formatting. I'm also seeing regular messages telling me that
> someone has connected with golang-nuts on memo.com, which I've been
> rejecting at the moderation stage.
>
> Does anybody know what is going on? I don't want to start marking all
> these messages as spam if they are useful in some way, but so far I
> don't see it.
>
> Thanks.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c0d397c2-f22f-4cc4-80a5-df4836ff9dd8n%40googlegroups.com.

[go-nuts] Re: The right way for golang binary to reduce iTLB cache miss

[peterGo]

rmfr,

What is your data, what is its structure, and what are the access paths and 
frequencies?

Your data is unlikely to be a randomly accessed blob of bits. Is there a 
set of Pareto access paths that you can use to order your data by access 
frequency? You want the most frequently accessed data to be adjacent. 

Peter

On Friday, September 17, 2021 at 5:09:32 AM UTC-4 rmfr wrote:

> One of our Golang applications has a very huge binary size and the size of 
> the .text segment itself in the elf is approximately *34MB*. The iTLB 
> load miss reaches about *87%* of all iTLB cache hits.
>
> Is there any advice for big Golang applications to reduce the iTLB cache 
> miss? Two solutions come to me, PGO 
>  and using 
> hugepages to load the .text segment. But they are both seem very difficult 
> to implement 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/1778bb58-e2e1-4bba-a869-1effb1e3952an%40googlegroups.com.

[go-nuts] Re: Questions about documentation of Go standard library

[peterGo]

K,

For a finite, unsigned binary number, ignoring leading zeros, how many 
binary digits (the length in bits) are needed to represent a number?

Peter
On Sunday, August 29, 2021 at 4:07:41 PM UTC-4 kziem...@gmail.com wrote:

> Thank for explanation, but I don't understand "But how many bits do you 
> need to represent 0? The question is malformed as there are no set bits in 
> the used representation of 0.". Why this is malformed questions? When I 
> think of coding 1, I think about thaking one bit with 1 inside and when it 
> goes to 0, I would take one bit with 0 inside.
>
> K.
> piątek, 27 sierpnia 2021 o 07:14:45 UTC+2 Volker Dobler napisał(a):
>
>> On Thursday, 26 August 2021 at 22:17:55 UTC+2 kziem...@gmail.com wrote:
>>
>>> Another topic. I needed to check package "math/bits" (learning about Go 
>>> can lead us in such places quite fast) and I'm confused about function 
>>> "Len(x uint) int". In its description we have (
>>> https://pkg.go.dev/math/bi...@go1.17 
>>> )
>>> BEGINNING
>>> Len returns the minimum number of bits required to represent x; the 
>>> result is 0 for x == 0.
>>> END
>>> I have no problem with using function that says 0 can be encoded in 0 
>>> bits, but it is still odd. Maybe it is connected to something done under 
>>> the hood, about which I don't know a thing? Does anyone know why this 
>>> choose was made?
>>
>>  
>> No, the description doesn't say that 0 can be encoded in 0 bits:
>> It says that Len(0) returns 0.
>> If you want Len to be a total function you must return a value for every 
>> input.
>> For most inputs the value is strictly determined by what the functions 
>> does
>> (number of bits needed to represent), so Len(9) == 3. But how many bits
>> do you need to represent 0? The question is malformed as there are no 
>> set bits in the used representation of 0. One could have declared
>> "Len(0) returns -42"
>> but this makes no sense at all. Having Len(0)==0 results in
>> Len(a) <= Len(b) if a < b without having to invent totally arbitrary
>> values for Len(0).
>>
>> You probably should not overinterpret Go's documentation.
>> This is not lyric. "the result is 0 for x == 0" has no hidden meaning.
>>
>> V.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6515eb3f-4e79-4c9c-b881-e34c1b438177n%40googlegroups.com.

Re: [go-nuts] Re: A peculiar sort problem

[peterGo]

Tobias, 

The C# code is likely using the string sort method: SORT_STRINGSORT.

winnls.h:

//STRING Sort:  hyphen and apostrophe will sort with all other symbols
//
//co-op <---  hyphen (punctuation)
//co_op <---  underscore (symbol)
//coat
//comb
//coop
//cork
//we're <---  apostrophe (punctuation)
//went
//were
//
#define SORT_STRINGSORT   0x1000  // use string sort method

InvariantCulture means independent of culture (and language). The sort 
returns the same results for the US, Germany, and Azerbaijan.

Peter

On Wednesday, July 28, 2021 at 3:49:27 AM UTC-4 klau...@schwarzvogel.de 
wrote:

> Hi! 
>
> On Wed, 28 Jul 2021, James wrote:
> > It could be that .NET is using some locale based collation. Seems like a
> > lot of machinery, but might do the trick
> > https://pkg.go.dev/golang.org/x/te...@v0.3.6/collate 
> 
>
> I have managed to get the .NET code used for sorting:
>
> Files.Sort((x, y) => string.Compare(x.RelativePath, y.RelativePath, 
> CultureInfo.InvariantCulture,
> CompareOptions.IgnoreCase));
>
> My NET-fu is weak, but I do wonder what exactly
> `CultureInfo.InvariantCulture` means in the context of sorting.
>
> I'll do some more digging, but I suspect the only way I can match
> the .NET behavior 100% is indeed x/text/collate :-/
>
> 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/1b2fefda-f84c-4573-bf3d-7f71e4ee3b7dn%40googlegroups.com.

[go-nuts] Re: Surprising benchmark result

[peterGo]

Revised results using the same input data for each iteration without a copy 
just a Filter function.

i7-7500U
name   time/op
Filter3-4  2.29µs ± 0%
Filter4-4  1.51µs ± 0%

i5-8250U
name   time/op
Filter3-8  2.30µs ± 0%
Filter4-8  1.53µs ± 0%

Peter

On Wednesday, July 7, 2021 at 11:25:11 AM UTC-4 tapi...@gmail.com wrote:

> It is found that the test file is not written correctly.
> The filtered data should be reset in each loop.
> The corrected one: https://play.golang.org/p/yJMweZLIXAz 
> 
>
> ;D
>
> On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> The code: https://play.golang.org/p/DxUj6kBqf8k
>>
>> The Filter4 function has one more assignment statement than Filter3.
>> But the benchmark result shows Filter4 is faster than Filter3.
>>
>> The result:
>>
>> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>> BenchmarkFilter3-43575656   980.2 ns/op   0 
>> B/op   0 allocs/op
>> BenchmarkFilter4-43956533   916.8 ns/op   0 
>> B/op   0 allocs/op
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/da1cc2bd-a54d-402a-ac0d-9f7300dbd207n%40googlegroups.com.

[go-nuts] Re: How to pause/restart timer in a benchmark loop?

[peterGo]

On Wednesday, July 7, 2021 at 8:01:54 PM UTC-4 tapi...@gmail.com wrote:

> Peter's solution exhausted my memory and hang my whole computer, and I 
> have to restart it.
>

Adjust the number of iterations (b.N), to accomodate your limited memory, 
For example, for 8GB use 100,000,

   $ go test filter_test.go -bench=Filter -benchmem -benchtime=10x

Peter

 
>
>>
>> On Wednesday, July 7, 2021 at 11:29:30 AM UTC-4 tapi...@gmail.com wrote:
>>
>>> This doesn't work:
>>>
>>> func BenchmarkFilter3(b *testing.B) {
>>> data := buildOrginalData()
>>> data2 := make([]int, len(data))
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> b.StopTimer()
>>> copy(data2, data)
>>> b.StartTimer()
>>> _ = Filter3(data2)
>>> }
>>> }
>>>
>>> On Wednesday, July 7, 2021 at 11:28:13 AM UTC-4 tapi...@gmail.com wrote:
>>>

 For example, I don't want the time consumed for "copy(data2, data)" 
 being counted.
 How to achieve this?

 func BenchmarkFilter3(b *testing.B) {
 data := buildOrginalData()
 data2 := make([]int, len(data))
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
 copy(data2, data)
 _ = Filter3(data2)
 }
 }

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2fc7baf5-9a9a-4cd2-98d5-a11427afa39en%40googlegroups.com.

[go-nuts] Re: How to pause/restart timer in a benchmark loop?

[peterGo]

$ go test copy_test.go -bench=. -benchmem
BenchmarkFilter3-4  358167  3209 ns/op  8192 B/op  1 allocs/op
$

package main

import "testing"

func Filter3(a []int) []int {
s := make([]int, len(a))
for i := range s {
s[i] += 42
}
return nil
}

func buildOrginalData() []int {
data := make([]int, 1024)
for i := range data {
data[i] = i
}
return data
}

func BenchmarkFilter3(b *testing.B) {
data := buildOrginalData()
copies := make([][]int, b.N)
for i := range copies {
copies[i] = make([]int, len(data))
copy(copies[i], data)
}
b.ResetTimer()
for i := 0; i < b.N; i++ {
_ = Filter3(copies[i])
}
}

https://play.golang.org/p/tzBl8VBve3D

Peter


On Wednesday, July 7, 2021 at 11:28:13 AM UTC-4 tapi...@gmail.com wrote:

>
> For example, I don't want the time consumed for "copy(data2, data)" being 
> counted.
> How to achieve this?
>
> func BenchmarkFilter3(b *testing.B) {
> data := buildOrginalData()
> data2 := make([]int, len(data))
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> copy(data2, data)
> _ = Filter3(data2)
> }
> }
>

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

[go-nuts] Re: Understanding how []byte("astring") works

[peterGo]

Amit,

Compilers implement a specification:

The Go Programming Language Specification
https://golang.org/ref/spec

Conversions

A conversion changes the type of an expression to the type specified by the 
conversion. A conversion may appear literally in the source, or it may be 
implied by the context in which an expression appears.

Conversions to and from a string type

4. Converting a value of a string type to a slice of bytes type yields a 
slice whose successive elements are the bytes of the string.

[]byte("hellø")   // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}
[]byte("")// []byte{}

MyBytes("hellø")  // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}

Peter

On Sunday, June 13, 2021 at 8:24:57 PM UTC-4 amits...@gmail.com wrote:

> Hi - My main motivation to understand this is i always had to google
> this - how to convert a string to a byte slice.
>
> Is []byte a type that has been defined in the compiler?
>
> Or, is that an internal level detail that an earlier stage (parsing)
> takes care of when the compiler sees that statement?
>
> Thanks,
> Amit
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/34100c93-63d9-43b9-a36c-bf2aaf324c21n%40googlegroups.com.

[go-nuts] Re: Surprising benchmark result

[peterGo]

i7-7500U
name   time/op
Filter3-4  1.38µs ± 0%
Filter4-4  1.39µs ± 0%

i5-8250U
name   time/op
Filter3-8  1.37µs ± 0%
Filter4-8  1.39µs ± 0%


On Monday, June 7, 2021 at 7:42:43 PM UTC-4 tapi...@gmail.com wrote:

> On Monday, June 7, 2021 at 1:01:49 PM UTC-4 peterGo wrote:
>
>> name   time/op
>> Filter3-4  1.38µs ± 0%
>> Filter4-4  1.39µs ± 0%
>>
>>
> What is your CPU model?
>  
>
>>
>> On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>>
>>>
>>> The code: https://play.golang.org/p/DxUj6kBqf8k
>>>
>>> The Filter4 function has one more assignment statement than Filter3.
>>> But the benchmark result shows Filter4 is faster than Filter3.
>>>
>>> The result:
>>>
>>> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>>> BenchmarkFilter3-43575656   980.2 ns/op   0 
>>> B/op   0 allocs/op
>>> BenchmarkFilter4-43956533   916.8 ns/op   0 
>>> B/op   0 allocs/op
>>>
>>>
>>>

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

[go-nuts] Re: Surprising benchmark result

[peterGo]

name   time/op
Filter3-4  1.38µs ± 0%
Filter4-4  1.39µs ± 0%


On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:

>
> The code: https://play.golang.org/p/DxUj6kBqf8k
>
> The Filter4 function has one more assignment statement than Filter3.
> But the benchmark result shows Filter4 is faster than Filter3.
>
> The result:
>
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> BenchmarkFilter3-43575656   980.2 ns/op   0 
> B/op   0 allocs/op
> BenchmarkFilter4-43956533   916.8 ns/op   0 
> B/op   0 allocs/op
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39f6f3f0-08bf-431a-9f02-650ad0f03d3fn%40googlegroups.com.

Re: [go-nuts] Re: Table-driven benchmarks defeat inlining

[peterGo]

Ian,

I don't know whether it is feasible. It is unnecessary.

A benchmark should be treated as a scientific experiment. If we do that 
with Paul's benchmarks and write them in scientific form, then we get the 
expected results.

$ benchstat xpt.txt
name  time/op
PopCountSimple-4  5.71ns ± 0%
PopCountSlowSimple-4  5.70ms ± 0%
PopCountAlmostSimple/BenchmarkPopCountAlmostSimple-4  5.70ns ± 0%
PopCountNearlySimple/PopCountNearlySimple-4   5.69ns ± 0%
$

Peter


On Monday, June 7, 2021 at 6:14:05 AM UTC-4 Ian Davis wrote:

> Would it be feasible for the Go tool to disable inlining and deadcode 
> elimination of code within the bodies of Benchmarks and Tests? Not the code 
> under test of course. It could be as crude as disabling these optimizations 
> for files in _test.go files.
>
>
>
> On Sun, 6 Jun 2021, at 1:33 PM, Paul S. R. Chisholm wrote:
>
> Thanks! I'd seen the "dead code elimination" comment somewhere and 
> questioned it, but not enough.
>
> If I worry about what some future Go compiler might optimize, I end up 
> worrying quite a lot! For example, could this code:
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = 0
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> hypothetically be optimized to:
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = PopCount(0x1234567890abcdef) * b.N
> }
>
> since PopCount() always returns the same value for the same argument? It 
> probably wouldn't, since that would break many existing benchmarks.
>
> Maybe more reasonably worrisome: If sum is initialized and incremented but 
> never read, could all references to it be optimized away? That's easy 
> enough to avoid, as is the optimization I worried about above:
>
> var sum = 0 // Avoid dead code elimination
> const firstInput uint64 = 0x1234567890abcdef
>
> func BenchmarkPopCountSimple(b *testing.B) {
> for i, input := 0, firstInput; i < b.N; i++ {
> sum += PopCount(input)
> input++
> }
> if sum == 0 {
> b.Error("BenchmarkPopCountSimple: sum == 0")
> }
> }
>
> Here are my new benchmark results:
>
> $ go version
> go version go1.16.5 windows/amd64
> $ go test -cpu=1 -bench=.
> goos: windows
> goarch: amd64
> pkg: gopl.io/popcount
> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
> BenchmarkPopCountSimple 2710047904.419 ns/op
> BenchmarkPopCountSlowSimple  278   4235890 ns/op
> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple 
> 2727591344.434 ns/op
> BenchmarkPopCountNearlySimple/PopCountNearlySimple 
>  1456130778.172 ns/op
> PASS
> ok  gopl.io/popcount7.061s
>
> The anomalistically-low "simple" and "almost simple" results are now more 
> reasonable, but still nearly a factor of two lower than the "nearly simple" 
> results. They're still inlining the calls, as is the "slow simple" 
> benchmark, where the "nearly simple" one isn't:
>
> $ go test -cpu=1 -bench=. -gcflags=-m 2>&1 | egrep 'inlining call to 
> PopCount'
> .\popcount_test.go:10:18: inlining call to PopCount
> .\popcount_test.go:22:19: inlining call to PopCount
> .\popcount_test.go:34:19: inlining call to PopCount
>
> Overkill, right? --PSRC
>
> P.S.: For better or worse, I discovered I can -- but shouldn't, based on 
> the feedback I got! -- get "fancy" formatting by copying from vscode and 
> pasting into Gmail.
>
>
>
> On Tuesday, June 1, 2021 at 12:01:51 PM UTC-4 peterGo wrote:
>
> Here is a more definitive reply than my original reply.
>
>
> I got as far as this
> func BenchmarkPopCountSimple(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> As you can see from the objdump, BenchmarkPopCountSimple dead code is 
> eliminated.
>
> func BenchmarkPopCountSimple(b *testing.B) {
>   0x4e38c031c9XORL CX, CX
>
> for i := 0; i < b.N; i++ {
>   0x4e38c2eb03JMP 0x4e38c7
>   0x4e38c448ffc1INCQ CX
>   0x4e38c74839889001CMPQ CX, 0x190(AX)
>   0x4e38ce7ff4JG 0x4e38c4
> }
>   0x4e38d0c3RET
> I added an additional BenchmarkPopCountAlive benchmark.
>
> var sum = 0 // Avoid dead code elimination.
>

Re: [go-nuts] Re: Is this a bug ?

[peterGo]

Jan,

The untyped constant 1 assumes the type of x, which is float64. With 
explicit types:

package main

import "fmt"

func main() {
var a int = 0
// invalid operation: float64(1) << a (shift of type float64)
var x float64 = float64(1) << a
fmt.Println(x)
}

https://play.golang.org/p/jQ4k5qrxcTu

Peter

On Thursday, June 3, 2021 at 5:52:23 AM UTC-4 Jan Mercl wrote:

> On Thu, Jun 3, 2021 at 11:21 AM Brian Candler  wrote:
> >
> > Weird. It simplifies to this: https://play.golang.org/p/OsOhRMC6kBu
>
> I think this case is WAI.
>
> From https://golang.org/ref/spec#Operators
>
> " If the left operand of a non-constant shift expression is an untyped
> constant, it is first implicitly converted to the type it would assume
> if the shift expression were replaced by its left operand alone."
>
> The OP case is strange in that the constness of the RHS operator
> somehow changes the interpretation of the above quotation
> specification, but I cannot find that it should.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b8061835-44fb-4bcf-9017-d2c9a6b58608n%40googlegroups.com.

[go-nuts] Re: embedding files in tests

[peterGo]

"it seems a bug ... it should" Why?

Why perform unnecessary disk directory I/O for a build to discover which 
files satisfy the patterns for a test? Go tools are expected to be fast.

Peter

On Wednesday, June 2, 2021 at 5:49:41 AM UTC-4 manlio@gmail.com wrote:

> Here is an example:  https://play.golang.org/p/ElnTtxHnF5I
>
> The output of `go list -json ./pkg` only reports `TestEmbedPatterns`.
> The output of `go list -json -test ./pkg` reports TestEmbedFiles for the 
> pkg package (it seems a bug, since it should also be reported without the 
> -test flag).
> The TestEmbedFiles is also present in the generated `pkg.test` package and 
> the pkg [pkg.test] package.
>
> Thanks
> Manlio
>
>
> On Wednesday, June 2, 2021 at 4:23:32 AM UTC+2 nikolay.d...@gmail.com 
> wrote:
>
>> I think the question is about `go:embed` directive in `_test.go` files 
>> will be included in builds of non-test packages, right?
>>
>> Don't know for sure, but I think:
>> - a) if you have `mypkg_test.go` and in it `package mypkg_test` then 
>> `go:embed` will not get to your non test build as the package is different
>> - b) if you have `mypkg_test.go` and in it `pakcage mypkg` then... less 
>> clear. As above referenced in original docs `_test.go` will be excluded 
>> from non test build regardless of package.
>>
>> My personal take, is to go:embed only in case a).
>>
>> Cheers,
>> On Wednesday, June 2, 2021 at 8:09:20 AM UTC+8 peterGo wrote:
>>
>>> On Tuesday, June 1, 2021 at 9:17:11 AM UTC-4 manlio@gmail.com wrote:
>>>
>>>> When a file is embedded in a test file, will the file be embedded only 
>>>> in the test binary?
>>>> The documentation says nothing about this case, but the data from go 
>>>> list seems to confirm that the file is only embedded in the test binary.
>>>>
>>>> Thanks
>>>> Manlio
>>>>
>>>
>>> The documentation seems clear to me.
>>>
>>> Package testing
>>> https://golang.org/pkg/testing/
>>>
>>> To write a new test suite, create a file whose name ends _test.go that 
>>> contains the TestXxx functions as described here. Put the file in the same 
>>> package as the one being tested. The file will be excluded from regular 
>>> package builds but will be included when the "go test" command is run. 
>>>
>>> Peter
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/30b171c0-e3c0-4ff5-a279-fd83b8ed81c9n%40googlegroups.com.

[go-nuts] Re: embedding files in tests

[peterGo]

On Tuesday, June 1, 2021 at 9:17:11 AM UTC-4 manlio@gmail.com wrote:

> When a file is embedded in a test file, will the file be embedded only in 
> the test binary?
> The documentation says nothing about this case, but the data from go list 
> seems to confirm that the file is only embedded in the test binary.
>
> Thanks
> Manlio
>

The documentation seems clear to me.

Package testing
https://golang.org/pkg/testing/

To write a new test suite, create a file whose name ends _test.go that 
contains the TestXxx functions as described here. Put the file in the same 
package as the one being tested. The file will be excluded from regular 
package builds but will be included when the "go test" command is run. 

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/09209571-86eb-4392-8803-07b7bea05174n%40googlegroups.com.

[go-nuts] Re: Table-driven benchmarks defeat inlining

[peterGo]

Here is a more definitive reply than my original reply.

I got as far as this 

func BenchmarkPopCountSimple(b *testing.B) {
sum := 0 // Avoid dead code elimination.
for i := 0; i < b.N; i++ {
sum += PopCount(0x1234567890abcdef)
}
}

As you can see from the objdump, BenchmarkPopCountSimple dead code is 
eliminated.

func BenchmarkPopCountSimple(b *testing.B) {
  0x4e38c031c9XORL CX, CX
for i := 0; i < b.N; i++ {
  0x4e38c2eb03JMP 0x4e38c7
  0x4e38c448ffc1INCQ CX
  0x4e38c74839889001CMPQ CX, 0x190(AX)
  0x4e38ce7ff4JG 0x4e38c4
}
  0x4e38d0c3RET

I added an additional BenchmarkPopCountAlive benchmark.

var sum = 0 // Avoid dead code elimination.

func BenchmarkPopCountAlive(b *testing.B) {
sum = 0
for i := 0; i < b.N; i++ {
sum += PopCount(0x1234567890abcdef)
}
}

As you can see from the objdump, BenchmarkPopCountAlive code is not 
eliminated.

For details, see the popcount.txt attachment.

Peter

On Monday, May 31, 2021 at 6:29:27 PM UTC-4 Paul S. R. Chisholm wrote:

> This is not a serious problem, but it surprised me. (By the way, how can I 
> post a message with code formatting?)
>
> I'd like to create table-driven benchmarks:
> https://blog.golang.org/subtests.
>
> To that end, I started with code from *The Go Programming Language*:
>
> // PopCount is based on an example from chapter 2 of THE GO PROGRAMMING 
> LANGUAGE.
> // Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
> // License: https://creativecommons.org/licenses/by-nc-sa/4.0/
>
> package popcount
>
> // pc[i] is the population count of i.
> var pc [256]byte
>
> func init() {
> for i := range pc {
> pc[i] = pc[i/2] + byte(i&1)
> }
> }
>
> // PopCount returns the population count (number of set bits) of x.
> func PopCount(x uint64) int {
> return int(pc[byte(x>>(0*8))] +
> pc[byte(x>>(1*8))] +
> pc[byte(x>>(2*8))] +
> pc[byte(x>>(3*8))] +
> pc[byte(x>>(4*8))] +
> pc[byte(x>>(5*8))] +
> pc[byte(x>>(6*8))] +
> pc[byte(x>>(7*8))])
> }
>
> I then wrote a simple test:
>
> // popcount_simple_test.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountSimple(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> Because I was paranoid about dead code elimination, I wrote an identical 
> test that calls the function many times (inside the loop to call it b.N 
> times, which should make no difference if the hypothetically-still-dead 
> code is being eliminated):
>
> // popcount_slow_simple_test.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountSlowSimple(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> // Exactly as before, but call the function many times.
> for j:= 0; j < 1_000_000; j++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
> }
>
> Then I wrote an "almost simple" test that uses testing.B.Run() but is 
> hardwired to call the function being benchmarked:
>
> // popcount_almost_simple_test.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountAlmostSimple(b *testing.B) {
> b.Run("BenchmarkPopCountAlmostSimple", func(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> })
> }
>
> Finally, I wrote a "nearly-simple" test that passes arguments to Run() 
> that could have come from a table:
>
> // popcount_nearly_simple.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountNearlySimple(b *testing.B) {
> f := PopCount
> name := "PopCountNearlySimple"
> b.Run(name, func(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += f(0x1234567890abcdef)
> }
> })
> }
>
> The simple and almost-simple results are nearly identical (happily, the 
> slow results are not), but the nearly-simple results are an order of 
> magnitude slower:
>
> $ go version
> go version go1.16.4 windows/amd64
> $ go test -cpu=1 -bench=.
> goos: windows
> goarch: amd64
> pkg: gopl.io/popcount
> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple
>  10   0.6102 ns/op
> BenchmarkPopCountNearlySimple/PopCountNearlySimple  
> 1949256626.197 ns/op
> BenchmarkPopCountSimple
>  10   0.5994 ns/op
> BenchmarkPopCountSlowSimple
>  1953606194 ns/op
> PASS
> ok  gopl.io/popcount4.534s
>
> After reading this article:
>
>
> https://medium.com/a-journey-with-go/go-inlining-strategy-limitation-6b6d7fc3b1be
>
> I ran:
>
> $ go test -cpu=1 -bench=. -gcflags=-m 2>&1 | egrep 'inlining call to 
> PopCount'
> 

[go-nuts] Re: Table-driven benchmarks defeat inlining

[peterGo]

I got as far as this 

func BenchmarkPopCountSimple(b *testing.B) {
sum := 0 // Avoid dead code elimination.
for i := 0; i < b.N; i++ {
sum += PopCount(0x1234567890abcdef)
}
}

I added additional benchmarks

func BenchmarkPopCountSimpleX(b *testing.B) {
sum := 0 // Does not avoid dead code elimination.
for i := 0; i < b.N; i++ {
sum += PopCount(0x1234567890abcdef)
}
}

var sum = 0 // Avoid dead code elimination.

func BenchmarkPopCountSimpleY(b *testing.B) {
sum = 0
for i := 0; i < b.N; i++ {
sum += PopCount(0x1234567890abcdef)
}
}

func BenchmarkPopCountSimpleZ(b *testing.B) {
for i := 0; i < b.N; i++ {
// Dead code elimination.
}
}

The results

$ go version
go version devel go1.17-3b770f2ccb Sun May 30 17:47:50 2021 + 
linux/amd64
$ go test -bench=BenchmarkPopCountSimple
BenchmarkPopCountSimple-410 0.3634 ns/op
BenchmarkPopCountSimpleX-4   10 0.3727 ns/op
BenchmarkPopCountSimpleY-4   508559316  2.295 ns/op
BenchmarkPopCountSimpleZ-4   10 0.3655 ns/op
$ 

It doesn't look like you have avoided dead code elimination for 
BenchmarkPopCountSimple.

Peter

On Monday, May 31, 2021 at 6:29:27 PM UTC-4 Paul S. R. Chisholm wrote:

> This is not a serious problem, but it surprised me. (By the way, how can I 
> post a message with code formatting?)
>
> I'd like to create table-driven benchmarks:
> https://blog.golang.org/subtests.
>
> To that end, I started with code from *The Go Programming Language*:
>
> // PopCount is based on an example from chapter 2 of THE GO PROGRAMMING 
> LANGUAGE.
> // Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
> // License: https://creativecommons.org/licenses/by-nc-sa/4.0/
>
> package popcount
>
> // pc[i] is the population count of i.
> var pc [256]byte
>
> func init() {
> for i := range pc {
> pc[i] = pc[i/2] + byte(i&1)
> }
> }
>
> // PopCount returns the population count (number of set bits) of x.
> func PopCount(x uint64) int {
> return int(pc[byte(x>>(0*8))] +
> pc[byte(x>>(1*8))] +
> pc[byte(x>>(2*8))] +
> pc[byte(x>>(3*8))] +
> pc[byte(x>>(4*8))] +
> pc[byte(x>>(5*8))] +
> pc[byte(x>>(6*8))] +
> pc[byte(x>>(7*8))])
> }
>
> I then wrote a simple test:
>
> // popcount_simple_test.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountSimple(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> Because I was paranoid about dead code elimination, I wrote an identical 
> test that calls the function many times (inside the loop to call it b.N 
> times, which should make no difference if the hypothetically-still-dead 
> code is being eliminated):
>
> // popcount_slow_simple_test.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountSlowSimple(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> // Exactly as before, but call the function many times.
> for j:= 0; j < 1_000_000; j++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
> }
>
> Then I wrote an "almost simple" test that uses testing.B.Run() but is 
> hardwired to call the function being benchmarked:
>
> // popcount_almost_simple_test.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountAlmostSimple(b *testing.B) {
> b.Run("BenchmarkPopCountAlmostSimple", func(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> })
> }
>
> Finally, I wrote a "nearly-simple" test that passes arguments to Run() 
> that could have come from a table:
>
> // popcount_nearly_simple.go
> package popcount
>
> import "testing"
>
> func BenchmarkPopCountNearlySimple(b *testing.B) {
> f := PopCount
> name := "PopCountNearlySimple"
> b.Run(name, func(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += f(0x1234567890abcdef)
> }
> })
> }
>
> The simple and almost-simple results are nearly identical (happily, the 
> slow results are not), but the nearly-simple results are an order of 
> magnitude slower:
>
> $ go version
> go version go1.16.4 windows/amd64
> $ go test -cpu=1 -bench=.
> goos: windows
> goarch: amd64
> pkg: gopl.io/popcount
> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple
>  10   0.6102 ns/op
> BenchmarkPopCountNearlySimple/PopCountNearlySimple  
> 1949256626.197 ns/op
> BenchmarkPopCountSimple
>  10   0.5994 ns/op
> BenchmarkPopCountSlowSimple
>  1953606194 ns/op
> PASS
> ok  gopl.io/popcount4.534s
>
> After reading this article:
>
>
> 

[go-nuts] Re: parameter name a of fmt package

[peterGo]

The Go fmt Print functions use the C printf model for formatted output. The 
usual terminology is argument. 

---

The C Programming Language
https://en.wikipedia.org/wiki/The_C_Programming_Language

B.1.2 Formatted Output

The printf functions provide formatted output conversion.

int fprintf(FILE *stream, const char *format, ...)

fprintf converts and writes output to stream under the control of format . 
The return value
is the number of characters written, or negative if an error occurred.

The format string contains two types of objects: ordinary characters, which 
are copied to the
output stream, and conversion specifications, each of which causes 
conversion and printing of
the next successive argument to fprintf.

---

POSIX
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html

NAME

printf - write formatted output

SYNOPSIS

printf format [argument...]

DESCRIPTION

The printf utility shall write formatted operands to the standard output. 
The argument operands shall be formatted under control of the format 
operand.

---

Linux
https://linux.die.net/man/1/printf

printf(1) — Linux manual page
 
NAME

printf - format and print data

SYNOPSIS

printf FORMAT [ARGUMENT]...

DESCRIPTION 

Print ARGUMENT(s) according to FORMAT.

---

Peter

On Tuesday, May 25, 2021 at 4:14:50 AM UTC-4 Delta Echo wrote:

> What does the parameter name `a` stands for in fmt package's functions?
>
> like,
>
> func Printf(format string, a ...interface{}) (n int, err error)
>
> Is it argument?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/28a09f9c-6124-40fd-bf06-79b326fc9cb8n%40googlegroups.com.

[go-nuts] Re: Strange benchmark results

[peterGo]

The Go optimizing gc compiler and runtime are working as intended. The 
results are not strange. Nothing is broken. 

Peter

On Sunday, May 16, 2021 at 3:07:17 AM UTC-4 tapi...@gmail.com wrote:

> > you don't provide the Go version,
>
> My Go version is Go 1.16.3. (BTW, "go test" really should print Go version 
> in the first line).
>
> > you don't provide memory allocation statistics,
>
> There are no surprises in memory allocation statistics so I didn't mention 
> them.
>
> > you only provide results for a single data point.
>
> There are no surprises for small Ns. So I I didn't provide the results for 
> them.
>
> > I am unable reproduce your result.
>
> At least, you exactly reproduced my first observation: if N is large 
> enough, the one line implementations are fast as the others.
>
> And you partially reproduced my second observation: the InsertOneline 
> implementations 
> run faster for odd Ns than even Ns for large Ns.
>
>
> On Saturday, May 15, 2021 at 11:49:38 AM UTC-4 peterGo wrote:
>
>> For your sliceinsert microbenchmarks, you don't provide the Go version, 
>> you don't provide memory allocation statistics, and you only provide 
>> results for a single data point.
>>
>> My results for several values of N:
>>
>> https://play.golang.org/p/WuKmIy_jY20
>>
>> There are significant differences in CPU performance for different values 
>> of N, ranging from 1:1 to 2:1 for append versus precise implementations.
>>
>> I am unable reproduce your result.
>>
>> Peter
>>
>> On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>>
>>>
>>> package main
>>>
>>> import "testing"
>>>
>>> const N = 1615119
>>> // It is strange that if N is large enough,
>>> // the one line implementations are fast as the others.
>>> // And if N is odd number, the InsertOneline_Disassemble
>>> // implementation is about 10% faster than the others.
>>>
>>> func init() {
>>> println(" N =", N)
>>> }
>>>
>>> func InsertOneline(s []int, k int, vs ...int) []int {
>>> return append(s[:k], append(vs, s[k:]...)...)
>>> }
>>>
>>> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
>>> z := append(vs, s[k:]...)
>>> return append(s[:k], z...)
>>> }
>>>
>>> func InsertVerbose(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := make([]int, len(s) + len(vs))
>>> copy(s2, s[:k])
>>> copy(s2[k:], vs)
>>> copy(s2[k+len(vs):], s[k:])
>>> return s2
>>> }
>>>
>>>
>>> func InsertVerbose_b(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := make([]int, 0, len(s) + len(vs))
>>> s2 = append(s2, s[:k]...)
>>> s2 = append(s2, vs...)
>>> s2 = append(s2, s[k:]...)
>>> return s2
>>> }
>>>
>>> func InsertVerbose_c(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
>>> s2 = append(s2, s[:k]...)
>>> s2 = append(s2, vs...)
>>> s2 = append(s2, s[k:]...)
>>> return s2
>>> }
>>>
>>> var s1 []int
>>> func Benchmark_InsertOneline(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/5
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s1 = InsertOneline(x, k, y...)
>>> }
>>> }
>>>
>>> var s1b []int
>>> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/2
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s1b = InsertOneline_D

[go-nuts] Re: Is the escape analysis reports accurate?

[peterGo]

Here, and elsewhere (Strange benchmark results), if you not sure what is 
going on then you say that it must be weird, strange, an error, inaccurate, 
and so on. The problem appears to be that you are not taking into account 
that the Go gc and gccgo compilers are optimizing compilers.

For your example,

https://play.golang.org/p/3Cst23vNkKI

$ go version
go version devel go1.17-cca23a7373 Sat May 22 00:51:17 2021 + 
linux/amd64
$ go run -gcflags='-m -m' tl.2.go
./tl.2.go:18:6: can inline g with cost 8 as: func() []T { var ts []T; ts = 
make([]T, N); return ts }
./tl.2.go:9:6: can inline main with cost 28 as: func() { var r []T; r = 
make([]T, N); println(r[i]); var r1 []T; r1 = g(); println(r1[i]) }
./tl.2.go:13:15: inlining call to g func() []T { var ts []T; ts = make([]T, 
N); return ts }
./tl.2.go:10:17: make([]T, N) does not escape
./tl.2.go:13:15: make([]T, N) does not escape
./tl.2.go:19:18: make([]T, N) escapes to heap:
./tl.2.go:19:18:   flow: ts = &{storage for make([]T, N)}:
./tl.2.go:19:18: from make([]T, N) (spill) at ./tl.2.go:19:18
./tl.2.go:19:18: from ts = make([]T, N) (assign) at ./tl.2.go:19:9
./tl.2.go:19:18:   flow: ~r0 = ts:
./tl.2.go:19:18: from return ts (return) at ./tl.2.go:20:5
./tl.2.go:19:18: make([]T, N) escapes to heap


On Sunday, May 23, 2021 at 5:01:38 AM UTC-4 tapi...@gmail.com wrote:

> And how to interpret the conflicting messages for the following program?
>
> package main
>
> type T int
>
> const N = 1<<12
> var i = N - 1
>
>
> func main() {
> var r = make([]T, N) // make([]T, N) does not escape
> println(r[i])
> 
> var r1 = g() // make([]T, N) does not escape
> println(r1[i])
> 
> }
>
> func g() []T {
> var ts = make([]T, N) // make([]T, N) escapes to heap
> return ts
> }
>
> On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 tapi...@gmail.com wrote:
>
>> In the following code, "make([]T, n)" is reported as escaped.
>> But does it really always escape at run time?
>> Does the report just mean "make([]T, n) possibly escapes to heap"?
>>
>> package main
>>
>> type T int
>>
>> const K = 1<<13
>> const N = 1<<12
>> var n = N
>> var i = n-1
>>
>> func main() {
>> var r = make([]T, N) // make([]T, N) does not escape
>> println(r[i])
>> 
>> var r2 = make([]T, n) // make([]T, n) escapes to heap
>> println(r2[i])
>> 
>> var r3 = make([]T, K) // make([]T, K) escapes to heap
>> println(r3[i])
>> }
>>
>

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

[go-nuts] Re: Is the escape analysis reports accurate?

[peterGo]

Here, and elsewhere (Strange benchmark results), if you not sure what is 
going on then you say that it must be weird, strange, an error, inaccurate, 
and so on. The problem appears to be that you are not taking into account 
that the Go gc and gccgo compilers are optimizing compilers.

For your example,

https://play.golang.org/p/SuQHjzALWe0

$ go version
go version devel go1.17-cca23a7373 Sat May 22 00:51:17 2021 + 
linux/amd64
$ go run -gcflags='-m -m' tl.1.go
# command-line-arguments
./tl.1.go:11:6: can inline main with cost 30 as: func() { var r []T; r = 
make([]T, N); println(r[i]); var r2 []T; r2 = make([]T, n); println(r2[i]); 
var r3 []T; r3 = make([]T, K); println(r3[i]) }
./tl.1.go:9:5: can inline init with cost 5 as: func() { i = n - 1 }
./tl.1.go:15:15: make([]T, n) escapes to heap:
./tl.1.go:15:15:   flow: {heap} = &{storage for make([]T, n)}:
./tl.1.go:15:15: from make([]T, n) (non-constant size) at 
./tl.1.go:15:15
./tl.1.go:18:15: make([]T, K) escapes to heap:
./tl.1.go:18:15:   flow: {heap} = &{storage for make([]T, K)}:
./tl.1.go:18:15: from make([]T, K) (too large for stack) at 
./tl.1.go:18:15
./tl.1.go:12:14: make([]T, N) does not escape
./tl.1.go:15:15: make([]T, n) escapes to heap
./tl.1.go:18:15: make([]T, K) escapes to heap


On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 tapi...@gmail.com wrote:

> In the following code, "make([]T, n)" is reported as escaped.
> But does it really always escape at run time?
> Does the report just mean "make([]T, n) possibly escapes to heap"?
>
> package main
>
> type T int
>
> const K = 1<<13
> const N = 1<<12
> var n = N
> var i = n-1
>
> func main() {
> var r = make([]T, N) // make([]T, N) does not escape
> println(r[i])
> 
> var r2 = make([]T, n) // make([]T, n) escapes to heap
> println(r2[i])
> 
> var r3 = make([]T, K) // make([]T, K) escapes to heap
> println(r3[i])
> }
>

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

Re: [go-nuts] Re: String to uint32

[peterGo]

On Saturday, May 22, 2021 at 6:36:30 PM UTC-4 Ian Lance Taylor wrote:

> On Sat, May 22, 2021 at 3:26 PM Mosleh Saeidi  
> wrote: 
> > 
> > so what is the solution, I have a variable type is uint32, and now want 
> to convert a string to that variable ? 
>
> To convert a string to an integer see 
> https://golang.org/pkg/strconv/#ParseInt . 
>
> Ian 
>


For unsigned integers, s/ParseInt/ 
ParseUint/ 


Peter
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bc10f9b0-32a5-4be5-af58-5d95f1bc88cdn%40googlegroups.com.

[go-nuts] Re: String to uint32

[peterGo]

On Saturday, May 22, 2021 at 6:26:29 PM UTC-4 Mosleh Saeidi wrote:

> so what is the solution, I have a variable type is uint32, and now want to 
> convert a string to that variable ?
>


https://play.golang.org/p/429NO4g-yte

Peter

 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/630ffecd-84a3-43eb-928f-ae7838deb71bn%40googlegroups.com.

[go-nuts] Re: Strange benchmark results

[peterGo]

For your sliceinsert microbenchmarks, you don't provide the Go version, you 
don't provide memory allocation statistics, and you only provide results 
for a single data point.

My results for several values of N:

https://play.golang.org/p/WuKmIy_jY20

There are significant differences in CPU performance for different values 
of N, ranging from 1:1 to 2:1 for append versus precise implementations.

I am unable reproduce your result.

Peter

On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:

>
> package main
>
> import "testing"
>
> const N = 1615119
> // It is strange that if N is large enough,
> // the one line implementations are fast as the others.
> // And if N is odd number, the InsertOneline_Disassemble
> // implementation is about 10% faster than the others.
>
> func init() {
> println(" N =", N)
> }
>
> func InsertOneline(s []int, k int, vs ...int) []int {
> return append(s[:k], append(vs, s[k:]...)...)
> }
>
> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
> z := append(vs, s[k:]...)
> return append(s[:k], z...)
> }
>
> func InsertVerbose(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, len(s) + len(vs))
> copy(s2, s[:k])
> copy(s2[k:], vs)
> copy(s2[k+len(vs):], s[k:])
> return s2
> }
>
>
> func InsertVerbose_b(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, 0, len(s) + len(vs))
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> func InsertVerbose_c(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> var s1 []int
> func Benchmark_InsertOneline(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/5
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1 = InsertOneline(x, k, y...)
> }
> }
>
> var s1b []int
> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1b = InsertOneline_Disassemble(x, k, y...)
> }
> }
>
> var s2 []int
> func Benchmark_InsertVerbose(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s2 = InsertVerbose(x, k, y...)
> }
> }
>
> var s3 []int
> func Benchmark_InsertVerbose_b(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s3 = InsertVerbose_b(x, k, y...)
> }
> }
>
> var s4 []int
> func Benchmark_InsertVerbose_c(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s4 = InsertVerbose_c(x, k, y...)
> }
> }
>
>
> The result:
>
> $ go test -bench=. -benchtime=3s
>  N = 1615119
> goos: linux
> goarch: amd64
> pkg: a.y/bench/sliceinsert
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> Benchmark_InsertOneline-4693   4741509 ns/op
> Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
> Benchmark_InsertVerbose-4764   4627334 ns/op
> Benchmark_InsertVerbose_b-4  769   4958537 ns/op
> Benchmark_InsertVerbose_c-4  661   4855514 ns/op
>

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

[go-nuts] Re: Strange benchmark results

[peterGo]

My results:

https://play.golang.org/p/o2cGAcpNMkX

I can't reproduce your results.

Peter

On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:

>
> package main
>
> import "testing"
>
> const N = 1615119
> // It is strange that if N is large enough,
> // the one line implementations are fast as the others.
> // And if N is odd number, the InsertOneline_Disassemble
> // implementation is about 10% faster than the others.
>
> func init() {
> println(" N =", N)
> }
>
> func InsertOneline(s []int, k int, vs ...int) []int {
> return append(s[:k], append(vs, s[k:]...)...)
> }
>
> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
> z := append(vs, s[k:]...)
> return append(s[:k], z...)
> }
>
> func InsertVerbose(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, len(s) + len(vs))
> copy(s2, s[:k])
> copy(s2[k:], vs)
> copy(s2[k+len(vs):], s[k:])
> return s2
> }
>
>
> func InsertVerbose_b(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, 0, len(s) + len(vs))
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> func InsertVerbose_c(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> var s1 []int
> func Benchmark_InsertOneline(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/5
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1 = InsertOneline(x, k, y...)
> }
> }
>
> var s1b []int
> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1b = InsertOneline_Disassemble(x, k, y...)
> }
> }
>
> var s2 []int
> func Benchmark_InsertVerbose(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s2 = InsertVerbose(x, k, y...)
> }
> }
>
> var s3 []int
> func Benchmark_InsertVerbose_b(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s3 = InsertVerbose_b(x, k, y...)
> }
> }
>
> var s4 []int
> func Benchmark_InsertVerbose_c(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s4 = InsertVerbose_c(x, k, y...)
> }
> }
>
>
> The result:
>
> $ go test -bench=. -benchtime=3s
>  N = 1615119
> goos: linux
> goarch: amd64
> pkg: a.y/bench/sliceinsert
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> Benchmark_InsertOneline-4693   4741509 ns/op
> Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
> Benchmark_InsertVerbose-4764   4627334 ns/op
> Benchmark_InsertVerbose_b-4  769   4958537 ns/op
> Benchmark_InsertVerbose_c-4  661   4855514 ns/op
>

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

[go-nuts] Re: Reflect on Rust for Android and Linux kernel support

[peterGo]

On Sunday, May 9, 2021 at 3:40:52 AM UTC-4 Uli Kunitz wrote:

>
> I have only read about researchers who wrote a whole kernel in Go. 
>
> UIi
>

The benefits and costs of writing a POSIX kernel in a high-level language
Cody Cutler, M. Frans Kaashoek, and Robert T. Morris, MIT CSAIL
https://www.usenix.org/conference/osdi18/presentation/cutler
https://pdos.csail.mit.edu/papers/biscuit.pdf

Biscuit research OS
Biscuit is a monolithic, POSIX-subset operating system kernel in Go for 
x86-64 CPUs. It was written to study the performance trade-offs of using a 
high-level language with garbage collection to implement a kernel with a 
common style of architecture.
https://github.com/mit-pdos/biscuit

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1800c21d-7898-413c-87a5-ca6e6d9b0d90n%40googlegroups.com.

[go-nuts] Re: Security issue in

[peterGo]

Manlio,

FYI:

Know, Prevent, Fix: A framework for shifting the discussion around 
vulnerabilities in open source
Rob Pike, Eric Brewer, Abhishek Arya, Anne Bertucio and Kim Lewandowski 
https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html

Surviving software dependencies
Russ Cox
https://dl.acm.org/doi/10.1145/3347446

Peter

On Friday, May 7, 2021 at 5:10:48 AM UTC-4 manlio@gmail.com wrote:

> I think the problem here is not only the lack of a vulnerability database 
> for go, but the fact that a lot of people use a module where only one 
> person (the owner) has access to the repository.
>
> Maybe it is time for a new site like gopkg.in, where each module has one 
> or more maintainer and there is a review process similar to the one used 
> for the development of Go.
>
> Manlio
> On Friday, May 7, 2021 at 9:05:22 AM UTC+2 christoph...@gmail.com wrote:
>
>> I just became aware of a security problem in the package 
>> https://github.com/satori/go.uuid  through 
>> this reddit thread :
>> https://www.reddit.com/r/golang/comments/n6bnsh/cve20213538_issued_for_latest_release_of/?utm_source=share_medium=ios_app_name=iossmf
>>
>> The issue for the security problem is here: 
>> https://github.com/satori/go.uuid/issues/73 
>> 
>>
>> There is a CVE identifier for this security problem: 
>> https://github.com/satori/go.uuid/issues/115
>> It is 3 years old and hasn't been resolved. 
>>
>> The problem is that the owner of the package has apparently vanished.
>>
>> I report this problem here because this package is used by more than 20 
>> thousand go packages or programs (e.g. gogs). (
>> https://pkg.go.dev/github.com/satori/go.uuid?tab=importedby)
>>
>> Now that we have this fantastic functionality of modules, I would like to 
>> know if we could imagine that the go tools would issue a warning if an 
>> imported package has a security issue reported in CVE. I have seen that 
>> there is a github tool to do that, but we don't get these notifications by 
>> default. 
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c32e20a1-11a0-4253-8fb6-5841aea32429n%40googlegroups.com.

Re: [go-nuts] Why fmt.Println(math.Sqrt2) gives ...0951 not ...0950?

[peterGo]

On Saturday, May 1, 2021 at 10:12:36 AM UTC-4 kziem...@gmail.com wrote:

> Can you guide me to some materials about const in Go? 
>
> Kamil
>
>>
>>
The Go Blog: Constants
https://blog.golang.org/constants

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4f22816b-1dc0-41b9-9a2d-4aad10ee76ean%40googlegroups.com.

[go-nuts] Re: encoding/xml expose line

[peterGo]

Patrick,

A similar proposal has just been accepted for encoding/csv:

encoding/csv: add the ability to get the line number of a record #44221
https://github.com/golang/go/issues/44221

Peter

On Saturday, April 17, 2021 at 12:45:11 PM UTC-4 Patrick wrote:

> I have my own programming language (a bit similar to XSLT) and the XML can 
> be valid but there still might be an error such as an uninitialised 
> variable. I'd like to present feedback to the user on which line the error 
> occurred.
>
> I am thinking about opening an issue on GitHub and providing a (simple) 
> patch.
>
> Patrick
>

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

[go-nuts] Re: encoding/csv: getting a line number of current record when using csv.Reader

[peterGo]

Dan,

For Go 1.17:

encoding/csv: add the ability to get the line number of a record #44221
https://github.com/golang/go/issues/44221

Peter

On Thursday, April 8, 2021 at 12:36:27 PM UTC-4 yodanj...@gmail.com wrote:

> My need is similar to issue #26679 but not the same.
>
> I am using 1.15.8
>
> I have a need for the "current line number" when reading a csv file (with 
> Reader.Read() ) so that I can report errors in the data (not a csv 
> parsing error but errors in the data in the csv file).  In my case, a 
> comment character is being used to allow my user to provide comments in the 
> file for easier maintainability of their csv data.  Because of comments in 
> the file the record number and line number are not the same so any 
> reporting of errors to my user cannot point to any specific line number in 
> the file for the data error ... I have to either give info on the record to 
> my user or tell them the non-commented line number (neither being a 
> user-friendly option as they have to look through the file to see where the 
> real error is instead of going to a specific line number).
>
> Any way to get the true (starting) line number of the current record as a 
> file is being read using the Reader.Read() function?
>
> Thanks
> Dan
>
>

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

[go-nuts] Re: these code line seens never reachable, can it be deleted?

[peterGo]

Why did you ignore other similar occurences?

:~/go/src/cmd/internal/obj$ grep -r 'if false {' *
arm/asm5.go:if false { /*debug['O']*/
arm/asm5.go:if false { /*debug['P']*/
arm/asm5.go:if false { /*debug['G']*/
arm64/asm7.go:if false {
arm64/asm7.go:if false { /*debug['P']*/
arm64/obj7.go:if false {
ppc64/obj9.go:if false {
x86/asm6.go:if false { /* debug['a'] > 1 */
x86/asm6.go:if false { /* debug['Q'] */
x86/asm6.go:if false { /* debug['Q'] */
:~/go/src/cmd/internal/obj$ 

Peter

On Tuesday, April 6, 2021 at 7:55:33 AM UTC-4 cuiw...@gmail.com wrote:

>
> https://github.com/golang/go/blob/master/src/cmd/internal/obj/x86/asm6.go#L2192-L2210
> if it can be delete i will send a pr!
>

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