[go-nuts] Re: why p's local run queue size is 256?

[jin wang]

but 256 run queue size, it's length is 256*8 2048byte, some cpu cache line 
is 32, 64, 128, 256, if run queue length is 128, half of queue size if 
64*8 512byte, they can't be in the same cache line.

在 2020年1月27日星期一 UTC+8下午12:50:32，changkun写道：
>
> 256 run queue size is designed for the work-steal scheduler to prevent 
> false sharing.
>
> 128 run queue size exactly fits one cache line. Since the run queue can be 
> stolen half of the run queue from the tail by other Ps, 256 run queue size 
> prevents false sharing when the work-steal happens on different cores.
>
> On Sunday, January 26, 2020 at 6:31:27 PM UTC+8, jin wang wrote:
>>
>> why p's local run queue size is 256, not 128 or 512?
>>
>

-- 
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/f65f8ad6-38e4-441a-a1db-78b2a40cdcdc%40googlegroups.com.

[go-nuts] Go Module and Build Tag

[Henry]

Hi,

I wonder whether it is possible to specify a dependency's build tags in go 
module. Let's say that Project A depends on Library B. Library B has 
optional features (using the *//+build*) that Project A requires. Is there 
any way to specify Library B's build tags in Project A's go.mod?

Thanks

Henry

-- 
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/7a46018a-d362-4671-937a-49b1e9f2a4a1%40googlegroups.com.

Re: [go-nuts] JSON: Having trouble parsing map keys with dots like {"foo.bar":"baz"}

[Mark Hansen]

Ah, thanks! Thought I might be holding it wrong.

Still though, isn’t it strange that the extra space works if you don’t have
the dot in the key?



On Wed, 29 Jan 2020 at 00:59, Lutz Horn  wrote:

> Remove the blank in ``json: "baz.bar"` and make it `json:"baz.bar"`. This
> works: https://play.golang.com/p/i9SURYgGO66
>
> 
> Von: golang-nuts@googlegroups.com  im
> Auftrag von m...@markhansen.co.nz 
> Gesendet: Dienstag, 28. Januar 2020 12:14
> An: golang-nuts
> Betreff: [go-nuts] JSON: Having trouble parsing map keys with dots like
> {"foo.bar":"baz"}
>
> Hi folks, for background, I'm trying to read the Kaiterra API<
> https://www.kaiterra.com/dev/#overview> using encoding/json, which has
> JSON values like this:
>
>
> {"id":"-0001-0001--7e57c0de","info.aqi":{"ts":"2018-03-26T08:53:20Z","data":{"pm10":120,"pm25":214}}}
>
> I'm having trouble parsing the "info.aqi" field using encoding/json. I set
> the "info.aqi" field as a struct tag `json: "info.aqi"`, but the struct is
> just empty after parsing.
>
> It seems more likely I'm holding it wrong, but I'm wondering if perhaps
> this is a bug in Go's JSON parsing?
>
> I thought I'd make a minimal repro test, which fails:
>
> package main
>
> import (
> "encoding/json"
> "strings"
> "testing"
> )
>
> type Foo struct {
> BazBar string `json: "baz.bar"`
> Quxstring `json: "qux"`
> }
>
> func TestDotKeyJsonParsing(t *testing.T) {
> f := {}
> d := json.NewDecoder(strings.NewReader(`{"baz.bar": "hello", "qux":
> "hi"}`))
> err := d.Decode(f)
> if err != nil {
> t.Fatalf("json decoding failed: %v", err)
> }
> if f.Qux != "hi" {
> t.Fatalf("Expected f.Qux to be hi")
> }
>
> if f.BazBar != "hello" {
> t.Errorf("wanted: hello, got: %q", f.BazBar)
> }
> }
>
> And the Qux field passes fine, but the BazBar field is not set, so the
> test fails there:
> --- FAIL: TestDotKeyJsonParsing (0.00s)
> /Users/mark/projects/godot/dot_test.go:26: wanted: hello, got: ""
>
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/539f857c-d96a-45af-9a74-c328753bd12d%40googlegroups.com
> <
> https://groups.google.com/d/msgid/golang-nuts/539f857c-d96a-45af-9a74-c328753bd12d%40googlegroups.com?utm_medium=email_source=footer
> >.
>

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

Re: [go-nuts] Go present questions

[Gonzalo Serrano]

5 years later, I just hacked some ASCII bullets and non-standard spaces 
like this:

* More DDD

*Strategical* *patterns*

- Bounded Context
- Ubiquitous Language

*Tactical* *patterns*

●   Entities: do the stuff, generate events
●   Repositories: abstract the persistence ops
●   Aggregates: transactional clusters of entites
  ●   keep them small
  ●   refer other aggregates by ID
  ●   change 1 aggregate per Tx
  ●   persist entities + events in the same Tx (Transactional Outbox 
pattern)

: aggregate design is sometimes hard
: need to thin about what can be eventual consistent
: need to talk to frontend/PO


Looks good enough to me.

On Monday, June 29, 2015 at 3:46:12 AM UTC+2, kortschak wrote:
>
> On Mon, 2015-06-29 at 11:23 +1000, Andrew Gerrand wrote: 
> > The latter is mostly that it was never implemented, as I've never 
> > needed it. 
>
> > When you find yourself reaching for a sub-section, ask yourself 
> > whether you're putting too much information on a slide. 
>
> This is the right answer, though possibly present should fail more 
> noisily when there are two subsection stanzas on a slide. 
>
>
>

-- 
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/083cf560-1939-4239-9887-bad84d9b4676%40googlegroups.com.

[go-nuts] Re: TCPScan -- Check TCP Connectivity

[Rich]

I didn't leave the URL to github:

https://github.com/rmasci/tcpscan

Sorry about that.



On Tuesday, January 28, 2020 at 10:23:17 AM UTC-5, Rich wrote:
>
> This  originally started as a learning exercise in Go Routines when going 
> through a course on Go Programming. I needed a real world programming 
> example, and every day it seems I have to perform checks for 
> tcpconnectivity -- and worse yet our security guys didn't like putting on 
> netcat or nmap so we had to use telnet.  That's like using a screwdriver as 
> a chisel, it works but not what it was designed for. We literally had 
> people who made scripts using telnet to check the connectivity to 100 hosts 
> to see if they were online on a regular basis, which using Telnet took over 
> a minute for all of them to time out and report if they were open, but 
> didn't tell you if the port was open, closed or filtered by a firewall. 
>
> So I took my little learning excersize and made a program called tcpscan. 
> Honestly I am more of a sysadmin than I am a programmer, and Go is really 
> my first C like compiled language, and I relied more on Bash, PHP, little 
> Perl, TCL (Expect) so I am sure there are a lot of things that could be 
> done better in the program -- but thats what I am hoping for. If this is 
> useful, people like it, make it better right?
>
> Small Example of scanning hosts from a file, Checking TCP, Checking ICMP 
> (Ping) and SSL Cert
>
> ~] $ cat list;tcpscan -f list -i -s
> https://www.youtube.com
> https://www.google.com
> https://www.twitter.com
> https://www.github.com
> https://www.amazon.com
>
> ++-+---+-+-++
> |Address |Port |Status | TCP |ICMP |  
>   SSL |
>
> ++=+===+=+=++
> |www.youtube.com | 443 |  Open | 91.88ms | 92.87ms |  
>TLS v1.2 / OK: 63 days |
> | www.google.com | 443 |  Open | 62.23ms | 63.89ms |  
>TLS v1.2 / OK: 63 days |
> |www.twitter.com | 443 |  Open |101.69ms | 90.86ms |  
>TLS v1.2 / OK: 38 days |
> | www.github.com | 443 |  Open |122.60ms |121.52ms |  
>   TLS v1.2 / OK: 126 days |
> | www.amazon.com | 443 |  Open |128.97ms | 76.66ms |  
>   TLS v1.2 / OK: 337 days |
>
> ++-+---+-+-++
>
> Scanned 5 hosts/ports in 493.79ms
>

-- 
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/9a775f36-8419-4061-a97b-0a659cf7c412%40googlegroups.com.

Re: [go-nuts] TCPScan -- Check TCP Connectivity

[Richard Masci]

I didn't leave the Github url -- sorry

https://github.com/rmasci/tcpscan



On Tue, Jan 28, 2020 at 10:23 AM Rich  wrote:

> This  originally started as a learning exercise in Go Routines when going
> through a course on Go Programming. I needed a real world programming
> example, and every day it seems I have to perform checks for
> tcpconnectivity -- and worse yet our security guys didn't like putting on
> netcat or nmap so we had to use telnet.  That's like using a screwdriver as
> a chisel, it works but not what it was designed for. We literally had
> people who made scripts using telnet to check the connectivity to 100 hosts
> to see if they were online on a regular basis, which using Telnet took over
> a minute for all of them to time out and report if they were open, but
> didn't tell you if the port was open, closed or filtered by a firewall.
>
> So I took my little learning excersize and made a program called tcpscan.
> Honestly I am more of a sysadmin than I am a programmer, and Go is really
> my first C like compiled language, and I relied more on Bash, PHP, little
> Perl, TCL (Expect) so I am sure there are a lot of things that could be
> done better in the program -- but thats what I am hoping for. If this is
> useful, people like it, make it better right?
>
> Small Example of scanning hosts from a file, Checking TCP, Checking ICMP
> (Ping) and SSL Cert
>
> ~] $ cat list;tcpscan -f list -i -s
> https://www.youtube.com
> https://www.google.com
> https://www.twitter.com
> https://www.github.com
> https://www.amazon.com
>
> ++-+---+-+-++
> |Address |Port |Status | TCP |ICMP |
>   SSL |
>
> ++=+===+=+=++
> |www.youtube.com | 443 |  Open | 91.88ms | 92.87ms |
>TLS v1.2 / OK: 63 days |
> | www.google.com | 443 |  Open | 62.23ms | 63.89ms |
>TLS v1.2 / OK: 63 days |
> |www.twitter.com | 443 |  Open |101.69ms | 90.86ms |
>TLS v1.2 / OK: 38 days |
> | www.github.com | 443 |  Open |122.60ms |121.52ms |
>   TLS v1.2 / OK: 126 days |
> | www.amazon.com | 443 |  Open |128.97ms | 76.66ms |
>   TLS v1.2 / OK: 337 days |
>
> ++-+---+-+-++
>
> Scanned 5 hosts/ports in 493.79ms
>
> --
> 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/LuactGKC2kY/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/49924f7f-da71-452f-89af-c8ee3edc42ce%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/CAJ0CmuE_3Jj4mi0BViHLrE7%3DNgTSVFipu_o-d2b-JPUTjr4s7Q%40mail.gmail.com.

[go-nuts] Re: go modules and internal packages

[Manlio Perillo]

On Tuesday, January 28, 2020 at 12:34:04 AM UTC+1, R Srinivasan wrote:
>
> Oops. That was messed up.
>
> I have so far not migrated towards the new go modules. I am beginning the 
> process. Looking for ideas.
>
> I split my applications into independent packages each in its own 
> directory.
>
> the structure might look like:
>
> top/src
>  /pkg1
>  /pkg2
>
> the imports are based on relative paths - eg:
> import (
> "../pkg1"
> )
>

That's really the wrong way to go.

If top is equal to $GOPATH, then there is no need to use relative imports.
If you do `import "pkg1", the import path will be automatically resolved to 
top/src/pkg1.

The difference with the new modules systems is that import paths will no 
longer be resolved to a local filesystem path using $GOPATH.
 

>
> Questions:
> - there is just 1 go.mod at the top level right?
> - go.mod only specifies what the external packages are. 
> eg.google.olang.org/package
>
>
I'm a bit confused to what do you mean as top level.
Assuming pkg1 and pkg2 are different projects, maybe inside a vcs 
repository, then each project will have it's own go.mod file.

If the projects are inside GOPATH (yes, GOPATH is still useful with 
modules), run `go mod init` inside the project root directory, and it will 
automatically create a new go.mod file.

Also, with modules *all* packages not inside a module are external.
This means that the module path should specify a remove resource, like 
"github.com/user/project".
If the module path is like "pkg1", go will report an error since it does 
not know how to get it.

The alternative is to use the replace directive.  You can check the 
official documentation or the wiki.



Manlio Perillo

-- 
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/abee61a0-003c-4183-a413-4f1fb0e02cd3%40googlegroups.com.

[go-nuts] [security] Go 1.13.7 and Go 1.12.16 are released

[Katie Hockman]

Hi gophers,

We have just released Go 1.13.7 and Go 1.12.16 to address recently reported
security issues. We recommend that all users update to one of these
releases (if you’re not sure which, choose Go 1.13.7).

   -

   X.509 certificate validation bypass on Windows 10

   A Windows vulnerability allows attackers to spoof valid certificate
   chains when the system root store is in use. These releases include a
   mitigation for Go applications, but it’s strongly recommended that affected
   users install the Windows security update to protect their system.
   This issue is CVE-2020-0601 and Go issue golang.org/issue/36834.



   -

   Panic in crypto/x509 certificate parsing and
   golang.org/x/crypto/cryptobyte

   On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1
   parsing functions of golang.org/x/crypto/cryptobyte can lead to a panic.
   The malformed certificate can be delivered via a crypto/tls connection
   to a client, or to a server that accepts client certificates. net/http
   clients can be made to crash by an HTTPS server, while net/http servers
   that accept client certificates will recover the panic and are unaffected.
   Thanks to Project Wycheproof  for
   providing the test cases that led to the discovery of this issue.
   The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.
   This is also fixed in version v0.0.0-20200124225646-8b5121be2f68 of
   golang.org/x/crypto/cryptobyte.

The upcoming Go 1.14rc1 release will also include the fixes above.

Downloads are available at https://golang.org/dl for all supported
platforms.

Thank you,

[image: ] Katie and Dmitri on behalf of 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/CALvTBve_%2BBVSs%2B6tK8muVRkON09SCrqQcQDp9xUA-%2B27jGva1g%40mail.gmail.com.

Re: [go-nuts] JSON: Having trouble parsing map keys with dots like {"foo.bar":"baz"}

[Rich]

All of these are good suggestions -- but when working with JSON I find this 
package to be very helpful: 

https://github.com/hjson/hjson-go  

I use json as a config file for my programs and when users fat finger the 
config, forget a comma or put a space in the wrong place -- this for the 
most part fixes those minor blunders.  I've also found that even though 
another system generated the JSON, it might not be fully compliant with 
what I wrote, hjson-go has bailed me out on more than one project. 



On Tuesday, January 28, 2020 at 9:59:51 AM UTC-5, Jake Montgomery wrote:
>
> FYI - "go vet" will catch this. Running "go vet" is always a good idea.
>
> On Tuesday, January 28, 2020 at 9:00:05 AM UTC-5, Lutz Horn wrote:
>>
>> Remove the blank in ``json: "baz.bar"` and make it `json:"baz.bar"`. This 
>> works: https://play.golang.com/p/i9SURYgGO66 
>>
>>  
>> Von: golan...@googlegroups.com  im Auftrag 
>> von ma...@markhansen.co.nz  
>> Gesendet: Dienstag, 28. Januar 2020 12:14 
>> An: golang-nuts 
>> Betreff: [go-nuts] JSON: Having trouble parsing map keys with dots like 
>> {"foo.bar":"baz"} 
>>
>> Hi folks, for background, I'm trying to read the Kaiterra API<
>> https://www.kaiterra.com/dev/#overview> using encoding/json, which has 
>> JSON values like this: 
>>
>> {"id":"-0001-0001--7e57c0de","info.aqi":{"ts":"2018-03-26T08:53:20Z","data":{"pm10":120,"pm25":214}}}
>>  
>>
>>
>> I'm having trouble parsing the "info.aqi" field using encoding/json. I 
>> set the "info.aqi" field as a struct tag `json: "info.aqi"`, but the struct 
>> is just empty after parsing. 
>>
>> It seems more likely I'm holding it wrong, but I'm wondering if perhaps 
>> this is a bug in Go's JSON parsing? 
>>
>> I thought I'd make a minimal repro test, which fails: 
>>
>> package main 
>>
>> import ( 
>> "encoding/json" 
>> "strings" 
>> "testing" 
>> ) 
>>
>> type Foo struct { 
>> BazBar string `json: "baz.bar"` 
>> Quxstring `json: "qux"` 
>> } 
>>
>> func TestDotKeyJsonParsing(t *testing.T) { 
>> f := {} 
>> d := json.NewDecoder(strings.NewReader(`{"baz.bar": "hello", "qux": 
>> "hi"}`)) 
>> err := d.Decode(f) 
>> if err != nil { 
>> t.Fatalf("json decoding failed: %v", err) 
>> } 
>> if f.Qux != "hi" { 
>> t.Fatalf("Expected f.Qux to be hi") 
>> } 
>>
>> if f.BazBar != "hello" { 
>> t.Errorf("wanted: hello, got: %q", f.BazBar) 
>> } 
>> } 
>>
>> And the Qux field passes fine, but the BazBar field is not set, so the 
>> test fails there: 
>> --- FAIL: TestDotKeyJsonParsing (0.00s) 
>> /Users/mark/projects/godot/dot_test.go:26: wanted: hello, got: "" 
>>
>>
>>

-- 
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/36e6c19c-77e2-40cc-91b4-d155085564c1%40googlegroups.com.

Re: [go-nuts] Why is go too slow?

[nilsocket]

Thanks a lot for your answer.

Thank you.

On Tuesday, January 28, 2020 at 9:15:58 PM UTC+5:30, Ian Lance Taylor wrote:
>
> On Tue, Jan 28, 2020 at 7:33 AM nilsocket > 
> wrote:
>
>> Attached two files main.c and main.go,
>> both try to compute fib(40), 20 times on `x` no.of threads/goroutines.
>> fib(40) is recursive.
>>
>> *Prerequisites for C:*
>>
>>1. libuv (https://github.com/libuv/libuv)
>>
>>
>>
>> *Compile*:
>>
>>- *C :*
>>   - *Unoptimized:*
>>
>> * gcc main.c -lpthread -luv *
>>
>>
>>- *Optimized:*
>>   gcc-O3 main.c -lpthread -luv
>>
>>
>>- *Go :*
>>   - go build
>>   
>>   
>> *Run:*
>>
>>- 
>>
>> *C:time UV_THREADPOOL_SIZE=x ./a.out // substitute `x` with physical core 
>>count *
>>- 
>>
>> *GO:./temp x // substitute `x` with physical core count *
>>
>>
>> Results:
>>
>> Thread CountC (Optimized)C (Unoptimized)GO
>> 1 4.38s 11.36s 11.7s
>> 4 1.12s 3.1s 2.9s
>> 8 1.1s 2.9s 2.7s
>>
>>
>> Laptop with 4 physical cores(8 logical cores).
>>
>> Why can't go provide Optimization flag?
>> I understand go developers want compiler to be simple, but the difference 
>> seems too big to leave it out.
>>
>> But isn't there any possibility to abstract the complexity and provide 
>> optimization flag?
>>
>
>
> Go doesn't provide an optimization flag because it always optimizes.
>
> Your program amounts to a microbenchmark of the tail recursion 
> optimization.  The Go compiler doesn't optimize tail recursion, because it 
> confuses stack traces and breaks runtime.Callers.  The C compiler has no 
> such constraints.  You might be interested in 
> https://golang.org/issue/22624.
>
> There will always be microbenchmarks in which C code executes faster than 
> Go code.  Microbenchmarks can be useful if analyzed with care, but the real 
> question for performance is always how a real program behaves.
>
> 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/5d21abd1-1910-4bbb-a24e-6080ceaf0c1c%40googlegroups.com.

Re: [go-nuts] Why is go too slow?

[burak serdar]

On Tue, Jan 28, 2020 at 8:33 AM nilsocket  wrote:

> Attached two files main.c and main.go,
> both try to compute fib(40), 20 times on `x` no.of threads/goroutines.
> fib(40) is recursive.
>

Your benchmark is flawed. Goroutines are not threads. Also, the printing of
the results is included in the times you measure. You're benchmarking i/o
implementations of two libraries

Measure single-threaded implementations without printf's and see what
happens.


>
> *Prerequisites for C:*
>
>1. libuv (https://github.com/libuv/libuv)
>
>
>
> *Compile*:
>
>- *C :*
>   - *Unoptimized:*
>
> * gcc main.c -lpthread -luv *
>
>
>- *Optimized:*
>   gcc-O3 main.c -lpthread -luv
>
>
>- *Go :*
>   - go build
>
>
> *Run:*
>
>-
>
> *C:time UV_THREADPOOL_SIZE=x ./a.out // substitute `x` with physical core
>count *
>-
>
> *GO:./temp x // substitute `x` with physical core count *
>
>
> Results:
>
> Thread CountC (Optimized)C (Unoptimized)GO
> 1 4.38s 11.36s 11.7s
> 4 1.12s 3.1s 2.9s
> 8 1.1s 2.9s 2.7s
>
>
> Laptop with 4 physical cores(8 logical cores).
>
> Why can't go provide Optimization flag?
> I understand go developers want compiler to be simple, but the difference
> seems too big to leave it out.
>
> But isn't there any possibility to abstract the complexity and provide
> optimization flag?
>
> --
> 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/cec68183-27d1-47cc-b106-48766a2242e6%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/CAMV2RqothU1hn81sFf9eJdOQonLR2kZ_E7LwjC9KsJDYw4Hddg%40mail.gmail.com.

Re: [go-nuts] Why is go too slow?

[Ian Lance Taylor]

On Tue, Jan 28, 2020 at 7:33 AM nilsocket  wrote:

> Attached two files main.c and main.go,
> both try to compute fib(40), 20 times on `x` no.of threads/goroutines.
> fib(40) is recursive.
>
> *Prerequisites for C:*
>
>1. libuv (https://github.com/libuv/libuv)
>
>
>
> *Compile*:
>
>- *C :*
>   - *Unoptimized:*
>
> * gcc main.c -lpthread -luv *
>
>
>- *Optimized:*
>   gcc-O3 main.c -lpthread -luv
>
>
>- *Go :*
>   - go build
>
>
> *Run:*
>
>-
>
> *C:time UV_THREADPOOL_SIZE=x ./a.out // substitute `x` with physical core
>count *
>-
>
> *GO:./temp x // substitute `x` with physical core count *
>
>
> Results:
>
> Thread CountC (Optimized)C (Unoptimized)GO
> 1 4.38s 11.36s 11.7s
> 4 1.12s 3.1s 2.9s
> 8 1.1s 2.9s 2.7s
>
>
> Laptop with 4 physical cores(8 logical cores).
>
> Why can't go provide Optimization flag?
> I understand go developers want compiler to be simple, but the difference
> seems too big to leave it out.
>
> But isn't there any possibility to abstract the complexity and provide
> optimization flag?
>


Go doesn't provide an optimization flag because it always optimizes.

Your program amounts to a microbenchmark of the tail recursion
optimization.  The Go compiler doesn't optimize tail recursion, because it
confuses stack traces and breaks runtime.Callers.  The C compiler has no
such constraints.  You might be interested in https://golang.org/issue/22624
.

There will always be microbenchmarks in which C code executes faster than
Go code.  Microbenchmarks can be useful if analyzed with care, but the real
question for performance is always how a real program behaves.

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/CAOyqgcVVGXCQssZ%3Dowgfuv_z1OBMv_8sdG36PER7BcLFsrAtxw%40mail.gmail.com.

Re: [go-nuts] Re: Is it considered to separate runtime and cmd/compile irrelevant standard libraries out from the core language repo and hosted in a different module, eg. std?

[Ian Lance Taylor]

On Tue, Jan 28, 2020 at 12:27 AM changkun  wrote:
>
> - the main repo team focuses on the core language distribution (meaning a 
> compiler that implements language spec, a runtime package that supports all 
> kinds of runtime mechanism support), provides the minimum "std-only" APIs to 
> support all standard library use cases. Also, a dedicated issue tracker, 
> remove all kinds of sub repo, std issues, better managing language evolution 
> history.
> - the std repo team (or "hand over to Go community" but may never be 
> possible), as one of the Go user groups, provides use case and experiences 
> reports to the main repo, similar to the regular regression reports from 
> kubernetes project, versioned std evolves without bothering the main repo 
> team. Go users can tracking std issues without bothered by whatever cmd/* has 
> proposed to change.

You just took one team and turned it into two teams.  Where are those
extra people going to come from?

Again, the single team can barely manage to do a Go release today.
We're late every time, and we find it just as frustrating as everyone
else.  Increasing the amount of work may be more scalable, but making
something more scalable only helps if you have idle people who want to
help but have nothing to do.

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/CAOyqgcU917-yPPUZVyrywTttG1vC%2Bz7qSMwLmFq-mq_-nwwXPg%40mail.gmail.com.

[go-nuts] Why is go too slow?

[nilsocket]

Attached two files main.c and main.go,
both try to compute fib(40), 20 times on `x` no.of threads/goroutines.
fib(40) is recursive.

*Prerequisites for C:*

   1. libuv (https://github.com/libuv/libuv)
   


*Compile*:

   - *C :*
  - *Unoptimized:*

* gcc main.c -lpthread -luv *
   

   - *Optimized:*
  gcc-O3 main.c -lpthread -luv


   - *Go :*
  - go build
  
  
*Run:*

   - 

*C:time UV_THREADPOOL_SIZE=x ./a.out // substitute `x` with physical core 
   count *
   - 

*GO:./temp x // substitute `x` with physical core count *


Results:

Thread CountC (Optimized)C (Unoptimized)GO
1 4.38s 11.36s 11.7s
4 1.12s 3.1s 2.9s
8 1.1s 2.9s 2.7s


Laptop with 4 physical cores(8 logical cores).

Why can't go provide Optimization flag?
I understand go developers want compiler to be simple, but the difference 
seems too big to leave it out.

But isn't there any possibility to abstract the complexity and provide 
optimization flag?

-- 
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/cec68183-27d1-47cc-b106-48766a2242e6%40googlegroups.com.
#include 
#include 

uv_loop_t* loop;

int _fib(int n) {
  if (n < 2) {
return 1;
  }
  return _fib(n - 2) + _fib(n - 1);
}

void fib(uv_work_t* req) {
  int n = *(int*)req->data;  // get n ==> 40
  fprintf(stdout, "fib(%d)=%d\n", n, _fib(n));
}

// compute fib(40), 20 times
int main() {
  loop = uv_default_loop();

  int data[20];
  uv_work_t req[20];

  for (int i = 0; i < 20; i++) {
data[i] = 40;
// set fib num to compute, (40)
req[i].data = (void*)[i];
// queue work, to run in multiple threads
uv_queue_work(loop, [i], fib, NULL);
  }

  // execute
  return uv_run(loop, UV_RUN_DEFAULT);
}

main.go
Description: Binary data

[go-nuts] TCPScan -- Check TCP Connectivity

[Rich]

This  originally started as a learning exercise in Go Routines when going 
through a course on Go Programming. I needed a real world programming 
example, and every day it seems I have to perform checks for 
tcpconnectivity -- and worse yet our security guys didn't like putting on 
netcat or nmap so we had to use telnet.  That's like using a screwdriver as 
a chisel, it works but not what it was designed for. We literally had 
people who made scripts using telnet to check the connectivity to 100 hosts 
to see if they were online on a regular basis, which using Telnet took over 
a minute for all of them to time out and report if they were open, but 
didn't tell you if the port was open, closed or filtered by a firewall. 

So I took my little learning excersize and made a program called tcpscan. 
Honestly I am more of a sysadmin than I am a programmer, and Go is really 
my first C like compiled language, and I relied more on Bash, PHP, little 
Perl, TCL (Expect) so I am sure there are a lot of things that could be 
done better in the program -- but thats what I am hoping for. If this is 
useful, people like it, make it better right?

Small Example of scanning hosts from a file, Checking TCP, Checking ICMP 
(Ping) and SSL Cert

~] $ cat list;tcpscan -f list -i -s
https://www.youtube.com
https://www.google.com
https://www.twitter.com
https://www.github.com
https://www.amazon.com
++-+---+-+-++
|Address |Port |Status | TCP |ICMP |
SSL |
++=+===+=+=++
|www.youtube.com | 443 |  Open | 91.88ms | 92.87ms |
 TLS v1.2 / OK: 63 days |
| www.google.com | 443 |  Open | 62.23ms | 63.89ms |
 TLS v1.2 / OK: 63 days |
|www.twitter.com | 443 |  Open |101.69ms | 90.86ms |
 TLS v1.2 / OK: 38 days |
| www.github.com | 443 |  Open |122.60ms |121.52ms |
TLS v1.2 / OK: 126 days |
| www.amazon.com | 443 |  Open |128.97ms | 76.66ms |
TLS v1.2 / OK: 337 days |
++-+---+-+-++

Scanned 5 hosts/ports in 493.79ms

-- 
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/49924f7f-da71-452f-89af-c8ee3edc42ce%40googlegroups.com.

Re: [go-nuts] Cgo fixed length array woes

[Ian Lance Taylor]

On Tue, Jan 28, 2020 at 4:44 AM mark mellar  wrote:
>
> Hi Folks, I'm having some trouble instantiating a C struct from a 3rd party 
> API.
>
> I'm not sure if this is more a C question or a Go question, details in the 
> code below, any help would be much appreciated!
>
> M
>
> // This non-compiling example demonstrates an issue I'm having integrating a 
> 3rd party C api with my Go code
> // The comment preceding 'import "C"' constitutes C code which is interpreted 
> as a header when compiling.
> // 'api_struct' represents the 3rd party struct I'm attempting to instantiate 
> and populate in my Go Code
> //we cannot make changes to this struct
> // other c functions in the comment are helper functions I've written to 
> instantiate certain C types
>
> // The go code defines an array of strings and an array of ints. For each of 
> these arrays a helper
> // function is called to create a C array of the C equivalent type before 
> populating that array.
> // Once C arrays have been populated they are assigned to fields in the a new 
> api_struct.
>
> // This method works fine for the string array, but compile fails when we get 
> to the int array
> // This is because makeIntArray returns *_Ctype_int but api_struct.rLimits 
> expects [12]_Ctype_int. Here's the error...
> // cannot use cInts (type *_Ctype_int) as type [12]_Ctype_int in field value
>
> // I'd like to modify makeIntArray to return a [12]_Ctype_int but I can't 
> seem to find the right syntax to achieve this
> package main
>
> /*
> #define  ARRLEN 12
> #include 
>
> struct api_struct {
> char**askedHosts;
> int rLimits[ARRLEN];
> };
>
> static char**makeCharArray(int size) {
> return calloc(sizeof(char*), size);
> }
>
> static void setArrayString(char **a, char *s, int n) {
> a[n] = s;
> }
>
> static void freeCharArray(char **a, int size) {
> int i;
> for (i = 0; i < size; i++)
> free(a[i]);
> free(a);
> }
>
> static int*makeIntArray() {
> int* p = malloc(sizeof(p) * ARRLEN);
> return p;
> }
>
> static void setArrayInt(int *a, int s, int n) {
> a[n] = s;
> }
>
> static void freeIntArray(int *a, int size) {
> free(a);
> }
>
>
> */
> import "C"
> import "fmt"
>
> func main() {
> goHosts := []string{"host1", "host2", "host3"}
> cHosts := C.makeCharArray(C.int(len(goHosts)))
> for i, s := range goHosts {
> C.setArrayString(cHosts, C.CString(s), C.int(i))
> }
>
> goLimits := []int{1,2,3,4,5,6,7,8,9,10,11,12}
> cInts := C.makeIntArray()
> for i, s := range goLimits {
> C.setArrayInt(cInts, C.int(s), C.int(i))
> }
>
> s := C.struct_api_struct{
> askedHosts: cHosts,
> rLimits: cInts,
> }
> fmt.Printf("%+v\n", s)
> }


The easy, and likely more efficient, way is to just set the rLimits
field element by element.

There is no safe way to convert from a *C.int to a [12]C.int in Go.
You can do it easily enough using unsafe.

a := *(*[12]C.int)(unsafe.Pointer(p))

This is of course only safe if p does in fact point to 12 C.int values.

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/CAOyqgcXsdWfWP%3D_sdWkZs%2BWrcx4wCXN7qHMugTBhoE5%3DjKW_Lw%40mail.gmail.com.

[go-nuts] Scanning TCP Hosts using TCPSCAN

[Rich]

This  originally started as a learning exercise in Go Routines when going 
through a course on Go Programming. I needed a real world programming 
example, and every day it seems I have to perform checks for 
tcpconnectivity -- and worse yet our security guys didn't like putting on 
netcat or nmap so we had to use telnet.  That's like using a screwdriver as 
a chisel, it works but not what it was designed for. We literally had 
people who made scripts using telnet to check the connectivity to 100 hosts 
to see if they were online on a regular basis, which using Telnet took over 
a minute for all of them to time out and report if they were open, but 
didn't tell you if the port was open, closed or filtered by a firewall. 

So I took my little learning excersize and made a program called tcpscan. 
Honestly I am more of a sysadmin than I am a programmer, and Go is really 
my first C like compiled language, and I relied more on Bash, PHP, little 
Perl, TCL (Expect) so I am sure there are a lot of things that could be 
done better in the program -- but thats what I am hoping for. If this is 
useful, people like it, make it better right?

http://github.com/rmasci/tcpscan

 ~] $ cat list;tcpscan -f list
https://www.youtube.com
https://www.google.com
https://www.twitter.com
https://www.github.com
https://www.amazon.com
++-+---+-+
|Address |Port |Status | TCP |
++=+===+=+
|www.youtube.com | 443 |  Open | 45.51ms |
| www.google.com | 443 |  Open | 44.95ms |
|www.twitter.com | 443 |  Open | 61.89ms |
| www.github.com | 443 |  Open | 77.86ms |
| www.amazon.com | 443 |  Open |153.61ms |
++-+---+-+

Scanned 5 hosts/ports in 170.48ms

-- 
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/fc2d591f-a7cf-4f65-aade-224bb02fb128%40googlegroups.com.

[go-nuts] Asynq - A simple asynchronous task queue library for Go ~ Contributors welcome!

[Ken Hibino]

Asynq is a simple Go library for queueing tasks and processing them in the 
background with workers.
It is backed by Redis and it is designed to have a low barrier to entry. It 
should be integrated in your web stack easily.

Please check it out at github.com/hibiken/asynq

It's an early-stage project, but contributors are welcome!

-- 
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/6991d009-da02-4053-a5e5-52acf59438ac%40googlegroups.com.

Re: [go-nuts] JSON: Having trouble parsing map keys with dots like {"foo.bar":"baz"}

[Jake Montgomery]

FYI - "go vet" will catch this. Running "go vet" is always a good idea.

On Tuesday, January 28, 2020 at 9:00:05 AM UTC-5, Lutz Horn wrote:
>
> Remove the blank in ``json: "baz.bar"` and make it `json:"baz.bar"`. This 
> works: https://play.golang.com/p/i9SURYgGO66 
>
>  
> Von: golan...@googlegroups.com   > im Auftrag von ma...@markhansen.co.nz  <
> ma...@markhansen.co.nz > 
> Gesendet: Dienstag, 28. Januar 2020 12:14 
> An: golang-nuts 
> Betreff: [go-nuts] JSON: Having trouble parsing map keys with dots like 
> {"foo.bar":"baz"} 
>
> Hi folks, for background, I'm trying to read the Kaiterra API<
> https://www.kaiterra.com/dev/#overview> using encoding/json, which has 
> JSON values like this: 
>
> {"id":"-0001-0001--7e57c0de","info.aqi":{"ts":"2018-03-26T08:53:20Z","data":{"pm10":120,"pm25":214}}}
>  
>
>
> I'm having trouble parsing the "info.aqi" field using encoding/json. I set 
> the "info.aqi" field as a struct tag `json: "info.aqi"`, but the struct is 
> just empty after parsing. 
>
> It seems more likely I'm holding it wrong, but I'm wondering if perhaps 
> this is a bug in Go's JSON parsing? 
>
> I thought I'd make a minimal repro test, which fails: 
>
> package main 
>
> import ( 
> "encoding/json" 
> "strings" 
> "testing" 
> ) 
>
> type Foo struct { 
> BazBar string `json: "baz.bar"` 
> Quxstring `json: "qux"` 
> } 
>
> func TestDotKeyJsonParsing(t *testing.T) { 
> f := {} 
> d := json.NewDecoder(strings.NewReader(`{"baz.bar": "hello", "qux": 
> "hi"}`)) 
> err := d.Decode(f) 
> if err != nil { 
> t.Fatalf("json decoding failed: %v", err) 
> } 
> if f.Qux != "hi" { 
> t.Fatalf("Expected f.Qux to be hi") 
> } 
>
> if f.BazBar != "hello" { 
> t.Errorf("wanted: hello, got: %q", f.BazBar) 
> } 
> } 
>
> And the Qux field passes fine, but the BazBar field is not set, so the 
> test fails there: 
> --- FAIL: TestDotKeyJsonParsing (0.00s) 
> /Users/mark/projects/godot/dot_test.go:26: wanted: hello, got: "" 
>
>
> -- 
> 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 golan...@googlegroups.com  golang-nuts+unsubscr...@googlegroups.com >. 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/539f857c-d96a-45af-9a74-c328753bd12d%40googlegroups.com
> <
> https://groups.google.com/d/msgid/golang-nuts/539f857c-d96a-45af-9a74-c328753bd12d%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
>

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

Re: [go-nuts] Use CONNECT method to proxies for HTTP requests

[Edouard Buschini]

I solved my problem. The offending line what in the request.go file for the
net/http package:

 558   host := cleanHost(r.Host)
 559   if host == "" {
 560 if r.URL == nil {
 561   return errMissingHost
 562 }
 563 host = cleanHost(r.URL.Host)
 564   }
...
 571   ruri := r.URL.RequestURI()
 572   if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
 573 ruri = r.URL.Scheme + "://" + host + ruri

The host used is the one from the header if it is found.
I bypass it setting the r.URL.Opaque:
103   if p, err := proxy(req); p != nil && err == nil && req.URL.Scheme ==
"http" {
104 req.URL.Opaque = fmt.Sprintf("%s://%s", req.URL.Scheme,
path.Join(req.URL.Host, req.URL.Path))
105   }

I'm pretty sure I'm not catching a ton of corner cases but IMHO I think it
should use r.URL.Host first like the doc says for the basic request.

On Mon, Jan 27, 2020 at 11:22 AM Edouard Buschini <
edouard.busch...@gmail.com> wrote:

> Hi all!
>
> Asking for the help of the community because I haven't been able to find
> the answer on my own.
>
> I'm writing an http fuzzer in go and was implementing a proxy options from
> the cli.
> My use case is that I want all the requests to be sent to the proxy when
> the flag is set. No matter if it's tls or just pure http.
>
> For this, I just the `Proxy` field in the `http.Transport` type. It works
> well for TLS because it first sends the CONNECT method and then request is
> just written to the socket when the TLS handshake has been established.
> But for not TLS, it actually does not use CONNECT, instead, it changes the
> `URL` field of the `http.Request` object to the `Host` field. So when the
> request arrives to the proxy, the request is all messed up if the initial
> `Host` field did not actually contain a reachable host.
>
> I've tried sending the full proxied request using `CONNECT
> :80\r\n\r\n` with netcat and it worked:
>
> ```
>
> CONNECT www.google.com:80 HTTP/1.1
>
>
> HTTP/1.0 200 Connection established
>
>
> POST / HTTP/1.1
>
> Host: 2
>
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
> Firefox/68.0
>
>
>
> HTTP/1.1 204 No Content
>
> ...
>
> ```
>
>
> What I'm doing right now is:
>
> ```
>
> var proxy func(*http.Request) (*url.URL, error)
>
> proxy = http.ProxyFromEnvironment
>
>
> if flags.Proxy != nil {
>
> proxy = http.ProxyURL(flags.Proxy)
>
> }
>
>
> numRedirects := 0
>
> client := http.Client{
>
> Transport: {
>
> Proxy: proxy,
>
> TLSClientConfig: {
>
> InsecureSkipVerify: flags.Insecure,
>
> },
>
> },
>
> }
> ```
>
> I've looked at the code a little bit and found that:
> https://golang.org/src/net/http/transport.go#L1516 is where it happens.
> And I can clearly see that `CONNECT` is used when it needs to setup a TLS
> tunnel.
>
> If you guys have any idea how to achieve this, that would be awesome!
> Right now, I'm thinking just using `req.Write` after creating the
> connection myself, but I kind of don't really want to re-invent the wheel
> knowing that `http.Client` is great.
>
> 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/2c2ae451-87d4-4d96-a68f-572b152cb9af%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/CADTiKyyHG%3D9Txagv6Kjj-f19j49Z8ckDsz9Z%2B_6HkJN3FtdJxw%40mail.gmail.com.

AW: [go-nuts] JSON: Having trouble parsing map keys with dots like {"foo.bar":"baz"}

[Lutz Horn]

Remove the blank in ``json: "baz.bar"` and make it `json:"baz.bar"`. This 
works: https://play.golang.com/p/i9SURYgGO66


Von: golang-nuts@googlegroups.com  im Auftrag von 
m...@markhansen.co.nz 
Gesendet: Dienstag, 28. Januar 2020 12:14
An: golang-nuts
Betreff: [go-nuts] JSON: Having trouble parsing map keys with dots like 
{"foo.bar":"baz"}

Hi folks, for background, I'm trying to read the Kaiterra 
API using encoding/json, which has JSON 
values like this:

{"id":"-0001-0001--7e57c0de","info.aqi":{"ts":"2018-03-26T08:53:20Z","data":{"pm10":120,"pm25":214}}}

I'm having trouble parsing the "info.aqi" field using encoding/json. I set the 
"info.aqi" field as a struct tag `json: "info.aqi"`, but the struct is just 
empty after parsing.

It seems more likely I'm holding it wrong, but I'm wondering if perhaps this is 
a bug in Go's JSON parsing?

I thought I'd make a minimal repro test, which fails:

package main

import (
"encoding/json"
"strings"
"testing"
)

type Foo struct {
BazBar string `json: "baz.bar"`
Quxstring `json: "qux"`
}

func TestDotKeyJsonParsing(t *testing.T) {
f := {}
d := json.NewDecoder(strings.NewReader(`{"baz.bar": "hello", "qux": "hi"}`))
err := d.Decode(f)
if err != nil {
t.Fatalf("json decoding failed: %v", err)
}
if f.Qux != "hi" {
t.Fatalf("Expected f.Qux to be hi")
}

if f.BazBar != "hello" {
t.Errorf("wanted: hello, got: %q", f.BazBar)
}
}

And the Qux field passes fine, but the BazBar field is not set, so the test 
fails there:
--- FAIL: TestDotKeyJsonParsing (0.00s)
/Users/mark/projects/godot/dot_test.go:26: wanted: hello, got: ""


--
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/539f857c-d96a-45af-9a74-c328753bd12d%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/AM7P191MB1060C7A5A59B82BF870605209E0A0%40AM7P191MB1060.EURP191.PROD.OUTLOOK.COM.

[go-nuts] JSON: Having trouble parsing map keys with dots like {"foo.bar":"baz"}

[mark]

Hi folks, for background, I'm trying to read the Kaiterra API 
 using encoding/json, which has 
JSON values like this:

{"id":"-0001-0001--7e57c0de","*info.aqi*
":{"ts":"2018-03-26T08:53:20Z","data":{"pm10":120,"pm25":214}}}

I'm having trouble parsing the "info.aqi" field using encoding/json. I set 
the "info.aqi" field as a struct tag `json: "info.aqi"`, but the struct is 
just empty after parsing.

It seems more likely I'm holding it wrong, but I'm wondering if perhaps 
this is a bug in Go's JSON parsing?

I thought I'd make a minimal repro test, which fails:

package main

import (
"encoding/json"
"strings"
"testing"
)

type Foo struct {
BazBar string `json: "baz.bar"`
Quxstring `json: "qux"`
}

func TestDotKeyJsonParsing(t *testing.T) {
f := {}
d := json.NewDecoder(strings.NewReader(`{"baz.bar": "hello", "qux": "hi"}`))
err := d.Decode(f)
if err != nil {
t.Fatalf("json decoding failed: %v", err)
}
if f.Qux != "hi" {
t.Fatalf("Expected f.Qux to be hi")
}

if f.BazBar != "hello" {
t.Errorf("wanted: hello, got: %q", f.BazBar)
}
}

And the Qux field passes fine, but the BazBar field is not set, so the test 
fails there:
--- FAIL: TestDotKeyJsonParsing (0.00s)
/Users/mark/projects/godot/dot_test.go:26: wanted: hello, got: ""

-- 
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/539f857c-d96a-45af-9a74-c328753bd12d%40googlegroups.com.

[go-nuts] Cgo fixed length array woes

[mark mellar]

Hi Folks, I'm having some trouble instantiating a C struct from a 3rd party 
API.

I'm not sure if this is more a C question or a Go question, details in the 
code below, any help would be much appreciated!

M

// This non-compiling example demonstrates an issue I'm having integrating 
a 3rd party C api with my Go code
// The comment preceding 'import "C"' constitutes C code which is 
interpreted as a header when compiling.  
// 'api_struct' represents the 3rd party struct I'm attempting to 
instantiate and populate in my Go Code
//we cannot make changes to this struct 
// other c functions in the comment are helper functions I've written to 
instantiate certain C types

// The go code defines an array of strings and an array of ints. For each 
of these arrays a helper
// function is called to create a C array of the C equivalent type before 
populating that array.
// Once C arrays have been populated they are assigned to fields in the a 
new api_struct.

// This method works fine for the string array, but compile fails when we 
get to the int array
// This is because makeIntArray returns *_Ctype_int but api_struct.rLimits 
expects [12]_Ctype_int. Here's the error...
// cannot use cInts (type *_Ctype_int) as type [12]_Ctype_int in field value

// I'd like to modify makeIntArray to return a [12]_Ctype_int but I can't 
seem to find the right syntax to achieve this
package main

/*
#define  ARRLEN 12
#include 

struct api_struct {
char**askedHosts;
int rLimits[ARRLEN];
};

static char**makeCharArray(int size) {
return calloc(sizeof(char*), size);
}

static void setArrayString(char **a, char *s, int n) {
a[n] = s;
}

static void freeCharArray(char **a, int size) {
int i;
for (i = 0; i < size; i++)
free(a[i]);
free(a);
}

static int*makeIntArray() {
int* p = malloc(sizeof(p) * ARRLEN);
return p;
}

static void setArrayInt(int *a, int s, int n) {
a[n] = s;
}

static void freeIntArray(int *a, int size) {
free(a);
}


*/
import "C"
import "fmt"

func main() {
goHosts := []string{"host1", "host2", "host3"}
cHosts := C.makeCharArray(C.int(len(goHosts)))
for i, s := range goHosts {
C.setArrayString(cHosts, C.CString(s), C.int(i))
}

goLimits := []int{1,2,3,4,5,6,7,8,9,10,11,12}
cInts := C.makeIntArray()
for i, s := range goLimits {
C.setArrayInt(cInts, C.int(s), C.int(i))
}

s := C.struct_api_struct{
askedHosts: cHosts,
rLimits: cInts,
}
fmt.Printf("%+v\n", s)
}



-- 
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/7aeed9ae-2670-429d-a273-76adea4ef905%40googlegroups.com.

Re: [go-nuts] go modules and internal packages

[R Srinivasan]

Thanks a bunch.

Based on these, I should be including the repo name in my imports - even 
for private packages. If the repo changes, then the code has to be edited. 
For example I use an in-house instance of say bitbucket and then publish to 
the world on GitHub ,the sources will have to change to point to the new 
repo (for the internal packages)

Am I reading these wrong?

srini


On Tuesday, January 28, 2020 at 2:36:14 AM UTC-5, Lutz Horn wrote:
>
> Take a look at these blog articles: 
>
> https://blog.golang.org/using-go-modules 
> https://blog.golang.org/migrating-to-go-modules 
>
> Lutz 
>
>  
> Von: golan...@googlegroups.com   > im Auftrag von R Srinivasan > 
> Gesendet: Dienstag, 28. Januar 2020 00:29 
> An: golang-nuts 
> Betreff: [go-nuts] go modules and internal packages 
>
> I have so far not migrated towards the new go modules. I am beginning the 
> process. Looking for ideas. 
>
> I split my applications into indepe 
>
> -- 
> 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 golan...@googlegroups.com  golang-nuts+unsubscr...@googlegroups.com >. 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/fea9c93a-bb07-4f90-adcf-ebc5f6c71ae5%40googlegroups.com
> <
> https://groups.google.com/d/msgid/golang-nuts/fea9c93a-bb07-4f90-adcf-ebc5f6c71ae5%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
>

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

Re: [go-nuts] Re: Is it considered to separate runtime and cmd/compile irrelevant standard libraries out from the core language repo and hosted in a different module, eg. std?

[changkun]

I think splitting std libraries and language core distribution may speed up 
and making Go development process more scalable.
Literatures indicates this pattern is the critical aspect to development 
scalability (M.Beck, One the Hourglass model, ACM communications, 
https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/fulltext
)

In this case, 

- the main repo team focuses on the core language distribution (meaning a 
compiler that implements language spec, a runtime package that supports all 
kinds of runtime mechanism support), provides the minimum "std-only" APIs 
to support all standard library use cases. Also, a dedicated issue tracker, 
remove all kinds of sub repo, std issues, better managing language 
evolution history.
- the std repo team (or "hand over to Go community" but may never be 
possible), as one of the Go user groups, provides use case and experiences 
reports to the main repo, similar to the regular regression reports from 
kubernetes project, versioned std evolves without bothering the main repo 
team. Go users can tracking std issues without bothered by whatever cmd/* 
has proposed to change.

As Axel pointed out, this kind of splitting shapes what future Go is, I 
partly agree with the argument of "all of this is still in far future". 
However, I see this can be quickly done either within one future early 
cycle or incrementally kick out these packages from the main repo. There 
are some observed messes and hacks in a unified release:
- The main repo's crypto package requires x/crypto, x/sys, etc.
- A shared internal package, which not even satisfy the Go language spec
- go:linkname to avoid cycle import
- ...
Rethinking the minimum runtime API spec that supports std libraries may 
help shape what future Go could be.

A consideration might be the breaking of Go 1 promise. A quick idea to 
resolve this is to use the Go module as I briefly mentioned before.
Say std libraries are distributed in "golang.org/std/pkgname", importing 
"pkgname" or "golang.org/std/pkgname" both points to the same standard 
library. 
Nothing breaks here. "golang.org/x/pkgname2" is a practice already exist.

This kind of decentralization indeed requires a lot of work to the Go team 
(unclear yet) but seems more decent for the long good, experiences and 
lessons are learned from many other languages and open source projects, 
e.g. C++ committee, kubernetes SIGs.
 



On Tuesday, January 28, 2020 at 4:24:38 AM UTC+8, Ian Lance Taylor wrote:
>
> On Mon, Jan 27, 2020 at 7:02 AM 'Axel Wagner' via golang-nuts 
> > wrote: 
> > 
> > The original message mentions size. The given list is 25MB/337MB 
> uncompressed or 7MB/115MB compressed. So in terms of saved space, we are 
> talking ~6%. It's not nothing, but it's also not a lot. Especially as 
> you'll most likely need to download them right after anyway. 
> > 
> > You also mentions splitting up the issue tracker. But note, that even 
> though the various x-repos are already separate repositories, they still 
> use the same issue-tracker. Clearly, having a unified issue tracker is 
> perceived as a *benefit* to the Go team, not a detriment. 
> > 
> > It might indeed be worth versioning the stdlib as modules at some point. 
> I know that was discussed as part of the question of what "Go 2" means. 
> Having the ability to bump major versions of the stdlib would enable to 
> overhaul APIs at some point in the future. But note that the Go 1 stability 
> promise stays in place, so again, neither in terms of size, nor in terms of 
> splitting management, this would provide any benefits. Programs using Go v1 
> stdlib packages will likely continue to exist into the far future, so even 
> *if* there's at some point a v2 of the stdlib, v1 will still need to be 
> shipped and supported (though likely the v1 API would wrap v2 packages, so 
> the actual size increase would be moderate). But all of this is still far 
> in the future, AFAICT. 
>
>
> I see two different things to consider.  One is the possibility of 
> splitting the release into separate downloadable files.  That by 
> itself seems simple enough, and we could do it if it seems useful. 
> But as Axel says it doesn't seem all that useful.  It seems like it 
> would make downloading a release more complex for 99% of people for 
> the benefit of 1% of people.  That's not an impossible tradeoff but it 
> needs to really be a big help for the 1%.  I don't see the benefit 
> myself (but admittedly I have a fast Internet connection anyhow). 
>
> The more interesting thing to consider is that if we split the release 
> like that, people will naturally start mixing and matching different 
> versions, either on purpose or by accident.  That could be useful in 
> some ways, but it is also much harder to support.  Considering how 
> much trouble we have making a single unified release, it's not obvious 
> to me that the Go team has the bandwidth to handle separate release 
> cycles that need to work together. 
>