Re: [go-nuts] Go UDP performance

[Tharaneedharan Vilwanathan]

Hi All,

Sorry for the delay.

I remembered I got better UDP performance in another system. So I had to
track it.

First, please find the code at the end of this mail.

- Version: I used go 1.7.1
- Platform: Ubuntu 16.10 on x86_64 (I used two setups. In one, I used i7
Skull Canyon NUC and in the other the two systems are E5-2650 v4 based 2U
servers with 10Gb and 1Gb links)
- Model: One side just sends and the other side just receives pkts.
- I didnt profile the code yet.

Now, based on my tests, this is what I see:

- in the Xeon based servers, I get about 2.6Gbps (0.0Kbps reverse comm).
- The same setup has 1Gb links. I get about 956Mbps. This is good too!
- With localhost, I get about 2.7Gbps.

Now, in i7 NUC:

- With localhost, I get about 4.6Gbps.
- With a peer IP address, I get only about 220Mbps. This is where I got
stuck.

There are some things to note. First, there is no peer. It just sends to
the other side. This leads to ICMP packets in the reverse side, though low
(5kbps).

What is more, I simply sent the packets to 192.168.1.1 which is my home
router/gateway, Linksys WRT610N. Probably, this is my bottleneck.

I still dont have proof that the ethernet port on the NUC is good enough. I
will connect a Mac soon and find it out.

Hope this helps.

Thanks
dharani

--
package main

import (
"fmt"
"net"
"os"
"time"
)

var buffer []byte

var displayReq bool
var pkts int
var bytes int
var dest string

func send() {
conn, err := net.Dial("udp", dest)
if err != nil {
fmt.Printf("Dial() failed. Error %s\n", err)
os.Exit(1)
}
defer conn.Close()

pkts = 0
bytes = 0

for {
n, err := conn.Write(buffer[0:1472])
if err != nil {
//fmt.Printf("Write failed! Error: %s\n", err)
//os.Exit(1)
}
pkts++
bytes += n
}
}

func recv() {
pc, err := net.ListenPacket("udp", ":45000")
if err != nil {
fmt.Printf("Read failed! Error: %s\n", err)
os.Exit(1)
}
defer pc.Close()

pkts = 0
bytes = 0

for {
n, addr, err := pc.ReadFrom(buffer)
if err != nil {
fmt.Printf("Read failed! Error: %s\n", err)
os.Exit(1)
}
if false {
fmt.Printf("Got a pkt from addr: %s\n", addr)
}
pkts++
bytes += n
}
}

func main() {
if len(os.Args) != 3 {
fmt.Printf("Usage: %s [send|recv] addr:port\n", os.Args[0])
os.Exit(1)
}
mode := os.Args[1]
dest = os.Args[2]

buffer = make([]byte, 1600)
go displayTimerProc()

if mode == "send" {
send()
} else {
recv()
}
}

func displayTimerProc() {
for {
displayReq = true
time.Sleep(time.Second)
fmt.Printf("Pkts %d, Bytes %d, rate %d mbps\n",
pkts, bytes, bytes*8/(1000*1000))
pkts = 0
bytes = 0
}
}

--


On Tue, Feb 21, 2017 at 3:51 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Mon, 20 Feb 2017 13:02:15 -0800
> Tharaneedharan Vilwanathan  wrote:
>
> > Hi All,
> >
> > I am trying to send a lot of UDP packets from Go code but I realized
> > UDP performance is too low. The max I was able to do is about
> > 160Mbps. This is in Ubuntu 16.10 on x86_64 (i7-6700HQ).
> >
> > I tried to google on this and it looks like this is about the
> > performance we can get. I am a bit surprised.
> >
> > Am I missing something? Any suggestions on how to improve the
> > performance?
>
> You could estimate what a "dumb sender written in C" could produce:
>
> On the receiver box, do:
>
>   # apt install netcat-openbsd
>   $ nc -k -u -l  >/dev/null
>
> On the sender box, do:
>
>   # apt install netcat-openbsd pv
>   $ pv 
> and see what speed pv will show to you.
>
> On my old Intel E8400 Core2Duo machine I get circa 900MiB when
> transferring between a two endpoints on the localhost using a pair of
> netcats.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] playgo - CLI tool to send .go file to the Go Playground

[pltvs]

Usually when we share a runnable Go code we do: copy code, open Go 
Playground, paste code, click Share.

So playgo  does it for you.

go get -u github.com/plutov/playgo/cmd/playgo
playgo helloworld.go
https://play.golang.org/p/v3rrZLwEUC

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Reflection: Constructing a struct type that satisfies an interface

[Matt Harden]

Is the intermediate Go struct necessary, or do you just want to convert a
text proto to a binary representation?

On Wed, Feb 22, 2017 at 6:10 PM  wrote:

> Hi,
>
> I'm fiddling with gRPC and its service reflection. I discovered a neat
> package (github.com/jhump/protoreflect) that let me quickly enumerate the
> services that are exposed by the gRPC server, the RPCs that are in those
> gRPC services, and finally the proto messages that are used as inputs and
> outputs.
>
> Later, I'll worry about how to actually send out the RPC.
>
> For now, I'm trying to unserialize a text proto message into a dynamically
> constructed Go struct, which I'd then serialize back into a binary proto.
>
> I'd like to make the generated struct satisfy the proto.Message interface.
> There are three methods required by that interface.
>
> How would one go about attaching the required methods onto the newly
> constructed type?
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Reflection: Constructing a struct type that satisfies an interface

[ivucica]

Hi,

I'm fiddling with gRPC and its service reflection. I discovered a neat 
package (github.com/jhump/protoreflect) that let me quickly enumerate the 
services that are exposed by the gRPC server, the RPCs that are in those 
gRPC services, and finally the proto messages that are used as inputs and 
outputs.

Later, I'll worry about how to actually send out the RPC. 

For now, I'm trying to unserialize a text proto message into a dynamically 
constructed Go struct, which I'd then serialize back into a binary proto.

I'd like to make the generated struct satisfy the proto.Message interface. 
There are three methods required by that interface.

How would one go about attaching the required methods onto the newly 
constructed type?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: NewTicker function example

[Rodolfo Azevedo]

You can use sync WaitGroup too

https://play.golang.org/p/bb3a6t1N-C

But WILL NOT WORK ON playground, because of limitations of time package on 
playground.

Regards.

Em quarta-feira, 22 de fevereiro de 2017 21:39:12 UTC-4, Keith Brown 
escreveu:
>
> Oddly, I can't find a single example on the world wide web for what I am 
> trying to do.
>
> I have 2 functions which I want to run on a periodic basis. The functions 
> are square and cube. 
> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
> But, I am not sure how to schedule these functions.  I looked here, 
> https://gobyexample.com/tickers, but really isn't that helpful or 
> intuitive. 
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: NewTicker function example

[Rodolfo Azevedo]

Like this?

https://play.golang.org/p/rXPl7Bco0c

Em quarta-feira, 22 de fevereiro de 2017 21:39:12 UTC-4, Keith Brown 
escreveu:
>
> Oddly, I can't find a single example on the world wide web for what I am 
> trying to do.
>
> I have 2 functions which I want to run on a periodic basis. The functions 
> are square and cube. 
> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
> But, I am not sure how to schedule these functions.  I looked here, 
> https://gobyexample.com/tickers, but really isn't that helpful or 
> intuitive. 
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: unexpected end of JSON input while unmarshal to struct

[Diogo Ribeiro]

Thanks Nathan, it worked.
I didn't know that *LimitOrder.UnmarshalJSON would call json.Unmarshal.

Em terça-feira, 21 de fevereiro de 2017 05:24:45 UTC-3, Nathan Kerr 
escreveu:
>
> I figured it out.
>
> First off, the posted playground had a different json string and did not 
> use your UnmarshalJSON function. These made translating between the 
> non-working setup described in your post and the working playground 
> annoying. In the future, share the non-working setup.
>
> At the point when I figured things out, my code was: 
> https://play.golang.org/p/aMvz_JTrjD. This won't run on playground 
> because it uses github.com/pkg/errors to add context to the errors so I 
> could see which error was returned along with a much needed stack trace.
>
> I found two problems with the implementation of UnmarshalJSON:
>
> 1. tmp["response_data"] and tmp2["order"] return zero values when the key 
> is not found. This happened, first, because of the difference between the 
> posted json and the json in the posted playground. Second, because of the 
> second problem.
>
> 2. json.Unmarshal uses a type's UnmarshalJSON function if it exists to do 
> the unmarshalling. This created a loop where *LimitOrder.UnmarshalJSON 
> calls json.Unmarshal, which calls *LimitOrder.UnmarshalJSON, and so on. 
> Line 71 prints out the call stack for the returned error that confirms this.
>
> My recommended way of doing things is https://play.golang.org/p/kRKevuX8LW, 
> that is write out the structs you need. This will also allow you to check 
> the status_code from the response. If your LimitOrder will outlive the 
> response then change ResponseData.LimitOrder to be a pointer.
>
> Hope this helps.
>
> On Tuesday, February 21, 2017 at 6:25:10 AM UTC+1, Diogo Ribeiro wrote:
>>
>> Could you help me to understand why I'm always getting the error unexpected 
>> end of JSON input while trying to unmarshal the following json to the 
>> LimitOrder struct? It works if I use golang playground 
>> https://play.golang.org/p/udPQ_TayXG but not locally running tests.
>>
>>
>> P.S.: if I use map[string]json.RawMessage instead of LimitOrder struct 
>> I'm able to execute the unmarshal.
>>
>>
>> {
>>   "response_data": {
>> "order": {
>>   "order_id": 3,
>>   "coin_pair": "BRLBTC",
>>   "order_type": 1,
>>   "status": 4,
>>   "has_fills": true,
>>   "quantity": "1.",
>>   "limit_price": "900.0",
>>   "executed_quantity": "1.",
>>   "executed_price_avg": "900.0",
>>   "fee": "0.0030",
>>   "created_timestamp": "1453835329",
>>   "updated_timestamp": "1453835329",
>>   "operations": [
>> {
>>   "operation_id": 1,
>>   "quantity": "1.",
>>   "price": "900.0",
>>   "fee_rate": "0.30",
>>   "executed_timestamp": "1453835329"
>> }
>>   ]
>> }
>>   },
>>   "status_code": 100,
>>   "server_unix_timestamp": "1453835329"}
>>
>> *LimitOrder struct*
>>
>>
>> type LimitOrder struct {
>>   OrderId int `json:"order_id"`
>>   CoinPair string `json:"coin_pair"`
>>   OrderType int `json:"order_type"`
>>   Status int `json:"status"`
>>   HasFills bool `json:"has_fills"`
>>   Quantity float64 `json:"quantity,string"`
>>   LimitPrice float64 `json:"limit_price,string"`
>>   ExecutedQuantity float64 `json:"executed_quantity,string"`
>>   ExecutedPriceAvg float64 `json:"executed_price_avg,string"`
>>   Fee float64 `json:"fee,string"`
>>   Operations []*Operation `json:"operations"`
>>   CreatedTimestamp string `json:"created_timestamp"`
>>   UpdatedTimestamp string `json:"updated_timestamp"`}
>>
>>
>> and this is how I'm trying to unmarshal it
>>
>>
>> func (limitOrder *LimitOrder) UnmarshalJSON(buf []byte) error {
>>
>>   tmp := make(map[string]json.RawMessage)
>>   if err := json.Unmarshal(buf, &tmp); err != nil {
>> return err
>>   }
>>
>>   tmp2 := make(map[string]json.RawMessage)
>>
>>   if err := json.Unmarshal(tmp["response_data"], &tmp2); err != nil {
>> return err
>>   }
>>
>>   if err := json.Unmarshal(tmp2["order"], limitOrder); err != nil {
>> return err
>>   }
>>
>>   return nil}
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Can Go run on a calculator?

[Tyler Compton]

The TI-84 series uses the z80 instruction set, which isn't a compile target
in Go, unfortunately. That's not to say it couldn't be, but I bet there are
some more fundamental issues that would make compiling to a TI-84
impossible. I don't think Go supports any 8-bit machines.

On Wed, Feb 22, 2017 at 6:20 PM  wrote:

> I realized today that the TI-84 Plus C *Silver Edition* calculator I have
> is able to run assembly instructions, and after further Googling and some
> Wikipedia searches I found out that some C compilers exist. It uses the
> Zilog Z80 8-bit CPU with 128 KB of RAM (21 KB user accessible) and 4 MB of
> Flash ROM (3.5 MB user accessible), so I'm not expecting fireworks, but if
> I could get it to print "Hello World" we could successfully say Go runs on
> calculators (take that, Java!).
>
> Thanks,
> Meyer
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] NewTicker function example

[Keith Brown]

Oddly, I can't find a single example on the world wide web for what I am 
trying to do.

I have 2 functions which I want to run on a periodic basis. The functions 
are square and cube. 
Here is my code so far. https://play.golang.org/p/akMxcg2Sra
But, I am not sure how to schedule these functions.  I looked 
here, https://gobyexample.com/tickers, but really isn't that helpful or 
intuitive. 



-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Can Go run on a calculator?

[meyerzinn]

I realized today that the TI-84 Plus C *Silver Edition* calculator I have 
is able to run assembly instructions, and after further Googling and some 
Wikipedia searches I found out that some C compilers exist. It uses the 
Zilog Z80 8-bit CPU with 128 KB of RAM (21 KB user accessible) and 4 MB of 
Flash ROM (3.5 MB user accessible), so I'm not expecting fireworks, but if 
I could get it to print "Hello World" we could successfully say Go runs on 
calculators (take that, Java!).

Thanks,
Meyer

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Beginner Question : Reassignment of counter variable inside for loop in https://github.com/golang/mobile/tree/master/example/flappy

[Jesse McNelis]

On Thu, Feb 23, 2017 at 8:59 AM, Victor Kovacs  wrote:
>
> // The ground.
>> for i := range g.groundY {
>> i := i
>> // The top of the ground.
>> newNode(func(eng sprite.Engine, n *sprite.Node, t clock.Time) {
>>
>
>  While this solves the issue I would like to understand what is happening.
> Any insight is appreciated.
>
>
This is a variant of https://golang.org/doc/faq#closures_and_goroutines

Your function literal captures a reference to the variables 'i' and 'j',
These variables are modified by the loop on the next iteration.

The reason for using i := i is to copy the value from the loop variable 'i'
in to a new variable also called 'i', which won't be modified by the next
iteration of the loop.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Beginner Question : Reassignment of counter variable inside for loop in https://github.com/golang/mobile/tree/master/example/flappy

[Victor Kovacs]

 Hi, 

I've recently started learning go as a way to learn mobile apps and have 
started experimenting with flappy from the mobile examples 
(https://github.com/golang/mobile/tree/master/example/flappy)
While doing some changes I've run into a problem that I don't understand. 
The code : 


   for i :=0; i <2; i++{
> for j :=0; j<2 ; j++{
> newNode(func(eng sprite.Engine, n *sprite.Node, t clock.Time) {
> fmt.Println(i, j)


produces this error with i and j being 2 :  

panic: runtime error: index out of range
>

The example code 
https://github.com/golang/mobile/tree/master/example/flappy solves this by 
assigning i again inside the loop-block  : 
 starting ligne 96  : 

>
> newNode := func(fn arrangerFunc) { 
> n := &sprite.Node{Arranger: arrangerFunc(fn)} 
> eng.Register(n) 
> scene.AppendChild(n) 
> } 
>
> // The ground. 
> for i := range g.groundY { 
> i := i 
> // The top of the ground. 
> newNode(func(eng sprite.Engine, n *sprite.Node, t clock.Time) {
>

 While this solves the issue I would like to understand what is happening. 
Any insight is appreciated. 

Thanks for your help, 
Victor


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] correct/working 9p2000 library in Go?

[Latchesar Ionkov]

I guess you assume that we are actually checking if there are issues
open and closing them when the bugs get fixed. That's definitely not
true for my repositories and I am not planning to spend time on this.

https://github.com/lionkov/go9p was superseded by
https://github.com/lionkov/ninep (I was told that some people dislike
packages that start with go). I don't know of any bugs in it, if there
are some, I'd be happy to fix them (but not close the issues :)

I believe Ron's HarveyOS/ninep is a clone of mine repository.

On Sun, Feb 19, 2017 at 10:39 AM, Jason E. Aten  wrote:
> I'd like to play with the 9p protocol (plan9's "everything is a filesystem"
> IPC protocol; I guess the updated 9p2000 version is the one everyone
> actually uses) ...
>
> ...but the implementations I can find in Go seem
> half-done/incomplete/unmaintained.
>
> http://9p.cat-v.org/implementations  + other searches turned up:
>
>
> 0) https://github.com/9fans/go - Last commit 2 years ago. 2 outstanding
> issues, 8 outstanding pull requests. Appears orphaned.
>
> 1) https://code.google.com/p/go9p/ seems to be superceeded by
> https://github.com/lionkov/go9p - 6 open issues including race conditions
> that appear quite serious.
>
> 2) https://github.com/rminnich/go9p/  - last commit in 2015, 3 outstanding
> issues, 7 outstanding pull requests
>
> 3) https://github.com/Harvey-OS/ninep - recent activity as of 11 days ago
> (yay), but an open issue indicates ongoing data races and experimentation
> with the implementation that indicates it is likely not stable or usable by
> 3rd parties.
>
> 4) https://github.com/docker/go-p9p - six open issues, some of them serious
> and indicating that it cannot interoperate with other 9p implementations
>
> 5) https://github.com/joushou/qp  - very little documentation and its build
> is failing
>
> So to my question...
>
> Does anyone know of, or have a pointer to, a working/solid/correct 9p
> (9p2000) client/server library in Go?
>
>
> Perhaps the authors of the above could chime in and clarify if their package
> *is* actually in good shape, despite appearances.
>
>
> NB the problematic licensing of any code derived from the original C
> implementation means I'll need to locate a non-Lucent  license in order to
> use a lib. So this rules out a straight port of the C.
>
> Thanks!
>
> -J
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] correct/working 9p2000 library in Go?

[Jason E. Aten]

Thanks Latchesar. Mr. Minnich notes here

https://github.com/Harvey-OS/ninep/issues/21

that, with regards to his fork:

> I've been using it for quite some time now and it's been very solid and
stable.

On Wed, Feb 22, 2017 at 4:30 PM, Latchesar Ionkov  wrote:

> I guess you assume that we are actually checking if there are issues
> open and closing them when the bugs get fixed. That's definitely not
> true for my repositories and I am not planning to spend time on this.
>
> https://github.com/lionkov/go9p was superseded by
> https://github.com/lionkov/ninep (I was told that some people dislike
> packages that start with go). I don't know of any bugs in it, if there
> are some, I'd be happy to fix them (but not close the issues :)
>
> I believe Ron's HarveyOS/ninep is a clone of mine repository.
>
> On Sun, Feb 19, 2017 at 10:39 AM, Jason E. Aten 
> wrote:
> > I'd like to play with the 9p protocol (plan9's "everything is a
> filesystem"
> > IPC protocol; I guess the updated 9p2000 version is the one everyone
> > actually uses) ...
> >
> > ...but the implementations I can find in Go seem
> > half-done/incomplete/unmaintained.
> >
> > http://9p.cat-v.org/implementations  + other searches turned up:
> >
> >
> > 0) https://github.com/9fans/go - Last commit 2 years ago. 2 outstanding
> > issues, 8 outstanding pull requests. Appears orphaned.
> >
> > 1) https://code.google.com/p/go9p/ seems to be superceeded by
> > https://github.com/lionkov/go9p - 6 open issues including race
> conditions
> > that appear quite serious.
> >
> > 2) https://github.com/rminnich/go9p/  - last commit in 2015, 3
> outstanding
> > issues, 7 outstanding pull requests
> >
> > 3) https://github.com/Harvey-OS/ninep - recent activity as of 11 days
> ago
> > (yay), but an open issue indicates ongoing data races and experimentation
> > with the implementation that indicates it is likely not stable or usable
> by
> > 3rd parties.
> >
> > 4) https://github.com/docker/go-p9p - six open issues, some of them
> serious
> > and indicating that it cannot interoperate with other 9p implementations
> >
> > 5) https://github.com/joushou/qp  - very little documentation and its
> build
> > is failing
> >
> > So to my question...
> >
> > Does anyone know of, or have a pointer to, a working/solid/correct 9p
> > (9p2000) client/server library in Go?
> >
> >
> > Perhaps the authors of the above could chime in and clarify if their
> package
> > *is* actually in good shape, despite appearances.
> >
> >
> > NB the problematic licensing of any code derived from the original C
> > implementation means I'll need to locate a non-Lucent  license in order
> to
> > use a lib. So this rules out a straight port of the C.
> >
> > Thanks!
> >
> > -J
> >
> > --
> > 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.
> > For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

[Matt Layher]

No special workarounds in my package that I'm aware of!  My guess would 
be that it's inconsistent between netlink families.  I've only really 
played with genetlink and rtnetlink.


- Matt


On 02/22/2017 05:14 PM, Steven Hartland wrote:
Hmm fails with EPERM when we try to listen for CN_IDX_PROC I guess 
that may be a special case given what it is.


Be interested to know if your module avoids this issue somehow?

On 22/02/2017 21:17, Matt Layher wrote:
> 1. "Only processes with an effective UID of 0 or the CAP_NET_ADMIN capability 
may send or listen to a netlink multicast group."


This appears not to be true, at least in the case of rtnetlink and 
listening to multicast notifications for link additions and removals.


https://play.golang.org/p/dn3-549-Ay

First terminal:
$ whoami
matt
$ go build
$ getcap ./nlmcast
$ ./nlmcast

Second terminal:
$ sudo ip link add type nlmon
$ sudo ip link del dev nlmon0

Back to first terminal (./nlmcast still running):
2017/02/22 16:13:46 received 1 messages
2017/02/22 16:13:50 received 1 messages


> 2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an 
effective UID of 0."


Yep, this is documented in my package: 
https://godoc.org/github.com/mdlayher/netlink#HeaderFlags


I had read in some header, I think, that NLM_F_ATOMIC "may be 
obsolete". I haven't ever tried it. I should look into it. I'll also 
note this case in my post.


- Matt



On Wednesday, February 22, 2017 at 3:45:24 PM UTC-5, Steven Hartland 
wrote:


It's required for read only in some situations too, for example
we use it here to listen for process exit codes.

http://man7.org/linux/man-pages/man7/netlink.7.html

Mentions two separate cases:
1. "Only processes with an effective UID of 0 or the
CAP_NET_ADMIN capability may send or listen to a netlink
multicast   group."
2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an
effective UID of 0."

On 22/02/2017 18:24, Matt Layher wrote:

Sure, I can make a note of this.  Almost everything I've done
with netlink so far has been read-only, which is probably why I
haven't run into any issues.

On Wednesday, February 22, 2017 at 1:13:26 PM UTC-5, Steven
Hartland wrote:

One thing you don't mention, which we found particularly
frustrating with netlink, is that using it can often need
cap_net_admin :(

On 22/02/2017 17:38, Matt Layher wrote:

Hey all,

I recently spent some time working with Linux's netlink IPC
mechanism in Go.  Because I had a hard time finding
accurate information about netlink, I decided to do a
write-up on some of its fundamental concepts, and how I was
able to make use of them from Go.

This post focuses on how netlink sockets and messages work,
and how to work with them from Go or another language of
your choice.

You can find the first portion of that write-up, focusing
on netlink, here:

https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8



I still have more to write regarding generic netlink and my
high-level Go netlink and wifi packages themselves (parts 2
and 3).

If you're just looking for some source code, check out:

https://github.com/mdlayher/netlink

https://github.com/mdlayher/wifi


Happy to address any questions or comments here.  Thanks
for your time!

- Matt Layher
-- 
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.
For more options, visit https://groups.google.com/d/optout
.








--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

[Steven Hartland]

Hmm fails with EPERM when we try to listen for CN_IDX_PROC I guess that 
may be a special case given what it is.


Be interested to know if your module avoids this issue somehow?

On 22/02/2017 21:17, Matt Layher wrote:
> 1. "Only processes with an effective UID of 0 or the CAP_NET_ADMIN capability 
may send or listen to a netlink multicast group."


This appears not to be true, at least in the case of rtnetlink and 
listening to multicast notifications for link additions and removals.


https://play.golang.org/p/dn3-549-Ay

First terminal:
$ whoami
matt
$ go build
$ getcap ./nlmcast
$ ./nlmcast

Second terminal:
$ sudo ip link add type nlmon
$ sudo ip link del dev nlmon0

Back to first terminal (./nlmcast still running):
2017/02/22 16:13:46 received 1 messages
2017/02/22 16:13:50 received 1 messages


> 2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an 
effective UID of 0."


Yep, this is documented in my package: 
https://godoc.org/github.com/mdlayher/netlink#HeaderFlags


I had read in some header, I think, that NLM_F_ATOMIC "may be 
obsolete". I haven't ever tried it. I should look into it. I'll also 
note this case in my post.


- Matt



On Wednesday, February 22, 2017 at 3:45:24 PM UTC-5, Steven Hartland 
wrote:


It's required for read only in some situations too, for example we
use it here to listen for process exit codes.

http://man7.org/linux/man-pages/man7/netlink.7.html

Mentions two separate cases:
1. "Only processes with an effective UID of 0 or the CAP_NET_ADMIN
capability may send or listen to a netlink multicast   group."
2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an
effective UID of 0."

On 22/02/2017 18:24, Matt Layher wrote:

Sure, I can make a note of this.  Almost everything I've done
with netlink so far has been read-only, which is probably why I
haven't run into any issues.

On Wednesday, February 22, 2017 at 1:13:26 PM UTC-5, Steven
Hartland wrote:

One thing you don't mention, which we found particularly
frustrating with netlink, is that using it can often need
cap_net_admin :(

On 22/02/2017 17:38, Matt Layher wrote:

Hey all,

I recently spent some time working with Linux's netlink IPC
mechanism in Go.  Because I had a hard time finding accurate
information about netlink, I decided to do a write-up on
some of its fundamental concepts, and how I was able to make
use of them from Go.

This post focuses on how netlink sockets and messages work,
and how to work with them from Go or another language of
your choice.

You can find the first portion of that write-up, focusing on
netlink, here:

https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8



I still have more to write regarding generic netlink and my
high-level Go netlink and wifi packages themselves (parts 2
and 3).

If you're just looking for some source code, check out:

https://github.com/mdlayher/netlink

https://github.com/mdlayher/wifi


Happy to address any questions or comments here.  Thanks for
your time!

- Matt Layher
-- 
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.
For more options, visit https://groups.google.com/d/optout
.






--
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Compiler Intermediate Representation

[adonovan via golang-nuts]

On Tuesday, 21 February 2017 12:23:44 UTC-5, Arpit Aggarwal wrote:
>
> I am doing a project in which I need Go compiler's intermediate 
> representation(IR) (which is semantics preserving and I can get all all 
> info like line number and data type and other features) (human readable) to 
> convert to another IR of a tool.
>

The most convenient way to access the semantics of a Go program is to use 
the golang.org/x/tools/go/ssa package, which builds a high-level SSA-based 
intermediate representation.

$ cat fib.go
package fib

func fib(x int) int {
if x < 2 {
return x
}
return fib(x-2) + fib(x-1)
}

$ go build golang.org/x/tools/cmd/ssadump
$ ./ssadump -build=F fib.go
# Name: fib.fib
# Package: fib
# Location: fib.go:3:6
func fib(x int) int:
0:entry P:0 
S:2
t0 = x < 2:int 
bool
if t0 goto 1 else 2
1:  if.then P:1 
S:0
return x
2:  if.done P:1 
S:0
t1 = x - 2:int 
 int
t2 = fib(t1)   
 int
t3 = x - 1:int 
 int
t4 = fib(t3)   
 int
t5 = t2 + t4   
 int
return t5

# Name: fib.init
# Package: fib
# Synthetic: package initializer
func init():
0:entry P:0 
S:2
t0 = *init$guard   
bool
if t0 goto 2 else 1
1:   init.start P:1 
S:1
*init$guard = true:bool
jump 2
2:init.done P:2 
S:0
return

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] Enhanced Markdown template processor(emd): helper to generate README file

[mhhcbon]

Hi,

I made this package to spare me some efforts 
while maintaining README files of my projects.

Its a binary written in go which take advantages
of text/template to allow dynamic generation
of the README file with help of
 some fine grained helpers.

Just check the README file of the project 
and compare it with the e.md file 

I created for this project.

With help of emd, now i can invoke 
   emd gen -out README.md
to generate an updated version of the README file 
(for most of what is doable to automate).

Find the list of helpers here 


I think its a good companion with godoc, 
each other being strong in the companion weaknesses.
godoc is better for structured text for api documentation,
markdown is better at loosely structured text.

Find the repo at https://github.com/mh-cbon/emd

That s it!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Initializing nested struct, by dynamically forming struct member path

[C Banning]

Clean-up 
example: https://github.com/clbanning/mxj/blob/master/examples/leafnodes.go

On Wednesday, February 22, 2017 at 4:31:47 AM UTC-7, C Banning wrote:
>
> Perhaps not very elegant but seems to produce what you're looking for: 
> https://play.golang.org/p/bpM69Q-ddV 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

[Matt Layher]

> 1. "Only processes with an effective UID of 0 or the CAP_NET_ADMIN 
capability may send or listen to a netlink multicast   group."

This appears not to be true, at least in the case of rtnetlink and 
listening to multicast notifications for link additions and removals.

https://play.golang.org/p/dn3-549-Ay

First terminal:
$ whoami
matt
$ go build
$ getcap ./nlmcast
$ ./nlmcast

Second terminal:
$ sudo ip link add type nlmon 
$ sudo ip link del dev nlmon0

Back to first terminal (./nlmcast still running):
2017/02/22 16:13:46 received 1 messages
2017/02/22 16:13:50 received 1 messages


> 2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an effective 
UID of 0."

Yep, this is documented in my package: 
https://godoc.org/github.com/mdlayher/netlink#HeaderFlags

I had read in some header, I think, that NLM_F_ATOMIC "may be obsolete". I 
haven't ever tried it. I should look into it. I'll also note this case in 
my post.

- Matt



On Wednesday, February 22, 2017 at 3:45:24 PM UTC-5, Steven Hartland wrote:
>
> It's required for read only in some situations too, for example we use it 
> here to listen for process exit codes.
>
> http://man7.org/linux/man-pages/man7/netlink.7.html
> Mentions two separate cases:
> 1. "Only processes with an effective UID of 0 or the CAP_NET_ADMIN 
> capability may send or listen to a netlink multicast   group."
> 2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an effective UID 
> of 0."
>
> On 22/02/2017 18:24, Matt Layher wrote:
>
> Sure, I can make a note of this.  Almost everything I've done with netlink 
> so far has been read-only, which is probably why I haven't run into any 
> issues.
>
> On Wednesday, February 22, 2017 at 1:13:26 PM UTC-5, Steven Hartland 
> wrote: 
>>
>> One thing you don't mention, which we found particularly frustrating with 
>> netlink, is that using it can often need cap_net_admin :(
>>
>> On 22/02/2017 17:38, Matt Layher wrote:
>>
>> Hey all, 
>>
>> I recently spent some time working with Linux's netlink IPC mechanism in 
>> Go.  Because I had a hard time finding accurate information about netlink, 
>> I decided to do a write-up on some of its fundamental concepts, and how I 
>> was able to make use of them from Go.
>>
>> This post focuses on how netlink sockets and messages work, and how to 
>> work with them from Go or another language of your choice.
>>
>> You can find the first portion of that write-up, focusing on netlink, 
>> here:
>>
>> https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8
>>
>> I still have more to write regarding generic netlink and my high-level Go 
>> netlink and wifi packages themselves (parts 2 and 3). 
>>
>> If you're just looking for some source code, check out:
>>
>> https://github.com/mdlayher/netlink
>> https://github.com/mdlayher/wifi
>>
>> Happy to address any questions or comments here.  Thanks for your time!
>>
>> - Matt Layher
>> -- 
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

RE: [go-nuts] Re: Trying to understand := and named return values

[John Souvestre]

Ø  // Add two numbers

Ø  Add(x, y int) int

 

Although I support documenting functions as you did above, I feel that this 
example doesn’t serve your argument well.  In this specific case the 
counter-argument would be that the documentation adds nothing at all to the 
user’s understanding of the function, hence it is superfluous.  Indeed, the 
documentation doesn’t mention that the two numbers have to be int’s, so I’m 
forced to also read the function declaration anyway.  It’s like putting a 
useless comment on a line of code, for example:

 

A = A + 1// Add 1 to A

 

I expect that we can all agree that this comment is not only useless, but is 
actually bad since it distracts the user for no benefit.

 

Regardless, as I said, I do support the documentation line in your example 
simply because of human nature.  It’s often better to have a rule (all 
functions must be preceded by documentation) than to leave it up to the 
programmer to decide on a case-by-case basis.  The result is higher quality 
code overall, I believe.

 

Let’s look at another example.  Which form is better?  Which tells the user 
more?  Which requires less documentation?

 

Power(x, y int) int

Power(base, exponent int) int

 

Yes, I think that using named parameters (both calling and return) is good in 
general.  Yes, there are cases (such as Add) where it doesn’t help, but it also 
doesn’t hurt.

John

John Souvestre - New Orleans LA

 

From: Thomas Bushnell, BSG [mailto:tbushn...@google.com] 
Sent: 2017 February 22, Wed 11:01
To: John Souvestre; golang-nuts
Subject: Re: [go-nuts] Re: Trying to understand := and named return values

 

Function parameters are not a good place (in general - there are exceptions) to 
document arguments.

 

// Frob the outer otter.

FrobOuterOtter(otter Otter)

 

is not better than

 

// Frob the outer otter

FrobOuterOtter(Otter)

 

from the standpoint of external documentation.

 

But if you want the function to have access to the parameters, you need to name 
them. The same is not true for return values.

 

// Add two numbers

Add(x, y int) int

 

is fine. This is silly:

 

// Add two numbers

Add(x, y int) (sum int)

 

Since the comment already says in English what is returned, there isn't any 
value to repeating it again in the return value. Except when there are multiple 
ones and the order matters:

 

// Lookup returns the name and email address of the user.

Lookup(id Identity) (name, email string)

 

 

On Tue, Feb 21, 2017 at 6:46 PM John Souvestre  wrote:

I feel the opposite.  I view named returns as documentation of a function's 
parameters.  I'm constantly amazed by the (correct) emphasis placed on using 
appropriate names for calling parameters, but not for the return parameters.  
The goal is that I shouldn't have to read a function's code to use the 
function, right?

So how can the disparity be justified?  Oh, and the longer the function is the 
more benefit there is to using them.

John

John Souvestre - New Orleans LA


-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Ian Lance Taylor
Sent: 2017 February 21, Tue 16:13
To: andrew.penneba...@gmail.com
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Trying to understand := and named return values

On Tue, Feb 21, 2017 at 1:46 PM,   wrote:
> Seems like named returns + if/for/switch initializers = a shadowing
> nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> this is a dangerously subtle problem out there.

Yes, named returns may have been a mistake.  Only use them in very
very short functions.

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 
 .
For more options, visit https://groups.google.com/d/optout.

--
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 
 .
For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

[Steven Hartland]

It's required for read only in some situations too, for example we use 
it here to listen for process exit codes.


http://man7.org/linux/man-pages/man7/netlink.7.html
Mentions two separate cases:
1. "Only processes with an effective UID of 0 or the CAP_NET_ADMIN 
capability may send or listen to a netlink multicast   group."
2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an effective 
UID of 0."


On 22/02/2017 18:24, Matt Layher wrote:
Sure, I can make a note of this.  Almost everything I've done with 
netlink so far has been read-only, which is probably why I haven't run 
into any issues.


On Wednesday, February 22, 2017 at 1:13:26 PM UTC-5, Steven Hartland 
wrote:


One thing you don't mention, which we found particularly
frustrating with netlink, is that using it can often need
cap_net_admin :(

On 22/02/2017 17:38, Matt Layher wrote:

Hey all,

I recently spent some time working with Linux's netlink IPC
mechanism in Go.  Because I had a hard time finding accurate
information about netlink, I decided to do a write-up on some of
its fundamental concepts, and how I was able to make use of them
from Go.

This post focuses on how netlink sockets and messages work, and
how to work with them from Go or another language of your choice.

You can find the first portion of that write-up, focusing on
netlink, here:

https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8



I still have more to write regarding generic netlink and my
high-level Go netlink and wifi packages themselves (parts 2 and 3).

If you're just looking for some source code, check out:

https://github.com/mdlayher/netlink

https://github.com/mdlayher/wifi 

Happy to address any questions or comments here.  Thanks for your
time!

- Matt Layher
-- 
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 .
For more options, visit https://groups.google.com/d/optout
.




--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Golang Messenger Bot frameworks

[Nyah Check]

Cool, I'll try that.

On Wed, Feb 22, 2017 at 7:36 PM, Diego Medina  wrote:

> great!, I use their http api directly with Go and works really well.
>
> On Wed, Feb 22, 2017 at 1:31 PM, Nyah Check  wrote:
>
>> Hi Diego,
>>
>> Here is the link: https://messengerchallenge.splashthat.com/
>>
>> 2. iric, Facebook uses https://wit.ai/ for their chat bots, and they
>>> have an http API so using regular Go you don't need any sdk/framework
>>>
>> Yeah, I saw that. It appears there's a python API not Go. I'll try the
>> regular HTTP then.
>>
>> Thanks,
>> Nyah
>> --
>> "The heaviest penalty for declining to rule is to be ruled by someone
>> inferior to yourself." --*Plato*
>>
>
>
>
> --
> Diego Medina
> Lift/Scala Consultant
> di...@fmpwizard.com
> https://blog.fmpwizard.com/
>



-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Golang Messenger Bot frameworks

[Diego Medina]

great!, I use their http api directly with Go and works really well.

On Wed, Feb 22, 2017 at 1:31 PM, Nyah Check  wrote:

> Hi Diego,
>
> Here is the link: https://messengerchallenge.splashthat.com/
>
> 2. iric, Facebook uses https://wit.ai/ for their chat bots, and they have
>> an http API so using regular Go you don't need any sdk/framework
>>
> Yeah, I saw that. It appears there's a python API not Go. I'll try the
> regular HTTP then.
>
> Thanks,
> Nyah
> --
> "The heaviest penalty for declining to rule is to be ruled by someone
> inferior to yourself." --*Plato*
>



-- 
Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Are relative import paths idiomatic?

[so . query]

Ok, Thanks for the answer!


On Wednesday, February 22, 2017 at 9:46:26 AM UTC-8, Diego Medina wrote:
>
> Hi,
>
> Not recommended, it's better to be explicit by using the full import path, 
> even if it feels odd at first, other users reading your code will know 
> exactly where the packages are.
> For more info, see the last two replies here
>
> https://groups.google.com/d/topic/golang-nuts/8grbqER8h54/discussion
>
> from a few days ago.
>
> Thanks
>
>
>
> On Wednesday, February 22, 2017 at 11:52:08 AM UTC-5, so.q...@gmail.com 
> wrote:
>>
>> Is it recommended or acceptable to use relative import paths, 
>> particularly for nested packages? or should I typically always use the full 
>> path?
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Golang Messenger Bot frameworks

[Nyah Check]

Hi Diego,

Here is the link: https://messengerchallenge.splashthat.com/

2. iric, Facebook uses https://wit.ai/ for their chat bots, and they have
> an http API so using regular Go you don't need any sdk/framework
>
Yeah, I saw that. It appears there's a python API not Go. I'll try the
regular HTTP then.

Thanks,
Nyah
-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

[Matt Layher]

Sure, I can make a note of this.  Almost everything I've done with netlink 
so far has been read-only, which is probably why I haven't run into any 
issues.

On Wednesday, February 22, 2017 at 1:13:26 PM UTC-5, Steven Hartland wrote:
>
> One thing you don't mention, which we found particularly frustrating with 
> netlink, is that using it can often need cap_net_admin :(
>
> On 22/02/2017 17:38, Matt Layher wrote:
>
> Hey all, 
>
> I recently spent some time working with Linux's netlink IPC mechanism in 
> Go.  Because I had a hard time finding accurate information about netlink, 
> I decided to do a write-up on some of its fundamental concepts, and how I 
> was able to make use of them from Go.
>
> This post focuses on how netlink sockets and messages work, and how to 
> work with them from Go or another language of your choice.
>
> You can find the first portion of that write-up, focusing on netlink, here:
>
> https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8
>
> I still have more to write regarding generic netlink and my high-level Go 
> netlink and wifi packages themselves (parts 2 and 3). 
>
> If you're just looking for some source code, check out:
>
> https://github.com/mdlayher/netlink
> https://github.com/mdlayher/wifi
>
> Happy to address any questions or comments here.  Thanks for your time!
>
> - Matt Layher
> -- 
> 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 .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Linux, Netlink, and Go - Part 1: netlink

[Steven Hartland]

One thing you don't mention, which we found particularly frustrating 
with netlink, is that using it can often need cap_net_admin :(


On 22/02/2017 17:38, Matt Layher wrote:

Hey all,

I recently spent some time working with Linux's netlink IPC mechanism 
in Go.  Because I had a hard time finding accurate information about 
netlink, I decided to do a write-up on some of its fundamental 
concepts, and how I was able to make use of them from Go.


This post focuses on how netlink sockets and messages work, and how to 
work with them from Go or another language of your choice.


You can find the first portion of that write-up, focusing on netlink, 
here:

https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8

I still have more to write regarding generic netlink and my high-level 
Go netlink and wifi packages themselves (parts 2 and 3).


If you're just looking for some source code, check out:

https://github.com/mdlayher/netlink
https://github.com/mdlayher/wifi

Happy to address any questions or comments here.  Thanks for your time!

- Matt Layher
--
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 
.

For more options, visit https://groups.google.com/d/optout.


--
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Linux, Netlink, and Go - Part 1: netlink

[Matt Layher]

Hey all, 

I recently spent some time working with Linux's netlink IPC mechanism in 
Go.  Because I had a hard time finding accurate information about netlink, 
I decided to do a write-up on some of its fundamental concepts, and how I 
was able to make use of them from Go.

This post focuses on how netlink sockets and messages work, and how to work 
with them from Go or another language of your choice.

You can find the first portion of that write-up, focusing on netlink, here:
https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8

I still have more to write regarding generic netlink and my high-level Go 
netlink and wifi packages themselves (parts 2 and 3). 

If you're just looking for some source code, check out:

https://github.com/mdlayher/netlink
https://github.com/mdlayher/wifi

Happy to address any questions or comments here.  Thanks for your time!

- Matt Layher

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Are relative import paths idiomatic?

[Diego Medina]

Hi,

Not recommended, it's better to be explicit by using the full import path, 
even if it feels odd at first, other users reading your code will know 
exactly where the packages are.
For more info, see the last two replies here

https://groups.google.com/d/topic/golang-nuts/8grbqER8h54/discussion

from a few days ago.

Thanks



On Wednesday, February 22, 2017 at 11:52:08 AM UTC-5, so.q...@gmail.com 
wrote:
>
> Is it recommended or acceptable to use relative import paths, particularly 
> for nested packages? or should I typically always use the full path?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Trying to understand := and named return values

[Marvin Renich]

* John Souvestre  [170222 11:16]:
> Ø  does it sounds good to disable (in specs) named return vars shadowing ?
> 
> This would help,

I don't think this is a good solution.  It also breaks Go 1 compatibility.

> but the := problem isn’t limited to return variables.
> I think that it’s when there are two (or more) variables, and only one
> is new, that is the real flaw.  I would prefer that it only work when
> both variables are new.

This I agree with 100%.

> I’ve taken to never using := in any multiple variable situation to
> avoid the problem.  This is something that a ver or lint utility can
> check for now, too.  J

Me too.  In fact, I try to only use := in if/for/switch, since I can't
use var there.  As a separate statement, it's easy to use var ... =
instead of ... :=.

...Marvin

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Golang Messenger Bot frameworks

[Diego Medina]

Hi,

1. Would help if you could post a link to the challenge/API
2. iric, Facebook uses https://wit.ai/ for their chat bots, and they have 
an http API so using regular Go you don't need any sdk/framework

Thanks

On Wednesday, February 22, 2017 at 8:15:19 AM UTC-5, Nyah Check wrote:
>
> Hi Gophers,
>
> I a looking to participate in the Facebook Messenger Bot challenge. 
> Looking at the API. The recommended bot framework has no golang support. I 
> don't know if any one here knows any good Bot AI frameworks I could use.
>
> Inverential Peace,
> Nyah
>
> -- 
> "The heaviest penalty for declining to rule is to be ruled by someone 
> inferior to yourself." --*Plato* 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to locate the function definition of golang source code?

[Ian Lance Taylor]

On Wed, Feb 22, 2017 at 12:22 AM, Jiajun Huang  wrote:
> Hello, I'm reading golang source code, it's in version 1.8. some times, I
> got some functions like: (runtime/proc.go, function main):
>
>107 func main() {
>108 g := getg()
>109
>110 // Racectx of m0->g0 is used only as the parent of the main
> goroutine.
>111 // It must not be used for anything else.
>112 g.m.g0.racectx = 0
>
> I got the function, getg, and located it in(runtime/stubs.go):
>
>18 // getg returns the pointer to the current g.
>19 // The compiler rewrites calls to this function into instructions
>20 // that fetch the g directly (from TLS or from the dedicated
> register).
>21 func getg() *g
>22
>
> I've search the golang source code library for it, but results doesn't
> contain the definition. and the comment say, The compiler rewrites calls to
> this function into instructions, so where can I find the rewritten Assembly
> code?

It's not easy.  The getg function is translated into the SSA operation
OpGetG.  That is rewritten by processor-specific rules listed in
cmd/compile/internal/ssa/gen.  On amd64 we see (in files in
cmd/compile/internal/ssa/gen)
(GetG mem) -> (LoweredGetG mem)
and a pseudo-op
 {name: "LoweredGetG", argLength: 1, reg: gp01}, // arg0=mem
Then we can look over in cmd/compile/internal/amd64/ssa.go where we
can see the handling of OpAMD64LoweredGetG.  That is where getg gets
turned into actual machine instructions, although they aren't written
in assembler but rather in the internal format that cmd/asm parses
instructions into.  Basically, on amd64, it's a load from a TLS
pseudo-register.  The handling of REG_TLS is over in
cmd/internal/obj/x86/asm6.go where we can finally see the instruction
prefix being used, which generates %gs or %fs depending on the system
and whether this is 386 or amd64.

Really a much simpler way to see what the generated instructions are
is to disassemble a function that calls getg.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Trying to understand := and named return values

['Thomas Bushnell, BSG' via golang-nuts]

Function parameters are not a good place (in general - there are
exceptions) to document arguments.

// Frob the outer otter.
FrobOuterOtter(otter Otter)

is not better than

// Frob the outer otter
FrobOuterOtter(Otter)

from the standpoint of external documentation.

But if you want the function to have access to the parameters, you need to
name them. The same is not true for return values.

// Add two numbers
Add(x, y int) int

is fine. This is silly:

// Add two numbers
Add(x, y int) (sum int)

Since the comment already says in English what is returned, there isn't any
value to repeating it again in the return value. *Except *when there are
multiple ones and the order matters:

// Lookup returns the name and email address of the user.
Lookup(id Identity) (name, email string)


On Tue, Feb 21, 2017 at 6:46 PM John Souvestre  wrote:

> I feel the opposite.  I view named returns as documentation of a
> function's parameters.  I'm constantly amazed by the (correct) emphasis
> placed on using appropriate names for calling parameters, but not for the
> return parameters.  The goal is that I shouldn't have to read a function's
> code to use the function, right?
>
> So how can the disparity be justified?  Oh, and the longer the function is
> the more benefit there is to using them.
>
> John
>
> John Souvestre - New Orleans LA
>
>
> -Original Message-
> From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> On Behalf Of Ian Lance Taylor
> Sent: 2017 February 21, Tue 16:13
> To: andrew.penneba...@gmail.com
> Cc: golang-nuts
> Subject: Re: [go-nuts] Re: Trying to understand := and named return values
>
> On Tue, Feb 21, 2017 at 1:46 PM,   wrote:
> > Seems like named returns + if/for/switch initializers = a shadowing
> > nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> > this is a dangerously subtle problem out there.
>
> Yes, named returns may have been a mistake.  Only use them in very
> very short functions.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Are relative import paths idiomatic?

[so . query]

Is it recommended or acceptable to use relative import paths, particularly 
for nested packages? or should I typically always use the full path?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] "go clean -i -race" cannot remove pkg files generated by "go build -i -race"

[goofansu]

$ go build -i -race -x .
WORK=/var/folders/_r/wnjprt2s18v2g9t2cdtt5hs8gn/T/go-build242567175
mkdir -p $WORK/test_viper/_obj/
mkdir -p $WORK/test_viper/_obj/exe/
cd /Users/suyejun/go/src/test_viper
/usr/local/Cellar/go/1.8/libexec/pkg/tool/darwin_amd64/compile -o $WORK/
test_viper.a -trimpath $WORK -race -p main -complete -installsuffix race 
-buildid 
b98ca87a44021961fe5b03f0752e6e83e153a5d7 -importmap github.com/spf13/viper=
test_viper/vendor/github.com/spf13/viper -D _/Users/suyejun/go/src/test_viper 
-I $WORK -I /Users/suyejun/go/pkg/darwin_amd64_race -pack ./main.go
cd .
/usr/local/Cellar/go/1.8/libexec/pkg/tool/darwin_amd64/link -o $WORK/
test_viper/_obj/exe/a.out -L $WORK -L /Users/suyejun/go/pkg/darwin_amd64_race 
-installsuffix race -extld=clang -buildmode=exe 
-buildid=b98ca87a44021961fe5b03f0752e6e83e153a5d7 
-race $WORK/test_viper.a
mv $WORK/test_viper/_obj/exe/a.out test_viper
suyejun@suyejun-iMac ~/g/s/test_viper>

$ go clean -i -race -n ./...
cd /Users/suyejun/go/src/test_viper
rm -f test_viper test_viper.exe test_viper.test test_viper.test.exe main 
main.exe
rm -f /Users/suyejun/go/bin/test_viper
cd /Users/suyejun/go/src/test_viper/vendor/github.com/fsnotify/fsnotify
rm -f fsnotify.test fsnotify.test.exe fen fen.exe inotify inotify.exe 
inotify_poller inotify_poller.exe open_mode_bsd open_mode_bsd.exe windows 
windows.exe
rm -f 
/Users/suyejun/go/pkg/darwin_amd64/test_viper/vendor/github.com/fsnotify/fsnotify.a
cd /Users/suyejun/go/src/test_viper/vendor/github.com/hashicorp/hcl
rm -f hcl.test hcl.test.exe
rm -f 
/Users/suyejun/go/pkg/darwin_amd64/test_viper/vendor/github.com/hashicorp/hcl.a
cd /Users/suyejun/go/src/test_viper/vendor/github.com/hashicorp/hcl/hcl/ast
rm -f ast.test ast.test.exe
rm -f 
/Users/suyejun/go/pkg/darwin_amd64/test_viper/vendor/github.com/hashicorp/hcl/hcl/ast.a
cd 
/Users/suyejun/go/src/test_viper/vendor/github.com/hashicorp/hcl/hcl/parser
rm -f parser.test parser.test.exe

clean with "-race" is always finding "darwin_amd64" while it should be "
darwin_amd64_race".

I'm using Go 1.8 on macOS 10.12. Is it a bug?

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ Pimp yourself ] Anyone can solve this?

[tanya - cube]

Floyd's Triangle 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] how to locate the function definition of golang source code?

[Jiajun Huang]

Hello, I'm reading golang source code, it's in version 1.8. some times, I 
got some functions like: (runtime/proc.go, function main):

   107 func main() {
   108 g := getg()
   109
   110 // Racectx of m0->g0 is used only as the parent of the main 
goroutine.
   111 // It must not be used for anything else.
   112 g.m.g0.racectx = 0

I got the function, getg, and located it in(runtime/stubs.go):

   18 // getg returns the pointer to the current g.
   19 // The compiler rewrites calls to this function into instructions
   20 // that fetch the g directly (from TLS or from the dedicated 
register).
   21 func getg() *g
   22

I've search the golang source code library for it, but results doesn't 
contain the definition. and the comment say, The compiler rewrites calls to 
this function into instructions, so where can I find the rewritten Assembly 
code?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [go-nuts] Re: Trying to understand := and named return values

[John Souvestre]

Ø  does it sounds good to disable (in specs) named return vars shadowing ?

 

This would help, but the := problem isn’t limited to return variables.  I think 
that it’s when there are two (or more) variables, and only one is new, that is 
the real flaw.  I would prefer that it only work when both variables are new.

 

I’ve taken to never using := in any multiple variable situation to avoid the 
problem.  This is something that a ver or lint utility can check for now, too.  
J

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of djad...@gmail.com
Sent: 2017 February 22, Wed 09:35
To: golang-nuts
Cc: m...@renich.org
Subject: Re: [go-nuts] Re: Trying to understand := and named return values

 



On Wednesday, February 22, 2017 at 3:39:58 PM UTC+2, Marvin Renich wrote:

On Tue, Feb 21, 2017 at 1:46 PM,   > wrote: 
> Seems like named returns + if/for/switch initializers = a shadowing 
> nightmare. I wish the Go compiler emitted a loud warning on shadowing, as 
> this is a dangerously subtle problem out there. 

* Ian Lance Taylor [170221 16:13]: 
> Yes, named returns may have been a mistake.  Only use them in very 
> very short functions. 

* John Souvestre  > [170221 21:46]: 
> I feel the opposite.  I view named returns as documentation of a 
> function's parameters.  I'm constantly amazed by the (correct) 
> emphasis placed on using appropriate names for calling parameters, but 
> not for the return parameters.  The goal is that I shouldn't have to 
> read a function's code to use the function, right? 

I agree with the John and the others that named return variables are a 
good feature. 

The confusion is not because of the named returns, but because the := 
notation used with multiple variables on the left combines declaration 
and simple assignment without allowing, much less requiring, the 
programmer to explicitly identify which variables are being declared and 
which are simply being assigned a new value.  This is relevant when := 
is used at the block scope as well as in if/for/switch initializers. 

...Marvin 

 

 

 

does it sounds good to disable (in specs) named return vars shadowing ?

Djadala

 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Trying to understand := and named return values

[djadala]

On Wednesday, February 22, 2017 at 3:39:58 PM UTC+2, Marvin Renich wrote:
>
> On Tue, Feb 21, 2017 at 1:46 PM,  > 
> wrote: 
> > Seems like named returns + if/for/switch initializers = a shadowing 
> > nightmare. I wish the Go compiler emitted a loud warning on shadowing, 
> as 
> > this is a dangerously subtle problem out there. 
>
> * Ian Lance Taylor [170221 16:13]: 
> > Yes, named returns may have been a mistake.  Only use them in very 
> > very short functions. 
>
> * John Souvestre > [170221 21:46]: 
> > I feel the opposite.  I view named returns as documentation of a 
> > function's parameters.  I'm constantly amazed by the (correct) 
> > emphasis placed on using appropriate names for calling parameters, but 
> > not for the return parameters.  The goal is that I shouldn't have to 
> > read a function's code to use the function, right? 
>
> I agree with the John and the others that named return variables are a 
> good feature. 
>
> The confusion is not because of the named returns, but because the := 
> notation used with multiple variables on the left combines declaration 
> and simple assignment without allowing, much less requiring, the 
> programmer to explicitly identify which variables are being declared and 
> which are simply being assigned a new value.  This is relevant when := 
> is used at the block scope as well as in if/for/switch initializers. 
>
> ...Marvin 
>
>


does it sounds good to disable (in specs) named return vars shadowing ?
Djadala
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Windows vs Linux networking stack differences

[Konstantin Khomoutov]

On Wed, 22 Feb 2017 04:43:01 -0800 (PST)
Luke Mauldin  wrote:

> One of the things I love about Go is its ability to write code in one
> OS and easily cross-compile and deploy that code to another OS.  Can
> someone help me understand the differences in Windows vs Linux Go
> networking stack?  I know that at the top level they are both the
> same, just use net.Dial("tcp", ":8080), etc.. but I would like to
> know if there are underlying network stack differences in the Go
> standard library that will cause different performance
> characteristics between the two OSes?

IIUC, on both OSes, their native means of doing asynchronous I/O on
network sockets are used -- epoll on Linux and IOCPs on Windows.

Basically this means that performance differences on the same hardware
should be due to differences in the underlying OS implementations
and kernel defaults and/or their tuning.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Trying to understand := and named return values

[Marvin Renich]

On Tue, Feb 21, 2017 at 1:46 PM,   wrote:
> Seems like named returns + if/for/switch initializers = a shadowing
> nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> this is a dangerously subtle problem out there.

* Ian Lance Taylor [170221 16:13]:
> Yes, named returns may have been a mistake.  Only use them in very
> very short functions.

* John Souvestre  [170221 21:46]:
> I feel the opposite.  I view named returns as documentation of a
> function's parameters.  I'm constantly amazed by the (correct)
> emphasis placed on using appropriate names for calling parameters, but
> not for the return parameters.  The goal is that I shouldn't have to
> read a function's code to use the function, right?

I agree with the John and the others that named return variables are a
good feature.

The confusion is not because of the named returns, but because the :=
notation used with multiple variables on the left combines declaration
and simple assignment without allowing, much less requiring, the
programmer to explicitly identify which variables are being declared and
which are simply being assigned a new value.  This is relevant when :=
is used at the block scope as well as in if/for/switch initializers.

...Marvin

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Golang Messenger Bot frameworks

[Nyah Check]

Hi Gophers,

I a looking to participate in the Facebook Messenger Bot challenge. Looking
at the API. The recommended bot framework has no golang support. I don't
know if any one here knows any good Bot AI frameworks I could use.

Inverential Peace,
Nyah

-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Capital Golang conference

[Rajanikanth Jammalamadaka]

Hello Fellow Gophers,

Just wanted to let you know about this conference in the Washington DC metro 
area:

https://www.eventbrite.com/e/capital-go-language-conference-2017-tickets-32139266411?aff=es2

Thanks
Raj 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go Windows vs Linux networking stack differences

[Luke Mauldin]

One of the things I love about Go is its ability to write code in one OS 
and easily cross-compile and deploy that code to another OS.  Can someone 
help me understand the differences in Windows vs Linux Go networking 
stack?  I know that at the top level they are both the same, just use 
net.Dial("tcp", ":8080), etc.. but I would like to know if there are 
underlying network stack differences in the Go standard library that will 
cause different performance characteristics between the two OSes?

Luke Mauldin

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Syscall trouble with parameter handling

[snmed]

Hi Konstantin

Thanks a lot for your input. You were right about the second parameter and 
the call to ColInitalize, so now i'm a bit further but still get an error.
I will have a closer look on that error and hope i find a solution for it.

Cheers
snmed

Am Mittwoch, 22. Februar 2017 11:58:35 UTC+1 schrieb Konstantin Khomoutov:
>
> On Tue, 21 Feb 2017 22:55:18 -0800 (PST) 
> snmed > wrote: 
>
> > Has anyone a hint, what i'm doing wrong with the Call arguments? I 
> > think the last parameter is the problematic one, but i can't figure 
> > out how to pass that argument. 
>
> A couple of ideas: 
>
>   * [1] Features a comment by someone stating: 
>
> | The second parameter is not present in the latest API. 
> | 
> | The second parameter 
> | _In_  DWORDcoInit, 
> | is not present in the latest AMSI.dll. Use the below code if you are 
> | importing to C#. [DllImport("Amsi.dll", EntryPoint = "AmsiInitialize", 
> | CallingConvention = CallingConvention.StdCall)] public static extern 
> | int AmsiInitialize([MarshalAs(UnmanagedType.LPWStr)]string appName, 
> | out IntPtr amsiContext); 
> | 
> | Eler 
> | 12/6/2016 
>
> Which might mean you just need to drop the second 0 (coInit) and 
> make your pointer to context the second one. 
>
>   * An example presented at [2] clearly shows the code calls 
> CoInitialize() before attempting to initialize the AMSI library.  This 
> hints at that this library uses or is based on COM technology.  AFAIK, 
> to use anything COM-related in a thread, you first need to prepare that 
> thread for this -- by calling CoInitialize() or CoInitializeEx().  The 
> fact the second argument to AmsiInitialize() is called "coInit" hints 
> at that this might indeed be the cause. 
>
> Please note that since goroutines by default are multiplexed on any 
> number of OS threads, you will most probably need to call 
> runtime.LockOSThread() before doing anything with AMSI and make sure 
> all further calls to that lib are managed by that single goroutine -- 
> say, by making it serve calls on a channel. 
>
>   * I'm not sure how MustFindProc("AmsiInitialize") is defined to behave 
> with regard to "wide" vs "char" version of the API, so maybe -- for some 
> weird reason -- it manages to locate AmsiInitializeA(), and that one 
> gets confused with the wide character data you pass to it as its first 
> parameter?  Try explicitly requesting AmsiInitializeW() instead and see 
> whether that fixes the problem. 
>
> I'd say it's always a good idea to always refer to the API facet you 
> need explicitly (and these days you usually want FooW() in most cases). 
>
> 1. https://msdn.microsoft.com/en-us/library/windows/desktop/dn889862 
> (v=vs.85).aspx 
> 
>  
> 2. 
> https://social.msdn.microsoft.com/Forums/vstudio/zh-CN/28e6c37f-ac29-43e6-ba65-a7cbd23b6831/how-to-use-amsiinitialize-function-how-to-use-the-amsiantimalware-scan-interface?forum=visualcpluszhchs
>  
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Syscall trouble with parameter handling

[snmed]

Okay thanks anyway

Am Mittwoch, 22. Februar 2017 11:51:45 UTC+1 schrieb brainman:
>
> > Has anyone a hint, what i'm doing wrong with the Call arguments?
>
> I do not know. Sorry.
>
> > I think the last parameter is the problematic one, ...
>
> It looks fine to me.
>
> Alex
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Initializing nested struct, by dynamically forming struct member path

[C Banning]

Perhaps not very elegant but seems to produce what you're looking for: 
https://play.golang.org/p/bpM69Q-ddV 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Syscall trouble with parameter handling

[Konstantin Khomoutov]

On Tue, 21 Feb 2017 22:55:18 -0800 (PST)
snmed  wrote:

> Has anyone a hint, what i'm doing wrong with the Call arguments? I
> think the last parameter is the problematic one, but i can't figure
> out how to pass that argument.

A couple of ideas:

  * [1] Features a comment by someone stating:

| The second parameter is not present in the latest API.
|
| The second parameter 
| _In_  DWORDcoInit,
| is not present in the latest AMSI.dll. Use the below code if you are
| importing to C#. [DllImport("Amsi.dll", EntryPoint = "AmsiInitialize",
| CallingConvention = CallingConvention.StdCall)] public static extern
| int AmsiInitialize([MarshalAs(UnmanagedType.LPWStr)]string appName,
| out IntPtr amsiContext);
|
| Eler
| 12/6/2016

Which might mean you just need to drop the second 0 (coInit) and
make your pointer to context the second one.

  * An example presented at [2] clearly shows the code calls
CoInitialize() before attempting to initialize the AMSI library.  This
hints at that this library uses or is based on COM technology.  AFAIK,
to use anything COM-related in a thread, you first need to prepare that
thread for this -- by calling CoInitialize() or CoInitializeEx().  The
fact the second argument to AmsiInitialize() is called "coInit" hints
at that this might indeed be the cause.

Please note that since goroutines by default are multiplexed on any
number of OS threads, you will most probably need to call
runtime.LockOSThread() before doing anything with AMSI and make sure
all further calls to that lib are managed by that single goroutine --
say, by making it serve calls on a channel.

  * I'm not sure how MustFindProc("AmsiInitialize") is defined to behave
with regard to "wide" vs "char" version of the API, so maybe -- for some
weird reason -- it manages to locate AmsiInitializeA(), and that one
gets confused with the wide character data you pass to it as its first
parameter?  Try explicitly requesting AmsiInitializeW() instead and see
whether that fixes the problem.

I'd say it's always a good idea to always refer to the API facet you
need explicitly (and these days you usually want FooW() in most cases).

1. https://msdn.microsoft.com/en-us/library/windows/desktop/dn889862
(v=vs.85).aspx
2. 
https://social.msdn.microsoft.com/Forums/vstudio/zh-CN/28e6c37f-ac29-43e6-ba65-a7cbd23b6831/how-to-use-amsiinitialize-function-how-to-use-the-amsiantimalware-scan-interface?forum=visualcpluszhchs

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Syscall trouble with parameter handling

[brainman]

> Has anyone a hint, what i'm doing wrong with the Call arguments?

I do not know. Sorry.

> I think the last parameter is the problematic one, ...

It looks fine to me.

Alex

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Initializing nested struct, by dynamically forming struct member path

[Bharath B]

Hi,

Thanks for the response.

Below is the sample json being used,

{
   "jsondata": [
{
  "dataReference":[
  {
"parameterType" : "common",
"applicationtype":
{
  "application1": 
  {
"applicationName": "appl1",
"param1": 
{
  "name": "param1",
  "value": "test2",
  "Type": "text",
  "oper": "ADD"
}
  }
}
  }
  ]
}
]
}

>From my side I will populate the struct and provide it the application for 
consumption.

Regards,
Bharath B

On Tuesday, 21 February 2017 15:44:09 UTC+5:30, Nathan Kerr wrote:
>
> Could you give an example of the json you are starting from?
>
> Also, what database are you using?
>
> On Sunday, February 19, 2017 at 8:27:32 AM UTC+1, Bharath B wrote:
>>
>> Hi,
>>
>> I am trying to read those values and store in DB.
>>
>> Regards,
>> Bharath B
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.