Re: [go-nuts] How to convert a net.Addr into a netip.AddrPort ?

[christoph...@gmail.com]

Solved the conversion question: 

conn, err := net.DialUDP("udp", nil, remoteAddr)
localAddr := conn.LocalAddr().(*net.UDPAddr)

Le dimanche 24 décembre 2023 à 19:29:50 UTC+1, Robert Engels a écrit :

> github.com/robaho/go-trader has udp multicast support with both server 
> and client code
>
> On Dec 24, 2023, at 11:05 AM, christoph...@gmail.com <
> christoph...@gmail.com> wrote:
>
> 
>
> Hello,
>
> I'm developping a UDP client server program. Everything is clear on the 
> server side. 
>
> I'm just a bit confused with the client side. 
>
> In C we can specify the network address and set the port to 0 so that a 
> free port is picked. Apparently we can't do that with the net API. 
>
> The client must use net.DialUDP() to get a connection it can use to send 
> messages to the remote server. If the laddr is set to nil, net.DialUDP will 
> pick the local address and port. We thus can't pick the local address and 
> let the system pick the port. It'll pick both. I assume it is to solve the 
> IPv4 and IPv6 coexistence. 
>
> The returned net.UDPAddr has a LocalAddress() method returning a net.Addr. 
> How can I convert this net.Addr into a netip.AddrPort ?  I can only get a 
> string version of the address. Are we expected to use the ResolveUDP to 
> convert the string into the UDPAddr ? 
>
>  
>
> -- 
> You received this message because you are subscribed 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/f248a95d-ac11-4e9f-81d8-d53d047d24ffn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/f248a95d-ac11-4e9f-81d8-d53d047d24ffn%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/71d25f4a-7da5-47af-9c28-d889ac91cec3n%40googlegroups.com.

[go-nuts] How to convert a net.Addr into a netip.AddrPort ?

[christoph...@gmail.com]

Hello,

I'm developping a UDP client server program. Everything is clear on the 
server side. 

I'm just a bit confused with the client side. 

In C we can specify the network address and set the port to 0 so that a 
free port is picked. Apparently we can't do that with the net API. 

The client must use net.DialUDP() to get a connection it can use to send 
messages to the remote server. If the laddr is set to nil, net.DialUDP will 
pick the local address and port. We thus can't pick the local address and 
let the system pick the port. It'll pick both. I assume it is to solve the 
IPv4 and IPv6 coexistence. 

The returned net.UDPAddr has a LocalAddress() method returning a net.Addr. 
How can I convert this net.Addr into a netip.AddrPort ?  I can only get a 
string version of the address. Are we expected to use the ResolveUDP to 
convert the string into the UDPAddr ? 

 

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

[go-nuts] Encrypting a small secret using curve25519

[christoph...@gmail.com]

Hello, 

I noticed that the go standard library only support ed25519 signing 
(https://pkg.go.dev/crypto/ed25519@go1.21.1). 

I would need to encrypt a small secret with the public key of the receiver 
so that he is the only one able to decrypt it with its private key. The 
small secret would typically be a random symmetric key used to encrypt the 
possibly long message.  

The only solution I found is to use nacl.Box 
(https://pkg.go.dev/golang.org/x/crypto/nacl/box). Why is it so ? 

Are there alternative reliable go packages I could use ? I'll use only a 
pure Go package, not a libsodium wrapper package. 


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

[go-nuts] Interface() method of reflect.Value sometimes allocates, sometimes not

[christoph...@gmail.com]

I'm implementing a value encoder similar to gob. While bench-marking my 
code against gob, I noticed some unexpected memory allocations with a 
particular type of data.

See this minimal code example in the go playground 
https://go.dev/play/p/4rm-kCtD274

There is a simple function foo() receiving a []uint reflect.Value as input. 
It calls the Interface() method to get back a []uint value that it can then 
use. 

When the input value is a []uint, the Interface() method doesn't allocate. 

When the input value is a []uint of a [][]uint (a matrix), the Interface() 
method allocates the slice header on the heap. 

I was wondering if this is just a limitation of optimization or if there 
was a constrain imposing the allocation.

In my code and gob's code (see the helpers functions in enc_helpers.go) the 
slice returned by Interface() is only used locally. 


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

[go-nuts] Re: delve crashes in presence of a circular reference variable

[christoph...@gmail.com]

I should have added that the debugger crashes when it reaches a break point 
after the p =  instruction or steps over this instruction. It doesn't 
crash when there is no break point.

Le vendredi 23 juin 2023 à 10:38:32 UTC+2, christoph...@gmail.com a écrit :

> Here is the minimal example code causing delve 1.20.2 to crash with a 
> stack overflow
>
> func TestExample(t *testing.T)  {
> type pptr *pptr
> var p pptr
> p = 
> t.Error("hello")
> }
>
> Here is the stack trace
>
> goroutine 6 [running]:
> runtime.deductAssistCredit(0x108?)
> /usr/local/go/src/runtime/malloc.go:1201 +0x7b fp=0xc021380360 
> sp=0xc021380358 pc=0x40f8db
> runtime.mallocgc(0x108, 0xa9d2e0, 0x1)
> /usr/local/go/src/runtime/malloc.go:932 +0xd0 fp=0xc0213803c8 
> sp=0xc021380360 pc=0x40f0d0
> runtime.newobject(0x7fa133558108?)
> /usr/local/go/src/runtime/malloc.go:1254 +0x27 fp=0xc0213803f0 
> sp=0xc0213803c8 pc=0x40f9e7
> github.com/go-delve/delve/pkg/proc.newVariable({0x0 
> <http://github.com/go-delve/delve/pkg/proc.newVariable(%7B0x0>, 0x0}, 
> 0xc000104e48, {0xb98be8?, 0xc000e7a6c0?}, 0xc0002fc2c0, {0xb93350?, 
> 0xc0002b8ac0})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:635 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:635> 
> +0x2d0 fp=0xc021380498 sp=0xc0213803f0 pc=0x7607f0
> github.com/go-delve/delve/pkg/proc.(*Variable).newVariable(...)
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:606 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:606>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadPtr(0xc01cfae120)
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1266 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1266> 
> +0x11b fp=0xc021380510 sp=0xc021380498 pc=0x764ddb
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfae120,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1303 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1303> 
> +0xad2 fp=0xc021380708 sp=0xc021380510 pc=0x765b72
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfade60,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1311 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311> 
> +0xb45 fp=0xc021380900 sp=0xc021380708 pc=0x765be5
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfadc20,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1311 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311> 
> +0xb45 fp=0xc021380af8 sp=0xc021380900 pc=0x765be5
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad9e0,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1311 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311> 
> +0xb45 fp=0xc021380cf0 sp=0xc021380af8 pc=0x765be5
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad7a0,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1311 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311> 
> +0xb45 fp=0xc021380ee8 sp=0xc021380cf0 pc=0x765be5
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad560,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1311 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311> 
> +0xb45 fp=0xc0213810e0 sp=0xc021380ee8 pc=0x765be5
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad320,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> /home/meessen/go/pkg/mod/
> github.com/go-delve/de...@v1.20.2/pkg/proc/variables.go:1311 
> <http://github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311> 
> +0xb45 fp=0xc0213812d8 sp=0xc0213810e0 pc=0x765be5
>
> github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad0e0,
>  
> 0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
> . . .
>
>

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

[go-nuts] delve crashes in presence of a circular reference variable

[christoph...@gmail.com]

Here is the minimal example code causing delve 1.20.2 to crash with a stack 
overflow

func TestExample(t *testing.T)  {
type pptr *pptr
var p pptr
p = 
t.Error("hello")
}

Here is the stack trace

goroutine 6 [running]:
runtime.deductAssistCredit(0x108?)
/usr/local/go/src/runtime/malloc.go:1201 +0x7b fp=0xc021380360 
sp=0xc021380358 pc=0x40f8db
runtime.mallocgc(0x108, 0xa9d2e0, 0x1)
/usr/local/go/src/runtime/malloc.go:932 +0xd0 fp=0xc0213803c8 
sp=0xc021380360 pc=0x40f0d0
runtime.newobject(0x7fa133558108?)
/usr/local/go/src/runtime/malloc.go:1254 +0x27 fp=0xc0213803f0 
sp=0xc0213803c8 pc=0x40f9e7
github.com/go-delve/delve/pkg/proc.newVariable({0x0, 0x0}, 0xc000104e48, 
{0xb98be8?, 0xc000e7a6c0?}, 0xc0002fc2c0, {0xb93350?, 0xc0002b8ac0})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:635
 
+0x2d0 fp=0xc021380498 sp=0xc0213803f0 pc=0x7607f0
github.com/go-delve/delve/pkg/proc.(*Variable).newVariable(...)
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:606
github.com/go-delve/delve/pkg/proc.(*Variable).loadPtr(0xc01cfae120)
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1266
 
+0x11b fp=0xc021380510 sp=0xc021380498 pc=0x764ddb
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfae120, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1303
 
+0xad2 fp=0xc021380708 sp=0xc021380510 pc=0x765b72
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfade60, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311
 
+0xb45 fp=0xc021380900 sp=0xc021380708 pc=0x765be5
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfadc20, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311
 
+0xb45 fp=0xc021380af8 sp=0xc021380900 pc=0x765be5
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad9e0, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311
 
+0xb45 fp=0xc021380cf0 sp=0xc021380af8 pc=0x765be5
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad7a0, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311
 
+0xb45 fp=0xc021380ee8 sp=0xc021380cf0 pc=0x765be5
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad560, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311
 
+0xb45 fp=0xc0213810e0 sp=0xc021380ee8 pc=0x765be5
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad320, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
/home/meessen/go/pkg/mod/github.com/go-delve/delve@v1.20.2/pkg/proc/variables.go:1311
 
+0xb45 fp=0xc0213812d8 sp=0xc0213810e0 pc=0x765be5
github.com/go-delve/delve/pkg/proc.(*Variable).loadValueInternal(0xc01cfad0e0, 
0x0, {0x1, 0x1, 0x200, 0x40, 0x, 0x1900})
. . .

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

[go-nuts] Why is reflect.CanAddr() returning false in this case ?

[christoph...@gmail.com]

I'm trying to get the uintptr address of a value p for which I have the 
reflect.Value so that I can compare it with the value obtained with 
v.Pointer() when p is a pointer. 

Here is a simple recursive pointer example code showing what happens: 
https://go.dev/play/p/pST8DierbXS

It is a pointer to itself defined like this:

type pptr *pptr
var p pptr
p = 

The problem is that reflect.ValueOf(p).CanAddr() unexpectedly returns false.

I would like to test if reflect.ValueOf(p).Addr().Pointer() == 
reflect.ValueOf(p).Pointer()

I have a similar problem when p is a struct with a pointer field to itself. 
CanAddr() returns false: https://go.dev/play/p/Oygg5X8Royr




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

[go-nuts] Unexpected circular type definition limitation

[christoph...@gmail.com]

It is possible to define two structures globally with mutual type 
dependency as this:

type A struct {
B []B
}

type B struct {
A A[]
}

but I just noticed that we can't do that inside a function:

func Foo() {
type A struct {
B []B
}

type B struct {
   A A[]
}
}

Is there a reason for this limitation ? 

I would like to use this inside a test function to avoid polluting the name 
space and so that I can reuse these simple type names for different tests 
with slightly different definitions. 


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

[go-nuts] How to detect a reflect.Value of nil ?

[christoph...@gmail.com]

I have a method that receives a reflect.Value as input argument. 

When the method is given the argument reflect.ValueOf(nil), the methods 
Type(), IsNil(), or IsZero() panic. For instance, when I call the method 
IsZero() I see the panic message "panic: reflect: call of 
reflect.Value.IsZero on zero Value " :)

Is there a way to detect that the method was given a reflect.ValueOf(nil) ? 

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

[go-nuts] Re: Installing a package with an associated command

[christoph...@gmail.com]

Indeed, it works. What if there are multiple binaries to install ? Does the 
user have to type the full package name for each program he want to install 
?

Isn’t there an equivalent to "go install ./..." that installs everything in 
one simple and short instruction ? 

Le mercredi 25 mai 2022 à 08:40:04 UTC+2, Volker Dobler a écrit :

> If you want the command to be installed: Why don't you install
> _the_ _command_ with 
> go install https://github.com/chmike/clog/cmd/clogClr@latest
> ? (Note that there is no need to install the package.)
>
> V.
>
> On Wednesday, 25 May 2022 at 08:13:58 UTC+2 christoph...@gmail.com wrote:
>
>> I have a small package (https://github.com/chmike/clog) that also 
>> contains a command in the cmd subdirectory (clogClr). How do I install 
>> the clog package and the command ? 
>>
>> When I execute "go install github.com/chmike/clog@latest" I get the 
>> error message that it is not a main package. When I use go get that package 
>> is installed, but not the command (clogClr). 
>>
>> I understand that for security purpose installing a package should not 
>> automatically install an executable binary. 
>>
>> For now I do a git clone and a "go install ./...". It's fine for me, not 
>> for an end user. I assume there is a better way. 
>>
>

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

[go-nuts] Installing a package with an associated command

[christoph...@gmail.com]

I have a small package (https://github.com/chmike/clog) that also contains 
a command in the cmd subdirectory (clogClr). How do I install the clog 
package and the command ? 

When I execute "go install github.com/chmike/clog@latest" I get the error 
message that it is not a main package. When I use go get that package is 
installed, but not the command (clogClr). 

I understand that for security purpose installing a package should not 
automatically install an executable binary. 

For now I do a git clone and a "go install ./...". It's fine for me, not 
for an end user. I assume there is a better way. 

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

Re: [go-nuts] Re: Can’t view golang source when clicking on method name in a pkg.go.dev

[christoph...@gmail.com]

Thank you very much. I disabled the DuckDuckGo Privacy Essentials 
 
extension and it now works. 

I also noticed that when I do a duckduckgo search for golang packages, that 
the pkg.go.dev pages are low ranked if present. I'll stop using duckduckgo. 


Le mardi 26 avril 2022 à 23:20:44 UTC+2, bjoer...@gmail.com a écrit :

> On Tue, Apr 26, 2022 at 11:12 PM 'Michael Pratt' via golang-nuts
>  wrote:
> >
> > This sounds like https://go.dev/issue/48956. In that case, it was some 
> interference from an extension.
>
> Indeed: The same extension caused it for me.
>
> Cheers
>

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

[go-nuts] Re: Can’t view golang source when clicking on method name in a pkg.go.dev

[christoph...@gmail.com]

This is a screen capture of what I see https://imgur.com/a/nuBfZeY

Le mardi 26 avril 2022 à 09:37:38 UTC+2, christoph...@gmail.com a écrit :

> Sorry, my message needs a clarification. The page 
> https://cs.opensource.google/go/go/+/go1.18.1:src/encoding/json/stream.go;l=49
>  
> doesn’t show me the source code. 
> I see a big gray circle with the message, "authorization rejected, contact 
> the administrator" which is hopeless of course. 
>
>  
> Le mardi 26 avril 2022 à 09:16:06 UTC+2, christoph...@gmail.com a écrit :
>
>> I’m redirected to this page 
>> https://cs.opensource.google/go/go/+/go1.18.1:src/encoding/json/stream.go;l=49
>>  
>> when I click on the Decode method in the web page 
>> https://pkg.go.dev/encoding/json#Decoder. 
>>
>> Is this a transient problem or is the code not open source anymore ? 
>>
>

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

[go-nuts] Re: Can’t view golang source when clicking on method name in a pkg.go.dev

[christoph...@gmail.com]

Sorry, my message needs a clarification. The page 
https://cs.opensource.google/go/go/+/go1.18.1:src/encoding/json/stream.go;l=49 
doesn’t show me the source code. 
I see a big gray circle with the message, "authorization rejected, contact 
the administrator" which is hopeless of course. 

 
Le mardi 26 avril 2022 à 09:16:06 UTC+2, christoph...@gmail.com a écrit :

> I’m redirected to this page 
> https://cs.opensource.google/go/go/+/go1.18.1:src/encoding/json/stream.go;l=49
>  
> when I click on the Decode method in the web page 
> https://pkg.go.dev/encoding/json#Decoder. 
>
> Is this a transient problem or is the code not open source anymore ? 
>

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

[go-nuts] Can’t view golang source when clicking on method name in a pkg.go.dev

[christoph...@gmail.com]

I’m redirected to this page 
https://cs.opensource.google/go/go/+/go1.18.1:src/encoding/json/stream.go;l=49 
when I click on the Decode method in the web page 
https://pkg.go.dev/encoding/json#Decoder. 

Is this a transient problem or is the code not open source anymore ? 

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

[go-nuts] How to format hour in 24h format without leading 0 ?

[christoph...@gmail.com]

I need to format a time stamp hours in 24h format but without leading 0. 
This means 7 -> "7" and 17 -> "17".

For 24h values, the only formatting key value provided and documented is 
15. But this produces "7" -> "07" and 17 -> "17" which is not what I need.

According to  https://gosamples.dev/date-time-format-cheatsheet/, a 
formatting key word for this format seam to be missing. 

Note by the way that the formatting key value numbering is easy to remember 
for Americans only. Every time I need to format a time value I have to look 
it up with google, or the cheat sheet referenced above.

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

[go-nuts] Re: When will the official encoding/json package support parsing json5？

[christoph...@gmail.com]

You might want to try qjson that I wrote a year ago 
(https://github.com/qjson). 
It's basically just one function that converts qjson text into json. Qjson 
is inspired by hjson, but extend it in many ways. 
It is convenient for config files. 

Maybe I extend it a bit too far by supporting unquoted strings or single 
quoted strings. Lol


Le samedi 19 mars 2022 à 01:03:17 UTC+1, ben...@gmail.com a écrit :

> Yeah, Go's encoding/json will almost certainly never support json5. 
> However, one very simple approach: if you're using JSON for a config file 
> and just need ability to add // line comments, you can just write a simple 
> transformer which reads the file line by line and filters out lines that 
> start with "//" (optionally preceded by whitespace), and then send the 
> result to encoding/json.
>
> On Friday, March 18, 2022 at 1:59:21 PM UTC+13 r...@rwx.gg wrote:
>
>> It is my sincere hope that Go will never support anything as poorly 
>> designed as JSON5, using reflection is already slow enough. Comments were 
>> never intended for JSON and never should be added, ever. But since most 
>> discerning development shops are moving to Protobuf for everything that 
>> matters, perhaps that would be less of a problem.
>>
>> On Monday, March 14, 2022 at 12:07:37 PM UTC-4 fliter wrote:
>>
>>> I need to add comments to json, but now json version does not support 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/f580e928-0dd6-476a-ab3b-2e482b397f46n%40googlegroups.com.

Re: [go-nuts] Possible float64 precision problem

[christoph...@gmail.com]

Thank you for offering your help. 

I can now definitely confirm that there is no computation difference 
between Go and C in my program. There is thus no red flag to use Go in our 
scientific application. What a relief. 

The problem is that our C and Go programs don't store the values in the 
same location. I thus compared different values, but they were close enough 
to be confusing. 

It is impressive that the C and Go computation yields the exact same values 
and output when using %g. I could locate my values with a simple text 
search and diagnose their misplacement. I still need to determine which of 
the C or Go program is doing it wrong. This code translation process may 
have uncover a bug in the C program. 
Le jeudi 10 mars 2022 à 00:31:25 UTC+1, pdc...@gmail.com a écrit :

> Hi Christopher, what input int64 is leading to this result (difference in 
> behavior between Go & C). Does it happen with any input?
> I'm asking because I'm interested in playing around with this a bit, maybe 
> writing two trivial programs (one on each language) and comparing the 
> machine code generated from each one. I'm trying to venture into low level 
> debugging/reverse engineering and I think it will be a good exercise.
>
> Thank you!
>
> Best
>
> Pablo
>
> On Wed, Mar 9, 2022, 4:39 PM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Wed, 2022-03-09 at 03:37 -0800, christoph...@gmail.com wrote:
>> > I'm translating a scientific C program into Go that is doing some
>> > 64bit floating point operations.
>> >
>> > In this process I check that the same input yields the same output.
>> > Unfortunately they don't yield the same result, though the
>> > computation is simple. It is as follow. I receive a 64bit integer
>> > value.
>> >
>> > This value is converted to float64/double, and divided by 2^64.
>> > The resulting number is multiplied by 1e8.
>> >
>> > With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09
>> > E6 8E. The last 15bits are different. The computation is performed
>> > with the same computer.
>> >
>> > Could it be that the C program is performing the computation with
>> > long double (80 bit) precision and that Go is doing it with 64bit
>> > precision ?
>> >
>> > Is there something I could do about it because that might be a red
>> > flag for replacing the C program with a Go program.
>>
>> This is not very surprising depending on the algorithms that are being
>> used/the problem that is being solved. Some problems are fundamentally
>> difficult to solve exactly and the nature of floating point makes them
>> sensitive to the precise set of operations used, intermediate rounding
>> and the order of operations (even for operations that are commutative
>> in theory). As Robert said, knowing the C compiler will be important,
>> and I'd go further, knowing which platform you are building the Go
>> program on can be important due to differences in how floating point
>> operations are rendered into machine code by the compiler, or even how
>> the processor orders apparently commutative operations.
>>
>> Assuming the values that you've pasted above are big endian, then the
>> Go value is within a 1e12th of the value calculate by C (
>> https://go.dev/play/p/dn7G2LI75RC). This is not terrible, and maybe
>> that level of precision is all that can be promised by the algorithm
>> (and believing digits smaller that 1e-12 is dangerous). Alternatively
>> there is no fundamental limit at this point and there is a better more
>> stable algorithm that you can use (though you are only four orders of
>> magnitude from the machine epsilon
>> https://en.wikipedia.org/wiki/Machine_epsilon, so be aware).
>>
>> Floats are tricky beasts and can easily trip people up. I would suggest
>> that you read
>> https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html (and
>> the more friendly https://floating-point-gui.de/).
>>
>>
>>
>> -- 
>> You received this message because you are subscribed 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/ee58b6e5ad163014b256d249e21c875307fecddb.camel%40kortschak.io
>> .
>>
>

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

[go-nuts] Re: Possible float64 precision problem

[christoph...@gmail.com]

A simple C and Go program to demonstrate the problem doesn't show any 
difference between C and Go. 
It's thus most probably a difference in the code that I must investigate. 
Sorry for the noise. 

Le mercredi 9 mars 2022 à 12:37:10 UTC+1, christoph...@gmail.com a écrit :

> I'm translating a scientific C program into Go that is doing some 64bit 
> floating point operations. 
>
> In this process I check that the same input yields the same output. 
> Unfortunately they don't yield the same result, though the computation is 
> simple. It is as follow. I receive a 64bit integer value. 
>
> This value is converted to float64/double, and divided by 2^64.
> The resulting number is multiplied by 1e8. 
>
> With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 E6 
> 8E. The last 15bits are different. The computation is performed with the 
> same computer.
>
> Could it be that the C program is performing the computation with long 
> double (80 bit) precision and that Go is doing it with 64bit precision ? 
>
> Is there something I could do about it because that might be a red flag 
> for replacing the C program with a Go program.
>

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

[go-nuts] Possible float64 precision problem

[christoph...@gmail.com]

I'm translating a scientific C program into Go that is doing some 64bit 
floating point operations. 

In this process I check that the same input yields the same output. 
Unfortunately they don't yield the same result, though the computation is 
simple. It is as follow. I receive a 64bit integer value. 

This value is converted to float64/double, and divided by 2^64.
The resulting number is multiplied by 1e8. 

With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 E6 
8E. The last 15bits are different. The computation is performed with the 
same computer.

Could it be that the C program is performing the computation with long 
double (80 bit) precision and that Go is doing it with 64bit precision ? 

Is there something I could do about it because that might be a red flag for 
replacing the C program with a Go program.

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

[go-nuts] New edition of the Go Programming Language comming soon ?

[christoph...@gmail.com]

Hello Go friends, 

is there a new edition of the "Go Programming Language" book to be 
published soon ? 
It is quite old now and there have been a few changes to Go since then. 
Go.mod and generics. I was considering buying it, but if a new edition 
comes out in a few months, it would be wasted money. 

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

[go-nuts] Re: Unable to handle duplicate cookies

[christoph...@gmail.com]

Thank you very much. This solves my issue.

Le jeudi 23 septembre 2021 à 10:42:35 UTC+2, seank...@gmail.com a écrit :

> net/http.Request.Cookie is a convenience function documented to return a 
> single cookie
> net/http.Request.Cookies will return all cookies, filtering on that should 
> be pretty easy
>
> On Thursday, September 23, 2021 at 10:02:34 AM UTC+2 
> christoph...@gmail.com wrote:
>
>> I implemented a simple web site with a csrf secure cookie that is reset 
>> for each page showing a form. I assumed that simply setting the cookie with 
>> the same name and a new value would override the cookie in the client 
>> browser. 
>>
>> This assumption is correct as long as the url of the page is the same. To 
>> my surprise, when the url are different (same domain name), I end up with 
>> two cookies with the same name. I saw this behavior with chromium and 
>> firefox which can't be a coincidence. Note that I didn't specified the path 
>> when setting the cookie. I assumed that that the path would be "/" by 
>> default. 
>>
>> The result is that the client browser is sending two cookies with the 
>> same name. Unfortunately, the standard lib returns only the first cookie. 
>> The Query method returns an array of values in case of multiple occurrence 
>> of the parameter name. It seam that the Cookie method should also return an 
>> array of value since we can also get multiple cookies with a same name. 
>>
>

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

[go-nuts] Unable to handle duplicate cookies

[christoph...@gmail.com]

I implemented a simple web site with a csrf secure cookie that is reset for 
each page showing a form. I assumed that simply setting the cookie with the 
same name and a new value would override the cookie in the client browser. 

This assumption is correct as long as the url of the page is the same. To 
my surprise, when the url are different (same domain name), I end up with 
two cookies with the same name. I saw this behavior with chromium and 
firefox which can't be a coincidence. Note that I didn't specified the path 
when setting the cookie. I assumed that that the path would be "/" by 
default. 

The result is that the client browser is sending two cookies with the same 
name. Unfortunately, the standard lib returns only the first cookie. The 
Query method returns an array of values in case of multiple occurrence of 
the parameter name. It seam that the Cookie method should also return an 
array of value since we can also get multiple cookies with a same name. 

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

[go-nuts] derive encoder/decoder from std json encoder/decoder ?

[christoph...@gmail.com]

I need to write a binary encoder/decoder very similar to the std JSON 
encoder/decoder. 
I would like to reuse 80% of the JSON encoder/decoder code and adapt it to 
support my binary encoding. 

Is this allowed and at which condition ?

Would it be possible to publish my code on github with an MIT license 
instead of the BSD license ? This is just because all my projects are all 
using the MIT license.

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

Re: [go-nuts] Computing a hash over a uintptr ?

[christoph...@gmail.com]

> That is true in current implementations, but Go, the language, does not 
guarantee that pointers will never move. 

That is what I thought, but it is allowed to use a pointer far map keys. 
And I have seen some programs/package using this feature. 
Apparently all these programs and packages would break if objects were to 
be moved around ? 

Le vendredi 4 juin 2021 à 07:25:11 UTC+2, Ian Lance Taylor a écrit :

> On Thu, Jun 3, 2021 at 9:13 PM Robert Engels  wrote:
> >
> > Doesn’t that depend on what the uintptr refers to? Eg if it was 
> allocated off heap to begin with then it should be stable and computing a 
> hash on it is valid.
>
> That is true in current implementations, but Go, the language, does
> not guarantee that pointers will never move.
>
> Ian
>
>
> > On Jun 3, 2021, at 9:42 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
> >
> > 
> > On Thu, Jun 3, 2021 at 4:19 PM christoph...@gmail.com <
> christoph...@gmail.com> wrote:
> >>
> >> The documentation doesn’t specify that we can cast an uintptr into a 
> uint64.
> >
> >
> > Both are integer types, so they can be converted. You might be worried 
> about their respective sizes and you are correct that the spec does not 
> guarantee that a uintptr is at most 64 bit. However, at least for any 
> implementation I know on any supported architecture, that's the case. If 
> you *really* want to make sure, you can do something like this:
> >
> > func toBytes(v uintptr) []byte {
> > var out []byte
> > mask := ^uintptr(0)
> > for mask != 0 {
> > out = append(out, uint8(v))
> > v >>= 8
> > mask >>= 8
> > }
> > return out
> > }
> >
> > But really, you can just trust that a uintptr fits into a uint64. Or, if 
> you want to future-proof, assume it's uint64, but guard by build tags to 
> known architectures (so it at least fails to compile if that assumption 
> ever changes).
> >
> >> To give some context, the application is for a cache with the hash key 
> computed over a pointer to a heap allocated struct. I need to store the 
> pointer in the cache entry to test for matching, but this would prevent the 
> struct to be garbage collected. Storing the pointer as an uintptr would do 
> the trick.
> >
> >
> > This is problematic. The address of a value can change, so the uintptr 
> would change as well. So there is no guarantee that your hash stays the 
> same, in subsequent calls.
> > Today, that usually doesn't happen, but there is no guarantee it stays 
> that way. If you are willing to assume that it doesn't happen, you should 
> definitely also be willing to assume a uintptr fits into a uint64
> >
> >>
> >>
> >> --
> >> You received this message because you are subscribed 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/7983a13f-5bf6-4299-a598-1d023ec9a9e9n%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/CAEkBMfFsZNHLXcONF9C6Nadr6muUP_kgOJwM3QUXSZ0KxPnfYQ%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/35E8DBC1-E067-4717-BFFF-18732D77B987%40ix.netcom.com
> .
>

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

[go-nuts] Computing a hash over a uintptr ?

[christoph...@gmail.com]

The documentation specifies that a pointer can be cast into a uintptr 
integer. I assume that the uintptr is ignored by the garbage collector. 

I would like to compute a hash over the uintptr. How do I achieve that ? 

The documentation doesn’t specify that we can cast an uintptr into a 
uint64. The byte size may not match. What would be the idiomatic way to 
compute a hash over a uintpr ? Is it valid to do that ? 

To give some context, the application is for a cache with the hash key 
computed over a pointer to a heap allocated struct. I need to store the 
pointer in the cache entry to test for matching, but this would prevent the 
struct to be garbage collected. Storing the pointer as an uintptr would do 
the trick. 

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

[go-nuts] Security issue in

[christoph...@gmail.com]

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/9c18eecc-126d-4614-872d-474ebe90513cn%40googlegroups.com.

[go-nuts] Re: How to manage replace directives in go.mod files when code versioning ?

[christoph...@gmail.com]

Thank you for pointing this out. I wasn’t aware of it. But the question 
still holds for published main programs. 

Le mardi 27 avril 2021 à 07:27:58 UTC+2, Uli Kunitz a écrit :

> Are you aware of "replace directives only apply in the main 
> module's go.mod file and are ignored in other modules. See Minimal 
> version selection <https://golang.org/ref/mod#minimal-version-selection> for 
> details."?
>
> You can find it here: https://golang.org/ref/mod#go-mod-file-replace
>
> On Tuesday, April 27, 2021 at 7:23:52 AM UTC+2 christoph...@gmail.com 
> wrote:
>
>> When debugging or testing we may need to add a replace directive in the 
>> go.mod file.
>>
>> This change intended to be local only may interfere with code versioning. 
>> The replace directive may be accidentally committed and published. What is 
>> the proper way to manage replace directives when it comes to code 
>> versioning ? 
>>
>> Apparently we are supposed to remove replace directives before commits, 
>> and put it back to continue testing. That is boring and error prone. Is 
>> there a better way ?
>>
>

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

Re: [go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?

[christoph...@gmail.com]

It seam that C is wrong on this one and Go is right. The rationale is that 
a NaN must propagate through operations so that we can detect problems 
(avoid silent NaNs). See https://en.wikipedia.org/wiki/NaN

Thus any operation involving a NaN must return an NaN and this includes Max 
and Min. 
 
Le jeudi 22 avril 2021 à 12:43:23 UTC+2, jesper.lou...@gmail.com a écrit :

> On Thu, Apr 22, 2021 at 11:54 AM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>>
>> Does anyone know the reason for this? (Looking through other languages,
>> the situation in general seems to be a mess).
>>
>>
> I looked at OCaml, which provides both variants:
>
> Float.max : float -> float -> float
> Float.max_num : float -> float -> float
>
> The `max` function includes NaNs in the computation, while `max_num` omits 
> them. Another important treatment the documentation mentions is `max 
> -0.0 +0.0`.
>
> I also looked at Matlab and R. They essentially provide ways to either 
> include the NaN or omit it from the computation, usually when you have a 
> vector of numbers where some of the numbers are unknown. I.e., they take 
> extra (optional) flags to their functions which tells you how to treat NaN 
> values.
>
> The "pure" solution is clearly the one where NaN's yield a NaN. It is 
> isomorphic to a Monoid based on optional values with the NaN forming the 
> unknown element, often called the option-monoid or the maybe-monoid. Or 
> said otherwise: for any type a, where a is a monoid, so is 'option a':
>
> forall a. Monoid a => Monoid (Option a)
>
> Since the max function itself is a monoid with the neutral element taken 
> as the minimal value, -inf, we can thus "lift" NaN values on top and still 
> have some mathematical consistency.
>
> But if you have an array of values, where some of them can be NaN, it is 
> probably smart to provide a function which filters the array of NaN values 
> and computes the remaining values. R provides the function `na.omit(..)` 
> for this. So do option types in languages such as OCaml or Haskell. Here, 
> we are not that concerned about what is sound from a formal point of view, 
> but more concerned with data cleanup before we start using the formality.
>
> Max of two values is a special case. The generalized version takes an 
> array/vector of values and provides the maximum in the structure.
>
> All of this leads me to conclude you probably want both variants in the 
> end. In some situations, it is better to include NaN values in the 
> computation, and in other situations, the right move is to omit/exclude 
> them.
>
>
>

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

[go-nuts] How to manage replace directives in go.mod files when code versioning ?

[christoph...@gmail.com]

When debugging or testing we may need to add a replace directive in the 
go.mod file.

This change intended to be local only may interfere with code versioning. 
The replace directive may be accidentally committed and published. What is 
the proper way to manage replace directives when it comes to code 
versioning ? 

Apparently we are supposed to remove replace directives before commits, and 
put it back to continue testing. That is boring and error prone. Is there a 
better way ?

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

[go-nuts] Big variations in benchmarking results ?

[christoph...@gmail.com]

Hello,

I'm benchmarking some code with my mac book air. The code is only 
computation and writing in a preallocated slice. I see big variations in 
the ns/op (e.g. 5000 to 8000). I disabled the turbo boost but the 
variations are still there. 

To verify I tried the code benchmarking on an Ubuntu desktop computer and 
the variations are small (e.g. 4000 +/- 100 at most). 

What could explain these variations ? Is there a way to avoid 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/01c4cc10-b602-4cad-b369-3e410b563c6an%40googlegroups.com.

[go-nuts] Is the Go png encoder performing gamma correction ?

[christoph...@gmail.com]

It is unspecified in the documentation if the png encoder is performing 
gamma correction. I thus assume that it is not performing gamma correction. 
Is this assumption correct ?

According to wikipedia, jpg images are gamma encoded. What is the status of 
png images ? It seam relevant for antialiasing, especially for font 
rendering. 

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

Re: [go-nuts] Casting int to bool and the reverse for bit hacking ?

[christoph...@gmail.com]

Thank you Aleksey. That is indeed a working solution, and it works well.
 Here are the two functions I wrote as suggested:

func bool2int(b bool) int {
if b {
return 1
}
return 0
}

func testBitHack(v int) bool {
return (bool2int(v==10) & bool2int(v==5) & bool2int(v==15)) == 0
}

Here is the Go assembly code of testBitHack

"".testBitHack STEXT nosplit size=47 args=0x10 locals=0x0
0x 0 (main.go:12)   TEXT"".testBitHack(SB), 
NOSPLIT|ABIInternal, $0-16
0x 0 (main.go:12)   FUNCDATA$0, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x 0 (main.go:12)   FUNCDATA$1, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x 0 (main.go:13)   MOVQ"".v+8(SP), AX
0x0005 5 (main.go:13)   CMPQAX, $10
0x0009 9 (main.go:13)   SETEQ   CL
0x000c 00012 (main.go:13)   CMPQAX, $5
0x0010 00016 (main.go:13)   SETEQ   DL
0x0013 00019 (main.go:13)   CMPQAX, $15
0x0017 00023 (main.go:13)   SETEQ   AL
0x001a 00026 (main.go:13)   MOVBLZX DL, DX
0x001d 00029 (main.go:13)   MOVBLZX CL, CX
0x0020 00032 (main.go:13)   ANDQDX, CX
0x0023 00035 (main.go:13)   MOVBLZX AL, AX
0x0026 00038 (main.go:13)   TESTQ   AX, CX
0x0029 00041 (main.go:13)   SETEQ   "".~r1+16(SP)
0x002e 00046 (main.go:13)   RET

The function bool2int and its condition were effectively optimized away by 
the Go compiler.  That’s awesome. Good job. It’s a nice trick.




Le samedi 21 novembre 2020 à 11:41:03 UTC+1, aleksey...@gmail.com a écrit :

> To me your example appears somewhat confusing, int(bool(int())) is the
> fishiest part IMO. I assume bool(int()) is just (v^v1 != 0) in
> disguise and this is essentially
>
> (v^v1 != 0) & (v^v2 != 0) & (v^v3 != 0)
>
> Am i right?
>
> Go can't & bools, so
>
> func bool2int(b bool) int { // This is what Go compiler can optimize well
> if b {
> return 1
> }
> return 0
> }
>
> And this leaves us with
>
> bool2int(v^v1 != 0) & bool2int(v^v2 != 0) & bool2int(v^v3 != 0)
>
> Is that correct?
>
> https://godbolt.org/z/jq368G
>
> I don't see branching in relevant parts. v == v1 || v == v2 will of
> course branch because || is a condition.
>
> Does that answer your question or maybe I am missing something?
>
> пт, 20 нояб. 2020 г. в 11:27, christoph...@gmail.com
> :
> >
> > Go has a strict type separation between int and bool. For a normal usage 
> this is OK. I guess it also ease assembly portability because there is not 
> always a machine instruction to do so.
> >
> > For bit hacking, this is an unfortunate limitation. A handy feature of 
> bool <-> int conversion is that true is converted to 1 and any integer 
> different of zero to true. As a consequence, when we write int(bool(x)) we 
> get 0 when x is 0, and 1 when x is not 0. I checked the math/bits package 
> and there is not an equivalent function.
> >
> > Is there a way around this that avoids the conditional branching ?
> >
> > The use case I have to test if an integer is in a quite small constant 
> set of integers. With bool <-> int conversion, we can use binary operation 
> like this for instance which would be valid in C
> >
> > r := int(bool(v^v1))(bool(v^v2))(bool(v^v3))
> >
> > This is to be compared with
> >
> > r := v==v1 || v==v2 || v==v3
> >
> > The second form is of course more readable, but will also have a 
> conditional branch at each ||. If most tested integers are different from 
> v1, v2 and v3, the first form seam to me more efficient due to pipelining. 
> Though branching prediction can mitigate the penalty.
> >
> > The best I could do as valid Go alternative is this
> >
> > r := (v^v1)*(v^v2)*(v^v3)
> >
> > but the multiplication is obviously not efficient.
> >
> > Did I miss something ?
> >
> > --
> > You received this message because you are subscribed 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/a2b743d7-011d-481f-9a0f-3f00f4507328n%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/4381cff4-a79e-4b91-bf04-c7a2c95af309n%40googlegroups.com.

[go-nuts] Re: Carting int to bool and the reverse for bit hacking ?

[christoph...@gmail.com]

Thank you for the responses. Unfortunately, they all comment on the given 
use case. 
The real question is if we should add a function in math/bits that performs 
the operation. 
The function would be 

func notZero(x int) int {
if x == 0 {
return 0
}
return 1
}

Regarding code optimization, do they also optimize range testing ?

if x >= a && x <= b ...

can be translated into the following when b > a. 

if uint(x - a) <= uint(b-a) ...

This replaces two conditional branches with one. I checked go assembly and 
the later is indeed simpler. 

I benchmarked decode rune with both and didn't see much difference. This is 
probably because in a tight loop of benchmark tests, the branching 
prediction does well its job. 


Le samedi 21 novembre 2020 à 10:30:13 UTC+1, b.ca...@pobox.com a écrit :

> That's fantastic.  Paste in
>
> int Test0(int v, int v1, int v2, int v3)
> {
>  return v == v1 || v == v2 || v == v3;
> }
>
> and then the the compiler options to -O3.
>

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

[go-nuts] Carting int to bool and the reverse for bit hacking ?

[christoph...@gmail.com]

Go has a strict type separation between int and bool. For a normal usage 
this is OK. I guess it also ease assembly portability because there is not 
always a machine instruction to do so. 

For bit hacking, this is an unfortunate limitation. A handy feature of bool 
<-> int conversion is that true is converted to 1 and any integer different 
of zero to true. As a consequence, when we write int(bool(x)) we get 0 when 
x is 0, and 1 when x is not 0. I checked the math/bits package and there is 
not an equivalent function.

Is there a way around this that avoids the conditional branching ? 

The use case I have to test if an integer is in a quite small constant set 
of integers. With bool <-> int conversion, we can use binary operation like 
this for instance which would be valid in C

r := int(bool(v^v1))(bool(v^v2))(bool(v^v3))

This is to be compared with 

r := v==v1 || v==v2 || v==v3

The second form is of course more readable, but will also have a 
conditional branch at each ||. If most tested integers are different from 
v1, v2 and v3, the first form seam to me more efficient due to pipelining. 
Though branching prediction can mitigate the penalty. 

The best I could do as valid Go alternative is this

r := (v^v1)*(v^v2)*(v^v3)

but the multiplication is obviously not efficient. 

Did I miss something ? 

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

[go-nuts] Re: Why key.PublicKey.Equal(key.PublicKey) return false ?

[christoph...@gmail.com]

My formulation was not clear. The test fails, and it reports a key 
mismatch. 

Le mardi 27 octobre 2020 à 16:21:05 UTC+1, christoph...@gmail.com a écrit :

> I have the following test that fails reporting a key  mismatch. 
>
> func TestKeyEqual(t *testing.T) {
>  key, err := rsa.GenerateKey(rand.Reader, 2048)
>  if err != nil {
>  t.Fatal("failed generating private key: ", err)
>  }
>  if !key.PublicKey.Equal(key.PublicKey) {
>  t.Fatal("key mismatch")
>  }
> }
>
> Why is that ? Shouldn’t it return true ? 
>
> Initially I compared key after save and reload read, and since it failed, 
> I just tested the same key for equality to verify that Equal was working as 
> expected. Apparently it does not or I’m doing something wrong. 
>

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

[go-nuts] Why key.PublicKey.Equal(key.PublicKey) return false ?

[christoph...@gmail.com]

I have the following test that fails reporting a key  mismatch. 

func TestKeyEqual(t *testing.T) {
 key, err := rsa.GenerateKey(rand.Reader, 2048)
 if err != nil {
 t.Fatal("failed generating private key: ", err)
 }
 if !key.PublicKey.Equal(key.PublicKey) {
 t.Fatal("key mismatch")
 }
}

Why is that ? Shouldn’t it return true ? 

Initially I compared key after save and reload read, and since it failed, I 
just tested the same key for equality to verify that Equal was working as 
expected. Apparently it does not or I’m doing something wrong. 

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

[go-nuts] Re: Generics and parentheses

[christoph...@gmail.com]

I would like to insist on considering the D syntax using the ! for generics 
instantiation. 

The first time I saw it, I was puzzled and found it unpleasant. But this is 
just because it is unfamiliar and not intuitive.
Once I got used to it, I found it much simple than the C++ templates. In 
fact I even found it easier to use than the C++ notation.

The thing is that generic instantiation will be very frequent and most of 
the time with only one template argument. The notation using a simple ! is 
then much lighter and readable then a notation using parenthesis. 

Please, consider and favor the readability and code lightness of the most 
frequent use with generics which is the instantiation with one type 
argument.

Compare T!int  with T(int)  or T[int] or T, or A!B!int with A(B(int)) 
or A[B[int]] or A>. 

Please take the time time to experiment it and optimize the most frequent 
use. 
The D notation gave me the impression that use of generics was simple. Much 
simpler than with C++. 

Go generics made a huge and good simplification by dropping the contracts. 
Please, follow the same strategy for the instantiation of generics which 
will be the most frequent occurrence in the code.  

Le mardi 14 juillet 2020 à 23:56:01 UTC+2, gri a écrit :

> We have received a variety of feedback on the generics draft design 
> 
>  
> (blog ). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> , and eventually 
> in the playground .
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
>