Re: [go-nuts] xml to json, parsing xml

You can parse XML and JSON quickly with these tools: https://github.com/twpayne/go-xmlstruct https://github.com/twpayne/go-jsonstruct They generate Go code that parses all the example XML and JSON files that you throw at them. Regards, Tom On Tuesday, April 23, 2024 at 9:17:33 PM UTC+2 Don

[go-nuts] Re: Offline version of A Tour of Go

thanks this was helpful. Is there a good rule of thumb when updating old "go get" instructions. e.g. Go Tour (googlesource.com)

Re: [go-nuts] Congrats to the Go team

And for the 1.12 vs 1.22: │ /Users/robertengels/go1.12.17.txt │ /Users/robertengels/go1.22.2.txt│ │ sec/op │sec/op vs base │ AddFixed-8 0.5900n ± ∞ ¹ 0.7931n ± ∞ ¹~

Re: [go-nuts] Congrats to the Go team

│ /Users/robertengels/go1.21.5.txt │ /Users/robertengels/go1.22.2.txt│ │

Re: [go-nuts] Congrats to the Go team

What’s it look like when your run it through https://pkg.go.dev/golang.org/x/perf/cmd/benchstat which will provide a nice side by side comparison? On Wed, 24 Apr 2024 at 19:26, 'Robert Engels' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I have a fairly stable project

Re: [go-nuts] Congrats to the Go team

Rough guess, it seems about the same. 1.22.2: BenchmarkAddFixed-8 10 0.7931 ns/op 0 B/op 0 allocs/op

[go-nuts] Re: Congrats to the Go team

How does it perform with v1.22.0? I found a small but measurable drop in throughput in one of my projects when compiled with 1.22.0. Issue raised here: https://github.com/golang/go/issues/65647#issuecomment-1944830588 I have a feeling it's an issue with my older development hardware. But it's

[go-nuts] Congrats to the Go team

I have a fairly stable project github.com/robaho/fixed which is almost 100% cpu bound. It doesn’t change so it makes a great way to compare the performance of different Go versions using the same hardware. I took the time to re-run the tests today. Using

Re: [go-nuts] go build v go build .

On Wed, Apr 24, 2024 at 06:24:33PM +0100, Steve Mynott wrote: > Is there any difference between "go build" and "go build ."? The last param of "go build" is the package to build. If you don't specify anything, it builds the package in the current directory. In you second case, it builds the

[go-nuts] go build v go build .

Is there any difference between "go build" and "go build ."? -- Steve Mynott rsa3072/629FBB91565E591955B5876A79CEFAA4450EBD50 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it,

Re: [go-nuts] Where is my type?

Your answer has put me on the right track. Here's the long version: https://stackoverflow.com/questions/48790663/why-value-stored-in-an-interface-is-not-addressable-in-golang On Wednesday, April 24, 2024 at 6:55:53 PM UTC+2 cpu...@gmail.com wrote: > > In the first case, the interface contains

Re: [go-nuts] Where is my type?

> In the first case, the interface contains a value of type S, which is not writable. The value contained in the interface is not addressable. Thank you for the quick feedback. Why is that? Memory for val has been allocated and val is passed by value (hence copied). Why is that copy not be

[go-nuts] Re: Where is my type?

It's worth noting that before the Unmarshal v is {}(main.S) and afterwards {}(map[string]interface{}) On Wednesday, April 24, 2024 at 6:46:18 PM UTC+2 cpu...@gmail.com wrote: > Every time I feel I've come to terms with how Go works I round a corner > and hit a wall, even after doing this for

Re: [go-nuts] Where is my type?

In the first case, the interface contains a value of type S, which is not writable. The value contained in the interface is not addressable. So Unmarshal creates a new map and fills that. In the second case the interface contains *S, which is writable, so unmarshal fills it in via reflection. On

[go-nuts] Where is my type?

Every time I feel I've come to terms with how Go works I round a corner and hit a wall, even after doing this for >5 years. Here's one. Consider this simple code (https://go.dev/play/p/bph5I80vc99): package main import ( "encoding/json" "fmt" ) type S struct { Foo int } func update(v any) {

Re: [go-nuts] Critical Section - static analysis

The github link you provided results in a 404 error. > On Apr 22, 2024, at 1:58 PM, Stephen Illingworth > wrote: > > Hello, > > I've created a proof-of-concept for a method of defining critical sections. > Crucially, the scheme allows for static analysis, thereby helping prevent > violations