Re: [go-nuts] Order of evaluation need more definition in spec

Great idea! On Fri, Mar 15, 2019 at 11:25 AM zshi via golang-nuts < golang-nuts@googlegroups.com> wrote: > Thanks for response, I'm new here still need do more research on existing > topics. > > I understand compiler can do more optimization with less order > restriction, and I agree it's best

Re: [go-nuts] Order of evaluation need more definition in spec

Thanks for response, I'm new here still need do more research on existing topics. I understand compiler can do more optimization with less order restriction, and I agree it's best to not coding in that way. The problem is how to prevent people doing that since it's very similar to the usual

Re: [go-nuts] Println output missing in Windows, but not Linux

Thanks, it did seem to be something like that. In the cmd window I couldn't see it, but when I wrote to a file I could see garbage bytes at the end of my line On Tue, Mar 12, 2019 at 10:34 PM Kurtis Rader wrote: > I'm a new Go programmer but a grey beard (I started programming in the > 1970's).

[go-nuts] syscall.SendMsg/RecvMsg

Hello, I am trying to pass a descriptor using syscall.SendMsg/RecvMsg and I noticed that inod for the second process is not the same as original, but according to Unix Networking API, inod should stay the same and only number of reference to inod should be incremented. Anybody successfully

[go-nuts] gomobile genjava duplicate constructor definition

I am attempting to update a service package which was written to be used on mobile devices by using the gomobile bind package. It appears there was a change made in this commit

[go-nuts] Re: gdb go optimized out

First off, we are always happy to have new users in the group. But one more bit of etiquette - Please don't post screenshots of text. Instead copy paste the text into the message. I like to use fixed width font, or put it in a code block. See the recent discussion at

Re: [go-nuts] net: should default DNS resolver try every server?

Makes sense. Thank you, Ian. Also for anyone who will stumble upon this thread in the future, this issue shows what impact on performance consulting every server would have. пятница, 15 марта 2019 г., 18:42:47 UTC+3 пользователь Ian Lance Taylor

Re: [go-nuts] net: should default DNS resolver try every server?

On Fri, Mar 15, 2019 at 8:31 AM Timofei Bredov wrote: > > Context: I use go version go1.12 linux/amd64. I have a VPN set up which has > private DNS server. This server can resolve URLs that have top level domain > name ".custom-tld". > > File /etc/resolvconf has the following content: > >

[go-nuts] Re: How to lowercase all field names for MarshalJSON and UnmarshalJSON?

Me too I have to add struct tags to over 300 objects, repeating the same text in a different style, totally unproductive and annoying work which the computer should do for me. In the end I've used a tool that parses the .go files and adds the tags automatically, although that resulted in

[go-nuts] net: should default DNS resolver try every server?

Context: I use go version go1.12 linux/amd64. I have a VPN set up which has private DNS server. This server can resolve URLs that have top level domain name ".custom-tld". File /etc/resolvconf has the following content: nameserver 8.8.8.8 nameserver 1.1.1.1 nameserver 192.10.10.18 When I try

[go-nuts] liteide x36 released

Hi, all. LiteIDE x36 released, add new editor path navigation toolbar, optimization quick open plugin. * LiteIDE Home        http://liteide.org * LiteIDE Source code         https://github.com/visualfc/liteide * Release downloads         https://github.com/visualfc/liteide/releases/latest      

Re: [go-nuts] How to limit client IPs in tls listener?

So looks like nftables is my only choice then? On Friday, March 15, 2019 at 10:30:28 PM UTC+8, Andrei Tudor Călin wrote: > > That sounds like something a firewall would do, not your Go program. > > On 3/15/19 3:14 PM, Glen Huang wrote: > > Thanks, but if I'm not wrong, that means the three-way

Re: [go-nuts] How to limit client IPs in tls listener?

That sounds like something a firewall would do, not your Go program. On 3/15/19 3:14 PM, Glen Huang wrote: > Thanks, but if I'm not wrong, that means the three-way handshake has to > complete before I can reject a client? Anyway I can reject them at SYN? > > On Friday, March 15, 2019 at

Re: [go-nuts] How to limit client IPs in tls listener?

Thanks, but if I'm not wrong, that means the three-way handshake has to complete before I can reject a client? Anyway I can reject them at SYN? On Friday, March 15, 2019 at 10:07:57 PM UTC+8, Andrei Tudor Călin wrote: > > Here is a rough sketch: > > type allowedIPsListener struct { >

Re: [go-nuts] How to limit client IPs in tls listener?

Here is a rough sketch: type allowedIPsListener struct { allowed []net.IP inner net.Listener } func (ln *allowedIPsListener) Accept() (net.Conn, error) { for { conn, err := ln.inner.Accept() if err != nil { return

Re: [go-nuts] How to limit client IPs in tls listener?

Thanks for the quick reply. I want to use tcp, is it possible to leverage TCPListener or I have to invent my own? It seems I'll face the same issue as I do with tls? On Friday, March 15, 2019 at 9:46:00 PM UTC+8, Andrei Tudor Călin wrote: > > Begin by implementing a `net.Listener` which checks

Re: [go-nuts] How to limit client IPs in tls listener?

Begin by implementing a `net.Listener` which checks the list of allowed IPs. You'll be able to run code before the connection is passed on to crypto/tls. Wrap it using https://golang.org/pkg/crypto/tls/#NewListener. On 3/15/19 2:10 PM, Glen Huang wrote: > I'm trying to limit which clients are

[go-nuts] How to limit client IPs in tls listener?

I'm trying to limit which clients are allowed to connect to my tls server by their IPs. I know I can do that after Accept, check their IPs and close the connection if they're not whitelisted. But that means the full tls handshake has to complete before I can do that. Another option is that I

[go-nuts] bacillus - a minimalist build automation server written in Go

bacillμs (Build Automation/Continuous Integration Low-Linecount μ(micro)-Service) is a simple build automation server. Job status, control and artifacts are presented via a simple web dashboard. Use it to respond to webhooks from github, gitlab, gogs.io, etc. or to git hooks from your own