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

[twp...@gmail.com]

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 Caldwell wrote:

> Oops, I didn't look carefully at the json output of my little program. It 
> does sometimes emit arrays. For example:
>
> go build xmlparse.go
>
> ./xmlparse -url 'https://news.google.com/atom'
>
>
> This produces what, for some part, represents acceptable json. The 
> exceptions are the atom entries that would still require, I think, another 
> pass to fix up the go structure unless someone applies a priori knowledge 
> of the xml structure when building it.
>
>
> D
>
>
>
> D
>
>
> D
>
> On Tue, Apr 23, 2024 at 1:18 PM Don Caldwell  wrote:
>
>> I agree. The link that I sent demonstrates one very simple way. Mapping 
>> XML with repetitive tag sets to JSON arrays, though, would take a bit of 
>> work meaning, I think, at least two passes.
>>
>> D
>>
>> On Tue, Apr 23, 2024, 13:04 robert engels  wrote:
>>
>>> I don’t think that is true. There are multiple ways to model XML into 
>>> json.
>>>
>>> See this http://badgerfish.ning.com for one of them.
>>>
>>> On Apr 23, 2024, at 11:43 AM, burak serdar  wrote:
>>>
>>> In general, you cannot convert xml to json. They have incompatible
>>> models. XML elements are ordered similar to a JSON array, but in many
>>> cases you want to map XML elements to JSON objects, which are
>>> unordered name-value collections. Also, there is no JSON equivalent of
>>> an XML attribute.
>>>
>>> If you want to work with XML, either use xml marshaling, or find a
>>> third-party DOM library.
>>>
>>> On Tue, Apr 23, 2024 at 10:29 AM Don Caldwell  wrote:
>>>
>>>
>>> Disclaimer - I am very new to golang.
>>> I puzzled about this for a few days. After some struggle, I got a little 
>>> program working that parses
>>> arbitrary xml into a structure that json can understand. You can find it 
>>> here:
>>> https://github.com/dfwcnj/gxmldecode
>>>
>>> On Thursday, October 7, 2021 at 10:06:30 AM UTC-4 RS wrote:
>>>
>>>
>>> What is the best approach to convert xml to json?
>>> However I need above all to parse a very complex xml to see if related 
>>> properties are existing.
>>> I thought maybe converting it to Json maybe make it easier.
>>>
>>>
>>> --
>>> You received this message because you are subscribed 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/90c0dd22-2d81-4393-b534-651a2376f386n%40googlegroups.com
>>> .
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqowOgbOnmGxsWegOuJ-_crQcNhsjj1Gxk3pAXhBmtNK5Q%40mail.gmail.com
>>> .
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5a2d51fa-92e3-47b7-9f62-5412f0e07685n%40googlegroups.com.

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

[Tony M]

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

  
shows
" go get golang.org/x/tour

but when i try 
 go install golang.org/x/tour

I find myself running into this issue installing any older modules before 
the "go get" deprecation
On Tuesday, September 26, 2023 at 7:22:41 AM UTC-7 Pankaj Jangid wrote:

> go install golang.org/x/website/tour@latest
>
> On Tuesday, 26 September 2023 at 11:59:57 UTC+5:30 王富民awaw wrote:
>
>> Hi Friends of Go
>>
>> Is there an offline version of A Tour of Go?
>> Could be in PDF or Powerpoint or preferably Go's beautiful present format.
>>
>> A quick Google search didn't reveal anything relevant.
>> 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/4f055dc7-a5b4-46af-9d40-d994c73199d1n%40googlegroups.com.

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

[robert engels]

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 ± ∞ ¹~ 
(p=1.000 n=1) ²
AddDecimal-8   243.00n ± ∞ ¹66.27n ± ∞ ¹~ 
(p=1.000 n=1) ²
AddBigInt-8 14.30n ± ∞ ¹10.65n ± ∞ ¹~ 
(p=1.000 n=1) ²
AddBigFloat-8   78.80n ± ∞ ¹66.33n ± ∞ ¹~ 
(p=1.000 n=1) ²
MulFixed-8  4.880n ± ∞ ¹3.939n ± ∞ ¹~ 
(p=1.000 n=1) ²
MulDecimal-872.00n ± ∞ ¹67.07n ± ∞ ¹~ 
(p=1.000 n=1) ²
MulBigInt-8 17.10n ± ∞ ¹10.49n ± ∞ ¹~ 
(p=1.000 n=1) ²
MulBigFloat-8   35.50n ± ∞ ¹24.12n ± ∞ ¹~ 
(p=1.000 n=1) ²
DivFixed-8  4.710n ± ∞ ¹3.661n ± ∞ ¹~ 
(p=1.000 n=1) ²
DivDecimal-8779.0n ± ∞ ¹469.6n ± ∞ ¹~ 
(p=1.000 n=1) ²
DivBigInt-8 46.10n ± ∞ ¹34.90n ± ∞ ¹~ 
(p=1.000 n=1) ²
DivBigFloat-8   108.0n ± ∞ ¹113.6n ± ∞ ¹~ 
(p=1.000 n=1) ²
CmpFixed-8 0.3800n ± ∞ ¹   0.2784n ± ∞ ¹~ 
(p=1.000 n=1) ²
CmpDecimal-88.050n ± ∞ ¹6.475n ± ∞ ¹~ 
(p=1.000 n=1) ²
CmpBigInt-8 5.870n ± ∞ ¹4.805n ± ∞ ¹~ 
(p=1.000 n=1) ²
CmpBigFloat-8   5.460n ± ∞ ¹5.081n ± ∞ ¹~ 
(p=1.000 n=1) ²
StringFixed-8   57.40n ± ∞ ¹50.64n ± ∞ ¹~ 
(p=1.000 n=1) ²
StringNFixed-8  55.60n ± ∞ ¹49.66n ± ∞ ¹~ 
(p=1.000 n=1) ²
StringDecimal-8 218.0n ± ∞ ¹197.0n ± ∞ ¹~ 
(p=1.000 n=1) ²
StringBigInt-8 122.00n ± ∞ ¹98.00n ± ∞ ¹~ 
(p=1.000 n=1) ²
StringBigFloat-8416.0n ± ∞ ¹395.2n ± ∞ ¹~ 
(p=1.000 n=1) ²
WriteTo-8   45.80n ± ∞ ¹31.71n ± ∞ ¹~ 
(p=1.000 n=1) ²
geomean 28.48n  22.28n-21.75%
¹ need >= 6 samples for confidence interval at level 0.95
² need >= 4 samples to detect a difference at alpha level 0.05

 │ /Users/robertengels/go1.12.17.txt │  
/Users/robertengels/go1.22.2.txt   │
 │   B/op│B/op  vs base 
   │
AddFixed-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
AddDecimal-8176.00 ± ∞ ¹   80.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
AddBigInt-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
AddBigFloat-848.00 ± ∞ ¹   48.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
MulFixed-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
MulDecimal-8 80.00 ± ∞ ¹   80.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
MulBigInt-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
MulBigFloat-80.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
DivFixed-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
DivDecimal-8 568.0 ± ∞ ¹   384.0 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
DivBigInt-8  8.000 ± ∞ ¹   8.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
DivBigFloat-824.00 ± ∞ ¹   24.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
CmpFixed-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
CmpDecimal-8 0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
CmpBigInt-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
CmpBigFloat-80.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
(p=1.000 n=1) ²
StringFixed-832.00 ± ∞ ¹   24.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
StringNFixed-8   32.00 ± ∞ ¹   24.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
StringDecimal-8  64.00 ± ∞ ¹   56.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
StringBigInt-8   24.00 ± ∞ ¹   16.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
StringBigFloat-8 192.0 ± ∞ ¹   176.0 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
WriteTo-818.00 ± ∞ ¹   28.00 ± ∞ ¹   ~ 
(p=1.000 n=1) ³
geomean⁴-8.44%  
 ⁴
¹ need >= 6 samples for confidence interval at level 0.95
² all samples are equal
³ need >= 4 samples to detect a difference at alpha level 0.05
⁴ summaries must be >0 to compute 

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

['Robert Engels' via golang-nuts]

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

   
 │  sec/op  │sec/op  vs base
│   

   
AddFixed-80.9603n ± ∞ ¹   0.7931n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
AddDecimal-8   66.41n ± ∞ ¹66.27n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
AddBigInt-89.452n ± ∞ ¹   10.650n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
AddBigFloat-8  63.26n ± ∞ ¹66.33n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
MulFixed-8 3.519n ± ∞ ¹3.939n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
MulDecimal-8   65.98n ± ∞ ¹67.07n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
MulBigInt-810.69n ± ∞ ¹10.49n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
MulBigFloat-8  23.72n ± ∞ ¹24.12n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
DivFixed-8 3.675n ± ∞ ¹3.661n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
DivDecimal-8   460.8n ± ∞ ¹469.6n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
DivBigInt-834.82n ± ∞ ¹34.90n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
DivBigFloat-8  110.4n ± ∞ ¹113.6n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
CmpFixed-80.2529n ± ∞ ¹   0.2784n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
CmpDecimal-8   6.883n ± ∞ ¹6.475n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
CmpBigInt-84.779n ± ∞ ¹4.805n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
CmpBigFloat-8  4.411n ± ∞ ¹5.081n ± ∞ ¹   ~ 
(p=1.000 n=1) ² 

   
StringFixed-8  50.36n ± 

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

[Steven Hartland]

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 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 1.21.17:
>
> BenchmarkAddFixed-8 20   0.59 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkAddDecimal-8500   243 ns/op 
> 176 B/op  8 allocs/op
> BenchmarkAddBigInt-81   14.3 ns/op
>  0 B/op  0 allocs/op
> BenchmarkAddBigFloat-8  200078.8 ns/op
> 48 B/op  1 allocs/op
> BenchmarkMulFixed-8 34.88 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkMulDecimal-8   200072.0 ns/op
> 80 B/op  2 allocs/op
> BenchmarkMulBigInt-81   17.1 ns/op
>  0 B/op  0 allocs/op
> BenchmarkMulBigFloat-8  300035.5 ns/op
>  0 B/op  0 allocs/op
> BenchmarkDivFixed-8 34.71 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkDivDecimal-8200   779 ns/op 
> 568 B/op 21 allocs/op
> BenchmarkDivBigInt-8300046.1 ns/op
>  8 B/op  1 allocs/op
> BenchmarkDivBigFloat-8  2000   108 ns/op  
> 24 B/op  2 allocs/op
> BenchmarkCmpFixed-8 20   0.38 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkCmpDecimal-8   28.05 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkCmpBigInt-835.87 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkCmpBigFloat-8  35.46 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkStringFixed-8  200057.4 ns/op
> 32 B/op  1 allocs/op
> BenchmarkStringNFixed-8 200055.6 ns/op
> 32 B/op  1 allocs/op
> BenchmarkStringDecimal-81000   218 ns/op  
> 64 B/op  5 allocs/op
> BenchmarkStringBigInt-8 1000   122 ns/op  
> 24 B/op  2 allocs/op
> BenchmarkStringBigFloat-8300   416 ns/op 
> 192 B/op  8 allocs/op
> BenchmarkWriteTo-8  300045.8 ns/op
> 18 B/op  0 allocs/op
>
>
> and version 1.21.5:
>
> BenchmarkAddFixed-8 10   0.9735 ns/op 
>  0 B/op  0 allocs/op
> BenchmarkAddDecimal-8   1431199569.99 ns/op   
> 80 B/op  2 allocs/op
> BenchmarkAddBigInt-81   13.42 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkAddBigFloat-8  1750670263.84 ns/op   
> 48 B/op  1 allocs/op
> BenchmarkMulFixed-8 3139831043.732 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkMulDecimal-8   1804652066.59 ns/op   
> 80 B/op  2 allocs/op
> BenchmarkMulBigInt-81   10.79 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkMulBigFloat-8  4918602424.30 ns/op   
>  0 B/op  0 allocs/op
> BenchmarkDivFixed-8 3068880693.721 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkDivDecimal-82510688   462.4 ns/op   
> 384 B/op 12 allocs/op
> BenchmarkDivBigInt-83399382237.02 ns/op   
>  8 B/op  1 allocs/op
> BenchmarkDivBigFloat-8   9415330   111.5 ns/op
> 24 B/op  2 allocs/op
> BenchmarkCmpFixed-8 10   0.2548 ns/op 
>  0 B/op  0 allocs/op
> BenchmarkCmpDecimal-8   1687145497.086 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkCmpBigInt-82348956344.952 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkCmpBigFloat-8  2608144644.503 ns/op  
>  0 B/op  0 allocs/op
> BenchmarkStringFixed-8  2372547050.57 ns/op   
> 24 B/op  1 allocs/op
> BenchmarkStringNFixed-8 232850.67 ns/op  

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

[robert engels]

Rough guess, it seems about the same.

1.22.2:

BenchmarkAddFixed-8 10   0.7931 ns/op  
0 B/op  0 allocs/op 

  
BenchmarkAddDecimal-8   1815612066.27 ns/op   
80 B/op  2 allocs/op

   
BenchmarkAddBigInt-81   10.65 ns/op
0 B/op  0 allocs/op 

  
BenchmarkAddBigFloat-8  1810566766.33 ns/op   
48 B/op  1 allocs/op

   
BenchmarkMulFixed-8 2957369673.939 ns/op   
0 B/op  0 allocs/op 

  
BenchmarkMulDecimal-8   1782734067.07 ns/op   
80 B/op  2 allocs/op

   
BenchmarkMulBigInt-81   10.49 ns/op
0 B/op  0 allocs/op 

  
BenchmarkMulBigFloat-8  4965171024.12 ns/op
0 B/op  0 allocs/op 

  
BenchmarkDivFixed-8 3094442373.661 ns/op   
0 B/op  0 allocs/op 

  
BenchmarkDivDecimal-82426755   469.6 ns/op   
384 B/op 12 allocs/op   


BenchmarkDivBigInt-83428970134.90 ns/op
8 B/op  1 allocs/op 

  
BenchmarkDivBigFloat-8   9028243   113.6 ns/op
24 B/op  2 allocs/op

   
BenchmarkCmpFixed-8 10   0.2784 ns/op  
0 B/op  0 allocs/op 

  
BenchmarkCmpDecimal-8   1814675106.475 ns/op   
0 B/op  0 allocs/op 

  
BenchmarkCmpBigInt-82440902524.805 ns/op   
0 B/op  0 allocs/op 

  
BenchmarkCmpBigFloat-8  2568825125.081 ns/op   
0 B/op  0 allocs/op 

  

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

[Stephen Illingworth]

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 
a compute bound project , similar to your project, so I'd be interested in 
hearing how you think it performs with 1.22.0
On Wednesday 24 April 2024 at 19:27:07 UTC+1 Robert Engels wrote:

> 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 1.21.17:
>
> BenchmarkAddFixed-8 20   0.59 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkAddDecimal-8500   243 ns/op 
> 176 B/op  8 allocs/op 
>   
> 
> BenchmarkAddBigInt-81   14.3 ns/op
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkAddBigFloat-8  200078.8 ns/op
> 48 B/op  1 allocs/op  
>   
>
> BenchmarkMulFixed-8 34.88 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkMulDecimal-8   200072.0 ns/op
> 80 B/op  2 allocs/op  
>   
>
> BenchmarkMulBigInt-81   17.1 ns/op
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkMulBigFloat-8  300035.5 ns/op
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkDivFixed-8 34.71 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkDivDecimal-8200   779 ns/op 
> 568 B/op 21 allocs/op 
>   
> 
> BenchmarkDivBigInt-8300046.1 ns/op
>  8 B/op  1 allocs/op  
>   
>
> BenchmarkDivBigFloat-8  2000   108 ns/op  
> 24 B/op  2 allocs/op  
>   
>
> BenchmarkCmpFixed-8 20   0.38 ns/op   
>  0 B/op  0 allocs/op  
>   
>
> BenchmarkCmpDecimal-8   2  

[go-nuts] Congrats to the Go team

['Robert Engels' via golang-nuts]

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 1.21.17:

BenchmarkAddFixed-8 20   0.59 ns/op
0 B/op  0 allocs/op 

  
BenchmarkAddDecimal-8500   243 ns/op 
176 B/op  8 allocs/op   


BenchmarkAddBigInt-81   14.3 ns/op 
0 B/op  0 allocs/op 

  
BenchmarkAddBigFloat-8  200078.8 ns/op
48 B/op  1 allocs/op

   
BenchmarkMulFixed-8 34.88 ns/op
0 B/op  0 allocs/op 

  
BenchmarkMulDecimal-8   200072.0 ns/op
80 B/op  2 allocs/op

   
BenchmarkMulBigInt-81   17.1 ns/op 
0 B/op  0 allocs/op 

  
BenchmarkMulBigFloat-8  300035.5 ns/op 
0 B/op  0 allocs/op 

  
BenchmarkDivFixed-8 34.71 ns/op
0 B/op  0 allocs/op 

  
BenchmarkDivDecimal-8200   779 ns/op 
568 B/op 21 allocs/op   


BenchmarkDivBigInt-8300046.1 ns/op 
8 B/op  1 allocs/op 

  
BenchmarkDivBigFloat-8  2000   108 ns/op  
24 B/op  2 allocs/op

   
BenchmarkCmpFixed-8 20   0.38 ns/op
0 B/op  0 allocs/op 

  
BenchmarkCmpDecimal-8   28.05 ns/op
0 B/op  0 allocs/op 

  
BenchmarkCmpBigInt-835.87 ns/op
0 B/op  0 allocs/op 

  

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

[Henrique Gogó]

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 current directory, so effectively, it's
just like the first case.

So no, there's no difference.

Henrique

-- 
You received this message because you are subscribed 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/ZilM5Akxi5qCOAzs%40localhost.

[go-nuts] go build v go build .

[Steve Mynott]

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, 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/CANuZA8SP5MzKFGOqtRhQe4t-kDFm9Dp9njKoaCp7u6tCf1eVOQ%40mail.gmail.com.

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

[cpu...@gmail.com]

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 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 addressable?
>
> On Wednesday, April 24, 2024 at 6:51:21 PM UTC+2 burak serdar wrote:
>
>> 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 Wed, Apr 24, 2024 at 10:46 AM 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 >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) { 
>> > if err := json.Unmarshal([]byte(`{"Foo": 42}`), ); err != nil { 
>> > panic(err) 
>> > } 
>> > fmt.Printf("%v %T\n", v, v) 
>> > } 
>> > 
>> > func main() { 
>> > var val S 
>> > 
>> > // map[Foo:42] map[string]interface {} 
>> > update(val) 
>> > 
>> > // &{42} *main.S 
>> > update() 
>> > } 
>> > 
>> > Why would calling by value change the type of the value passed to map? 
>> I would expect an interface with a dynamic type of main.S, but its 
>> map[string]interface{}, or json.Unmarshal makes it so. 
>> > 
>> > Insights appreciated :) 
>> > 
>> > -- 
>> > You received this message because you are subscribed 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/980466d2-1686-4b79-aec1-45b592db2caan%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/0010deaa-b3c9-4323-a1f4-d0dc3eec3c78n%40googlegroups.com.

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

[cpu...@gmail.com]

> 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 addressable?

On Wednesday, April 24, 2024 at 6:51:21 PM UTC+2 burak serdar wrote:

> 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 Wed, Apr 24, 2024 at 10:46 AM 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 >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) {
> > if err := json.Unmarshal([]byte(`{"Foo": 42}`), ); err != nil {
> > panic(err)
> > }
> > fmt.Printf("%v %T\n", v, v)
> > }
> >
> > func main() {
> > var val S
> >
> > // map[Foo:42] map[string]interface {}
> > update(val)
> >
> > // &{42} *main.S
> > update()
> > }
> >
> > Why would calling by value change the type of the value passed to map? I 
> would expect an interface with a dynamic type of main.S, but its 
> map[string]interface{}, or json.Unmarshal makes it so.
> >
> > Insights appreciated :)
> >
> > --
> > You received this message because you are subscribed 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/980466d2-1686-4b79-aec1-45b592db2caan%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/ec00ba73-b91e-4a1c-a5ed-4d5507a90c18n%40googlegroups.com.

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

[cpu...@gmail.com]

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 >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) {
> if err := json.Unmarshal([]byte(`{"Foo": 42}`), ); err != nil {
> panic(err)
> }
> fmt.Printf("%v %T\n", v, v)
> }
>
> func main() {
> var val S
>
> // map[Foo:42] map[string]interface {}
> update(val)
>
> // &{42} *main.S
> update()
> }
>
> Why would calling by value change the type of the value passed to map? I 
> would expect an interface with a dynamic type of main.S, but its 
> map[string]interface{}, or json.Unmarshal makes it so.
>
> Insights appreciated :)
>

-- 
You received this message because you are subscribed 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/cb131536-4e2d-4f24-a922-86b8e83c24cdn%40googlegroups.com.

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

[burak serdar]

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 Wed, Apr 24, 2024 at 10:46 AM 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 >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) {
> if err := json.Unmarshal([]byte(`{"Foo": 42}`), ); err != nil {
> panic(err)
> }
> fmt.Printf("%v %T\n", v, v)
> }
>
> func main() {
> var val S
>
> // map[Foo:42] map[string]interface {}
> update(val)
>
> // &{42} *main.S
> update()
> }
>
> Why would calling by value change the type of the value passed to map? I 
> would expect an interface with a dynamic type of main.S, but its 
> map[string]interface{}, or json.Unmarshal makes it so.
>
> Insights appreciated :)
>
> --
> You received this message because you are subscribed 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/980466d2-1686-4b79-aec1-45b592db2caan%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/CAMV2RqrUtoauyu8dHGrrVppY%3DeTVP7dCZkb%2Br_Ax696UuJy6dQ%40mail.gmail.com.

[go-nuts] Where is my type?

[cpu...@gmail.com]

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) {
if err := json.Unmarshal([]byte(`{"Foo": 42}`), ); err != nil {
panic(err)
}
fmt.Printf("%v %T\n", v, v)
}

func main() {
var val S

// map[Foo:42] map[string]interface {}
update(val)

// &{42} *main.S
update()
}

Why would calling by value change the type of the value passed to map? I 
would expect an interface with a dynamic type of main.S, but its 
map[string]interface{}, or json.Unmarshal makes it so.

Insights appreciated :)

-- 
You received this message because you are subscribed 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/980466d2-1686-4b79-aec1-45b592db2caan%40googlegroups.com.

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

[robert engels]

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 of the critical sections.
> 
> It's a simple concept but I think it's something that can be built upon.
> 
> https://github.com/JetSetIlly/critsec
> 
> I'm posting it here because I think it's an interesting problem and I would 
> like
> to hear expert opinion. The problem is a real one but does this solution have 
> any
> merit?
> 
> -
> 
> The basic mechanism in this project is something I've used in a large rproject
> where performance is important. I wanted a way of locking access to data but
> without the risk of forgetting to unlock it. Very simple: 
> 
>   func (crit *Section) Lease(f func() error) error {
>   crit.lock.Lock()
>   defer crit.lock.Unlock()
>   return f()
>   }
>   
> I've been very happy with that but I thought it would be interesting to come 
> up
> with a method for statically analysing usage of the Lease() function. In other
> words, to detect those times when I access critical data outside of a Lease.
> 
> What's needed for this to work is a way of tagging data to say that it should
> only be accessed 'inside' a Lease().
> 
> My idea is this: define critical data by embedding a crit.Section struct in a
> new struct type:
> 
>   type Section struct {
>   lock sync.Mutex
>   }
> 
> 
>   type exampleCritSectioning struct {
>   crit.Section
>   a int
>   b bool
>   }
>   
> We can then lease the critical section:
> 
>   var C exampleCritSectioning
>   _ = C.Lease(func() error {
>   a = 100
>   return nil
>   })
> 
> 
> 
> So, critical data is identified with the crit.Section type and critical 
> sections
> by the entry and exit of the Lease function. Static analysis is now relatively
> simple:
> 
> 1. Find all instances of types that embed the crit.Section type
> 2. Find all accesses to data of those types
> 3. Check whether the callgraph to those access include a call to the Lease() 
> function
>
>
> The proof-of-concept project includes an analysis package as well as the crit
> package. A detailed example of an analysis report is given in the README
> 
> 
> Notes
> 
> I haven't used the analysistest package for testing because I had problems 
> with
> getting it to work with a go.work file. The examples/ package is used in lieue
> of that. 
> 
> A standalone driver for the analysis is in 'analysis/cmd/critcheck'
> 
> The callgraph is created with the 'x/tools/go/callgraph/vta' package. I 
> didn't put
> much though into this so there might be a better graph method. But VTA 
> provided
> the best results during experimentation
> 
> 
> Regards
> Stephen
> 
> -- 
> You received this message because you are subscribed 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/e2d9f1d9-958a-45df-b402-fe98a213fa67n%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/CB784B45-7498-4C12-98CC-07CEBCFE9DD0%40ix.netcom.com.