[go-nuts] Go 1.22.6 and Go 1.21.13 are released

[announce]

Hello gophers,

We have just released Go versions 1.22.6 and 1.21.13, minor point releases.

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

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

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

Thanks to everyone who contributed to the releases.

Cheers,
David and Michael 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/psC0Td-ETheRaWP4LIMNSg%40geopod-ismtpd-5.

[go-nuts] windows: Proc.Call() forces heap allocation, while syscall.SyscallN(Proc.Addr()) doesn't

[Lorenz Bauer]

Hi,

I'm looking at calling functions from a DLL on Windows. I found syscall.DLL 
to do the job:


syscall.MustLoadDLL("foo.dll").MustFindProc("bar").Call(uintptr(unsafe.Pointer()))

Call() is annotated with //go:uintptrescapes 
,
 
which causes arg to be heap allocated. Rewriting the snippet above seems to 
avoid the escape to heap:

syscall.SyscallN(...MustFindProc("bar").Addr(), 
uintptr(unsafe.Pointer()))

Here is a fully worked snippet: https://go.dev/play/p/vJySh0z22uI The 
escape analysis shows that b doesn't escape:

go build -gcflags="-m=1" main.go
# command-line-arguments
./main.go:11:28: inlining call to syscall.MustLoadDLL
./main.go:12:26: inlining call to syscall.(*DLL).MustFindProc
./main.go:17:28: inlining call to syscall.(*Proc).Addr
./main.go:13:6: moved to heap: a
./main.go:14:11: ... argument escapes to heap
./main.go:17:18: ... argument escapes to heap

This is important for my use case because it would reduce allocations on a 
common operation.

The uintptrescapes annotation was added due to 
https://github.com/golang/go/issues/16035

A couple of questions:
- Is my analysis correct or am I missing something?
- Has anything changed in the last 8 years which means Proc.Call could be 
made to not escape its arguments?
- Does it make sense to document this on Proc.Call?

Thanks!
Lorenz

-- 
You received this message because you are subscribed 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/10645e8b-9806-4a29-8c9a-3376a9d56263n%40googlegroups.com.

[go-nuts] using runtime /debuglog.go

[Leah Stapleton]

I'm trying to debug a problem in the go runtime and wished to use the 
debuglog.go features found in 
https://github.com/golang/go/blob/master/src/runtime/debuglog.go

However,  when I follow the example 
here https://github.com/golang/go/issues/59600#issuecomment-1515040287 

d := dlog() if d != nil { d.s("foo") d.i(42) d.end() }

I can't build the Go source code

Building Go cmd/dist using /usr/local/go (go1.22.0 darwin/amd64)
Building Go toolchain1 using /usr/local/go
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1

*Invalid operation d != nil mismatched types (dlogger and untyped nil)*

I changed the code to remove the *d != nil *check, and was able to build 
the go source code, but when I build my app with this go source code using 
the *-tags debuglog*

bin/go build -tags debuglog -o myapp *.go

it is not printing any debug logs to my terminal

Can any suggest anything?

Thank you
  

invalid operation: d != nil (mismatched types dlogger and untyped nil)

Building Go cmd/dist using /usr/local/go. (go1.22.0 darwin/amd64)

Building Go toolchain1 using /usr/local/go.

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.

Building Go cmd/dist using /usr/local/go. (go1.22.0 darwin/amd64)

Building Go toolchain1 using /usr/local/go.

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.

Building Go cmd/dist using /usr/local/go. (go1.22.0 darwin/amd64)

Building Go toolchain1 using /usr/local/go.

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.

Building Go cmd/dist using /usr/local/go. (go1.22.0 darwin/amd64)

Building Go toolchain1 using /usr/local/go.

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.

Building Go cmd/dist using /usr/local/go. (go1.22.0 darwin/amd64)

Building Go toolchain1 using /usr/local/go.

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.

 invalid operation: d != nil (mismatched types dlogger and untyped 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/9d476777-34f5-4f42-8f44-5d92546d6b6cn%40googlegroups.com.

[go-nuts] Running only one sub-benchmark

[Jochen Voss]

Hello,

In a Go benchmark I use b.Run() to define a number of sub-benchmarks.  This 
seems to work:

> go test -run=^$ -bench '^BenchmarkTextLayout'
goos: darwin
goarch: arm64
pkg: seehuhn.de/go/pdf/graphics
BenchmarkTextLayout/CFFSimple1-8   49   24061184 ns/op
BenchmarkTextLayout/CFFSimple2-8   48   24036174 ns/op
BenchmarkTextLayout/OpenTypeCFFSimple1-8   49   24045372 ns/op
BenchmarkTextLayout/OpenTypeCFFSimple2-8   48   24147282 ns/op
BenchmarkTextLayout/TrueTypeSimple-8   51   23030744 ns/op
BenchmarkTextLayout/OpenTypeGlyfSimple-8   51   22865664 ns/op
BenchmarkTextLayout/BuiltIn-8   43   27654625 ns/op
...

Now I just want to run one of these sub-benchmarks.  I tried -bench 
'^BenchmarkTextLayout/CFFSimple1$' but this runs two of the benchmarks:

> go test -run=^$ -bench '^BenchmarkTextLayout/CFFSimple1$'
goos: darwin
goarch: arm64
pkg: seehuhn.de/go/pdf/graphics
BenchmarkTextLayout/CFFSimple1-8   49   24198452 ns/op
BenchmarkTextLayout/OpenTypeCFFSimple1-8   48   24209569 ns/op
PASS
ok   seehuhn.de/go/pdf/graphics 3.804s

How do I just run "BenchmarkTextLayout/CFFSimple1"?

The full code is here: 
https://github.com/seehuhn/go-pdf/blob/68fdeb74aeb39d74f9c0db6dd4117c775b0f251c/graphics/layoutext_test.go#L144

Many thanks,
Jochen

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

Re: [go-nuts] Making a post call with multiple instances of the same struct

[Marcello H]

Are you sure, when looking at the incoming message, that it is a json 
holding multiple "locks"?
If so, then you could make a small program just to unmarshall that , just 
to see what happens.

If you adjust the following code to what you want, you make it easier for 
us to understand:
https://go.dev/play/p/D_SSq2F_5hM
Op maandag 5 augustus 2024 om 20:51:23 UTC+2 schreef Ian Lance Taylor:

> On Mon, Aug 5, 2024 at 11:32 AM G K  wrote:
> >
> > I defined a global variable of the struct kind "Lock" as a slice - var 
> Lock []models.Lock
> > But then every time I tried to unmarshal the data from the post call 
> using the the reference to , I was getting an error message that 
> function couldn't unmarshal the object into a Go value. It unmarshals fine 
> you define the var Lock model.Lock as just a struct.
>
> Thanks, but rather than rephrasing into English, show us exactly what
> you did, and exactly what happened. Show us the exact code. Tell us
> the exact error message. Thanks.
>
> Ian
>
>
> > On Monday, August 5, 2024 at 11:37:26 AM UTC-5 Ian Lance Taylor wrote:
> >>
> >> On Mon, Aug 5, 2024 at 6:55 AM G K  wrote:
> >> >
> >> > I'm trying to create an HTTP rest api end where a POST method will be 
> able to accept and deserialize (unmarshall) a same data structre into 
> numerous instances. For the sake of example, lets say I have json struct:
> >> > type Lock struct
> >> > {
> >> > Key uint `json:"key"`
> >> > }
> >> > Nom Im trying to post unspecified amount of keys. I tried defying the 
> type as a slice but unmarshall function would not work. Does anyone have 
> any ideas how to go about this?
> >>
> >> Using a slice sounds like the right thing to do. What exactly did you
> >> try and what exactly happened?
> >>
> >> Ian
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/aab40be8-a26f-49f4-b762-d8527963ddcen%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/95d50aa1-c9e5-48bb-8c9e-ba0834197bbfn%40googlegroups.com.

Re: [go-nuts] Making a post call with multiple instances of the same struct

[Ian Lance Taylor]

On Mon, Aug 5, 2024 at 11:32 AM G K  wrote:
>
> I defined a global variable of the struct kind "Lock" as a slice - var Lock 
> []models.Lock
> But then every time I tried to unmarshal the data from the post call using 
> the the reference to , I was getting an error message that function 
> couldn't unmarshal the object into a Go value. It unmarshals fine you define 
> the var Lock model.Lock as just a struct.

Thanks, but rather than rephrasing into English, show us exactly what
you did, and exactly what happened.  Show us the exact code.  Tell us
the exact error message.  Thanks.

Ian


> On Monday, August 5, 2024 at 11:37:26 AM UTC-5 Ian Lance Taylor wrote:
>>
>> On Mon, Aug 5, 2024 at 6:55 AM G K  wrote:
>> >
>> > I'm trying to create an HTTP rest api end where a POST method will be able 
>> > to accept and deserialize (unmarshall) a same data structre into numerous 
>> > instances. For the sake of example, lets say I have json struct:
>> > type Lock struct
>> > {
>> > Key uint `json:"key"`
>> > }
>> > Nom Im trying to post unspecified amount of keys. I tried defying the type 
>> > as a slice but unmarshall function would not work. Does anyone have any 
>> > ideas how to go about this?
>>
>> Using a slice sounds like the right thing to do. What exactly did you
>> try and what exactly happened?
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/aab40be8-a26f-49f4-b762-d8527963ddcen%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/CAOyqgcXirXPVR9tZNgsw%2BVtmdnD%3DWJmQF_g4P6-bfWHRAe4%3DJA%40mail.gmail.com.

Re: [go-nuts] Making a post call with multiple instances of the same struct

[G K]

I defined a global variable of the struct kind "Lock" as a slice - var Lock 
[]models.Lock
But then every time I tried to unmarshal the data from the post call using 
the the reference to , I was getting an error message that function 
couldn't unmarshal the object into a Go value. It unmarshals fine you 
define the var Lock model.Lock as just a struct.
On Monday, August 5, 2024 at 11:37:26 AM UTC-5 Ian Lance Taylor wrote:

> On Mon, Aug 5, 2024 at 6:55 AM G K  wrote:
> >
> > I'm trying to create an HTTP rest api end where a POST method will be 
> able to accept and deserialize (unmarshall) a same data structre into 
> numerous instances. For the sake of example, lets say I have json struct:
> > type Lock struct
> > {
> > Key uint `json:"key"`
> > }
> > Nom Im trying to post unspecified amount of keys. I tried defying the 
> type as a slice but unmarshall function would not work. Does anyone have 
> any ideas how to go about this?
>
> Using a slice sounds like the right thing to do. What exactly did you
> try and what exactly happened?
>
> Ian
>

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

Re: [go-nuts] Making a post call with multiple instances of the same struct

[Ian Lance Taylor]

On Mon, Aug 5, 2024 at 6:55 AM G K  wrote:
>
>I'm trying to create an HTTP rest api end where a POST method will be able 
> to accept and deserialize (unmarshall) a same data structre into numerous 
> instances. For the sake of example, lets say I have json struct:
> type Lock struct
> {
>Key uint  `json:"key"`
> }
> Nom Im trying to post unspecified amount of keys. I tried defying the type as 
> a slice but unmarshall function would not work. Does anyone have any ideas 
> how to go about this?

Using a slice sounds like the right thing to do.  What exactly did you
try and what exactly happened?

Ian

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

[go-nuts] Making a post call with multiple instances of the same struct

[G K]

Hi,
   I'm trying to create an HTTP rest api end where a POST method will be 
able to accept and deserialize (unmarshall) a same data structre into 
numerous instances. For the sake of example, lets say I have json struct:
type Lock struct
{
   Key uint  `json:"key"`
}
Nom Im trying to post unspecified amount of keys. I tried defying the type 
as a slice but unmarshall function would not work. Does anyone have any 
ideas how to go about this?
Thanks,
GK

-- 
You received this message because you are subscribed 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/b3d9e8a1-a2d7-4cfc-8c86-cd859bfb0d6en%40googlegroups.com.

[go-nuts] Re: ANN: fun: call your LLMs like they are just a function

[Michael Oguidan]

Thank you @Mitar for sharing this knowledge with us.

On Sunday, August 4, 2024 at 8:52:29 AM UTC Mitar wrote:

> Hi!
>
> I made a small library which allows using AI models like they were
> just a Go function, but that Go function can be:
>
> - defined with natural language description
> - example inputs with expected outputs
> - or both
>
> Internally, it then calls into an LLM to get the answer. So it is not
> fast, but it is an interesting new way to define your functions. Check
> it out, any feedback welcome:
>
> https://gitlab.com/tozd/go/fun
>
> Caveat: Current LLMs available still randomly return trash for some
> inputs, even if they work great for very similar other inputs. But
> hopefully that will improve through time. And there are some ways to
> check for this (using JSON Schema to validate outputs, comparing
> outputs of multiple models, etc.).
>
>
> Mitar
>
> -- 
> https://mitar.tnode.com/
> https://twitter.com/mitar_m
> https://noc.social/@mitar
>

-- 
You received this message because you are subscribed 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/b6791b49-eefa-499a-ab9e-ea40612d96fcn%40googlegroups.com.

[go-nuts] ANN: fun: call your LLMs like they are just a function

[Mitar]

Hi!

I made a small library which allows using AI models like they were
just a Go function, but that Go function can be:

- defined with natural language description
- example inputs with expected outputs
- or both

Internally, it then calls into an LLM to get the answer. So it is not
fast, but it is an interesting new way to define your functions. Check
it out, any feedback welcome:

https://gitlab.com/tozd/go/fun

Caveat: Current LLMs available still randomly return trash for some
inputs, even if they work great for very similar other inputs. But
hopefully that will improve through time. And there are some ways to
check for this (using JSON Schema to validate outputs, comparing
outputs of multiple models, etc.).


Mitar

-- 
https://mitar.tnode.com/
https://twitter.com/mitar_m
https://noc.social/@mitar

-- 
You received this message because you are subscribed 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/CAKLmikPBH3ouhKbEt7v%3D2mBVwVxZ6DbKESSOZb6dfjMKk6BVoA%40mail.gmail.com.

Re: [go-nuts] Why do I get "The connection was reset" error when uploading a ~10MB file, and how to avoid reading the file into memory?

[Robert Engels]

Check out this https://jesseduffield.com/Golang-IO-Cookbook/ to see how to transfer the body to a file without reading the whole thing into memory. On Aug 2, 2024, at 12:41 PM, Robert Engels  wrote:You most likely have to read the incoming data. Depends on the framework. The tcp connection is reused so if you don’t read all of the sent data then the next request will be corrupted. I am not sure why it works with small files - I guess that the framework is reading some of the data into the request body buffer - and if it reads the full request body in doing so that would explain it. On Aug 2, 2024, at 12:35 PM, Denis Korovin  wrote:Hi everyone,I'm running into an issue with my Go server when trying to upload files around 10MB using a simple file upload form. In my browser, I'm seeing a "The connection was reset" error, and I'm not sure what is causing this problem or how to fix it.Here’s my current setup:  https://go.dev/play/p/7TVn-njfeiHWhen I attempt to upload a file around 10MB through this form, the browser gives me a "The connection was reset" error. I’ve verified that smaller files upload without any issues.My uploadHandler currently does nothing but send a 200 OK status. Ideally, I'd like to process the file upload without reading it entirely into memory, to handle larger file uploads efficiently.Can anyone help me understand why I'm getting this error and how to properly handle large file uploads without reading them completely into memory? Any guidance or examples would be greatly appreciated.Thanks in advance!



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f9cbb87f-c597-4249-a13e-fbc634b38e1bn%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/FAC045FC-BB12-4255-B42E-858CD9C154BA%40ix.netcom.com.

Re: [go-nuts] Why do I get "The connection was reset" error when uploading a ~10MB file, and how to avoid reading the file into memory?

[Robert Engels]

You most likely have to read the incoming data. Depends on the framework. The tcp connection is reused so if you don’t read all of the sent data then the next request will be corrupted. I am not sure why it works with small files - I guess that the framework is reading some of the data into the request body buffer - and if it reads the full request body in doing so that would explain it. On Aug 2, 2024, at 12:35 PM, Denis Korovin  wrote:Hi everyone,I'm running into an issue with my Go server when trying to upload files around 10MB using a simple file upload form. In my browser, I'm seeing a "The connection was reset" error, and I'm not sure what is causing this problem or how to fix it.Here’s my current setup:  https://go.dev/play/p/7TVn-njfeiHWhen I attempt to upload a file around 10MB through this form, the browser gives me a "The connection was reset" error. I’ve verified that smaller files upload without any issues.My uploadHandler currently does nothing but send a 200 OK status. Ideally, I'd like to process the file upload without reading it entirely into memory, to handle larger file uploads efficiently.Can anyone help me understand why I'm getting this error and how to properly handle large file uploads without reading them completely into memory? Any guidance or examples would be greatly appreciated.Thanks in advance!



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f9cbb87f-c597-4249-a13e-fbc634b38e1bn%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/22E935CC-E806-498F-8ECB-4487A6783965%40ix.netcom.com.

[go-nuts] Why do I get "The connection was reset" error when uploading a ~10MB file, and how to avoid reading the file into memory?

[Denis Korovin]

Hi everyone,

I'm running into an issue with my Go server when trying to upload files 
around 10MB using a simple file upload form. In my browser, I'm seeing a 
"The connection was reset" error, and I'm not sure what is causing this 
problem or how to fix it.

Here’s my current setup:  https://go.dev/play/p/7TVn-njfeiH

When I attempt to upload a file around 10MB through this form, the browser 
gives me a "The connection was reset" error. I’ve verified that smaller 
files upload without any issues.

My uploadHandler currently does nothing but send a 200 OK status. Ideally, 
I'd like to process the file upload without reading it entirely into 
memory, to handle larger file uploads efficiently.

Can anyone help me understand why I'm getting this error and how to 
properly handle large file uploads without reading them completely into 
memory? Any guidance or examples would be greatly appreciated.

Thanks in advance!

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

Re: [go-nuts] Request for Removal of Problematic Version: github.com/alibabacloud-go/ecs-20140526/v4 v4.24.17

['Axel Wagner' via golang-nuts]

Hi,

I believe module retraction 
was designed for this specific use case. It allows you to mark a specific
version as defective, without breaking any builds or anything - and without
requiring manual intervention by any module proxies. Note, in particular,
that there are more module proxies than just the default, public one. Even
if a version gets removed from that, people might still get the defective
version from a private or third-party proxy they use. Retraction doesn't
have that issue.

On Fri, 2 Aug 2024 at 06:23, papaya du  wrote:

> Dear Go Package Management Team,
>
> We have identified critical issues in the `v4.24.17` version of our
> package `github.com/alibabacloud-go/ecs-20140526/v4`
>  that severely affect
> its usability. To prevent any disruptions for users who rely on this
> package, we kindly request the removal of this specific version from the
> repository.
>
> Details:
> - Package: github.com/alibabacloud-go/ecs-20140526/v4
> - Version to be removed: v4.24.17
>
> Please note that we have already deleted the corresponding release and tag
> from our GitHub repository. The issues have been resolved in later
> versions, and we recommend users to update to the latest stable release.
>
> We understand the importance of maintaining a coherent and reliable
> package ecosystem and are committed to ensuring the quality and stability
> of our offerings. We apologize for any inconvenience caused and appreciate
> your assistance in this matter.
>
> Thank you for your attention and support. Should you require any
> additional information, please do not hesitate to contact us.
>
> Best regards.
>
> --
> You received this message because you are subscribed 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/a202c46f-1545-4863-8f62-dc67bbcd2e8en%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/CAEkBMfFY50pHByzr_3HrViCh4--vJyf3tVEJSO_f%2BhVBu_eJvQ%40mail.gmail.com.

[go-nuts] Request for Removal of Problematic Version: github.com/alibabacloud-go/ecs-20140526/v4 v4.24.17

[papaya du]

Dear Go Package Management Team,

We have identified critical issues in the `v4.24.17` version of our package 
`github.com/alibabacloud-go/ecs-20140526/v4` that severely affect its 
usability. To prevent any disruptions for users who rely on this package, 
we kindly request the removal of this specific version from the repository.

Details:
- Package: github.com/alibabacloud-go/ecs-20140526/v4
- Version to be removed: v4.24.17

Please note that we have already deleted the corresponding release and tag 
from our GitHub repository. The issues have been resolved in later 
versions, and we recommend users to update to the latest stable release.

We understand the importance of maintaining a coherent and reliable package 
ecosystem and are committed to ensuring the quality and stability of our 
offerings. We apologize for any inconvenience caused and appreciate your 
assistance in this matter.

Thank you for your attention and support. Should you require any additional 
information, please do not hesitate to contact us.

Best regards.

-- 
You received this message because you are subscribed 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/a202c46f-1545-4863-8f62-dc67bbcd2e8en%40googlegroups.com.

[go-nuts] Can't Set Breakpoint on runtime.assertE2I with Delve – Can Someone Help?

[六六RyuRyu]

I’m encountering a panic issue with runtime.assertE2I in my program. Since 
I can’t reproduce it consistently, I want to debug this function to 
understand its purpose and find the cause of the panic.
Here’s the relevant stack trace:

log.msgpanic({0x6281f60, 0xc099c50810}) /usr/local/go/src/runtime/panic.go:987 
+0x3ba fp=0xc04e9bab20 sp=0xc04e9baa60 pc=0x43b91a runtime.assertE2I(0x62fa080, 
0x12?) /usr/local/go/src/runtime/iface.go:451 +0x6d fp=0xc04e9bab48 
sp=0xc04e9bab20 pc=0x40d5ed

I’m having trouble setting a breakpoint on runtime.assertE2I using Delve. 
Does anyone know how I can achieve this?
*Additional Description:* When I tried to reproduce the issue with the 
following code:

type MyInterface interface {
`Method()`

}

type MyStruct struct{}

func main() {
`var i interface{} = MyStruct{}`
 `_ = i.(MyInterface)`

}

I found that the panic occurs in runtime.typeAssert instead of 
runtime.assertE2I. I’m not sure why this happens.

-- 
You received this message because you are subscribed 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/dc810cfc-c85b-422e-8ae6-7882ee0d9402n%40googlegroups.com.

[go-nuts] Re: photoslibrary/v1 no longer available

[peterGo]

On Thursday, August 1, 2024 at 9:30:27 AM UTC-4 Pratik Tamgole wrote:


Have tried using v0.3.2 and 0.189.0, but still getting the broken import 
error, the file does not seem to be there.

 
Really!

Follow the photoslibrary team instructions from my earlier post:  "vendor 
this library at v0.3.2."

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

peter

Regards,
Pratik Tamgole.

On Wednesday, July 31, 2024 at 7:30:37 PM UTC+5:30 peterGo wrote:

Pratik Tamgole

Changes
https://github.com/googleapis/google-api-go-client/blob/main/CHANGES.md

v0.4.0

Deletes photoslibrary/v1. The photoslibrary team hopes to fully support Go 
in the near future, but this autogenerated library is ready to be sunset. 
If you rely on this client, please vendor this library at v0.3.2.

For v0.3.2:
https://github.com/googleapis/google-api-go-client/tree/v0.3.2/photoslibrary/v1

peter

On Wednesday, July 31, 2024 at 9:05:10 AM UTC-4 Pratik Tamgole wrote:

Hi,

I'm trying to use the Go library photoslibrary/v1 but getting an error 
message saying:
 
*"google.golang.org/api/photoslibrary/v1 
: module 
google.golang.org/api@latest  found 
(v0.189.0), but does not contain package 
google.golang.org/api/photoslibrary/v1 
"*

And it seems they have removed it from the source.

How do I go about replacing this? Any other library that can help my app 
integrate with the GooglePhotos app? And if there is any other solution to 
working with the photoslibrary library? 


Regards, 
Pratik Tamgole

-- 
You received this message because you are subscribed 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/3fd496e5-4773-4c91-9d40-bbde9626bd55n%40googlegroups.com.

[go-nuts] Re: Help with reloading data on the HTML page

[Edgar Madrigal]

Might be worth to have functional demo in github? Not sure if you are doing 
webscraping or a browser or just a web app.

This appears more on the front end side, using javascript? Something like 
`window.reload`?
On Wednesday, July 31, 2024 at 8:29:20 AM UTC-6 Wellington Arantes wrote:

> Hello, First of all, I load the page HTML to search for information, and 
> this page HTML has one input text and one button, when I  type and click on 
> the button, I search for information on DB, and with data try to reload the 
> page with, but it's not happening.
>
>
> How do I reload that same page with data?

-- 
You received this message because you are subscribed 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/e5df0084-ba3c-47ca-83f5-c36e0f84eff2n%40googlegroups.com.

Re: [go-nuts] photoslibrary/v1 no longer available

[robert engels]

There is also a third-party library that might work or be a great starting 
point: https://github.com/gphotosuploader/google-photos-api-client-go

> On Aug 1, 2024, at 9:15 AM, robert engels  wrote:
> 
> It should be fairly straightforward to use the Rest api directly 
> https://developers.google.com/photos/library/guides/get-started 
> 
> 
> You can also look at the Java or PhP client library and reimplement in Go - 
> sadly it doesn’t seem they provide the raw proto files you could use to 
> generate the Go structs so you’ll have to do it by hand for the operations 
> you need.
> 
>> On Aug 1, 2024, at 1:41 AM, Pratik Tamgole > > wrote:
>> 
>> Hi,
>> Thank you for all the information.
>> 
>> Have tried using v0.3.2 and 0.189.0, but still getting the broken import 
>> error, the file does not seem to be there.
>> 
>> Also James, tried the 
>> https://pkg.go.dev/github.com/mathieubrun/go-google-photos-api/photoslibrary/v1
>>  
>> 
>>  but to no avail.
>> Changing the webapp on my side to be able to upload straight from the device 
>> rather than uploading it from google drive. 
>> 
>> Can you recommend resources to me if I want to make a repo like 
>> "https://pkg.go.dev/github.com/mathieubrun/go-google-photos-api/photoslibrary/v1
>>  
>> "
>>  as a substitute?
>>  
>> Again thanks for all your help!
>> 
>> Regards,
>> Pratik Tamgole.
>> 
>> On Wednesday, July 31, 2024 at 7:30:37 PM UTC+5:30 peterGo wrote:
>> Pratik Tamgole
>> 
>> Changes
>> https://github.com/googleapis/google-api-go-client/blob/main/CHANGES.md 
>> 
>> 
>> v0.4.0
>> 
>> Deletes photoslibrary/v1. The photoslibrary team hopes to fully support Go 
>> in the near future, but this autogenerated library is ready to be sunset. If 
>> you rely on this client, please vendor this library at v0.3.2.
>> 
>> For v0.3.2:
>> https://github.com/googleapis/google-api-go-client/tree/v0.3.2/photoslibrary/v1
>>  
>> 
>> 
>> peter
>> 
>> On Wednesday, July 31, 2024 at 9:05:10 AM UTC-4 Pratik Tamgole wrote:
>> Hi,
>> 
>> I'm trying to use the Go library photoslibrary/v1 but getting an error 
>> message saying:
>>  
>> "google.golang.org/api/photoslibrary/v1 
>> : module 
>> google.golang.org/api@latest  found 
>> (v0.189.0), but does not contain package 
>> google.golang.org/api/photoslibrary/v1 
>> "
>> 
>> And it seems they have removed it from the source.
>> 
>> How do I go about replacing this? Any other library that can help my app 
>> integrate with the GooglePhotos app? And if there is any other solution to 
>> working with the photoslibrary library? 
>> 
>> 
>> Regards, 
>> Pratik Tamgole
>> 
>> 
>> -- 
>> You received this message because you are subscribed 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/ebdd26be-462f-4924-8085-c0a9f8f9cd70n%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/10081CDD-3BDA-4362-92FE-5398F4BBE3C7%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/F50EC8E8-D246-48E7-ACE9-AA8DF92AA109%40ix.netcom.com.

Re: [go-nuts] photoslibrary/v1 no longer available

[robert engels]

It should be fairly straightforward to use the Rest api directly 
https://developers.google.com/photos/library/guides/get-started 


You can also look at the Java or PhP client library and reimplement in Go - 
sadly it doesn’t seem they provide the raw proto files you could use to 
generate the Go structs so you’ll have to do it by hand for the operations you 
need.

> On Aug 1, 2024, at 1:41 AM, Pratik Tamgole  wrote:
> 
> Hi,
> Thank you for all the information.
> 
> Have tried using v0.3.2 and 0.189.0, but still getting the broken import 
> error, the file does not seem to be there.
> 
> Also James, tried the 
> https://pkg.go.dev/github.com/mathieubrun/go-google-photos-api/photoslibrary/v1
>  
> 
>  but to no avail.
> Changing the webapp on my side to be able to upload straight from the device 
> rather than uploading it from google drive. 
> 
> Can you recommend resources to me if I want to make a repo like 
> "https://pkg.go.dev/github.com/mathieubrun/go-google-photos-api/photoslibrary/v1
>  
> "
>  as a substitute?
>  
> Again thanks for all your help!
> 
> Regards,
> Pratik Tamgole.
> 
> On Wednesday, July 31, 2024 at 7:30:37 PM UTC+5:30 peterGo wrote:
> Pratik Tamgole
> 
> Changes
> https://github.com/googleapis/google-api-go-client/blob/main/CHANGES.md 
> 
> 
> v0.4.0
> 
> Deletes photoslibrary/v1. The photoslibrary team hopes to fully support Go in 
> the near future, but this autogenerated library is ready to be sunset. If you 
> rely on this client, please vendor this library at v0.3.2.
> 
> For v0.3.2:
> https://github.com/googleapis/google-api-go-client/tree/v0.3.2/photoslibrary/v1
>  
> 
> 
> peter
> 
> On Wednesday, July 31, 2024 at 9:05:10 AM UTC-4 Pratik Tamgole wrote:
> Hi,
> 
> I'm trying to use the Go library photoslibrary/v1 but getting an error 
> message saying:
>  
> "google.golang.org/api/photoslibrary/v1 
> : module 
> google.golang.org/api@latest  found 
> (v0.189.0), but does not contain package 
> google.golang.org/api/photoslibrary/v1 
> "
> 
> And it seems they have removed it from the source.
> 
> How do I go about replacing this? Any other library that can help my app 
> integrate with the GooglePhotos app? And if there is any other solution to 
> working with the photoslibrary library? 
> 
> 
> Regards, 
> Pratik Tamgole
> 
> 
> -- 
> You received this message because you are subscribed 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/ebdd26be-462f-4924-8085-c0a9f8f9cd70n%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/10081CDD-3BDA-4362-92FE-5398F4BBE3C7%40ix.netcom.com.

[go-nuts] Re: photoslibrary/v1 no longer available

[Pratik Tamgole]

Hi,
Thank you for all the information.

Have tried using v0.3.2 and 0.189.0, but still getting the broken import 
error, the file does not seem to be there.

Also James, tried the 
https://pkg.go.dev/github.com/mathieubrun/go-google-photos-api/photoslibrary/v1 
but 
to no avail.
Changing the webapp on my side to be able to upload straight from the 
device rather than uploading it from google drive. 

Can you recommend resources to me if I want to make a repo like "
https://pkg.go.dev/github.com/mathieubrun/go-google-photos-api/photoslibrary/v1;
 
as a substitute?
 
Again thanks for all your help!

Regards,
Pratik Tamgole.

On Wednesday, July 31, 2024 at 7:30:37 PM UTC+5:30 peterGo wrote:

> Pratik Tamgole
>
> Changes
> https://github.com/googleapis/google-api-go-client/blob/main/CHANGES.md
>
> v0.4.0
>
> Deletes photoslibrary/v1. The photoslibrary team hopes to fully support Go 
> in the near future, but this autogenerated library is ready to be sunset. 
> If you rely on this client, please vendor this library at v0.3.2.
>
> For v0.3.2:
>
> https://github.com/googleapis/google-api-go-client/tree/v0.3.2/photoslibrary/v1
>
> peter
>
> On Wednesday, July 31, 2024 at 9:05:10 AM UTC-4 Pratik Tamgole wrote:
>
>> Hi,
>>
>> I'm trying to use the Go library photoslibrary/v1 but getting an error 
>> message saying:
>>  
>> *"google.golang.org/api/photoslibrary/v1 
>> : module 
>> google.golang.org/api@latest  found 
>> (v0.189.0), but does not contain package 
>> google.golang.org/api/photoslibrary/v1 
>> "*
>>
>> And it seems they have removed it from the source.
>>
>> How do I go about replacing this? Any other library that can help my app 
>> integrate with the GooglePhotos app? And if there is any other solution to 
>> working with the photoslibrary library? 
>>
>>
>> Regards, 
>> Pratik Tamgole
>>
>>

-- 
You received this message because you are subscribed 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/ebdd26be-462f-4924-8085-c0a9f8f9cd70n%40googlegroups.com.

[go-nuts] [ANN] sako: a Wallabag-compatible read-it-later application

['Sebastien Binet' via golang-nuts]

hi there,

I've just tagged v0.3.0 of sako[1], a Wallabag[2]-compatible read-it-later 
application.

I was getting tired of using the shared Wallabag instance from one of the 
CHATONS[3], which was getting slow (especially on the weekends), and I didn't 
want to self-host a big PHP stack.
So I've implemented `sako`, a pure-Go server (and client), that tries to be 
compatible with the Wallabag ecosystem (namely, the Wallabagger[4] plugin and 
the companion Android-App[5]).

In a nutshell:

```
$> go install git.sr.ht/~sbinet/sako/cmd/sako-mgr@latest

## create a new sako installation, with a super user
$> export SAKO_ROOT=/path/to/sako/data-dir
$> sako-mgr init -pass SomeS3cr3t -root ${SAKO_ROOT}

## adding a normal user
$> sako-mgr user-add -user bob -pass s3cr3t -email b...@example.org ${SAKO_ROOT}

## adding a sako-client (for use with the sako REST API)
$> sako-mgr client-add -user bob -client-name 'my sako client' ${SAKO_ROOT}
client for user "bob" created:
client-id=1_
client-secret=

## importing data from a remote Wallabag instance
$> sako-mgr import \
-src-uri https://wallabag.example.org \
-src-usr bob-on-wallabag  \
-src-pwd bob-pwd-on-wallabag  \
-src-api-id ${WALLABAG_CLIENT_ID} \
-src-api-secret ${WALLABAG_CLIENT_SECRET} \
-dst-uri ${SAKO_ROOT} \
-dst-usr bob  \
-dst-pwd s3cr3t

## using sako:
$> go install git.sr.ht/~sbinet/sako/cmd/sako-srv@latest
$> sako-srv -addr :8080 -dir ${SAKO_ROOT}
```

Screenshots are available on ~sbinet/sako.

Many thanks to Egon Elbre for their set of freely available (and cute) 
gophers[6] (and the one hiking with a backpack).

hth,
-s

[1]: https://sr.ht/~sbinet/sako/
[2]: https://wallabag.org/
[3]: https://chatons.org
[4]: https://github.com/wallabag/wallabagger
[5]: https://github.com/wallabag/android-app
[6]: https://github.com/egonelbre/gophers

PS: you need Go-1.23 (as sako is using iter.Seq2[T,U] and friends)

-- 
You received this message because you are subscribed 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/D33VTGWNEWMZ.26ESZQUY7YJRK%40sbinet.org.

[go-nuts] Help with reloading data on the HTML page

[Wellington Arantes]

Hello, First of all, I load the page HTML to search for information, and 
this page HTML has one input text and one button, when I  type and click on 
the button, I search for information on DB, and with data try to reload the 
page with, but it's not happening.


How do I reload that same page with data?

-- 
You received this message because you are subscribed 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/755d9924-dcbd-4f1e-b3a1-cb33d0d769b7n%40googlegroups.com.

[go-nuts] Re: photoslibrary/v1 no longer available

[peterGo]

Pratik Tamgole

Changes
https://github.com/googleapis/google-api-go-client/blob/main/CHANGES.md

v0.4.0

Deletes photoslibrary/v1. The photoslibrary team hopes to fully support Go 
in the near future, but this autogenerated library is ready to be sunset. 
If you rely on this client, please vendor this library at v0.3.2.

For v0.3.2:
https://github.com/googleapis/google-api-go-client/tree/v0.3.2/photoslibrary/v1

peter

On Wednesday, July 31, 2024 at 9:05:10 AM UTC-4 Pratik Tamgole wrote:

> Hi,
>
> I'm trying to use the Go library photoslibrary/v1 but getting an error 
> message saying:
>  
> *"google.golang.org/api/photoslibrary/v1 
> : module 
> google.golang.org/api@latest  found 
> (v0.189.0), but does not contain package 
> google.golang.org/api/photoslibrary/v1 
> "*
>
> And it seems they have removed it from the source.
>
> How do I go about replacing this? Any other library that can help my app 
> integrate with the GooglePhotos app? And if there is any other solution to 
> working with the photoslibrary library? 
>
>
> Regards, 
> Pratik Tamgole
>
>

-- 
You received this message because you are subscribed 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/93314f1b-3c9c-454a-95f3-ee8d91e0f015n%40googlegroups.com.

[go-nuts] Re: photoslibrary/v1 no longer available

[peterGo]

Pratik Tamgole

Changes
https://github.com/googleapis/google-api-go-client/blob/main/CHANGES.md

v0.4.0

Deletes photoslibrary/v1. The photoslibrary team hopes to fully support Go 
in the near future, but this autogenerated library is ready to be sunset. 
If you rely on this client, please vendor this library at v0.3.2.

peter

On Wednesday, July 31, 2024 at 9:05:10 AM UTC-4 Pratik Tamgole wrote:

> Hi,
>
> I'm trying to use the Go library photoslibrary/v1 but getting an error 
> message saying:
>  
> *"google.golang.org/api/photoslibrary/v1 
> : module 
> google.golang.org/api@latest  found 
> (v0.189.0), but does not contain package 
> google.golang.org/api/photoslibrary/v1 
> "*
>
> And it seems they have removed it from the source.
>
> How do I go about replacing this? Any other library that can help my app 
> integrate with the GooglePhotos app? And if there is any other solution to 
> working with the photoslibrary library? 
>
>
> Regards, 
> Pratik Tamgole
>
>

-- 
You received this message because you are subscribed 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/5d61ea8e-b6f5-4ad3-a86f-e004111b1021n%40googlegroups.com.

[go-nuts] Re: photoslibrary/v1 no longer available

[James Hawkins]

Hi Pratik,

Is this what you looking for?

https://pkg.go.dev/google.golang.org/api/photoslibrary/v1


v0.3.2
Apr 8, 2019
v0.3.1
Apr 8, 2019
v0.3.1-alpha
Apr 8, 2019
v0.3.0
Mar 26, 2019
v0.2.0
Mar 13, 2019
v0.1.0
Jan 2, 2019

Not sure where you getting the v0.189.0 version from that may be the 
symptom to your issue.

Also searching pkg.go.dev there are other packages you could use 

https://pkg.go.dev/github.com/mathieubrun/go-google-photos-api/photoslibrary/v1

Regards,

James

On Wednesday 31 July 2024 at 15:05:10 UTC+2 Pratik Tamgole wrote:

> Hi,
>
> I'm trying to use the Go library photoslibrary/v1 but getting an error 
> message saying:
>  
> *"google.golang.org/api/photoslibrary/v1 
> : module 
> google.golang.org/api@latest  found 
> (v0.189.0), but does not contain package 
> google.golang.org/api/photoslibrary/v1 
> "*
>
> And it seems they have removed it from the source.
>
> How do I go about replacing this? Any other library that can help my app 
> integrate with the GooglePhotos app? And if there is any other solution to 
> working with the photoslibrary library? 
>
>
> Regards, 
> Pratik Tamgole
>
>

-- 
You received this message because you are subscribed 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/9dbeb9c0-8c97-4a98-94fc-8dd3c7df555dn%40googlegroups.com.

[go-nuts] Re: photoslibrary/v1 no longer available

[peterGo]

Pratik Tamgole,

Changes
https://groups.google.com/g/golang-nuts/c/e7LnsRmTWrg

v0.4.0

Deletes photoslibrary/v1. The photoslibrary team hopes to fully support Go 
in the near future, but this autogenerated library is ready to be sunset. 
If you rely on this client, please vendor this library at v0.3.2.

peter

On Wednesday, July 31, 2024 at 9:05:10 AM UTC-4 Pratik Tamgole wrote:

> Hi,
>
> I'm trying to use the Go library photoslibrary/v1 but getting an error 
> message saying:
>  
> *"google.golang.org/api/photoslibrary/v1 
> : module 
> google.golang.org/api@latest  found 
> (v0.189.0), but does not contain package 
> google.golang.org/api/photoslibrary/v1 
> "*
>
> And it seems they have removed it from the source.
>
> How do I go about replacing this? Any other library that can help my app 
> integrate with the GooglePhotos app? And if there is any other solution to 
> working with the photoslibrary library? 
>
>
> Regards, 
> Pratik Tamgole
>
>

-- 
You received this message because you are subscribed 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/cf31271d-f9f5-4485-8d76-4f2439cb2c63n%40googlegroups.com.

[go-nuts] photoslibrary/v1 no longer available

[Pratik Tamgole]

Hi,

I'm trying to use the Go library photoslibrary/v1 but getting an error 
message saying:
 
*"google.golang.org/api/photoslibrary/v1: module 
google.golang.org/api@latest found (v0.189.0), but does not contain package 
google.golang.org/api/photoslibrary/v1"*

And it seems they have removed it from the source.

How do I go about replacing this? Any other library that can help my app 
integrate with the GooglePhotos app? And if there is any other solution to 
working with the photoslibrary library? 


Regards, 
Pratik Tamgole

-- 
You received this message because you are subscribed 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/3454424b-6f58-4bf3-aeb7-d390c81a1208n%40googlegroups.com.

[go-nuts] Re: help with basic tutorial

[Excel Ojo (Dude)]

hello, if you are new to Golang, you can learn with Test with Golang 
 and all check out Effective 
Golang . The later will really help you 
with understanding functions and all

On Wednesday, July 31, 2024 at 1:28:35 PM UTC+1 Cesar Marinho wrote:

> any good tutorial in some fundamentals?
> I am having some difficulties with including go files and use functions 
> between them.
> thanks!
>

-- 
You received this message because you are subscribed 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/d7815755-a495-4bfa-9ccf-802c540f743cn%40googlegroups.com.

[go-nuts] help with basic tutorial

[Cesar Marinho]

any good tutorial in some fundamentals?
I am having some difficulties with including go files and use functions 
between them.
thanks!

-- 
You received this message because you are subscribed 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/8fb8c52f-55c7-48ef-9484-71c06796506bn%40googlegroups.com.

[go-nuts] Re: What is the time complexity of math.Pow function?

[3613_PRANAB NANDI]

can you please explain the logic or give a reference to the logic

On Friday, May 17, 2019 at 11:16:50 AM UTC+5:30 navnee...@globallogic.com 
wrote:

> Yes 
> because we use divide and conquer method to solve recursively the problem 
> and get the solution in O(log(n)) times where n is the power
>
>
> On Thursday, January 14, 2016 at 10:06:39 PM UTC+5:30, Jingguo Yao wrote:
>>
>> What is the time complexity of Math.Pow(x, y) function (
>> https://golang.org/pkg/math/#Pow) in terms of x and y when the values of 
>> x and y are not for the special cases? I have skimmed the source code (
>> https://golang.org/src/math/pow.go?s=1186:1216#L28). And it seems that 
>> the time complexity is O(log2(y)). So the time complexity for 
>> math.Pow(0.87, 16384) should be O(log2(16384)) = (log2(2^14)) = O(14).
>>
>> Is my understanding correct?
>>
>>
-- 


* *

*
Go Green: Kindly don't print this unless so 
required.*

*
*

*Established U/S 3 of UGC Act and Accredited by NBA of 
AICTE and NAAC of UGC*



Visit us @ *http://www.kiit.ac.in 
*

Follow us @* **|***Twitter 
***|***Facebook** 
*|***Instagram 
***|*


 
  
  

The information 
contained in this electronic message and any
  attachments to this message 
are intended for the exclusive use of the
  addressee(s) and may contain 
proprietary, confidential or privileged
  information. If you are not the 
intended recipient, you should not
  disseminate, distribute or copy this 
e-mail. Please notify the sender
  immediately and delete all copies of 
this message and any attachments.
  

 VIRUS WARNING: Computer viruses can 
be
  transmitted via email. The recipient should check this email and any
  
attachments for the presence of viruses. The institute accepts no liability
  for any damage caused by any virus transmitted by this email.
  

 






-- 
You received this message because you are subscribed 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/4755b9a6-7a3f-407e-98cc-4ed737086bd1n%40googlegroups.com.

[go-nuts] Re: Optimization Question: Convert Array to Slice without Allocation

['Brian Candler' via golang-nuts]

On Tuesday 30 July 2024 at 21:54:32 UTC+1 William Gilmore wrote:


func DCT2DFast8(in []float64) (out [64]) {...} - Optimized static code, 0 
allocations when called directly. See following benchmark.


I am guessing return should be something like *out [64]float64* ?

 


Ideally, I would like for the following to work:

return (DCT2DFast8(result)[:]


(Aside: parentheses don't match)

 

Unfortunately, this does not since the function's return value is transient 
and the slice expression cannot operate on it.


By "transient" I think you mean "not addressable".  Try returning a pointer 
to the array, instead of an array value:
https://go.dev/play/p/4CTek2r78sk


-- 
You received this message because you are subscribed 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/27fd8942-7e9f-4bd8-b3f0-6a3bea5d5cdfn%40googlegroups.com.

[go-nuts] Golang Tour - Spanish Version

[Thiago Mowszet]

Hello!

The Gophers LATAM community completed the translation of the Go Tour 
several months ago. However, we have not yet received a response to our 
pull request. You can find the web address of the translation 
at: https://go-tour-lat.appspot.com 
Additionally, the issues and PR can be found at: 
https://github.com/golang/go/issues/64454 - 
https://github.com/golang/website/pull/264

Thank you for your attention.

Best regards,

Thiago Mowszet - Gophers LATAM Community

-- 
You received this message because you are subscribed 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/e565a8d5-ef34-4417-ba9f-6f4356e11c3dn%40googlegroups.com.

[go-nuts] Optimization Question: Convert Array to Slice without Allocation

[William Gilmore]

I am working on optimizing code to calculate discrete cosine transforms. I 
am doing this by implementing static code for a given array size vs. using 
code that can dynamically handle a slice of any size. Overall, I am seeing 
amazing performance - kudos Go compiler. I have one last optimization 
opportunity that I would like to achieve. Unfortunately, my Gofu is not 
sufficient to figure it out on my own. Is there a way to convert a fixed 
size array to a slice without having to incur 2 allocations.

Go Environment information:
go version go1.22.4 linux/amd64

   
Example:

func DCT2DFast8(in []float64) (out [64]) {...} - Optimized static code, 0 
allocations when called directly. See following benchmark.

func BenchmarkDCT2DFast8(b *testing.B) {
  for i := 0; i < b.N; i++ {
_ = DCT2DFast8(ary2d_flat[8])
  }
}

BenchmarkDCT2DFast8-12 1372852   757.9 ns/op   0 B/op   0 
allocs/op

Same functionality but wrapped in the generalized function that can be 
called for any size slice

func DCT_2D(input []float64, sz int) []float64 {
  ...
  if sz == 8 {
  r := DCT2DFast8(result)
  return []float64(r[:])
}
...
  }

BenchmarkDCT_2D_8-12  340670  3227 ns/op1024 B/op   2 
allocs/op

Is there a more performant way, meaning 1 or zero allocations, to convert a 
fixed size array to a slice?

Ideally, I would like for the following to work:

return (DCT2DFast8(result)[:]

Unfortunately, this does not since the function's return value is transient 
and the slice expression cannot operate on it.

The current static implementation is 2+ time faster than the more 
generalized form.

BenchmarkDCT_2D_8-12  144020  7922 ns/op2112 B/op  19 
allocs/op

But it falls far short of the 11 times faster than the array result.

Thank you in advance! 

lbe

-- 
You received this message because you are subscribed 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/738b551e-d441-4e63-a1a8-75db51800e06n%40googlegroups.com.

Re: [go-nuts] mutex profile headers

[Ian Lance Taylor]

On Mon, Jul 29, 2024 at 12:53 PM Leah Stapleton
 wrote:
>
> Hi, can anyone explain what the headers (in bold) refer to in mutex  
> profiles? Is it documented somewhere?  Thank you
>
>
> 871400731000 26738165 @ 0x81c8d94 0x81c8d93 0x81c88d7 0x8444386 0x82353a1
> # 0x81c8d93 runtime.unlock+0x4b3 /go pprof format 
> cyclesusr/local/go/src/runtime/lock_sema.go:103
> # 0x81c8d92 runtime.chansend+0x4b2 /usr/local/go/src/runtime/chan.go:228
> # 0x81c88d6 runtime.chansend1+0x16 /usr/local/go/src/runtime/chan.go:145
> # 0x8444385 main.contended.func1+0x65 /Users/mm/go/src/github.com/
>
> 49297035 720 @ 0x8205ad7 0x8205ad6 0x8217091 0x8217087 0x82334da
> # 0x8205ad6 runtime.unlock+0x156 /usr/local/go/src/runtime/lock_sema.go:103
> # 0x8205ad5 runtime.goschedImpl+0x155 /usr/local/go/src/runtime/proc.go:4059
> # 0x8217090 runtime.gopreempt_m+0x3d0 /usr/local/go/src/runtime/proc.go:4082
> # 0x8217086 runtime.newstack+0x3c6 /usr/local/go/src/runtime/stack.go:1070
> # 0x82334d9 runtime.morestack+0x79 /usr/local/go/src/runtime/asm_amd64.s:616

I'm not sure whether this format is documented anywhere.

The first number is the approximate number of cycles accumulated for
this stack trace.  The second number is the approximate number of
times we've seen this stack trace.  Both numbers are scaled by the
sampling probability.  The remaining numbers, after the @,  are the
stack trace--you can see that they appear again, off by one, in the
stack trace lines.

Ian

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

Re: [go-nuts] Re: go/types with typedef-of-typedef?

[Jason E. Aten]

I don't know. 

Here is what ChatGPT 4o mini suggested, accessed at https://chatgpt.com/; 
with some minor corrections to make it build. 

It seems to suggest there is no shortcut crosslink. 

The code below does demonstrate how to use the more up-to-date 
"golang.org/x/tools/go/packages" 
which handles modern modules (versus the older "golang.org/x/tools/go/loader
", pointed to/demonstrated above, which does not).

Q: In golang, How do you make the jump from a go/type.TypeName to ast.Decl ?

Answer:

In Go, if you want to convert a type or a type name (go/types.TypeName) to 
an ast.Decl, you're essentially looking to map a type information structure 
from the go/types package to its corresponding declaration in the go/token 
package.

The go/types.TypeName represents a type name in the Go type system, while 
ast.Decl is part of the abstract syntax tree (AST) and represents a 
declaration in Go source code.

Here's a general approach you can take to achieve this:

   1. 
   
   *Locate the Source Position:* Use the go/types package to get the 
   position of the type declaration. The go/types.TypeName object should have 
   information about its position in the source code, but this might be a bit 
   indirect since go/types does not provide direct mapping to ast.Decl.
   2. 
   
   *Read the Source File:* Once you have the position, you can use the 
   go/parser package to read and parse the source file to find the specific 
   declaration.
   3. 
   
   *Map the Position to the AST Declaration:* Using the source file content 
   and the position, you can find the corresponding declaration in the AST.
   
Here’s a step-by-step outline of how you might implement this:
Example Code

package main

import (
"fmt"
//"go/parser"
"go/token"
//"go/types"
"log"
"golang.org/x/tools/go/packages"
)

func findDecl(pkgPath string, typeName string) (*token.Position, string) {
// Load the package
cfg := {Mode: packages.NeedTypes | packages.NeedFiles | 
packages.NeedSyntax}
pkgs, err := packages.Load(cfg, pkgPath)
if err != nil {
log.Fatalf("failed to load package: %v", err)
}

// Find the type name
var typePos token.Position
for _, pkg := range pkgs {
for _, file := range pkg.Syntax {
for _, decl := range file.Decls {
if genDecl, ok := decl.(*ast.GenDecl); ok && genDecl.Tok == token.TYPE {
for _, spec := range genDecl.Specs {
if typeSpec, ok := spec.(*ast.TypeSpec); ok && typeSpec.Name.Name == 
typeName {
// Found the type declaration
typePos = pkg.Fset.Position(typeSpec.Pos())
return , pkg.Fset.File(typeSpec.Pos()).Name()
}
}
}
}
}
}
return nil, ""
}

func main() {
// Example usage
pos, file := findDecl("your_package_path", "YourTypeName")
if pos != nil {
fmt.Printf("Type declaration found in file %s at position %v\n", file, *pos)
} else {
fmt.Println("Type declaration not found")
}
}

Explanation
   
   1. 
   
   *Load Package:* Use golang.org/x/tools/go/packages to load the Go 
   package you’re interested in. This will give you access to the syntax trees 
   and type information.
   2. 
   
   *Search for Type Declaration:* Iterate through the syntax trees to find 
   the type declaration that matches your typeName. This is done by checking 
   each declaration in the file to see if it matches the type you're looking 
   for.
   3. 
   
   *Get Position:* Once you find the type declaration, get its position 
   using pkg.Fset.Position(). This gives you the line and column information 
   of the declaration.
   4. 
   
   *Return Results:* Return the position and filename where the type 
   declaration was found.
   
Notes
   
   - This approach assumes that you have access to the source code files 
   and that you can load them using the packages package.
   - The go/types package itself does not directly provide a way to get an 
   ast.Decl, so this indirect approach through positions and source file 
   parsing is necessary.
   - Make sure to adjust pkgPath and YourTypeName according to your 
   specific use case.

This method is useful for tooling and analysis where you need to connect 
type information with its corresponding code in the source file.
end Answer.

-- 
You received this message because you are subscribed 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/90942574-2f3b-4e15-912f-897fae3bb69bn%40googlegroups.com.

[go-nuts] mutex profile headers

[Leah Stapleton]

Hi, can anyone explain what the headers (in bold) refer to in mutex  
profiles? Is it documented somewhere?  Thank you 


*871400731000 26738165 @ 0x81c8d94 0x81c8d93 0x81c88d7 0x8444386 0x82353a1*
# 0x81c8d93 runtime.unlock+0x4b3 /usr/local/go/src/runtime/lock_sema.go:103
# 0x81c8d92 runtime.chansend+0x4b2 /usr/local/go/src/runtime/chan.go:228
# 0x81c88d6 runtime.chansend1+0x16 /usr/local/go/src/runtime/chan.go:145
# 0x8444385 main.contended.func1+0x65 /Users/mm/go/src/github.com/

*49297035 720 @ 0x8205ad7 0x8205ad6 0x8217091 0x8217087 0x82334da*
# 0x8205ad6 runtime.unlock+0x156 /usr/local/go/src/runtime/lock_sema.go:103
# 0x8205ad5 runtime.goschedImpl+0x155 /usr/local/go/src/runtime/proc.go:4059
# 0x8217090 runtime.gopreempt_m+0x3d0 /usr/local/go/src/runtime/proc.go:4082
# 0x8217086 runtime.newstack+0x3c6 /usr/local/go/src/runtime/stack.go:1070
# 0x82334d9 runtime.morestack+0x79 /usr/local/go/src/runtime/asm_amd64.s:616

-- 
You received this message because you are subscribed 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/89689b78-9e89-41ef-a09c-e1a5e1a0df8fn%40googlegroups.com.

Re: [go-nuts] How to refresh database/sql MySQL connection username and password

[Robert Engels]

I am fairly certain the reconnection details, etc will be driver specific.  Many dbs will not drop the current connections when changing passwords - only used when a new connection is created. The easiest solution is to set the max connection lifetime on the pool, and change the password there to match. How you coordinate that will be more involved. Might be easier to detect the invalid password error and reset the pool. On Jul 29, 2024, at 7:32 AM, prasa...@gmail.com  wrote:I have a long running daemon written in Go, that listens to a port and spins up multiple go routines for every new connection to handle the data. There is a global variable context that has db Conn(*sql.DB) that is assigned connection context returned by database/sql library’s open() function during initialization time.for security reasons we want to rotate db username & password periodically. I'm looking for best possible way to achieve same but i'm not able to find any pointers to it in documentation. Can anyone please suggest methods to handle the same?I'm also not able find info about auto reconnecting details in case of DB failure. Just wondering how long driver will keep retyring in case of DB shutdown or failure?closest one that i got is:  https://stackoverflow.com/questions/61921525/how-to-update-db-connection-in-gorm-with-new-aws-token/77287404#77287404.  but its good for only postgress.



-- 
You received this message because you are subscribed 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/db61ab36-ed98-4b86-bdd3-7125fe85e284n%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/09ABA647-58EA-4F33-923B-8AA2461FFDE8%40ix.netcom.com.

[go-nuts] How to refresh database/sql MySQL connection username and password

[prasa...@gmail.com]

I have a long running daemon written in Go, that listens to a port and 
spins up multiple go routines for every new connection to handle the data. 
There is a global variable context that has db Conn(*sql.DB) that is 
assigned connection context returned by database/sql library’s open() 
function during initialization time.
for security reasons we want to rotate db username & password periodically. 
I'm looking for best possible way to achieve same but i'm not able to find 
any pointers to it in documentation. Can anyone please suggest methods to 
handle the same?
I'm also not able find info about auto reconnecting details in case of DB 
failure. Just wondering how long driver will keep retyring in case of DB 
shutdown or failure?

closest one that i got is: 
 
https://stackoverflow.com/questions/61921525/how-to-update-db-connection-in-gorm-with-new-aws-token/77287404#77287404.
 
 but its good for only postgress.

-- 
You received this message because you are subscribed 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/db61ab36-ed98-4b86-bdd3-7125fe85e284n%40googlegroups.com.

Re: [go-nuts] Why no signed conversions in binary.ByteOrder?

['wagner riffel' via golang-nuts]

a2800276  wrote:
> I agree it has no technical merit. It can't do better, but it avoid having 
> to think about the type mismatch. The functionality provided by ByteOrder 
> is fairly simple to begin with, I assume its whole purpose is to reduce 
> cognitive load/avoid dumb mistakes. My assumption is that it's probably not 
> immediately obvious to everyone whether `a := int64(unsigned_value)` never 
> loses precision or never reinterprets/reorders the physical value of the 
> bytes. At least I had to stop and think about it and the benefit of a 
> things like ByteOrder would be not having to think :) Then again, I'm not 
> particularly bright.
> 

This binary package provides Varint (see go doc) encoded integer which detects
overflows. This may help with dumb mistakes if it's easy to switch to its
encoding format.

BR.

-w

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

Re: [go-nuts] Why no signed conversions in binary.ByteOrder?

[a2800276]

I agree it has no technical merit. It can't do better, but it avoid having 
to think about the type mismatch. The functionality provided by ByteOrder 
is fairly simple to begin with, I assume its whole purpose is to reduce 
cognitive load/avoid dumb mistakes. My assumption is that it's probably not 
immediately obvious to everyone whether `a := int64(unsigned_value)` never 
loses precision or never reinterprets/reorders the physical value of the 
bytes. At least I had to stop and think about it and the benefit of a 
things like ByteOrder would be not having to think :) Then again, I'm not 
particularly bright.



On Saturday 27 July 2024 at 22:13:59 UTC+2 wagner riffel wrote:

> a2800276  wrote:
> > Just out of curiosity, does anyone have a good rationale as to why there 
> > are only unsigned conversions available `binary.ByteOrder`? It would 
> seem 
> > that this functionality is there to avoid dumb careless errors doing 
> byte 
> > order conversions, but this design forces me to have to think about 
> whether 
> > I can cast uint64 to int64 without loss of precision ...
>
> I don't understand how an Int64() method can do any better than int64(x)
> conversion, neither how there's loss of precision if both are the same 
> size, and
> on any computer I'm aware of both types uses the same bit pattern. So maybe
> that's the rationale, use regular uint64 -> int64 langauge conversion.
>
> BR.
>
> -w
>

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

Re: [go-nuts] Re: go/types with typedef-of-typedef?

['Tim Hockin' via golang-nuts]

How do you make the jump from a go/type.TypeName to ast Decl?  Is there
some easy crosslink?

On Fri, Jul 26, 2024, 4:24 PM Jason E. Aten  wrote:

> To be more specific,
>
> ast.TypeSpec.Name.Name is, I think, what you are after.
>
> See https://pkg.go.dev/go/ast#TypeSpec
>
> And the TypeSpec are found in the ast.File.Decls, after type switching in
> the manner of getast.go#360
>
> https://pkg.go.dev/go/ast#File
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/eQxFFSRKL24/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/01c4a98c-30f4-4cd6-bc7f-a7edf781641an%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/CAO_RewZPe3HoHiO8WWZSRF6EEzLf4bWhS68M-ydW7tte-nMuhQ%40mail.gmail.com.

Re: [go-nuts] Why no signed conversions in binary.ByteOrder?

['wagner riffel' via golang-nuts]

a2800276  wrote:
> Just out of curiosity, does anyone have a good rationale as to why there 
> are only unsigned conversions available `binary.ByteOrder`? It would seem 
> that this functionality is there to avoid dumb careless errors doing byte 
> order conversions, but this design forces me to have to think about whether 
> I can cast uint64 to int64 without loss of precision ...

I don't understand how an Int64() method can do any better than int64(x)
conversion, neither how there's loss of precision if both are the same size, and
on any computer I'm aware of both types uses the same bit pattern. So maybe
that's the rationale, use regular uint64 -> int64 langauge conversion.

BR.

-w

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

[go-nuts] Why no signed conversions in binary.ByteOrder?

[a2800276]

Just out of curiosity, does anyone have a good rationale as to why there 
are only unsigned conversions available `binary.ByteOrder`? It would seem 
that this functionality is there to avoid dumb careless errors doing byte 
order conversions, but this design forces me to have to think about whether 
I can cast uint64 to int64 without loss of precision ...


-- 
You received this message because you are subscribed 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/34c94fb9-21e8-4fe1-b589-16f54a16000fn%40googlegroups.com.

[go-nuts] Re: go/types with typedef-of-typedef?

[Jason E. Aten]

To be more specific, 

ast.TypeSpec.Name.Name is, I think, what you are after.

See https://pkg.go.dev/go/ast#TypeSpec

And the TypeSpec are found in the ast.File.Decls, after type switching in 
the manner of getast.go#360

https://pkg.go.dev/go/ast#File

-- 
You received this message because you are subscribed 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/01c4a98c-30f4-4cd6-bc7f-a7edf781641an%40googlegroups.com.

[go-nuts] Re: go/types with typedef-of-typedef?

[Jason E. Aten]

I don't know if this is the only way, or the best way, but you can get all 
distinct types with the "golang.org/x/tools/go/loader" package. Here is an 
example, in the context of a code generator (greenpack) that produces 
serialization code:

https://github.com/glycerine/greenpack/blob/master/parse/getast.go#L95

which then calls getTypeSpecs()
https://github.com/glycerine/greenpack/blob/master/parse/getast.go#L137

which is implemented here
https://github.com/glycerine/greenpack/blob/master/parse/getast.go#L351

-- 
You received this message because you are subscribed 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/01a7cc1f-9335-4459-9714-2356ef54196an%40googlegroups.com.

[go-nuts] go/types with typedef-of-typedef?

['Tim Hockin' via golang-nuts]

Hi all,  I have been banging my head on this all day.  I am doinking around 
in some code-generation and find myself deep into the go/types package.

Given code like:

```
type E1 string
type E2 E1
```

I loaded the package with x/tools/go/packages.  I got the root scope via 
`pkg.Types.Scope()`.  I did a `Lookup(typename)` and got a `TypeName` 
back.  `TypeName.Type()` gets me a `Named`.

Here's where I am stuck.

In the debugger I can see that E1 and E2 are different.  E1's `fromRHS` 
field tells me it is a `go/types.Basic` with `.name` =  "string".  E2's 
`fromRHS` tells me it is `go/types.Named` which is an E1.

Awesome - that is what I want.  But I can't figure out how to learn that 
through the public API.  AFAICT, `fromRHS` is only used internally and 
calling `Underlying()` on E1 and E2 yields a string in both cases.

Is there any way to learn what I am trying to learn?  The information is 
THERE but I can't seem to get at it.

Tim

-- 
You received this message because you are subscribed 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/0e4da407-7e14-42e7-90e2-05f322509232n%40googlegroups.com.

[go-nuts] Re: about toolchain directive in go.mod?

[王旭东]

Hi,

Please refer to the Go toolchain selection 

 
section. go command consults the GOTOOLCHAIN env before making a decision.

Thanks,
Xudong



在2024年7月25日星期四 UTC+8 09:25:48 写道：

> go.mod:
> module toolchain_test
>
> go 1.22.3
>
> toolchain go1.25.0
>
> main.go:
>
> package main
>
> func main() {
>println("Hello World!")
> }
>
> when run go build, I think that should try to download toolchain 1.25.0 
> which do not exist. So I expect that cmd should failed. But It run sucess.
>
>

-- 
You received this message because you are subscribed 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/f3245f84-90d5-4361-b3fd-5dfa3aaa0906n%40googlegroups.com.

[go-nuts] about toolchain directive in go.mod?

[xie cui]

go.mod:
module toolchain_test

go 1.22.3

toolchain go1.25.0

main.go:

package main

func main() {
   println("Hello World!")
}

when run go build, I think that should try to download toolchain 1.25.0 
which do not exist. So I expect that cmd should failed. But It run sucess.

-- 
You received this message because you are subscribed 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/257fc164-a680-4c91-85b8-5ee71f0243efn%40googlegroups.com.

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

[Brendan Goldacker]

Sorry I was wrong. I posted a correction, but it as deleted for some 
reason. 

Channels do delete the element from the circular buffer on receive 
.
 
So my conclusion was wrong. 

The reason for the heap growth is that the producer go routine can send 
chunks faster than the consumer go routines can process them. So by keeping 
the channel's buffer size smaller we essentially rate limit the producer 
and keep the heap bounded. Additionally, I learned that an unbuffered or 
'full' channel has some slight performance benefit. A buffered channel a 
send requires copying the chunk to the channels queue, then a receive will 
copy it from the channel's queue to the consumers stack. However, if the 
buffer is full (or unbuffered), then send will copy the item directly to 
the receivers' stack (if there is a receiver waiting). Which also reduces 
heap usage. 

Thanks, Brendan
On Wednesday, July 24, 2024 at 5:55:04 PM UTC-5 Ian Lance Taylor wrote:

> On Wed, Jul 24, 2024 at 2:58 PM Brendan Goldacker  
> wrote:
>
>>
>> I took a look over the channels code 
>> .
>>  
>> I can't say I follow it 100%, but it seems like there is a circular buffer 
>> which would be of size 128 in the larger buffer case. Then there are two 
>> offset pointers for the heads and tails of the queue. It seems like the 
>> heap grows unbounded since when receiving from the channel, it doesn't 
>> actually delete the item form the circular queue. Instead it just 
>> increments our head pointer. Therefore, a channel holds a reference to a 
>> chunk buffer (up to 128 of them) even if they've already been read/received 
>> by a worker. Thus, these 'old' buffers cannot be GC'ed. The reference is 
>> only removed from the circular queue once the channel gets enough sends to 
>> overwrite the slot. 
>>
>
> That's interesting.  Would you mind filing an issue at 
> https://go.dev/issue so that the runtime team can take a look?  If you 
> are describing the issue correctly--I have no reason to think you 
> aren't--perhaps it would be relatively cheap to zero out the entry in the 
> channel buffer after the value is delivered to a goroutine.  Thanks.
>
> Ian
>

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

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

[Ian Lance Taylor]

On Wed, Jul 24, 2024 at 2:58 PM Brendan Goldacker 
wrote:

>
> I took a look over the channels code
> .
> I can't say I follow it 100%, but it seems like there is a circular buffer
> which would be of size 128 in the larger buffer case. Then there are two
> offset pointers for the heads and tails of the queue. It seems like the
> heap grows unbounded since when receiving from the channel, it doesn't
> actually delete the item form the circular queue. Instead it just
> increments our head pointer. Therefore, a channel holds a reference to a
> chunk buffer (up to 128 of them) even if they've already been read/received
> by a worker. Thus, these 'old' buffers cannot be GC'ed. The reference is
> only removed from the circular queue once the channel gets enough sends to
> overwrite the slot.
>

That's interesting.  Would you mind filing an issue at https://go.dev/issue
so that the runtime team can take a look?  If you are describing the issue
correctly--I have no reason to think you aren't--perhaps it would be
relatively cheap to zero out the entry in the channel buffer after the
value is delivered to a goroutine.  Thanks.

Ian

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

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

[Brendan Goldacker]

Thanks everyone for the leads and resources. After a few more days hacking 
away and experimenting with changes I was able to get a solution that runs 
under 20s (see here 
). 
Turns out GC wasn't a problem. Its was mostly issues I created. There are a 
few things that really helped me get there: 

1. *In place parsing lines* -- As Ben mentioned, I was doing duplicate work 
for each line. I would run `bytes.IndexByte(buffer '\n')` to find the end 
of the current line. Then I would pass the line to a 
`lineToMeasurement(line)` method which would iterate through each character 
to parse out the city and the temperature sample. So I was reading each 
character twice. I knew this duplication existed, but I didn't think much 
about it. Especially since `IndexByte` uses a SSE instruction (or so I 
believe it is), so I assumed this was negligent. However, when processing 1 
billion lines, a few nanoseconds per line really adds up.  Therefore I 
updated the lineToMeasure 
 to 
handle the parsing in a single pass. This cut down a few seconds of 
processing. 

2.* Lower amount of consumer routines* -- This was just a dumb oversight by 
me. I was running `runtime.NumCPU()` consumer go routines. However, there 
is an additional producer go routine, and a reducer go routine. Just 
changing the workers to NumCPU - 1  
removed
 
all that stack management and go scheduler overhead I was seeing in the CPU 
profile. I think this saved ~6s. 

3. *Sequentially reading the file with `file.Read` instead of MMapping *-- 
Originally I MMapped the file since It make the code simpler to write at 
first, and also because I wanted to learn how to do this in Go. I knew 
sequential reading was likely to be slightly faster since mmaping tends to 
only be better if you're sharing data across process or threads, or are 
randomly accessing the file. However, I copied the approach from the blog 
post 
 
to read the file sequentially with `file.Read`, then truncate the chunk on 
a '\n' char with `bytes.LastIndex(buf, '\n\)`. This approach cut down the 
runtime from ~30s to ~20s. I didn't expect this to be so drastically 
different. Prior, I had written a small benchmark to compare the speed of 
mmaping  
versus
 
reading sequentially 
.
 
Mmaping took ~5s to read all bytes, and the sequential approach took ~25s. 
However, the sequential approach uses a `Scanner`. So I'm assuming most of 
the additional time is due to the 'split' function, and not really with the 
`os.Read` calls. I'm still not sure why there is such a large difference in 
approaches. It could be because MMapping performs poorly on my platform? Or 
`bytes.LastIndex` is somehow more performant than `bytes.IndexByte`? Or 
sequential reading has some underlying benefit (like better page cache hit 
rate, or L1/L2 cache hit rate)? 


There are some additional things I've noticed, but I don't have answers 
for: 

1. *Large buffer channels *-- Originally I was allocating a chunks channel 
and a results channel 
 
with 
a larger buffer (128). I assumed having a large buffer would avoid the risk 
of the buffers becoming full, and the channel become blocking. However, 
after lowering the buffer to ~8 - 12 I saw some significant reductions in 
runtimes, especially with the variance around runtimes.  With large 
buffers, I would get ~35s runtimes (and sometimes up to 45s). But when I 
lowered the buffer size to 12, then the runtimes were between 19s and 22s 
every time. This seems counter intuitive to me. I assumed a channel was 
just some queue/array with a mutex. I think I'll need to do some more 
reading up on channels. 
*I will mention that I was running this while my laptop was low on battery, 
and some things were running in the background. So this may have been just 
a coincidence and channel size doesn't make any difference. *

2. *Seg faults when not copying slices* -- I threw away this code, but in 
one attempt I was seeing Seg faults when trying to read a slice from a 
struct, and I'm not sure why. I had updated my `Measurement` struc 
t 
to store a `cityBytes []byte`. Then on this line 
 I 
would set `citybytes: line[:idx]`. However, at a later point I would later 
try to reference `measurement.CityBytes[0]` and I would get a seg fault. 
The only fix was to copy the slice with `city := 

[go-nuts] Cogent Core, a cross-platform GUI framework in Go

[Kai O'Reilly]

Hello Gophers,

Today we are announcing the initial public release of the Cogent Core GUI 
framework. Cogent Core allows you to build powerful, fast, elegant apps 
that run on all platforms with a single Go codebase, allowing you to Code 
Once, Run Everywhere (Core). We encourage you to check out our blog post 
, which is an interactive 
Cogent Core app running on the web.

Cheers,
Kai O'Reilly and Randy O'Reilly

-- 
You received this message because you are subscribed 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/ff001af5-7206-4bdf-8008-15adf004776fn%40googlegroups.com.

Re: [go-nuts] When using cgo to generate Go structs, some fields are ignored in the definition.

[Ian Lance Taylor]

On Wed, Jul 24, 2024 at 5:29 AM 飞舟  wrote:
>
> I have a C struct, and when I use cgo to generate Go structs, some fields are 
> being ignored. I’m using go version go1.21.1 linux/amd64, and here is my env.

Please post code as plain text, rather than with a background.  Plain
text is much easier to read.  Thanks.

Also, please show us a complete, small, example.  I tried your
example.  I had to invent types for J_COLOR_SPACE and ImageFormat.  It
worked fine.

Does your actual code use anything like #pragma packed?  That will
cause this kind of problem, as Go does not currently have any way to
represent a packed struct.

Ian

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

[go-nuts] Re: When using cgo to generate Go structs, some fields are ignored in the definition.

[peterGo]

Repeat of post on Stack Overflow:

https://stackoverflow.com/questions/78786971/why-do-some-fields-in-the-go-structs-generated-using-cgo-become-anonymous

On Wednesday, July 24, 2024 at 8:29:39 AM UTC-4 飞舟 wrote:

> I have a C struct, and when I use cgo to generate Go structs, some fields 
> are being ignored. I’m using go version go1.21.1 linux/amd64, and here is 
> my env.
>
> go env:
>
> GO111MODULE='on'
> GOARCH='amd64'
> GOBIN=''
> GOCACHE='/root/.cache/go-build'
> GOENV='/root/.config/go/env'
> GOEXE=''
> GOEXPERIMENT=''
> GOFLAGS=''
> GOHOSTARCH='amd64'
> GOHOSTOS='linux'
> GOINSECURE=''
> GOMODCACHE='/root/go/pkg/mod'
> GONOPROXY=''
> GONOSUMDB=''
> GOOS='linux'
> GOPATH='/root/go'
> GOPRIVATE=''
> GOPROXY='https://goproxy.cn,direct'
> GOROOT='/usr/local/go'
> GOSUMDB='sum.golang.org'
> GOTMPDIR=''
> GOTOOLCHAIN='auto'
> GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
> GOVCS=''
> GOVERSION='go1.21.1'
> GCCGO='gccgo'
> GOAMD64='v1'
> AR='ar'
> CC='gcc'
> CXX='g++'
> CGO_ENABLED='1'
> GOMOD='/dev/null'
> GOWORK=''
> CGO_CFLAGS='-O2 -g'
> CGO_CPPFLAGS=''
> CGO_CXXFLAGS='-O2 -g'
> CGO_FFLAGS='-O2 -g'
> CGO_LDFLAGS='-O2 -g'
> PKG_CONFIG='pkg-config'
> GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 
> -ffile-prefix-map=/tmp/go-build2970417006=/tmp/go-build 
> -gno-record-gcc-switches'
>
> and this is my C struct:
> typedef struct PicHead
> {
> unsigned short flag;
> unsigned char version[16];
> unsigned int headSize;
> int64_t fileSize;
> unsigned int macrograph;
> unsigned int personInfor;
> unsigned int hierarchy;
> unsigned int srcWidth;
> unsigned int srcHeight;
> unsigned int sliceWidth;
> unsigned int sliceHeight;
> unsigned int thumbnailWidth;
> unsigned int thumbnailHeight;
> unsigned char bpp;
> unsigned char quality;
> J_COLOR_SPACE colrSpace;
> float scale;
> double ruler;
> unsigned int rate;
> long long extraOffset;
> long long tileOffset;
> ImageFormat sliceFormat;
> unsigned char headSpace[48];
> }PicHead;
>
> this is cgo gen
> type _Ctype_struct_PicHead struct {
> flag _Ctype_ushort
> version [16]_Ctype_uchar
> _ [40]byte
> bpp _Ctype_uchar
> quality _Ctype_uchar
> colrSpace _Ctype_J_COLOR_SPACE
> scale _Ctype_float
> _ [8]byte
> rate _Ctype_uint
> extraOffset _Ctype_longlong
> tileOffset _Ctype_longlong
> sliceFormat _Ctype_ImageFormat
> headSpace [48]_Ctype_uchar
> }
>

-- 
You received this message because you are subscribed 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/cd2d5a83-267c-4bc0-9e6f-0ee7fefbf499n%40googlegroups.com.

[go-nuts] When using cgo to generate Go structs, some fields are ignored in the definition.

[飞舟]

I have a C struct, and when I use cgo to generate Go structs, some fields 
are being ignored. I’m using go version go1.21.1 linux/amd64, and here is 
my env.

go env:

GO111MODULE='on'
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/root/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/root/go'
GOPRIVATE=''
GOPROXY='https://goproxy.cn,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 
-ffile-prefix-map=/tmp/go-build2970417006=/tmp/go-build 
-gno-record-gcc-switches'

and this is my C struct:
typedef struct PicHead
{
unsigned short flag;
unsigned char version[16];
unsigned int headSize;
int64_t fileSize;
unsigned int macrograph;
unsigned int personInfor;
unsigned int hierarchy;
unsigned int srcWidth;
unsigned int srcHeight;
unsigned int sliceWidth;
unsigned int sliceHeight;
unsigned int thumbnailWidth;
unsigned int thumbnailHeight;
unsigned char bpp;
unsigned char quality;
J_COLOR_SPACE colrSpace;
float scale;
double ruler;
unsigned int rate;
long long extraOffset;
long long tileOffset;
ImageFormat sliceFormat;
unsigned char headSpace[48];
}PicHead;

this is cgo gen
type _Ctype_struct_PicHead struct {
flag _Ctype_ushort
version [16]_Ctype_uchar
_ [40]byte
bpp _Ctype_uchar
quality _Ctype_uchar
colrSpace _Ctype_J_COLOR_SPACE
scale _Ctype_float
_ [8]byte
rate _Ctype_uint
extraOffset _Ctype_longlong
tileOffset _Ctype_longlong
sliceFormat _Ctype_ImageFormat
headSpace [48]_Ctype_uchar
}

-- 
You received this message because you are subscribed 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/b999871b-8341-4173-ab51-f888472fcc62n%40googlegroups.com.

[go-nuts] about 0-RTT in golang std tls 1.3 impl?

[xie cui]

does current go version support 0-RTT in clent and server with tls1.3。
I find it may be not.
https://github.com/golang/go/blob/90bcc552c0347948166817a602f612f219bc980c/src/crypto/tls/handshake_server_tls13.go#L158

-- 
You received this message because you are subscribed 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/5149a7c5-2db9-4431-9dea-6845e9a64874n%40googlegroups.com.

[go-nuts] Re: how to start with go?

[Guilherme de Oliveira Amorim]

Well, usually, when I want to learn a new programming language, I create a 
project using the architecture I'm most familiar with, which in this case 
is Clean Architecture.

This way, basic elements of the language are studied in an intuitive and 
contextualized way. This helps to consolidate the learning and gives a 
clearer view of what the language is capable of and what its limitations 
are.

It works well for me!

Hope this helps!

Em terça-feira, 23 de julho de 2024 às 10:46:19 UTC-3, James Hawkins 
escreveu:

> Hi Kowsik,  
>
> This is a time old statement from many new people to software not just 
> golang.  I think to rather brush your experience with a broad stroke you 
> should focus on one thing.  
>
> Maybe start here https://quii.gitbook.io/learn-go-with-tests  TDD has 
> some nice guard rails which will give you the space to learn about the 
> technology you are trying to use.
>
> On Tuesday 23 July 2024 at 14:33:14 UTC+2 Kowsik Vunnam wrote:
>
>> Hi everyone I am new to coding and I learned Golang. I dont know how to 
>> start contributing or how to search for issues or how to identify issues, 
>> My question is how do people identify the issues how do they test the code?
>
>

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

Re: [go-nuts] Re: how to start with go?

[Robert Engels]

A few people have reached out to tell me they found github.com/robaho/go-trader worthwhile when learning. It was a project I initially created to learn Go myself. It touches on all of the major food groups except db access. On Jul 23, 2024, at 9:01 AM, Guilherme de Oliveira Amorim  wrote:Well, usually, when I want to learn a new programming language, I create a project using the architecture I'm most familiar with, which in this case is Clean Architecture.This way, basic elements of the language are studied in an intuitive and contextualized way. This helps to consolidate the learning and gives a clearer view of what the language is capable of and what its limitations are.It works well for me!Hope this helps!Em terça-feira, 23 de julho de 2024 às 09:33:14 UTC-3, Kowsik Vunnam escreveu:Hi everyone I am new to coding and I learned Golang. I dont know how to start contributing or how to search for issues or how to identify issues, My question is how do people identify the issues how do they test the code?



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c05612e6-6684-4345-8ec3-161d84bcb895n%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/7F914CA8-39E1-4EBB-938D-154BC9B6F859%40ix.netcom.com.

[go-nuts] Re: how to start with go?

[Guilherme de Oliveira Amorim]

Well, usually, when I want to learn a new programming language, I create a 
project using the architecture I'm most familiar with, which in this case 
is Clean Architecture.

This way, basic elements of the language are studied in an intuitive and 
contextualized way. This helps to consolidate the learning and gives a 
clearer view of what the language is capable of and what its limitations 
are.

It works well for me!

Hope this helps!

Em terça-feira, 23 de julho de 2024 às 09:33:14 UTC-3, Kowsik Vunnam 
escreveu:

> Hi everyone I am new to coding and I learned Golang. I dont know how to 
> start contributing or how to search for issues or how to identify issues, 
> My question is how do people identify the issues how do they test the code?

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

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

['Marcos Issler' via golang-nuts]

Hi Brendan, take a look of this amazing event of Ardan Labs where they 
explore in depth how to analyze the GC. I think you will find your answer 
how the GC works and the best way to know how much goroutines vs GC memory 
use for your best performance. 

You need to sign in into Ardan Labs but it is free. I didn't find the video 
outside. 

https://courses.ardanlabs.com/courses/take/go-trace-tooling-concurrency/lessons/56254473-webinar-with-bill-kennedy-june-25-2024

They have some interesting info about it in the blogs page too: 

https://www.ardanlabs.com/blog/2018/12/garbage-collection-in-go-part1-semantics.html
https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part1.html

Bests,
Marcos Issler 

Em segunda-feira, 22 de julho de 2024 às 21:22:25 UTC-3, ben...@gmail.com 
escreveu:

> Hi Brendan, this is a fun problem. I'm looking at 
> https://github.com/Goldabj/1brc-go/blob/main/cmd/brc/log_processor.go, 
> and I suspect the main thing is that you're converting []byte to string, 
> which almost certainly allocates. You're also scanning through the bytes 
> several times (first to find the '\n', then the ';', then the '.'). And 
> you're calling ParseInt (twice), which does more work than you need to for 
> this problem. If you want to go further, I'd suggest keeping things as 
> []byte, and making the code search for the various delimiters *and* parse 
> at the same time.
>
> If you want to "cheat" :-), you could look at my write-up, where I present 
> 9 (incrementally faster) solutions to this problem: 
> https://benhoyt.com/writings/go-1brc/
>
> -Ben
>
> On Tuesday, July 23, 2024 at 8:17:57 AM UTC+12 Ian Lance Taylor wrote:
>
>> On Mon, Jul 22, 2024 at 1:05 PM Brendan Goldacker  
>> wrote:
>>
>>> I've been using the 1 billion row challenge 
>>>  as a way to 
>>> learn go over the past few days. With my limited go experience, I've seem 
>>> to hit a wall. 
>>>
>>> I have my submission here . On my 
>>> M1 macbook pro with 16GB of memory, it runs in ~39s. I can get it a few 
>>> seconds faster if I play around with some parameters (numWorkers and 
>>> chunkSizes). I'm trying to make it a goal to get <20s. However, I'm 
>>> stuck.
>>>
>>> I came across another submission from this blog post  
>>> . I've 
>>> copied over the submission to my repo (otherSubmission.go) and it runs 
>>> in ~19s. I was looking over their solution and it appears very similar to 
>>> mine in apprach. The only difference is that they use os.Read to read 
>>> the file sequentially, and my submission uses MMap. Plus a few other 
>>> minor differences. Overall, both approaches look to be about the same. 
>>> However, theirs runs in about half the time. I can't find anything that 
>>> stands out to why there would be such a large difference in runtime.
>>>
>>> I've been trying to use the profile and execution traces to figure out 
>>> why. Below are my flameGraphs and execution traces
>>> [image: Screenshot 2024-07-22 at 1 19 40 PM] 
>>> 
>>>  [image: Screenshot 2024-07-22 at 1 21 47 PM] 
>>> 
>>>
>>> Below are the otherSubmission profile and execution traces:
>>> [image: Screenshot 2024-07-22 at 1 23 39 PM] 
>>> 

[go-nuts] Re: how to start with go?

[James Hawkins]

Hi Kowsik,  

This is a time old statement from many new people to software not just 
golang.  I think to rather brush your experience with a broad stroke you 
should focus on one thing.  

Maybe start here https://quii.gitbook.io/learn-go-with-tests  TDD has some 
nice guard rails which will give you the space to learn about the 
technology you are trying to use.

On Tuesday 23 July 2024 at 14:33:14 UTC+2 Kowsik Vunnam wrote:

> Hi everyone I am new to coding and I learned Golang. I dont know how to 
> start contributing or how to search for issues or how to identify issues, 
> My question is how do people identify the issues how do they test the code?

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

[go-nuts] how to start with go?

[Kowsik Vunnam]

Hi everyone I am new to coding and I learned Golang. I dont know how to 
start contributing or how to search for issues or how to identify issues, 
My question is how do people identify the issues how do they test the code?

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

[go-nuts] Re: Why is there a huge gap between the memory profile's inuse_space in pprof and the externally obtained memory footprint?

[王旭东]

Hi,
I'm not an expert on pprof (Go) or psutil (Python).
But I find this page 

 might 
be helpful.

Thanks,
Xudong

在2024年7月20日星期六 UTC+8 15:21:05 写道：

> I'm working on the project https://github.com/Zxilly/go-size-analyzer, a 
> program that can be very memory intensive, so I've written some scripts to 
> fetch the pprof file during integration testing, and I'm using python's 
> psutil to read the cpu and memory usage to automatically plot into the 
> images.
>
> Recently I was working on some optimizations so I started to analyze the 
> pprof files collected in CI, my test program prints the heap profile file 
> once per second, but I noticed that in all mem pprof files the process 
> memory footprint varies dramatically for both inuse_space and psutil reads. 
> Here are two images showing the data read by the same test.
>
>
>
> As shown in the figure, the difference in size between the memory read by 
> psutil and the memory fetched by pprof is almost 800mb. I know that mem 
> pprof can't count data on the stack, but I don't think the stack holds that 
> much.
>
> You can download the data collected by CI and the rendered images at 
> https://github.com/Zxilly/go-size-analyzer/actions/runs/10007859171/artifacts/1718981276.
>  
> The data is in the cockroach-linux-amd64/json directory in the tarball.
>
> Below is the key code for collecting data.
>
>
> python part:
>
> ps_process = psutil.Process(process.pid)
> 
> while process.poll() is None:
> percent = ps_process.cpu_percent(interval=0.1)
> mem = ps_process.memory_info().rss / (1024 * 1024)
> elapsed_time = time.time() - start_time
> if elapsed_time > timeout:
> raise TimeoutError(f"Process {name} timed out after {timeout} 
> seconds.")
> 
> if draw:
> cpu_percentages.append(percent)
> memory_usage_mb.append(mem)
> timestamps.append(elapsed_time)
>
>
> golang part:
>
> var ctx context.Context
> ctx, heapProfileStop = context.WithCancel(context.Background())
> 
> go func() {
> ticker := time.NewTicker(1 * time.Second)
> defer ticker.Stop()
> 
> id := 0
> write := func() {
>id++
>path := filepath.Join(outputDir, fmt.Sprintf("mem-%d.pprof", 
> id))
>f, err := os.Create(path)
>defer func(f *os.File) {
>   err = f.Close()
>   if err != nil {
>  panic(err)
>   }
>}(f)
>if err != nil {
>   panic(err)
>}
> 
>err = pprof.WriteHeapProfile(f)
>if err != nil {
>   panic(err)
>}
> }
> 
> for {
>select {
>case <-ctx.Done():
>   write()
>   return
>case <-ticker.C:
>   write()
>}
> }
> }()
>

-- 
You received this message because you are subscribed 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/e8df9a0a-1d7c-421f-9943-8675243254b2n%40googlegroups.com.

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

[ben...@gmail.com]

Hi Brendan, this is a fun problem. I'm looking 
at https://github.com/Goldabj/1brc-go/blob/main/cmd/brc/log_processor.go, 
and I suspect the main thing is that you're converting []byte to string, 
which almost certainly allocates. You're also scanning through the bytes 
several times (first to find the '\n', then the ';', then the '.'). And 
you're calling ParseInt (twice), which does more work than you need to for 
this problem. If you want to go further, I'd suggest keeping things as 
[]byte, and making the code search for the various delimiters *and* parse 
at the same time.

If you want to "cheat" :-), you could look at my write-up, where I present 
9 (incrementally faster) solutions to this 
problem: https://benhoyt.com/writings/go-1brc/

-Ben

On Tuesday, July 23, 2024 at 8:17:57 AM UTC+12 Ian Lance Taylor wrote:

> On Mon, Jul 22, 2024 at 1:05 PM Brendan Goldacker  
> wrote:
>
>> I've been using the 1 billion row challenge 
>>  as a way to learn 
>> go over the past few days. With my limited go experience, I've seem to hit 
>> a wall. 
>>
>> I have my submission here . On my M1 
>> macbook pro with 16GB of memory, it runs in ~39s. I can get it a few 
>> seconds faster if I play around with some parameters (numWorkers and 
>> chunkSizes). I'm trying to make it a goal to get <20s. However, I'm 
>> stuck.
>>
>> I came across another submission from this blog post  
>> . I've 
>> copied over the submission to my repo (otherSubmission.go) and it runs 
>> in ~19s. I was looking over their solution and it appears very similar to 
>> mine in apprach. The only difference is that they use os.Read to read 
>> the file sequentially, and my submission uses MMap. Plus a few other 
>> minor differences. Overall, both approaches look to be about the same. 
>> However, theirs runs in about half the time. I can't find anything that 
>> stands out to why there would be such a large difference in runtime.
>>
>> I've been trying to use the profile and execution traces to figure out 
>> why. Below are my flameGraphs and execution traces
>> [image: Screenshot 2024-07-22 at 1 19 40 PM] 
>> 
>>  [image: Screenshot 2024-07-22 at 1 21 47 PM] 
>> 
>>
>> Below are the otherSubmission profile and execution traces:
>> [image: Screenshot 2024-07-22 at 1 23 39 PM] 
>> 
>>  [image: Screenshot 2024-07-22 at 1 22 47 PM] 
>> 

[go-nuts] Re: runtime: found bad pointer in Go heap when not using CGO and -race reveals nothing

[Kalen Krempely]

Thanks Jason! After more head banging in trying to narrow things down and 
taking yet another look through the existing issue reports you linked to I 
was able to find the fix. 

We were using a struct which had a field with type `strings.Builder`. The 
strings.Builder 
docs  state `Do not copy a non-zero 
Builder` as explained in this comment: golang/go#47276 (comment) 
. 
Switching to a string fixed the issue.

While the strings.Builder field was never non-zero in our use case, there 
might have been some race condition of sorts where it could become non-zero 
by the time the garbage collector was invoked since it was not always 
crashing right away.

*Take Away:* It would be great of the linters could warn about this, or if 
there could be a better error messages around this.

On Friday, July 19, 2024 at 6:56:37 PM UTC-7 Jason E. Aten wrote:

> There are a number of open bugs that mention the same error that you are 
> seeing
>
>
> https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+fatal+error%3A+found+bad+pointer+in+Go+heap+%28incorrect+use+of+unsafe+or+cgo%3F%29
>
> So you could try seeing if the issue reproduces with a different go 
> version, say, go 1.19. (per https://github.com/golang/go/issues/64781 )
>
>
>

-- 
You received this message because you are subscribed 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/76cb70f3-a6d5-4210-ac74-b546bfb98ca8n%40googlegroups.com.

Re: [go-nuts] Go 1BRC Challenge and GC Overhead

[Ian Lance Taylor]

On Mon, Jul 22, 2024 at 1:05 PM Brendan Goldacker 
wrote:

> I've been using the 1 billion row challenge
>  as a way to learn
> go over the past few days. With my limited go experience, I've seem to hit
> a wall.
>
> I have my submission here . On my M1
> macbook pro with 16GB of memory, it runs in ~39s. I can get it a few
> seconds faster if I play around with some parameters (numWorkers and
> chunkSizes). I'm trying to make it a goal to get <20s. However, I'm stuck.
>
> I came across another submission from this blog post
> . I've
> copied over the submission to my repo (otherSubmission.go) and it runs in
> ~19s. I was looking over their solution and it appears very similar to mine
> in apprach. The only difference is that they use os.Read to read the file
> sequentially, and my submission uses MMap. Plus a few other minor
> differences. Overall, both approaches look to be about the same. However,
> theirs runs in about half the time. I can't find anything that stands out
> to why there would be such a large difference in runtime.
>
> I've been trying to use the profile and execution traces to figure out
> why. Below are my flameGraphs and execution traces
> [image: Screenshot 2024-07-22 at 1 19 40 PM]
> 
>  [image: Screenshot 2024-07-22 at 1 21 47 PM]
> 
>
> Below are the otherSubmission profile and execution traces:
> [image: Screenshot 2024-07-22 at 1 23 39 PM]
> 
>  [image: Screenshot 2024-07-22 at 1 22 47 PM]
> 
>
> The first thing that stands out to my are the # of GC collections. My
> submission seems to be running GC much more 

[go-nuts] Go 1BRC Challenge and GC Overhead

[Brendan Goldacker]

I've been using the 1 billion row challenge 
 as a way to learn go 
over the past few days. With my limited go experience, I've seem to hit a 
wall. 

I have my submission here . On my M1 
macbook pro with 16GB of memory, it runs in ~39s. I can get it a few 
seconds faster if I play around with some parameters (numWorkers and 
chunkSizes). I'm trying to make it a goal to get <20s. However, I'm stuck.

I came across another submission from this blog post  
. I've copied 
over the submission to my repo (otherSubmission.go) and it runs in ~19s. I 
was looking over their solution and it appears very similar to mine in 
apprach. The only difference is that they use os.Read to read the file 
sequentially, and my submission uses MMap. Plus a few other minor 
differences. Overall, both approaches look to be about the same. However, 
theirs runs in about half the time. I can't find anything that stands out 
to why there would be such a large difference in runtime.

I've been trying to use the profile and execution traces to figure out why. 
Below are my flameGraphs and execution traces
[image: Screenshot 2024-07-22 at 1 19 40 PM] 

 [image: Screenshot 2024-07-22 at 1 21 47 PM] 


Below are the otherSubmission profile and execution traces:
[image: Screenshot 2024-07-22 at 1 23 39 PM] 

 [image: Screenshot 2024-07-22 at 1 22 47 PM] 


The first thing that stands out to my are the # of GC collections. My 
submission seems to be running GC much more frequently - 100,000 
incremental sweeps, 32,000 background sweeps, and around 1000 stop the 
world 

Re: [go-nuts] Surprising behaviour in x/time/rate

['James Lees' via golang-nuts]

Small update: I created #68541  to 
track this.

On Friday 19 July 2024 at 22:52:50 UTC+1 Ian Lance Taylor wrote:

> On Fri, Jul 19, 2024 at 1:52 PM 'James Lees' via golang-nuts
>  wrote:
> >
> > Hi there,
> > I've never posted here, so apologies if I'm breaching any etiquette, but 
> the contribution guide suggests posting here before creating an issue so I 
> thought I'd try.
> >
> > I was debugging an issue recently and saw some strange behaviour in the 
> x/time/rate package.
> >
> > The behaviour is exhibited in the following test
> >
> > func TestRateIssue(t *testing.T) {
> > l := NewLimiter(0, 1)
> > fmt.Println(l.Allow()) // should be true
> > fmt.Println(l.Allow()) // should be false
> >
> > l.SetLimit(10)
> >
> > time.Sleep(1 * time.Second)
> > fmt.Println(l.Allow()) // should be true but is false.
> > }
> >
> > This code seems very strange to me. If the burst is 1, decrementing it 
> here means that the limiter becomes unusable even if the limit is 
> subsequently increased.
> >
> > This code appeared here but the conversation doesn't really reflect the 
> code: the comment says:
> >
> > > The opposite in fact needs to happen: lim.tokens must be reduced by 
> the n consumed tokens?
> >
> > Which makes sense to me, but I'm not sure how we ended up decrementing 
> the burst. To me the solution to the reported problem (limiters not 
> actually being full) would be to set lim.tokens on the constructor, but I 
> haven't thought about that too deeply.
> >
> > I'm happy to propose a change/create an issue but hopefully you folks 
> can help me understand whether I'm missing something obvious!
>
> I agree that this seems wrong. Want to open a bug report or send a patch?
>
> Ian
>

-- 


--

*This email is confidential and protected by copyright, and might 
contain privileged information. The same goes for any attachments.*
*
*
*If 
we’ve sent it to you by mistake (sorry), please don’t copy it or show it to 
anyone. You also shouldn’t use it to make a decision, and you shouldn’t 
rely on the contents.  Let the sender know as soon as you can, and then 
delete the email. Thank you!*



Monzo Bank Limited is a company registered 
in England and Wales (No. 09446231) registered at Broadwalk House, 5 Appold 
St, London, EC2A 2AG. Monzo Bank Ltd is authorised by the Prudential 
Regulation Authority (PRA) and regulated by the Financial Conduct Authority 
and the PRA. Our Financial Services Register number is 730427.

-- 
You received this message because you are subscribed 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/62a626a3-3264-479a-8510-4835fd04f55en%40googlegroups.com.

Re: [go-nuts] this code sometimes hangs

['Brian Candler' via golang-nuts]

This video is well worth watching, pausing and rewinding as required. It's 
Bryan C. Mills "Rethinking Classical Concurrency Patterns":
https://www.youtube.com/watch?v=5zXAHh5tJqQ

It shows patterns which are tricky to implement correctly with condition 
variables and semaphores can be cleanly implemented with channels. It also 
shows a Go replacement for the traditional "worker pool" pattern.

On Friday 19 July 2024 at 22:16:18 UTC+1 Kurtis Rader wrote:

> On Fri, Jul 19, 2024 at 2:05 PM Laurence Guild  wrote:
>
>> well, if I am trying to learn golang then I may need examples of how to 
>> use sync.Cond, but it's good to know that it may have problems. If you have 
>> an interview then people may ask you questions and if you haven't tried to 
>> use some feature or haven't played with it then you may feel like you don't 
>> fully understand things and it can effect your feeling of confidence 
>>
>
> It's not that using sync.Cond "may have problems." Used correctly a 
> sync.Cond works fine in Go. It's that, as Ian said, sync.Cond is rarely 
> needed in Go programs and using a Go channel for transferring ownership of 
> data is idiomatic Go. So you should consider whether a channel will work 
> and only fall back on low level primitives like sync.Cond if a channel 
> isn't suitable.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

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

[go-nuts] Why is there a huge gap between the memory profile's inuse_space in pprof and the externally obtained memory footprint?

[Zxilly Chou]

I'm working on the project https://github.com/Zxilly/go-size-analyzer, a 
program that can be very memory intensive, so I've written some scripts to 
fetch the pprof file during integration testing, and I'm using python's 
psutil to read the cpu and memory usage to automatically plot into the 
images.

Recently I was working on some optimizations so I started to analyze the 
pprof files collected in CI, my test program prints the heap profile file 
once per second, but I noticed that in all mem pprof files the process 
memory footprint varies dramatically for both inuse_space and psutil reads. 
Here are two images showing the data read by the same test.



As shown in the figure, the difference in size between the memory read by 
psutil and the memory fetched by pprof is almost 800mb. I know that mem 
pprof can't count data on the stack, but I don't think the stack holds that 
much.

You can download the data collected by CI and the rendered images at 
https://github.com/Zxilly/go-size-analyzer/actions/runs/10007859171/artifacts/1718981276.
 
The data is in the cockroach-linux-amd64/json directory in the tarball.

Below is the key code for collecting data.


python part:

ps_process = psutil.Process(process.pid)

while process.poll() is None:
percent = ps_process.cpu_percent(interval=0.1)
mem = ps_process.memory_info().rss / (1024 * 1024)
elapsed_time = time.time() - start_time
if elapsed_time > timeout:
raise TimeoutError(f"Process {name} timed out after {timeout} 
seconds.")

if draw:
cpu_percentages.append(percent)
memory_usage_mb.append(mem)
timestamps.append(elapsed_time)


golang part:

var ctx context.Context
ctx, heapProfileStop = context.WithCancel(context.Background())

go func() {
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()

id := 0
write := func() {
   id++
   path := filepath.Join(outputDir, fmt.Sprintf("mem-%d.pprof", id))
   f, err := os.Create(path)
   defer func(f *os.File) {
  err = f.Close()
  if err != nil {
 panic(err)
  }
   }(f)
   if err != nil {
  panic(err)
   }

   err = pprof.WriteHeapProfile(f)
   if err != nil {
  panic(err)
   }
}

for {
   select {
   case <-ctx.Done():
  write()
  return
   case <-ticker.C:
  write()
   }
}
}()

-- 
You received this message because you are subscribed 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/117b16d4-a1a2-46a1-915e-8b7d8b607a46n%40googlegroups.com.

[go-nuts] Re: runtime: found bad pointer in Go heap when not using CGO and -race reveals nothing

[Jason E. Aten]

There are a number of open bugs that mention the same error that you are 
seeing

https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+fatal+error%3A+found+bad+pointer+in+Go+heap+%28incorrect+use+of+unsafe+or+cgo%3F%29

So you could try seeing if the issue reproduces with a different go 
version, say, go 1.19. (per https://github.com/golang/go/issues/64781 )


-- 
You received this message because you are subscribed 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/74d9b807-8d28-4d3e-88e9-1060190f8f6bn%40googlegroups.com.

[go-nuts] Re: runtime: found bad pointer in Go heap when not using CGO and -race reveals nothing

[Jason E. Aten]

> Is there an easy way to see if any of my dependencies are using CGO?

You could turn off CGO , with export CGO_ENABLED=0
and then a build should fail if a dependency uses CGO.

Or even faster: you could examine the library dependencies of the final 
executable and see if the C standard library is linked in.
Run ldd on your executable and look for libraries like these as evidence 
that CGO was used:

libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fed2a8eb000)

libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fed2a6d3000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fed2a2e2000)


-- 
You received this message because you are subscribed 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/394c0d32-aae3-4116-aa54-c0c683636ea8n%40googlegroups.com.

Re: [go-nuts] Surprising behaviour in x/time/rate

[Ian Lance Taylor]

On Fri, Jul 19, 2024 at 1:52 PM 'James Lees' via golang-nuts
 wrote:
>
> Hi there,
> I've never posted here, so apologies if I'm breaching any etiquette, but the 
> contribution guide suggests posting here before creating an issue so I 
> thought I'd try.
>
> I was debugging an issue recently and saw some strange behaviour in the 
> x/time/rate package.
>
> The behaviour is exhibited in the following test
>
> func TestRateIssue(t *testing.T) {
> l := NewLimiter(0, 1)
> fmt.Println(l.Allow()) // should be true
> fmt.Println(l.Allow()) // should be false
>
> l.SetLimit(10)
>
> time.Sleep(1 * time.Second)
> fmt.Println(l.Allow()) // should be true but is false.
> }
>
> This code seems very strange to me. If the burst is 1, decrementing it here 
> means that the limiter becomes unusable even if the limit is subsequently 
> increased.
>
> This code appeared here but the conversation doesn't really reflect the code: 
> the comment says:
>
> > The opposite in fact needs to happen: lim.tokens must be reduced by the n 
> > consumed tokens?
>
> Which makes sense to me, but I'm not sure how we ended up decrementing the 
> burst. To me the solution to the reported problem (limiters not actually 
> being full) would be to set lim.tokens on the constructor, but I haven't 
> thought about that too deeply.
>
> I'm happy to propose a change/create an issue but hopefully you folks can 
> help me understand whether I'm missing something obvious!

I agree that this seems wrong.  Want to open a bug report or send a patch?

Ian

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

Re: [go-nuts] this code sometimes hangs

[Kurtis Rader]

On Fri, Jul 19, 2024 at 2:05 PM Laurence Guild 
wrote:

> well, if I am trying to learn golang then I may need examples of how to
> use sync.Cond, but it's good to know that it may have problems. If you have
> an interview then people may ask you questions and if you haven't tried to
> use some feature or haven't played with it then you may feel like you don't
> fully understand things and it can effect your feeling of confidence
>

It's not that using sync.Cond "may have problems." Used correctly a
sync.Cond works fine in Go. It's that, as Ian said, sync.Cond is rarely
needed in Go programs and using a Go channel for transferring ownership of
data is idiomatic Go. So you should consider whether a channel will work
and only fall back on low level primitives like sync.Cond if a channel
isn't suitable.

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

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

Re: [go-nuts] this code sometimes hangs

[Laurence Guild]

well, if I am trying to learn golang then I may need examples of how to use 
sync.Cond, but it's good to know that it may have problems. If you have an 
interview then people may ask you questions and if you haven't tried to use 
some feature or haven't played with it then you may feel like you don't 
fully understand things and it can effect your feeling of confidence 

On Friday, July 19, 2024 at 4:58:13 PM UTC-4 Ian Lance Taylor wrote:

> On Fri, Jul 19, 2024 at 1:52 PM Laurence Guild  wrote:
> >
> >
> > Is there an article that says not to use sync.Cond ? This page seems to 
> have some fans of sync.Cond. I have xtensive software experience but I am 
> new to golang so I am just trying to learn
> >
> > https://github.com/golang/go/issues/21165
>
> I would say that sync.Cond has its uses in Go, but they are rare. In
> Go one normally uses channels for the kinds of things for which other
> languages use conditional variables. It's probably a mistake to use
> sync.Cond without a clear understanding of why channels won't work.
>
> Ian
>

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

Re: [go-nuts] this code sometimes hangs

[Ian Lance Taylor]

On Fri, Jul 19, 2024 at 1:52 PM Laurence Guild  wrote:
>
>
>  Is there an article that says not to use sync.Cond ? This page seems to have 
> some fans of sync.Cond. I have xtensive software experience but I am new to 
> golang so I am just trying to learn
>
> https://github.com/golang/go/issues/21165

I would say that sync.Cond has its uses in Go, but they are rare.  In
Go one normally uses channels for the kinds of things for which other
languages use conditional variables.  It's probably a mistake to use
sync.Cond without a clear understanding of why channels won't work.

Ian

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

Re: [go-nuts] this code sometimes hangs

[Laurence Guild]

 Is there an article that says not to use sync.Cond ? This page seems to 
have some fans of sync.Cond. I have xtensive software experience but I am 
new to golang so I am just trying to learn

https://github.com/golang/go/issues/21165

On Thursday, July 18, 2024 at 9:33:57 PM UTC-4 王旭东 wrote:

> Hi,
> It’s better to not use sync.Cond. Instead, use a channel to do a jame job. 
> There is even a issue to discuss remove it.
>
> 在2024年7月19日星期五 UTC+8 04:07:26 写道：
>
>> But I think that Done() is for the outer which prevents the broadcast. By 
>> putting it in the defer all of the subscribers should be waiting on the 
>> condition when it occurs. 
>>
>> Caveat- not looking at code - just remembering. 
>>
>> On Jul 18, 2024, at 3:01 PM, Lammie Jonson  wrote:
>>
>> 
>>
>>
>> >> defer goroutineRunning.Done()
>>
>> This doesn't work. Each invocation of subscribe() has it's own 
>> sync.WaitGroup. It's just used it appears to ensure that the enclosed 
>> goroutine is running before subscribe() returns 
>>
>>
>> -- 
>> You received this message because you are subscribed 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/45f26b0d-e00d-47e6-aede-ee9a70bb7d5dn%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/05375dce-9ea0-4d6d-808a-7f1f09134bc9n%40googlegroups.com.

[go-nuts] Surprising behaviour in x/time/rate

['James Lees' via golang-nuts]

Hi there,
I've never posted here, so apologies if I'm breaching any etiquette, but 
the contribution guide 

 
suggests posting here before creating an issue so I thought I'd try.

I was debugging an issue recently and saw some strange behaviour in the 
x/time/rate package.

The behaviour is exhibited in the following test

func TestRateIssue(t *testing.T) {
l := NewLimiter(0, 1)
fmt.Println(l.Allow()) // should be true
fmt.Println(l.Allow()) // should be false

l.SetLimit(10)

time.Sleep(1 * time.Second)
fmt.Println(l.Allow()) // should be true but is false.
}

This code 

 seems 
very strange to me. If the burst is 1, decrementing it here means that the 
limiter becomes unusable even if the limit is subsequently increased.

This code appeared here 
 
but 
the conversation doesn't really reflect the code: the comment says:

> The opposite in fact needs to happen: lim.tokens must be reduced by the n 
> consumed 
tokens?

Which makes sense to me, but I'm not sure how we ended up decrementing the 
burst. To me the solution to the reported problem (limiters not actually 
being full) would be to set lim.tokens on the constructor, but I haven't 
thought about that too deeply.

I'm happy to propose a change/create an issue but hopefully you folks can 
help me understand whether I'm missing something obvious!

Thanks

James

-- 


--

*This email is confidential and protected by copyright, and might 
contain privileged information. The same goes for any attachments.*
*
*
*If 
we’ve sent it to you by mistake (sorry), please don’t copy it or show it to 
anyone. You also shouldn’t use it to make a decision, and you shouldn’t 
rely on the contents.  Let the sender know as soon as you can, and then 
delete the email. Thank you!*



Monzo Bank Limited is a company registered 
in England and Wales (No. 09446231) registered at Broadwalk House, 5 Appold 
St, London, EC2A 2AG. Monzo Bank Ltd is authorised by the Prudential 
Regulation Authority (PRA) and regulated by the Financial Conduct Authority 
and the PRA. Our Financial Services Register number is 730427.

-- 
You received this message because you are subscribed 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/51d35812-8903-4801-b4d5-0beb3129542en%40googlegroups.com.

Re: [go-nuts] Mutex profiling question

[Robert Engels]

Thank you for the very detailed explanation. What I am struggling with is that even if the routines do a little work and go back to sleep (which is probably the case here) - as I increase the number of external clients I would expect there is always a routine ready to run. What I am observing is that the throughput is capped. Eg with 10 clients each processes 3k requests a second, but with 20 clients each processes 1.5k requests a sec. Yet, the cpu usage is about the same and the IO rates about the same. Which points to scheduling delays - but I’ll confess after reading your response I still am not sure how to diagnose (what other tools I can look at - the trace seems too noisy). Is there some way to get high level scheduling statistics?On Jul 18, 2024, at 6:31 PM, Rhys Hiltner  wrote:Hi Robert,First, note that the contention profile for runtime-internal locks doesn't correctly blame the part of the code that _caused_ delay: with Go 1.22 and 1.23, the call stacks are of (runtime-internal) lock users that _experienced_ delay. That's https://go.dev/issue/66999, and those odd semantics are the reason that those stacks aren't shown by default (and instead require the GODEBUG). That was briefly fixed in late May, but caused some slowdowns and so couldn't be part of the Go 1.23 release.Contention within findRunnable is probably on sched.lock, which protects the global portion of the scheduler. (Often, scheduling only needs to involve each P's local run queue.)> Is this a side effect of the scheduler, and it is really blocked in the unlock call waiting for another routine to be runnable?There really is a thread (an M with a P) that is blocked. It's not waiting for a G to be runnable .. depending on the exact part of findRunnable, it might be waiting to see whether a goroutine is runnable or not, or the M might be trying to go to sleep because it's determined that there's no work. The profile also shows runtime.goschedImpl, which means there's a G calling runtime.Gosched, and its M (and P) are blocked trying to add the G to the global run queue.As for what's causing it ... consider how much work the program's goroutines do when they run (maybe "only tens of microseconds"), how and how often the program uses Gosched (maybe "a bit too much", though I can't quantify that), the setting for GOMAXPROCS (maybe "lots", though GOOS=darwin implies it won't be huge). Summing the runtime/metrics buckets for "/sched/latencies:seconds" and multiplying by 8 (runtime.gTrackingPeriod) will give an estimate of how many times the scheduler started running a goroutine ... or a runtime/trace can show all of those details at once.RhysOn Thursday, July 18, 2024 at 1:00:15 PM UTC-7 robert engels wrote:Anyone have any idea on the high internal lock time on findRunnable?On Jul 18, 2024, at 10:36 AM, robert engels  wrote:Looks like the name was changed to runtimecontentionstacksMuch better now…(pprof) treeShowing nodes accounting for 481.75ms, 100% of 481.75ms totalDropped 39 nodes (cum <= 2.41ms)--+-      flat  flat%   sum%        cum   cum%   calls calls% + context 	 	 --+-                                          401.25ms 83.51% |   runtime.findRunnable (inline)                                           35.26ms  7.34% |   runtime.sysmon (inline)                                           17.37ms  3.62% |   runtime.stopm (inline)                                           14.01ms  2.92% |   runtime.saveBlockEventStack (inline)                                            6.07ms  1.26% |   runtime.goschedImpl (inline)                                            1.52ms  0.32% |   runtime.schedule (inline)                                            1.30ms  0.27% |   sync.(*Mutex).Unlock (inline)                                            1.30ms  0.27% |   github.com/robaho/go-trader/internal/exchange.sendMarketData (inline)                                            1.17ms  0.24% |   sync.(*Map).Swap (inline)                                            1.16ms  0.24% |   github.com/robaho/go-trader/internal/exchange.(*grpcServer).Connection (inline)  480.46ms 99.73% 99.73%   480.46ms 99.73%                | runtime.unlockbut this seems suspect, that finding the runnable should consume so much time. Is this a side effect of the scheduler, and it is really blocked in the unlock call waiting for another routine to be runnable?On Jul 18, 2024, at 10:14 AM, 'Robert Engels' via golang-nuts  wrote:I found this issue, https://github.com/golang/go/issues/57071 and tried running with GODEBUG=profileruntimelocks=1but it made no difference in the output.I am using Go 1.22.4 on OSX.Any ideas how I can determine what is causing this high contention shown below:(pprof) treeShowing nodes accounting for 4440.35ms, 100% of 4440.35ms 

Re: [go-nuts] xrealwd() in unix.c in Go 1.4

[Ian Lance Taylor]

On Thu, Jul 18, 2024 at 9:38 PM Chris Guthrey  wrote:
>
> I'm trying to learn how the last version of Go that is bootstrapped from C 
> works and as a learning exercise, maybe try porting to a new OS (on x86 for 
> now)...
>
> So I'm trying to get my head around the xrealdwd() function  in 
> /src/cmd/dist/unix.c - I just can't grok why it is needed.
>
> A quick search indicates that xrealdwd() is only ever used by build.c, and 
> the comment in build.c says:
>
> // xgetwd might return a path with symlinks fully resolved, and if
> // there happens to be symlinks in goroot, then the hasprefix test
> // will never succeed. Instead, we use xrealwd to get a canonical
> // goroot/src before the comparison to avoid this problem.
>
> I guess my understanding and knowledge of symlinks is lacking, but I guess i 
> just don't understand why hasprefix() will never succeed if there happens to 
> be symlinks in goroot...

hasprefix is a simple string comparison.  If /home is a symlink to
/real/home, and GOROOT is /home/go, then xgetwd can return
/real/home/go which won't match /home/go.


> The windows.c file also has a similar (at least similar in logic but not in 
> OS calls) approach to xrealdwd() so I must assume that hasprefix() does not 
> like symlinks on Windows either?

Yes, again, hasprefix is a simple string comparison.

> I think if this were ported to an OS that doesnt have symlinks, I might be 
> able to get away with making xrealwd() always just return the current 
> directory without trying to get a canonical path to goroot/src...

Yes, I suppose.  But I don't recommend following the path of porting
Go 1.4.  Instead, port the current Go tip, and build it on a supported
machine, and then use that to cross-compile.  See bootstrap.bash.

Ian

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

[go-nuts] xrealwd() in unix.c in Go 1.4

[Chris Guthrey]

Hi,

I'm trying to learn how the last version of Go that is bootstrapped from C 
works and as a learning exercise, maybe try porting to a new OS (on x86 for 
now)...   

So I'm trying to get my head around the xrealdwd() function  in 
/src/cmd/dist/unix.c - I just can't grok why it is needed. 

A quick search indicates that xrealdwd() is only ever used by build.c, and 
the comment in build.c says:

// xgetwd might return a path with symlinks fully resolved, and if
// there happens to be symlinks in goroot, then the hasprefix test
// will never succeed. Instead, we use xrealwd to get a canonical
// goroot/src before the comparison to avoid this problem.

I guess my understanding and knowledge of symlinks is lacking, but I guess 
i just don't understand why hasprefix() will never succeed if there happens 
to be symlinks in goroot...

The windows.c file also has a similar (at least similar in logic but not in 
OS calls) approach to xrealdwd() so I must assume that hasprefix() does not 
like symlinks on Windows either?

I think if this were ported to an OS that doesnt have symlinks, I might be 
able to get away with making xrealwd() always just return the current 
directory without trying to get a canonical path to goroot/src...  

Cheers,
Chris


-- 
You received this message because you are subscribed 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/935f7f80-beb2-4206-839e-68ca17950e38n%40googlegroups.com.

Re: [go-nuts] this code sometimes hangs

[王旭东]

Hi,
It’s better to not use sync.Cond. Instead, use a channel to do a jame job. 
There is even a issue to discuss remove it.

在2024年7月19日星期五 UTC+8 04:07:26 写道：

> But I think that Done() is for the outer which prevents the broadcast. By 
> putting it in the defer all of the subscribers should be waiting on the 
> condition when it occurs. 
>
> Caveat- not looking at code - just remembering. 
>
> On Jul 18, 2024, at 3:01 PM, Lammie Jonson  wrote:
>
> 
>
>
> >> defer goroutineRunning.Done()
>
> This doesn't work. Each invocation of subscribe() has it's own 
> sync.WaitGroup. It's just used it appears to ensure that the enclosed 
> goroutine is running before subscribe() returns 
>
>
> -- 
> You received this message because you are subscribed 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/45f26b0d-e00d-47e6-aede-ee9a70bb7d5dn%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/a59fdac8-ef6c-4da0-9e14-03d7cc0941dfn%40googlegroups.com.

Re: [go-nuts] Mutex profiling question

[Rhys Hiltner]

Hi Robert,

First, note that the contention profile for runtime-internal locks doesn't 
correctly blame the part of the code that _caused_ delay: with Go 1.22 and 
1.23, the call stacks are of (runtime-internal) lock users that 
_experienced_ delay. That's https://go.dev/issue/66999, and those odd 
semantics are the reason that those stacks aren't shown by default (and 
instead require the GODEBUG). That was briefly fixed in late May, but 
caused some slowdowns and so couldn't be part of the Go 1.23 release.

Contention within findRunnable is probably on sched.lock, which protects 
the global portion of the scheduler. (Often, scheduling only needs to 
involve each P's local run queue.)

> Is this a side effect of the scheduler, and it is really blocked in the 
unlock call waiting for another routine to be runnable?

There really is a thread (an M with a P) that is blocked. It's not waiting 
for a G to be runnable .. depending on the exact part of findRunnable, it 
might be waiting to see whether a goroutine is runnable or not, or the M 
might be trying to go to sleep because it's determined that there's no 
work. The profile also shows runtime.goschedImpl, which means there's a G 
calling runtime.Gosched, and its M (and P) are blocked trying to add the G 
to the global run queue.

As for what's causing it ... consider how much work the program's 
goroutines do when they run (maybe "only tens of microseconds"), how and 
how often the program uses Gosched (maybe "a bit too much", though I can't 
quantify that), the setting for GOMAXPROCS (maybe "lots", though 
GOOS=darwin implies it won't be huge). Summing the runtime/metrics buckets 
for "/sched/latencies:seconds" and multiplying by 8 
(runtime.gTrackingPeriod) will give an estimate of how many times the 
scheduler started running a goroutine ... or a runtime/trace can show all 
of those details at once.

Rhys

On Thursday, July 18, 2024 at 1:00:15 PM UTC-7 robert engels wrote:

> Anyone have any idea on the high internal lock time on findRunnable?
>
> On Jul 18, 2024, at 10:36 AM, robert engels  wrote:
>
> Looks like the name was changed to runtimecontentionstacks
>
>
> Much better now…
>
> (pprof) tree
> Showing nodes accounting for 481.75ms, 100% of 481.75ms total
> Dropped 39 nodes (cum <= 2.41ms)
> --+-
>   flat  flat%   sum%cum   cum%   calls calls% + context   
> --+-
>   401.25ms 83.51% |   
> runtime.findRunnable (inline)
>35.26ms  7.34% |   
> runtime.sysmon (inline)
>17.37ms  3.62% |   
> runtime.stopm (inline)
>14.01ms  2.92% |   
> runtime.saveBlockEventStack (inline)
> 6.07ms  1.26% |   
> runtime.goschedImpl (inline)
> 1.52ms  0.32% |   
> runtime.schedule (inline)
> 1.30ms  0.27% |   
> sync.(*Mutex).Unlock (inline)
> 1.30ms  0.27% |   
> github.com/robaho/go-trader/internal/exchange.sendMarketData (inline)
> 1.17ms  0.24% |   
> sync.(*Map).Swap (inline)
> 1.16ms  0.24% |   
> github.com/robaho/go-trader/internal/exchange.(*grpcServer).Connection 
> (inline)
>   480.46ms 99.73% 99.73%   480.46ms 99.73%| runtime.unlock
>
> but this seems suspect, that finding the runnable should consume so much 
> time. Is this a side effect of the scheduler, and it is really blocked in 
> the unlock call waiting for another routine to be runnable?
>
>
>
> On Jul 18, 2024, at 10:14 AM, 'Robert Engels' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> I found this issue, https://github.com/golang/go/issues/57071 and tried 
> running with 
>
> GODEBUG=profileruntimelocks=1
>
> but it made no difference in the output.
>
> I am using Go 1.22.4 on OSX.
>
> Any ideas how I can determine what is causing this high contention shown 
> below:
>
> (pprof) tree
> Showing nodes accounting for 4440.35ms, 100% of 4440.35ms total
> --+-
>   flat  flat%   sum%cum   cum%   calls calls% + context 
> --+-
>  4324.17ms 97.38% 97.38%  4324.17ms 97.38%| 
> runtime._LostContendedRuntimeLock
> --+-
>   116.17ms   100% 
> |   sync.(*Map).Swap (inline)
>   116.17ms  2.62%   100%   116.17ms  2.62%| 
> sync.(*Mutex).Unlock
> --+-
> 

Re: [go-nuts] go doc broken in official go repo

['Sean Liao' via golang-nuts]

the bootstrap version only allows you to build enough of the compiler for
it to run and build the rest of the distribution.
you should be using the go binary built from the given source tree when
interacting with it.

- sean

On Thu, Jul 18, 2024, 22:25 will@gmail.com 
wrote:

> I cloned the official Go repo locally, went into src/text/template, ran
> `go doc .`, and got this error:
>
> go: downloading go1.23.0 (darwin/arm64)
> go: download go1.23.0 for darwin/arm64: toolchain not available
>
> It looks like src/go.mod declares 1.23. Shouldn't it be the latest
> self-host version, whatever that was? v1.20 or something? It seems like an
> error to declare a Go version that doesn't exist.
>
> Will
>
> --
> You received this message because you are subscribed 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/b4047237-8390-48dd-87f9-c935396a35e8n%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/CAGabyPrG_C4zv0s8gZVLTG54Mk1G7Out0zZKv6aNP8V4%2BkfqrQ%40mail.gmail.com.

[go-nuts] runtime: found bad pointer in Go heap when not using CGO and -race reveals nothing

[Kalen Krempely]

My go program does not use any CGO, but is failing rather consistently with 
the following error. Disabling the garbage collector with 
`debug.SetGCPercent(-1)` "fixes" the issue. 

The main dependencies used are 
[bubbletea](https://github.com/charmbracelet/bubbletea) and 
[pgx](https://github.com/jackc/pgx/). Is there an easy way to see if any of 
my dependencies are using CGO? What else can I be trying to help narrow 
down this issue since I have tried quite a lot with no definitive answers.

There was no difference when switching from 
[pgx](https://github.com/jackc/pgx/) to [pq](https://github.com/lib/pq), a 
pure go postgres driver.

```
runtime: pointer 0xc0006eb850 to unallocated span span.base()=0xc0006e4000 
span.limit=0xc0006ec000 span.state=0
runtime: found in object at *(0xc000142690+0x20)
object=0xc000142690 s.base()=0xc000142000 s.limit=0xc000143fe0 
s.spanclass=14 s.elemsize=80 s.state=mSpanInUse
 *(object+0) = 0xc0004280e0
 *(object+8) = 0xc0002e6cc0
 *(object+16) = 0x2
 *(object+24) = 0x2
 *(object+32) = 0xc0006eb850 <==
 *(object+40) = 0xc00041c480
 *(object+48) = 0x2a9
 *(object+56) = 0x480
 *(object+64) = 0xc0003dc430
 *(object+72) = 0x2
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
```
Full stack traces further down.

go version go1.22.5 linux/amd64`

go env:
```
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/user/.cache/go-build'
GOENV='/home/user/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/user/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/user/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.5'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/user/workspace/product/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 
-ffile-prefix-map=/tmp/go-build1282480932=/tmp/go-build 
-gno-record-gcc-switches'
```


runtime: pointer 0xc0006eb850 to unallocated span span.base()=0xc0006e4000 
span.limit=0xc0006ec000 span.state=0
runtime: found in object at *(0xc000142690+0x20)
object=0xc000142690 s.base()=0xc000142000 s.limit=0xc000143fe0 
s.spanclass=14 s.elemsize=80 s.state=mSpanInUse
 *(object+0) = 0xc0004280e0
 *(object+8) = 0xc0002e6cc0
 *(object+16) = 0x2
 *(object+24) = 0x2
 *(object+32) = 0xc0006eb850 <==
 *(object+40) = 0xc00041c480
 *(object+48) = 0x2a9
 *(object+56) = 0x480
 *(object+64) = 0xc0003dc430
 *(object+72) = 0x2
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

runtime stack:
runtime.throw({0xe3835a?, 0x6?})
/usr/local/go/src/runtime/panic.go:1023 +0x5c fp=0x7c1dc4a65c00 
sp=0x7c1dc4a65bd0 pc=0x43d41c
runtime.badPointer(0x7c1dc748c578, 0xc0006eb850, 0xc000142690, 0x20)
/usr/local/go/src/runtime/mbitmap.go:286 +0x165 fp=0x7c1dc4a65c50 
sp=0x7c1dc4a65c00 pc=0x41a2c5
runtime.findObject(0xc0002e6cc0?, 0xc000142690?, 0x0?)
/usr/local/go/src/runtime/mbitmap.go:329 +0xa6 fp=0x7c1dc4a65c88 
sp=0x7c1dc4a65c50 pc=0x41a446
runtime.scanobject(0xc60168?, 0xc60168)
/usr/local/go/src/runtime/mgcmark.go:1492 +0x14c fp=0x7c1dc4a65d18 
sp=0x7c1dc4a65c88 pc=0x42692c
runtime.gcDrain(0xc60168, 0x7)
/usr/local/go/src/runtime/mgcmark.go:1242 +0x1f4 fp=0x7c1dc4a65d80 
sp=0x7c1dc4a65d18 pc=0x4261f4
runtime.gcDrainMarkWorkerIdle(...)
/usr/local/go/src/runtime/mgcmark.go:1114
runtime.gcBgMarkWorker.func2()
/usr/local/go/src/runtime/mgc.go:1406 +0x6f fp=0x7c1dc4a65dd0 
sp=0x7c1dc4a65d80 pc=0x42282f
runtime.systemstack(0x80)
/usr/local/go/src/runtime/asm_amd64.s:509 +0x4a fp=0x7c1dc4a65de0 
sp=0x7c1dc4a65dd0 pc=0x470f4a

goroutine 12 gp=0xc00049a8c0 m=11 mp=0xc000600808 [GC worker (active)]:
runtime.systemstack_switch()
/usr/local/go/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0004a1750 
sp=0xc0004a1740 pc=0x470ee8
runtime.gcBgMarkWorker()
/usr/local/go/src/runtime/mgc.go:1370 +0x1f2 fp=0xc0004a17e0 
sp=0xc0004a1750 pc=0x4224f2
runtime.goexit({})
/usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc0004a17e8 
sp=0xc0004a17e0 pc=0x472f01
created by runtime.gcBgMarkStartWorkers in goroutine 1
/usr/local/go/src/runtime/mgc.go:1234 +0x1c

goroutine 1 gp=0xc061c0 m=nil [runnable]:
github.com/muesli/termenv.Style.Styled({0x2, {0x11798b8, 0x1}, 
{0xc00065f810, 0x1, 0x1}}, {0x11798b8?, 0x1?})
/home/user/go/pkg/mod/github.com/muesli/termenv@v0.15.2/style.go:43 +0x190 
fp=0xc000718610 sp=0xc000718608 pc=0x6360d0
github.com/muesli/termenv.Style.String(...)
/home/user/go/pkg/mod/github.com/muesli/termenv@v0.15.2/style.go:39
github.com/charmbracelet/glamour/ansi.renderText({0x117d400, 0xc0002f6080}, 
0x0, {{0x11762b8, 0x1}, {0x11762b8, 0x1}, {0x0, 0x0}, {0x0, ...}, ...}, ...)

[go-nuts] go doc broken in official go repo

[will....@gmail.com]

I cloned the official Go repo locally, went into src/text/template, ran `go 
doc .`, and got this error:

go: downloading go1.23.0 (darwin/arm64)
go: download go1.23.0 for darwin/arm64: toolchain not available

It looks like src/go.mod declares 1.23. Shouldn't it be the latest 
self-host version, whatever that was? v1.20 or something? It seems like an 
error to declare a Go version that doesn't exist.

Will

-- 
You received this message because you are subscribed 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/b4047237-8390-48dd-87f9-c935396a35e8n%40googlegroups.com.

Re: [go-nuts] this code sometimes hangs

[Robert Engels]

But I think that Done() is for the outer which prevents the broadcast. By putting it in the defer all of the subscribers should be waiting on the condition when it occurs. Caveat- not looking at code - just remembering. On Jul 18, 2024, at 3:01 PM, Lammie Jonson  wrote:>> defer goroutineRunning.Done()This doesn't work. Each invocation of subscribe() has it's own sync.WaitGroup. It's just used it appears to ensure that the enclosed goroutine is running before subscribe() returns 



-- 
You received this message because you are subscribed 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/45f26b0d-e00d-47e6-aede-ee9a70bb7d5dn%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/82A1A7EE-EA99-4326-A122-7BCA889F8A32%40ix.netcom.com.

Re: [go-nuts] this code sometimes hangs

[Lammie Jonson]

>> defer goroutineRunning.Done()

This doesn't work. Each invocation of subscribe() has it's own 
sync.WaitGroup. It's just used it appears to ensure that the enclosed 
goroutine is running before subscribe() returns 


-- 
You received this message because you are subscribed 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/45f26b0d-e00d-47e6-aede-ee9a70bb7d5dn%40googlegroups.com.

Re: [go-nuts] Mutex profiling question

['robert engels' via golang-nuts]

Anyone have any idea on the high internal lock time on findRunnable?On Jul 18, 2024, at 10:36 AM, robert engels  wrote:Looks like the name was changed to runtimecontentionstacksMuch better now…(pprof) treeShowing nodes accounting for 481.75ms, 100% of 481.75ms totalDropped 39 nodes (cum <= 2.41ms)--+-      flat  flat%   sum%        cum   cum%   calls calls% + context 	 	 --+-                                          401.25ms 83.51% |   runtime.findRunnable (inline)                                           35.26ms  7.34% |   runtime.sysmon (inline)                                           17.37ms  3.62% |   runtime.stopm (inline)                                           14.01ms  2.92% |   runtime.saveBlockEventStack (inline)                                            6.07ms  1.26% |   runtime.goschedImpl (inline)                                            1.52ms  0.32% |   runtime.schedule (inline)                                            1.30ms  0.27% |   sync.(*Mutex).Unlock (inline)                                            1.30ms  0.27% |   github.com/robaho/go-trader/internal/exchange.sendMarketData (inline)                                            1.17ms  0.24% |   sync.(*Map).Swap (inline)                                            1.16ms  0.24% |   github.com/robaho/go-trader/internal/exchange.(*grpcServer).Connection (inline)  480.46ms 99.73% 99.73%   480.46ms 99.73%                | runtime.unlockbut this seems suspect, that finding the runnable should consume so much time. Is this a side effect of the scheduler, and it is really blocked in the unlock call waiting for another routine to be runnable?On Jul 18, 2024, at 10:14 AM, 'Robert Engels' via golang-nuts  wrote:I found this issue, https://github.com/golang/go/issues/57071 and tried running with GODEBUG=profileruntimelocks=1but it made no difference in the output.I am using Go 1.22.4 on OSX.Any ideas how I can determine what is causing this high contention shown below:(pprof) treeShowing nodes accounting for 4440.35ms, 100% of 4440.35ms total--+-      flat  flat%   sum%        cum   cum%   calls calls% + context 	 	 --+- 4324.17ms 97.38% 97.38%  4324.17ms 97.38%                | runtime._LostContendedRuntimeLock--+-                                          116.17ms   100% |   sync.(*Map).Swap (inline)  116.17ms  2.62%   100%   116.17ms  2.62%                | sync.(*Mutex).Unlock--+-                                          116.17ms   100% |   github.com/robaho/go-trader/internal/exchange.(*grpcServer).massquote         0     0%   100%   116.17ms  2.62%                | github.com/robaho/go-trader/internal/exchange.(*exchange).Quote                                          116.17ms   100% |   github.com/robaho/go-trader/internal/exchange.sendMarketData

-- 
You received this message because you are subscribed 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/25E80A1A-DFA8-4BA6-A49C-0F8F656DFA81%40me.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/8F118071-A663-4CD8-963A-0F549C2D7E9E%40me.com.

Re: [go-nuts] question about HACKING.md

[Ian Lance Taylor]

On Thu, Jul 18, 2024 at 11:29 AM Leah Stapleton
 wrote:
>
> In the document HACKING.md 
> (https://github.com/golang/go/blob/master/src/runtime/HACKING.md), it states 
> that we can determine if we're running on the user or system stack by running 
> `getg() == getg().m.curg`.
>
> However if the output of that equality check is true, does that mean we're on 
> user or system stack?

The user stack.

> getg can return the current g but when executing on the system stack it 
> returns the current M's g0.
>
> I assume that a true means we're on the user stack because it says "To get 
> the current user g, use getg().m.curg". However, there's no where that I can 
> see that says that m.curg can't be the system stack, so please clarify.

As it says, getg().m.curg is the current user g.  It's never a g0.  A
g0 is never a user g.  Each g has its own stack.  A g0 has a fixed
system thread stack, a user g has a Go-managed user stack.

Ian

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

[go-nuts] question about HACKING.md

[Leah Stapleton]

In the document HACKING.md 
(https://github.com/golang/go/blob/master/src/runtime/HACKING.md), it 
states that we can determine if we're running on the user or system stack 
by running `getg() == getg().m.curg`. 

However if the output of that equality check is true, does that mean we're 
on user or system stack?

getg can return the current g but when executing on the system stack it 
returns the current M's g0. 

I assume that a true means we're on the user stack because it says "To get 
the current user g, use getg().m.curg". However, there's no where that I 
can see that says that m.curg can't be the system stack, so please clarify.



Thank you,



-- 
You received this message because you are subscribed 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/39aacbed-0853-41cd-ad72-d9d0c9aa9242n%40googlegroups.com.

Re: [go-nuts] Mutex profiling question

[robert engels]

Looks like the name was changed to runtimecontentionstacks

Much better now…

(pprof) tree
Showing nodes accounting for 481.75ms, 100% of 481.75ms total
Dropped 39 nodes (cum <= 2.41ms)
--+-
  flat  flat%   sum%cum   cum%   calls calls% + context 
 
--+-
  401.25ms 83.51% |   
runtime.findRunnable (inline)
   35.26ms  7.34% |   runtime.sysmon 
(inline)
   17.37ms  3.62% |   runtime.stopm 
(inline)
   14.01ms  2.92% |   
runtime.saveBlockEventStack (inline)
6.07ms  1.26% |   
runtime.goschedImpl (inline)
1.52ms  0.32% |   runtime.schedule 
(inline)
1.30ms  0.27% |   
sync.(*Mutex).Unlock (inline)
1.30ms  0.27% |   
github.com/robaho/go-trader/internal/exchange.sendMarketData (inline)
1.17ms  0.24% |   sync.(*Map).Swap 
(inline)
1.16ms  0.24% |   
github.com/robaho/go-trader/internal/exchange.(*grpcServer).Connection (inline)
  480.46ms 99.73% 99.73%   480.46ms 99.73%| runtime.unlock

but this seems suspect, that finding the runnable should consume so much time. 
Is this a side effect of the scheduler, and it is really blocked in the unlock 
call waiting for another routine to be runnable?



> On Jul 18, 2024, at 10:14 AM, 'Robert Engels' via golang-nuts 
>  wrote:
> 
> I found this issue, https://github.com/golang/go/issues/57071 
>  and tried running with 
> 
> GODEBUG=profileruntimelocks=1
> 
> but it made no difference in the output.
> 
> I am using Go 1.22.4 on OSX.
> 
> Any ideas how I can determine what is causing this high contention shown 
> below:
> 
> (pprof) tree
> Showing nodes accounting for 4440.35ms, 100% of 4440.35ms total
> --+-
>   flat  flat%   sum%cum   cum%   calls calls% + context   
>  
> --+-
>  4324.17ms 97.38% 97.38%  4324.17ms 97.38%| 
> runtime._LostContendedRuntimeLock
> --+-
>   116.17ms   100% |   
> sync.(*Map).Swap (inline)
>   116.17ms  2.62%   100%   116.17ms  2.62%| 
> sync.(*Mutex).Unlock
> --+-
>   116.17ms   100% |   
> github.com/robaho/go-trader/internal/exchange 
> .(*grpcServer).massquote
>  0 0%   100%   116.17ms  2.62%| 
> github.com/robaho/go-trader/internal/exchange 
> .(*exchange).Quote
>   116.17ms   100% |   
> github.com/robaho/go-trader/internal/exchange.sendMarketData 
> 
> 
> 
> -- 
> You received this message because you are subscribed 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/25E80A1A-DFA8-4BA6-A49C-0F8F656DFA81%40me.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/0F9BD4CD-4125-4CF8-A253-CD697AAD29C6%40ix.netcom.com.

Re: [go-nuts] this code sometimes hangs

[robert engels]

To clarify, the inner Go routine calls Done() at the start, so the main can get 
to the Broadcast before the inners are waiting.

Which is what Jan’s fix will fix :) (pretty sure)

> On Jul 18, 2024, at 10:20 AM, robert engels  wrote:
> 
> Because the wait on the condition is in another Go routine, so the the 
> Broadcast occurs before all of the routines are waiting. Broadcast only wakes 
> up currently waiting routines.
> 
>> On Jul 18, 2024, at 9:01 AM, Lammie Jonson > > wrote:
>> 
>> // I am not sure why this code sometimes deadlocks, but sometimes it doesn't.
>> // Hopefully someone will have some suggestions 
>> 
>> package main
>> 
>> // ??? sometimes deadlocks
>> 
>> import (
>> "fmt"
>> "sync"
>> "time"
>> )
>> 
>> type Button struct {
>> Clicked *sync.Cond
>> }
>> 
>> func main() {
>> button := Button{
>> Clicked: sync.NewCond({}),
>> }
>> 
>> // running on goroutine every function that passed/registered
>> // and wait, not exit until that goroutine is confirmed to be running
>> subscribe := func(c *sync.Cond, param string, fn func(s string)) {
>> var goroutineRunning sync.WaitGroup
>> var cnt = 0
>> cnt = cnt + 1
>> 
>> fmt.Println("cnt:", cnt)
>> goroutineRunning.Add(1)
>> 
>> go func(p string) {
>>   goroutineRunning.Done()
>>   c.L.Lock() // critical section
>>   defer c.L.Unlock()
>> 
>>   fmt.Println("Registered and wait ... ")
>>   // HANG SPOT: can hang here 
>>   c.Wait()
>>   fmt.Println("afer goroutine wait for:", param)
>> 
>>   fn(p)
>> }(param)
>> fmt.Println("call wait before goroutine exit")
>> goroutineRunning.Wait()
>> fmt.Println("after wait, subscribe exits")
>> }
>> 
>> var clickRegistered sync.WaitGroup
>> 
>> for _, v := range []string{
>> "Maximizing window.",
>> "Displaying annoying dialog box!",
>> "Mouse clicked."} {
>> 
>> clickRegistered.Add(1)
>> 
>> subscribe(button.Clicked, v, func(s string) {
>> fmt.Println(s, "")
>> clickRegistered.Done()
>> })
>> }
>> 
>> fmt.Println("broadcast")
>> // is supposed to get the goroutines past HANG SPOT
>> button.Clicked.Broadcast()
>> time.Sleep(4000 * time.Millisecond)
>> 
>> clickRegistered.Wait()
>> }
>> 
>> -- 
>> You received this message because you are subscribed 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/d8148ef1-4d56-4b0b-a2d8-2992abe7a6c2n%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/BCE619ED-241A-4239-99E2-D8C20994EB0A%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/68FB0F9A-E05F-4909-ABD6-13A05922DE86%40ix.netcom.com.

Re: [go-nuts] this code sometimes hangs

[robert engels]

Because the wait on the condition is in another Go routine, so the the 
Broadcast occurs before all of the routines are waiting. Broadcast only wakes 
up currently waiting routines.

> On Jul 18, 2024, at 9:01 AM, Lammie Jonson  wrote:
> 
> // I am not sure why this code sometimes deadlocks, but sometimes it doesn't.
> // Hopefully someone will have some suggestions 
> 
> package main
> 
> // ??? sometimes deadlocks
> 
> import (
> "fmt"
> "sync"
> "time"
> )
> 
> type Button struct {
> Clicked *sync.Cond
> }
> 
> func main() {
> button := Button{
> Clicked: sync.NewCond({}),
> }
> 
> // running on goroutine every function that passed/registered
> // and wait, not exit until that goroutine is confirmed to be running
> subscribe := func(c *sync.Cond, param string, fn func(s string)) {
> var goroutineRunning sync.WaitGroup
> var cnt = 0
> cnt = cnt + 1
> 
> fmt.Println("cnt:", cnt)
> goroutineRunning.Add(1)
> 
> go func(p string) {
>   goroutineRunning.Done()
>   c.L.Lock() // critical section
>   defer c.L.Unlock()
> 
>   fmt.Println("Registered and wait ... ")
>   // HANG SPOT: can hang here 
>   c.Wait()
>   fmt.Println("afer goroutine wait for:", param)
> 
>   fn(p)
> }(param)
> fmt.Println("call wait before goroutine exit")
> goroutineRunning.Wait()
> fmt.Println("after wait, subscribe exits")
> }
> 
> var clickRegistered sync.WaitGroup
> 
> for _, v := range []string{
> "Maximizing window.",
> "Displaying annoying dialog box!",
> "Mouse clicked."} {
> 
> clickRegistered.Add(1)
> 
> subscribe(button.Clicked, v, func(s string) {
> fmt.Println(s, "")
> clickRegistered.Done()
> })
> }
> 
> fmt.Println("broadcast")
> // is supposed to get the goroutines past HANG SPOT
> button.Clicked.Broadcast()
> time.Sleep(4000 * time.Millisecond)
> 
> clickRegistered.Wait()
> }
> 
> -- 
> You received this message because you are subscribed 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/d8148ef1-4d56-4b0b-a2d8-2992abe7a6c2n%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/BCE619ED-241A-4239-99E2-D8C20994EB0A%40ix.netcom.com.

Re: [go-nuts] this code sometimes hangs

[Jan Mercl]

On Thu, Jul 18, 2024 at 4:24 PM Lammie Jonson  wrote:
>   goroutineRunning.Done()

Should be

defer goroutineRunning.Done()

(not tested)

-- 
You received this message because you are subscribed 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-XpOke74VyM9Lk8ym0ntjDcG65nZ0hO2gq0_dCDT3NW5w%40mail.gmail.com.

[go-nuts] Mutex profiling question

['Robert Engels' via golang-nuts]

I found this issue, https://github.com/golang/go/issues/57071 and tried running 
with 

GODEBUG=profileruntimelocks=1

but it made no difference in the output.

I am using Go 1.22.4 on OSX.

Any ideas how I can determine what is causing this high contention shown below:

(pprof) tree
Showing nodes accounting for 4440.35ms, 100% of 4440.35ms total
--+-
  flat  flat%   sum%cum   cum%   calls calls% + context 
 
--+-
 4324.17ms 97.38% 97.38%  4324.17ms 97.38%| 
runtime._LostContendedRuntimeLock
--+-
  116.17ms   100% |   sync.(*Map).Swap 
(inline)
  116.17ms  2.62%   100%   116.17ms  2.62%| sync.(*Mutex).Unlock
--+-
  116.17ms   100% |   
github.com/robaho/go-trader/internal/exchange.(*grpcServer).massquote
 0 0%   100%   116.17ms  2.62%| 
github.com/robaho/go-trader/internal/exchange.(*exchange).Quote
  116.17ms   100% |   
github.com/robaho/go-trader/internal/exchange.sendMarketData

-- 
You received this message because you are subscribed 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/25E80A1A-DFA8-4BA6-A49C-0F8F656DFA81%40me.com.

[go-nuts] this code sometimes hangs

[Lammie Jonson]

// I am not sure why this code sometimes deadlocks, but sometimes it 
doesn't.
// Hopefully someone will have some suggestions 

package main

// ??? sometimes deadlocks

import (
"fmt"
"sync"
"time"
)

type Button struct {
Clicked *sync.Cond
}

func main() {
button := Button{
Clicked: sync.NewCond({}),
}

// running on goroutine every function that passed/registered
// and wait, not exit until that goroutine is confirmed to be running
subscribe := func(c *sync.Cond, param string, fn func(s string)) {
var goroutineRunning sync.WaitGroup
var cnt = 0
cnt = cnt + 1

fmt.Println("cnt:", cnt)
goroutineRunning.Add(1)

go func(p string) {
  goroutineRunning.Done()
  c.L.Lock() // critical section
  defer c.L.Unlock()

  fmt.Println("Registered and wait ... ")
  // HANG SPOT: can hang here 
  c.Wait()
  fmt.Println("afer goroutine wait for:", param)

  fn(p)
}(param)
fmt.Println("call wait before goroutine exit")
goroutineRunning.Wait()
fmt.Println("after wait, subscribe exits")
}

var clickRegistered sync.WaitGroup

for _, v := range []string{
"Maximizing window.",
"Displaying annoying dialog box!",
"Mouse clicked."} {

clickRegistered.Add(1)

subscribe(button.Clicked, v, func(s string) {
fmt.Println(s, "")
clickRegistered.Done()
})
}

fmt.Println("broadcast")
// is supposed to get the goroutines past HANG SPOT
button.Clicked.Broadcast()
time.Sleep(4000 * time.Millisecond)

clickRegistered.Wait()
}

-- 
You received this message because you are subscribed 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/d8148ef1-4d56-4b0b-a2d8-2992abe7a6c2n%40googlegroups.com.

Re: [go-nuts] gomobile: weird dependency on dmitri.shuralyov.com/gpu/mtl

[王旭东]

sry, might be may fault.
Sorry, that might be my fault. What you observed from the go mod why  that 
could be related to this issue: https://github.com/golang/go/issues/27900?

在2024年7月18日星期四 UTC+8 11:36:24<王旭东> 写道：

> Hi,
>
> It seems there might be a misunderstanding regarding the go mod why 
> command. Please note that any transitive dependencies will not be displayed 
> in the output. For instance, x/exp/shiny could be a transitive dependency 
> of a direct dependency in your main module, which is why you see the 
> message "(main module does not need package golang.org/x/exp/shiny)."
>
> To understand why dmitri.shuralyov.com/gpu/mtl is used by x/mobile, I 
> recommend checking the source code of both x/mobile and x/exp/shiny.
>
>
> Xudong
>
> 在2024年7月17日星期三 UTC+8 23:42:28 写道：
>
>> Hi!
>>
>> Sadly, "go mod why" doesn't really work for gomobile (
>> https://cs.opensource.google/go/x/mobile) and its dependencies since 
>> they are technically not used in my library/package. They are used at build 
>> time to generate language bindings that make it possible to call Go 
>> functions from Java and Objective-C.
>>
>> go mod why golang.org/x/exp/shiny 
>>
>> go: downloading golang.org/x/exp v0.0.0-20190731235908-ec7cb31e5a56
>>
>> # golang.org/x/exp/shiny
>>
>> (main module does not need package golang.org/x/exp/shiny)
>>
>> My doubt is: why is dmitri.shuralyov.com/gpu/mtl, a package for gpu use 
>> and geometry rendering, listed as a dependency of 
>> https://cs.opensource.google/go/x/mobile (a package to generate language 
>> bindings to call Go functions from Java/Obj-C)? That doesn't sound right to 
>> me. Given the widely known supply chain attacks this is something that 
>> should be looked into, right?
>>
>>
>>
>> On Thu, Jul 11, 2024 at 9:04 PM Kurtis Rader  
>> wrote:
>>
>>> Try "go mod why $dependency"; e.g.,
>>>
>>> > go mod why github.com/sourcegraph/jsonrpc2
>>> # github.com/sourcegraph/jsonrpc2
>>> src.elv.sh/pkg/lsp
>>> github.com/sourcegraph/jsonrpc2
>>>
>>> There's also "go mod graph". 
>>>
>>> On Thu, Jul 11, 2024 at 4:44 PM Alvaro Crespo  
>>> wrote:
>>>
 Hi there!

 I'm not an expert go dev but I'm using 
 https://cs.opensource.google/go/x/mobile to build a domain layer for 
 both an Android and an iOS app. First of all, congrats on the good work. 
 The project is amazing.

 I recently updated the gomobile package version and found out a strange 
 looking new addition to my go.sum. Namely, this one:

 dmitri.shuralyov.com/gpu/mtl v0.0.0-20221208032759-85de2813cf6b/go.mod 
 h1:H6x//7gZCb22OMCxBHrMx7a5I7Hp++hsVxbQ4BYO7hU=

 I researched a bit and found out Dmitri (great job!) and his package (
 https://dmitri.shuralyov.com/gpu/mtl). But from the description it 
 doesn't look like something the gomobile project would need to use:

 Package mtl provides access to Apple's Metal API (
 https://developer.apple.com/documentation/metal).
 (...)
 This package is in very early stages of development. The API will 
 change when opportunities for improvement are discovered; it is not yet 
 frozen. Less than 20% of the Metal API surface is implemented. Current 
 functionality is sufficient to render very basic geometry.

 Is this ok? Using *go mod graph*it appears this is a dependency of 
 *golang.org/x/exp/shiny 
 ,*  which I'm also not entirely sure 
 why its included as a whole.

 Is this something that should be reported? I would love some 
 clarification on this.


 -- 
 You received this message because you are subscribed 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/aaa96093-696e-469a-895e-9cb99c82fc58n%40googlegroups.com
  
 
 .

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

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