[go-nuts] Re: Strange redirect behavior with http.StripPrefix

[j2gg0s]

Why this happens:
1. http.StripPrefix chang reuqest's path from /some/other/path to other/path
2. ServerMux.Handler will return 301 when cleanPath(r.URL.Path) != 
r.URL.Path

Link: https://github.com/golang/go/blob/go1.21.5/src/net/http/server.go#L2467

This seems to be a issue with ServerMux,
Our prefix cannot end with / when we use StripPrefix with ServerMux.
在2023年12月20日星期三 UTC+8 08:38:29 写道：

> Hi all,
>
> I was very confused by the behavior I was seeing while testing a simple 
> program with http.StripPrefix:
> package main
>
> import (
> "fmt"
> "net/http"
> )
>
> func main() {
> mux := http.NewServeMux()
> mux.HandleFunc("/other/", func(w http.ResponseWriter, r *http.Request) {
> fmt.Println(r.URL.Path)
> w.WriteHeader(200)
> w.Write([]byte("\n\nSeen path: " + r.URL.Path + "\n"))
> })
>
> // adding a / after /some/ here causes the strange redirect
> prefixHandler := http.StripPrefix("/some/", mux)
>
> // Start the HTTP server with the stripPrefixHandler
> err := http.ListenAndServe(":9080", http.HandlerFunc(func(w 
> http.ResponseWriter, r *http.Request) {
> fmt.Println(r.URL.Path)
> prefixHandler.ServeHTTP(w, r)
> }))
> if err != nil {
> panic(err)
> }
> }
>
> Try browsing to http://localhost:9080/some/other/path
>
> This works fine if the StripPrefix does not have the / after /some/
>
> That said: the strange behavior is: I notice with the above code 
> (including the slash after /some/ in StripPrefix) that browsing to 
> http://localhost:9080/some/other/path results in a 404 and effectively a 
> redirect to http://localhost:9080/other/path - the browser's URL changes 
> to the version of the path without the prefix!
>
> Why is the http handler returning a redirect to the stripped version?
>
> < HTTP/1.1 301 Moved Permanently
> < Content-Type: text/html; charset=utf-8
> < Location: /other/path
> < Date: Wed, 20 Dec 2023 00:37:00 GMT
> < Content-Length: 46
> < 
> Moved Permanently.
>
> I would expect to instead see a 404 with the given path /some/other/path.
>
> This seems like a bug or otherwise undocumented behavior, the docs just 
> say "StripPrefix handles a request for a path that doesn't begin with 
> prefix by replying with an HTTP 404 not found error."
>
> Thanks,
> Christian Stewart
> https://github.com/paralin
>

-- 
You received this message because you are subscribed 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/2eca6b78-49c6-4be2-b55d-f49d118b8e6fn%40googlegroups.com.

[go-nuts] Strange redirect behavior with http.StripPrefix

['Christian Stewart' via golang-nuts]

Hi all,

I was very confused by the behavior I was seeing while testing a simple 
program with http.StripPrefix:
package main

import (
"fmt"
"net/http"
)

func main() {
mux := http.NewServeMux()
mux.HandleFunc("/other/", func(w http.ResponseWriter, r *http.Request) {
fmt.Println(r.URL.Path)
w.WriteHeader(200)
w.Write([]byte("\n\nSeen path: " + r.URL.Path + "\n"))
})

// adding a / after /some/ here causes the strange redirect
prefixHandler := http.StripPrefix("/some/", mux)

// Start the HTTP server with the stripPrefixHandler
err := http.ListenAndServe(":9080", http.HandlerFunc(func(w 
http.ResponseWriter, r *http.Request) {
fmt.Println(r.URL.Path)
prefixHandler.ServeHTTP(w, r)
}))
if err != nil {
panic(err)
}
}

Try browsing to http://localhost:9080/some/other/path

This works fine if the StripPrefix does not have the / after /some/

That said: the strange behavior is: I notice with the above code (including 
the slash after /some/ in StripPrefix) that browsing to 
http://localhost:9080/some/other/path results in a 404 and effectively a 
redirect to http://localhost:9080/other/path - the browser's URL changes to 
the version of the path without the prefix!

Why is the http handler returning a redirect to the stripped version?

< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=utf-8
< Location: /other/path
< Date: Wed, 20 Dec 2023 00:37:00 GMT
< Content-Length: 46
< 
Moved Permanently.

I would expect to instead see a 404 with the given path /some/other/path.

This seems like a bug or otherwise undocumented behavior, the docs just say 
"StripPrefix handles a request for a path that doesn't begin with prefix by 
replying with an HTTP 404 not found error."

Thanks,
Christian Stewart
https://github.com/paralin

-- 
You received this message because you are subscribed 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/65819ada-a15a-45d9-b88b-85e6e988b6f1n%40googlegroups.com.

[go-nuts] Go 1.22 Release Candidate 1 is released

[announce]

Hello gophers,

We have just released go1.22rc1, a release candidate version of Go 1.22.
It is cut from release-branch.go1.22 at the revision tagged go1.22rc1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://go.dev/issue/new

If you have Go installed already, an easy way to try go1.22rc1
is by using the go command:
$ go install golang.org/dl/go1.22rc1@latest
$ go1.22rc1 download

You can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.22rc1

To find out what has changed in Go 1.22, read the draft release notes:
https://tip.golang.org/doc/go1.22

Cheers,
Than and Carlos for the Go team

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

Re: [go-nuts] Generic assembly function

[Clément Jean]

Btw, the assembly code was quite terrible... Here is a new version of it 
for people interested (feedback still welcomed):

TEXT ·AddVector16(SB),NOSPLIT,$0-48
MOVD $a+0(FP), R0
VLD1.P 32(R0), [V0.D2, V1.D2]
VADD V1.B16, V0.B16, V0.B16
MOVD $ret+32(FP), R0
VST1.P [V0.D2], (R0)
RET

TEXT ·AddVector32(SB),NOSPLIT,$0-96
MOVD $a+0(FP), R0
VLD1.P 64(R0), [V0.D2, V1.D2, V2.D2, V3.D2]
VADD V2.B16, V0.B16, V0.B16
VADD V3.B16, V1.B16, V1.B16
MOVD $ret+64(FP), R0
VST1.P [V0.D2, V1.D2], (R0)
RET

On Wednesday, December 20, 2023 at 7:40:36 AM UTC+8 Clément Jean wrote:

> That's what I thought. When I checked the assembly of a generic function I 
> could see the go.shape part and that's what made me think about 
> specialisation.
> However, after trying to write that myself it just didn't compile.
>
> I guess, I'll have to do lot of copy pasting ^^
>
> On Wednesday, December 20, 2023 at 2:23:01 AM UTC+8 David Finkel wrote:
>
>> On Thu, Dec 14, 2023 at 10:43 PM Clément Jean  
>> wrote:
>>
>>> Hi,
>>>
>>> I'm currently learning how to write Go assembly on arm64 and I made the 
>>> following functions:
>>>
>>> TEXT ·AddVector16(SB),NOSPLIT,$0-48
>>> MOVD a+0(FP), R0
>>> MOVD a+8(FP), R1
>>> MOVD a+16(FP), R2
>>> MOVD a+24(FP), R3
>>> VMOV R0, V0.D[0]
>>> VMOV R1, V0.D[1]
>>> VMOV R2, V1.D[0]
>>> VMOV R3, V1.D[1]
>>> VADD V1.B16, V0.B16, V0.B16
>>> VMOV V0.D[0], R0
>>> VMOV V0.D[1], R1
>>> MOVD R0, ret+32(FP)
>>> MOVD R1, ret+40(FP)
>>> RET
>>>
>>> TEXT ·AddVector32(SB),NOSPLIT,$0-96
>>> MOVD a+0(FP), R0
>>> MOVD a+8(FP), R1
>>> MOVD a+16(FP), R2
>>> MOVD a+24(FP), R3
>>> MOVD a+32(FP), R4
>>> MOVD a+40(FP), R5
>>> MOVD a+48(FP), R6
>>> MOVD a+56(FP), R7
>>> VMOV R0, V0.D[0]
>>> VMOV R1, V0.D[1]
>>> VMOV R2, V1.D[0]
>>> VMOV R3, V1.D[1]
>>> VMOV R4, V2.D[0]
>>> VMOV R5, V2.D[1]
>>> VMOV R6, V3.D[0]
>>> VMOV R7, V3.D[1]
>>> VADD V2.B16, V0.B16, V0.B16
>>> VADD V3.B16, V1.B16, V1.B16
>>> VMOV V0.D[0], R0
>>> VMOV V0.D[1], R1
>>> VMOV V1.D[0], R2
>>> VMOV V1.D[1], R3
>>> MOVD R0, ret+64(FP)
>>> MOVD R1, ret+72(FP)
>>> MOVD R2, ret+80(FP)
>>> MOVD R3, ret+88(FP)
>>> RET
>>> While these work, I'm forced to add the 16 and 32 suffixes. Is there any 
>>> way to have only one function name and link the assembly to something like:
>>> type Uint8x16 [16]uint8
>>> type Uint8x32 [32]uint8
>>>
>>> //go:noescape
>>> func AddVector[T Uint8x16 | Uint8x32](a, b T) T
>>> If there is let me know, otherwise is there some other alternatives?
>>>
>>>
>> Unfortunately, I think a suffix is the best you can do without jumping 
>> through some serious (and ugly) hoops.
>> The generics implementation opted for a "stenciling" approach, (and 
>> doesn't support specializations) so although the symbols do encode the GC 
>> shape a bit.
>> Here's the design doc for GC Shape Stenciling
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
>>   
>>  
>>
>>> Btw any feedback on the assembly is welcome, I'm new to it.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/3224bd47-2747-4e1d-bbc5-4a5c4a300f85n%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/b19562ac-5b2f-44f2-a6f9-77bf7eb8678en%40googlegroups.com.

Re: [go-nuts] Generic assembly function

[Clément Jean]

That's what I thought. When I checked the assembly of a generic function I 
could see the go.shape part and that's what made me think about 
specialisation.
However, after trying to write that myself it just didn't compile.

I guess, I'll have to do lot of copy pasting ^^

On Wednesday, December 20, 2023 at 2:23:01 AM UTC+8 David Finkel wrote:

> On Thu, Dec 14, 2023 at 10:43 PM Clément Jean  wrote:
>
>> Hi,
>>
>> I'm currently learning how to write Go assembly on arm64 and I made the 
>> following functions:
>>
>> TEXT ·AddVector16(SB),NOSPLIT,$0-48
>> MOVD a+0(FP), R0
>> MOVD a+8(FP), R1
>> MOVD a+16(FP), R2
>> MOVD a+24(FP), R3
>> VMOV R0, V0.D[0]
>> VMOV R1, V0.D[1]
>> VMOV R2, V1.D[0]
>> VMOV R3, V1.D[1]
>> VADD V1.B16, V0.B16, V0.B16
>> VMOV V0.D[0], R0
>> VMOV V0.D[1], R1
>> MOVD R0, ret+32(FP)
>> MOVD R1, ret+40(FP)
>> RET
>>
>> TEXT ·AddVector32(SB),NOSPLIT,$0-96
>> MOVD a+0(FP), R0
>> MOVD a+8(FP), R1
>> MOVD a+16(FP), R2
>> MOVD a+24(FP), R3
>> MOVD a+32(FP), R4
>> MOVD a+40(FP), R5
>> MOVD a+48(FP), R6
>> MOVD a+56(FP), R7
>> VMOV R0, V0.D[0]
>> VMOV R1, V0.D[1]
>> VMOV R2, V1.D[0]
>> VMOV R3, V1.D[1]
>> VMOV R4, V2.D[0]
>> VMOV R5, V2.D[1]
>> VMOV R6, V3.D[0]
>> VMOV R7, V3.D[1]
>> VADD V2.B16, V0.B16, V0.B16
>> VADD V3.B16, V1.B16, V1.B16
>> VMOV V0.D[0], R0
>> VMOV V0.D[1], R1
>> VMOV V1.D[0], R2
>> VMOV V1.D[1], R3
>> MOVD R0, ret+64(FP)
>> MOVD R1, ret+72(FP)
>> MOVD R2, ret+80(FP)
>> MOVD R3, ret+88(FP)
>> RET
>> While these work, I'm forced to add the 16 and 32 suffixes. Is there any 
>> way to have only one function name and link the assembly to something like:
>> type Uint8x16 [16]uint8
>> type Uint8x32 [32]uint8
>>
>> //go:noescape
>> func AddVector[T Uint8x16 | Uint8x32](a, b T) T
>> If there is let me know, otherwise is there some other alternatives?
>>
>>
> Unfortunately, I think a suffix is the best you can do without jumping 
> through some serious (and ugly) hoops.
> The generics implementation opted for a "stenciling" approach, (and 
> doesn't support specializations) so although the symbols do encode the GC 
> shape a bit.
> Here's the design doc for GC Shape Stenciling
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md
>   
>  
>
>> Btw any feedback on the assembly is welcome, I'm new to it.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/3224bd47-2747-4e1d-bbc5-4a5c4a300f85n%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/426161bd-fb19-43ef-bd2d-051f3acafdf7n%40googlegroups.com.

Re: [go-nuts] circular package dependency between golang.org/x/mod and golang.org/x/tools

[Rob Pike]

If it's only in the test, the circularity only arises when testing both
packages in a single build. That doesn't happen so is not a problem at all,
and in fact the stdlib is full of such circularities involving common
packages like fmt.

-rob



On Wed, Dec 20, 2023 at 7:49 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Dec 19, 2023 at 9:37 PM Nathan Lacey 
> wrote:
>
> > I noticed that we have a circular dependency between golang.org/x/mod
> and golang.org/x/tools
> >
> >  golang.org/x/mod  zip/zip_test.go includes golang.org/x/tools
> > I think we could get rid of the circular package dependency by changing
> that unit test to remove the dependency to tools/txtar .
>
> But why? What's the motivation to remove the cycle?
>
> --
> You received this message because you are subscribed 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/CAA40n-URNGfDo34j4Ui-wvCiYjQysfMoJii%2B1m3CP_U85c0ezA%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZQDm%2BLVbbhjijG4s%2B2VJtqx_rj3L0Rtra5vYN8%2B3NPwjQ%40mail.gmail.com.

Re: [go-nuts] Re: Why there is no net.ListenContext?

['Axel Wagner' via golang-nuts]

Hm, reading again, I don't think I actually understand your question. You
clearly are ListenConfig aware.
But what do you mean with "the same way we have Dial and DialContext"?
These are methods on Dialer, so ISTM that there is indeed a pretty clear
correspondence. Except that Dialer.Dial has been introduced in Go 1.1,
before we had context.Context, so we needed a new name for the
context-aware API.
So I'm not sure what exactly you are asking. ISTM you are not missing a
context-aware version of Listen, so what is it you are asking for?

On Tue, Dec 19, 2023 at 10:14 PM Axel Wagner 
wrote:

> You can use `ListenConfig.Listen` to do this:
> https://pkg.go.dev/net#ListenConfig.Listen
> I believe the reason to do it this way was the realization that there will
> probably be more ways to set up listening in the future and having lots of
> different ListenFoo functions in the package would overload the namespace
> too much.
>
> On Tue, Dec 19, 2023 at 9:28 PM Michał Matczuk  wrote:
>
>> The context is passed downstream but cancelling it seems to have no
>> effect.
>> I guess that the reason why it's not exported.
>> Can anyone shed more light on it?
>>
>> wtorek, 19 grudnia 2023 o 11:59:49 UTC+1 Michał Matczuk napisał(a):
>>
>>> If you take a look at net.Listen implementation
>>>
>>> func Listen(network, address string) (Listener, error) {
>>> var lc ListenConfig
>>> return lc.Listen(context.Background(), network, address)
>>> }
>>>
>>> you will notice the new listen API net.ListenConfig.
>>>
>>> This API is context aware, I think it would be handy if we had
>>> net.ListenContext the same way we have Dial and DialContext.
>>>
>>> Any thoughts on that?
>>>
>> --
>> You received this message because you are subscribed 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/8abe1abb-eb3b-4632-b3c0-e430f2f42270n%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/CAEkBMfFL%3D7FOBWWE2rRzPSVv99jtUUi%3D7Tiz7ZEtMYUtcCLT6g%40mail.gmail.com.

Re: [go-nuts] Re: Why there is no net.ListenContext?

['Axel Wagner' via golang-nuts]

You can use `ListenConfig.Listen` to do this:
https://pkg.go.dev/net#ListenConfig.Listen
I believe the reason to do it this way was the realization that there will
probably be more ways to set up listening in the future and having lots of
different ListenFoo functions in the package would overload the namespace
too much.

On Tue, Dec 19, 2023 at 9:28 PM Michał Matczuk  wrote:

> The context is passed downstream but cancelling it seems to have no effect.
> I guess that the reason why it's not exported.
> Can anyone shed more light on it?
>
> wtorek, 19 grudnia 2023 o 11:59:49 UTC+1 Michał Matczuk napisał(a):
>
>> If you take a look at net.Listen implementation
>>
>> func Listen(network, address string) (Listener, error) {
>> var lc ListenConfig
>> return lc.Listen(context.Background(), network, address)
>> }
>>
>> you will notice the new listen API net.ListenConfig.
>>
>> This API is context aware, I think it would be handy if we had
>> net.ListenContext the same way we have Dial and DialContext.
>>
>> Any thoughts on that?
>>
> --
> You received this message because you are subscribed 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/8abe1abb-eb3b-4632-b3c0-e430f2f42270n%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/CAEkBMfGavp70pXA%3DQWpa5NXroUWdCRhHUw%3D11JNssKDGvfgn3Q%40mail.gmail.com.

Re: [go-nuts] circular package dependency between golang.org/x/mod and golang.org/x/tools

[Jan Mercl]

On Tue, Dec 19, 2023 at 9:37 PM Nathan Lacey  wrote:

> I noticed that we have a circular dependency between golang.org/x/mod and 
> golang.org/x/tools
>
>  golang.org/x/mod  zip/zip_test.go includes golang.org/x/tools
> I think we could get rid of the circular package dependency by changing that 
> unit test to remove the dependency to tools/txtar .

But why? What's the motivation to remove the cycle?

-- 
You received this message because you are subscribed 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/CAA40n-URNGfDo34j4Ui-wvCiYjQysfMoJii%2B1m3CP_U85c0ezA%40mail.gmail.com.

[go-nuts] circular package dependency between golang.org/x/mod and golang.org/x/tools

[Nathan Lacey]

I noticed that we have a circular dependency between golang.org/x/mod and 
golang.org/x/tools

 golang.org/x/mod  zip/zip_test.go includes golang.org/x/tools
I think we could get rid of the circular package dependency by changing 
that unit test to remove the dependency to tools/txtar .

-- 
You received this message because you are subscribed 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/f60e4010-824e-4792-be33-6596601ffa8en%40googlegroups.com.

[go-nuts] Re: Why there is no net.ListenContext?

[Michał Matczuk]

The context is passed downstream but cancelling it seems to have no effect.
I guess that the reason why it's not exported.
Can anyone shed more light on it?   

wtorek, 19 grudnia 2023 o 11:59:49 UTC+1 Michał Matczuk napisał(a):

> If you take a look at net.Listen implementation
>
> func Listen(network, address string) (Listener, error) {
> var lc ListenConfig
> return lc.Listen(context.Background(), network, address)
> }
>
> you will notice the new listen API net.ListenConfig.
>
> This API is context aware, I think it would be handy if we had 
> net.ListenContext the same way we have Dial and DialContext.
>
> Any thoughts on that?
>

-- 
You received this message because you are subscribed 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/8abe1abb-eb3b-4632-b3c0-e430f2f42270n%40googlegroups.com.

Re: [go-nuts] Generic assembly function

[David Finkel]

On Thu, Dec 14, 2023 at 10:43 PM Clément Jean 
wrote:

> Hi,
>
> I'm currently learning how to write Go assembly on arm64 and I made the
> following functions:
>
> TEXT ·AddVector16(SB),NOSPLIT,$0-48
> MOVD a+0(FP), R0
> MOVD a+8(FP), R1
> MOVD a+16(FP), R2
> MOVD a+24(FP), R3
> VMOV R0, V0.D[0]
> VMOV R1, V0.D[1]
> VMOV R2, V1.D[0]
> VMOV R3, V1.D[1]
> VADD V1.B16, V0.B16, V0.B16
> VMOV V0.D[0], R0
> VMOV V0.D[1], R1
> MOVD R0, ret+32(FP)
> MOVD R1, ret+40(FP)
> RET
>
> TEXT ·AddVector32(SB),NOSPLIT,$0-96
> MOVD a+0(FP), R0
> MOVD a+8(FP), R1
> MOVD a+16(FP), R2
> MOVD a+24(FP), R3
> MOVD a+32(FP), R4
> MOVD a+40(FP), R5
> MOVD a+48(FP), R6
> MOVD a+56(FP), R7
> VMOV R0, V0.D[0]
> VMOV R1, V0.D[1]
> VMOV R2, V1.D[0]
> VMOV R3, V1.D[1]
> VMOV R4, V2.D[0]
> VMOV R5, V2.D[1]
> VMOV R6, V3.D[0]
> VMOV R7, V3.D[1]
> VADD V2.B16, V0.B16, V0.B16
> VADD V3.B16, V1.B16, V1.B16
> VMOV V0.D[0], R0
> VMOV V0.D[1], R1
> VMOV V1.D[0], R2
> VMOV V1.D[1], R3
> MOVD R0, ret+64(FP)
> MOVD R1, ret+72(FP)
> MOVD R2, ret+80(FP)
> MOVD R3, ret+88(FP)
> RET
> While these work, I'm forced to add the 16 and 32 suffixes. Is there any
> way to have only one function name and link the assembly to something like:
> type Uint8x16 [16]uint8
> type Uint8x32 [32]uint8
>
> //go:noescape
> func AddVector[T Uint8x16 | Uint8x32](a, b T) T
> If there is let me know, otherwise is there some other alternatives?
>
>
Unfortunately, I think a suffix is the best you can do without jumping
through some serious (and ugly) hoops.
The generics implementation opted for a "stenciling" approach, (and doesn't
support specializations) so although the symbols do encode the GC shape a
bit.
Here's the design doc for GC Shape Stenciling
https://go.googlesource.com/proposal/+/refs/heads/master/design/generics-implementation-gcshape.md



> Btw any feedback on the assembly is welcome, I'm new to 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/3224bd47-2747-4e1d-bbc5-4a5c4a300f85n%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/CANrC0Bh8ZB2R87pEJJ8eKA%3DZiSRjGpa%2BawjX8vdc0dfCMExuBQ%40mail.gmail.com.

[go-nuts] unnecessary zeroing in reflectdata.fillptrmask

[Ge]

Src: 
https://github.com/golang/go/blob/1d4b0b6236febe0646d8d7b0103da5d169f185cc/src/cmd/compile/internal/reflectdata/reflect.go#L1568-L1594

```
func dgcptrmask(t *types.Type, write bool) *obj.LSym {
...
ptrmask = make([]byte, n)
fillptrmask(t, ptrmask)
...
}

func fillptrmask(t *types.Type, ptrmask []byte) {
for i := range ptrmask {
ptrmask[i] = 0
}
...
}
```

The only caller of fillptrmask is dgcptrmask, so no need to initialize the 
ptrmask again.
And from the objdump result of the compiler binary it's not eliminated by 
DSE either.

```
➜  linux_amd64 go tool objdump -S ./compile| grep -A 30 "TEXT 
cmd/compile/internal/reflectdata.fillptrmask"
TEXT cmd/compile/internal/reflectdata.fillptrmask(SB) 
cmd/compile/internal/reflectdata/reflect.go
  0x719f40  493b6610CMPQ SP, 0x10(R14)
  0x719f44  0f868101JBE 0x71a0cb
  0x719f4a  55  PUSHQ BP
  0x719f4b  4889e5  MOVQ SP, BP
  0x719f4e  4883ec68SUBQ $0x68, SP
  0x719f52  48898c248800MOVQ CX, 0x88(SP)
  0x719f5a  48899c248000MOVQ BX, 0x80(SP)
  0x719f62  4889442460  MOVQ AX, 0x60(SP)
  0x719f67  4885c9  TESTQ CX, CX
  0x719f6a  7410JE 0x719f7c
  0x719f6c  4889d8  MOVQ BX, AX
  0x719f6f  4889cb  MOVQ CX, BX
  0x719f72  e8693ad6ff  CALL 
runtime.memclrNoHeapPointers(SB)
  0x719f77  488b442460  MOVQ 0x60(SP), AX
  0x719f7c  0f1f4000NOPL 0(AX)
  0x719f80  e81b74ebff  CALL 
cmd/compile/internal/types.PtrDataSize(SB)
  0x719f85  4885c0  TESTQ AX, AX
  0x719f88  0f8e9900JLE 0x71a027
  0x719f8e  488b94248800MOVQ 0x88(SP), DX
  0x719f96  4889d6  MOVQ DX, SI
  0x719f99  c1e203  SHLL $0x3, DX
  0x719f9c  8954243cMOVL DX, 0x3c(SP)
  0x719fa0  8d7a1f  LEAL 0x1f(DX), DI
  0x719fa3  c1ff1f  SARL $0x1f, DI
  0x719fa6  c1ef1b  SHRL $0x1b, DI
  0x719fa9  8d3cf7  LEAL 0(DI)(SI*8), DI
  0x719fac  8d7f1f  LEAL 0x1f(DI), DI
  0x719faf  c1ff05  SARL $0x5, DI
  0x719fb2  4863cf  MOVSXD DI, CX
  0x719fb5  48894c2450  MOVQ CX, 0x50(SP)
```





-- 
You received this message because you are subscribed 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/6590d17a-146d-4961-8644-0e6c8bd49632n%40googlegroups.com.

[go-nuts] Invitation to join Golang Struct Community

[Manish Rai Jain]

Hey Gophers!

I'm Manish, creator of Dgraph, Badger, Ristretto, and Sroar. As a Gopher since 
2014, I've always been passionate about our community and how we connect.

Let's face it, current chat platforms just don't cut it. They're often 
cluttered, confusing, and not great for productive conversations. That's why my 
team and I created Struct – a new way to chat that's all about clear, focused, 
and meaningful interactions.

Struct is different. It's a fresh mix of real-time conversations and 
forum-style threads, designed to make online discussions more engaging and less 
overwhelming. Here's what Struct aims for with CRISPY framework:

- Clear Context: Every thread has title, summary and tags for context.

- Real-time Chat: Instantly connect and collaborate.

- Isolated Conversations: Keep discussions focused and on-point.

- Spam-Free: Say goodbye to unwanted distractions.

- Progressive Learning using AI: Discover knowledge conversationally.

- Efficient Search: Find what you need, when you need it.

I'm thrilled to invite you to the first-ever Struct org for the Go language 
community. It's a space for us to dive into Go topics, share knowledge, and 
learn together.

Join us at Gopher Struct: 
https://gophers.struct.ai/join/uKHFUd0CPh81m73ETOhASMcb2tqCXTRJ

See you there!

Cheers,

Manish & the Struct Team

P.S. Want to know more about my journey and why I started Struct? Check out my 
story here ( https://manishrjain.com/about ).

Cheers,
Manish

Sent via Superhuman ( https://sprh.mn/?vip=manishrj...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/lqcf1f7c.68c86e9a-4808-4dbb-b64b-a6e44ff69204%40we.are.superhuman.com.

[go-nuts] Why there is no net.ListenContext?

[Michał Matczuk]

If you take a look at net.Listen implementation

func Listen(network, address string) (Listener, error) {
var lc ListenConfig
return lc.Listen(context.Background(), network, address)
}

you will notice the new listen API net.ListenConfig.

This API is context aware, I think it would be handy if we had 
net.ListenContext the same way we have Dial and DialContext.

Any thoughts on that?

-- 
You received this message because you are subscribed 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/73488643-5102-45e5-a91d-9d19f6523ec2n%40googlegroups.com.