[go-nuts] How to compare two network addresses (stringifyed or not) for equality?

['Константин Иванов' via golang-nuts]

Here is a code:

package main

import (
"fmt"
"log"
"net"
)

func main() {

l, err := net.Listen("tcp", "[::]:9090")
if err != nil {
log.Fatal(err)
}
defer l.Close()

go func() {
for {
l.Accept()
}
}()

c, err := net.Dial("tcp", "[::]:9090")
if err != nil {
log.Fatal(err)
}
defer c.Close()

fmt.Println(l.Addr().String())
fmt.Println(c.RemoteAddr().String())

fmt.Println(addrCmp(l.Addr().String(), c.RemoteAddr().String()))
}

func addrCmp(a, b string) bool {
if ahost, aport, err := net.SplitHostPort(a); err == nil {
if bhost, bport, err := net.SplitHostPort(b); err == nil {
if net.ParseIP(ahost).Equal(net.ParseIP(bhost)) {
return aport == bport
}
}
}
return false
}

Output is:

[::]:9090
[::1]:9090
false

Is there an easy way to compare two net.Addr or two strings that represents 
network addresses?

-- 
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: Confusing type rules

[xiiophen]

To answer the first point - the keyword is "*assignable*" here - an slice 
[]int{1,23} is not assignable to a slice []I where I is a type of int. 
See https://golang.org/ref/spec#Assignability 

( also golang treats slices as types in themselves 
ie https://golang.org/ref/spec#SliceType )

..However..

This or very similar has definitely been asked before (including by me I'm 
sure, maybe I should try to find the thread) - it does seem reasonable and 
useful - but it doesn't work (and may never)

 for example your suggestion would work very well with the whole fmt 
package - which often takes []interface as parameters, and then reflects on 
that array to find type .. however passing []int etc doesn't currently 
work, and requires an 'annoying' intermediate assign of each element to the 
interfacial struct.

Some links to previous discussions (of the more general case using 
[]interface{} as the receiving type)

https://groups.google.com/forum/#!topic/golang-nuts/0qWnorUuct8

and

https://groups.google.com/forum/#!topic/golang-nuts/yZqFmd7z82Y

had reasonable discussions - the second also points out that this is 
covered in the FAQ - maybe around 
here https://golang.org/doc/faq#convert_slice_of_interface


Personally I'd like to see this implemented too - it has good use.

-- 
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] Confusing type rules

[conrad via golang-nuts]

Hey nuts!

I ran into the following confusion 
today: https://play.golang.org/p/XH8wyj6IbT.

Consulting the golang spec, I think this is correct. `If the final argument 
is assignable to a slice type []T, it may be passed unchanged as the value 
for a ...T parameter if the argument is followed by  In this case no 
new slice is created.`, but I was definitely expecting the ... to act as 
though I'd typed out each element of the array.

Would it be reasonable to update the language to allow

func A (a... T) { }
b := make([]S)
A(b...)

if S is assignable to T (rather than the current rule, which is only if []S 
is assignable to []T)

Conrad

-- 
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] [Feedback] Create JSONSchema Validator

[santhosh . tekuri]

Hi,

https://github.com/santhosh-tekuri/jsonschema

I created JSONSchema Validator in GO.
It implements Draft4 and passes all tests including optional one in  
https://github.com/json-schema/JSON-Schema-Test-Suite

Looking for feedback.  Let me know if you find this useful.

Thanks
Santhosh Kumar Tekuri

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[Egon]

On Saturday, 3 June 2017 13:11:04 UTC+3, mhh...@gmail.com wrote:
>
> Hi,
>
> yes generics / not generics.
>
> That is, in what i proposed, only the consumer is enhanced, thus generics 
> are not required anymore on the declarer, except for this conv method, 
> indeed.
>
> also as the declarer can rely on more powerful tool on the consumer, 
> it needs to declare less to able more.
>
> That being said,
>
> Can you take a look to that, genericity less, it works
>
> https://gist.github.com/mh-cbon/2062efef48e246592bdb0665f0ab8547
>
> IMHO, its simple, it does what i need, it helps me to avoid obvious 
> gotchas,  after many attempt i feel satisfy, 
> please critic it.
>

I think this version is much clearer: https://play.golang.org/p/9DfxObeDj3 
:P
 

> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
> wrote:
>>
>> Generics enable more than just replacing loops. For example, they can 
>> enable libraries of generic algorithms to be used with any type of array. 
>> Here's an example:
>>
>> foo := GetArray()
>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>
>> That is simple to understand and in one line of code. Imagine the 
>> acrobatics (and lines of code) needed to do this using Go's loops!
>>
>> You can read my full article on why Go needs generics here: 
>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>
>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:
>>>
>>> Since everyone thinks it but nobody bothers to reply to it: this whole 
>>> thing you propose can be currently done with a for loop, which not only is 
>>> explicit about what it doing, but it also lets you control if you want to 
>>> exit early from it and so on. Complicating the whole language because 
>>> something is cool (yet looks like a really complex thing that you need to 
>>> think about while reading the code) is in no one's benefit. Stop trying to 
>>> avoid a couple of extra rows of for {} (where the third row is literally 
>>> just an "}")  and start embracing the fact that you can understand the code 
>>> by looking at it and not apply any complex mental acrobatics to figure out 
>>> what those three lines of code are doing. Your future self/person after you 
>>> will thank you for that. 
>>
>>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

for the fun, with early return,

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

On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote:
>
> > Generics enable more than just replacing loops. For example, they can 
> enable libraries of generic algorithms to be used with any type of array. 
> Here's an example:
>
> in my demonstration every type got this kind of method,
> the problem become how do you jump from Type A to type B.
> in []A to []B or A -> B
>
> indeed it works on the item level, no more on the collections.
>
> This question is solved in two ways,
> - interface definitions (not interface value)
> - static conversion, which always resumes to 
> func(in-type) out-type
>
> and some alternatives for convenience (producer/consumer)
> func (func(in-type) out-type
> func (in-type) func() out-type
> func (func(in-type) func() out-type
> // this is unfinished explanation it should include error management to be 
> handled more completely. see please previous conv() fn introduced earlier 
> to statically re decorate a func signature.
>
> So far the sum/reduce things operation,
> i left them as exercise to the stream declarer
> and did not consider them as core.
> Take become => filter (func(10 elements))
> Map is map
> Sort is All(fn sorter) []out
> Reduce is a map operation, preceded by a conv if it reduces to a different 
> type.
>
>
> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
> wrote:
>>
>> Generics enable more than just replacing loops. For example, they can 
>> enable libraries of generic algorithms to be used with any type of array. 
>> Here's an example:
>>
>> foo := GetArray()
>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>
>> That is simple to understand and in one line of code. Imagine the 
>> acrobatics (and lines of code) needed to do this using Go's loops!
>>
>> You can read my full article on why Go needs generics here: 
>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>
>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:
>>>
>>> Since everyone thinks it but nobody bothers to reply to it: this whole 
>>> thing you propose can be currently done with a for loop, which not only is 
>>> explicit about what it doing, but it also lets you control if you want to 
>>> exit early from it and so on. Complicating the whole language because 
>>> something is cool (yet looks like a really complex thing that you need to 
>>> think about while reading the code) is in no one's benefit. Stop trying to 
>>> avoid a couple of extra rows of for {} (where the third row is literally 
>>> just an "}")  and start embracing the fact that you can understand the code 
>>> by looking at it and not apply any complex mental acrobatics to figure out 
>>> what those three lines of code are doing. Your future self/person after you 
>>> will thank you for that. 
>>
>>

-- 
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] gob's interpreted machine

[Santhosh Ram Manohar]

>From https://blog.golang.org/gobs-of-data

"The first time you encode a value of a given type, the gob package builds 
a little interpreted machine specific to that data type. It uses reflection 
on the type to construct that machine, but once the machine is built it 
does not depend on reflection."

Is there any detailed info on how this interpreted machine is built and 
used ?

thanks,
Santhosh.

-- 
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] CGO & Plugins

[Nick Groenen]

On 2017-06-02  19:24:40, Michael Brown wrote:

Do you have any references on the stability of the current plugin system
that I can use for reference? I'm building a system now that I contemplate
using with some plugins and I'd like to know up front the challenges.


I wrote a blogpost on plugins earlier this year. The "caveats" section
has some remarks and references you might find interesting in this
context.

You can find it at
https://nick.groenen.me/posts/2017/01/09/plugins-in-go-18/

--
Nick Groenen
https://nick.groenen.me/

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


signature.asc
Description: PGP signature

[go-nuts] Re: Golang, SQL and ORM avoidance techniques

[silviucapota]

Hi Adam,

Back in 2014 I had the same driving motives like you and I ended up writing 
my own generator for Postgres (to deal with tables, views, and functions, 
for the basic types):

https://github.com/silviucm/pgtogogen
https://www.cmscomputing.com/articles/programming/generate-go-entities-from-postgres-tables-views

It served me well over the past 3-4 years, particularly because I tend to 
rely a lot on materialized views, that I can refresh via (generated) Go 
code for complex queries.

If you start your own project, I can tell you it's a large undertaking and 
will probably end up a work in progress over months and years. 
When mapping database object you will find that some of the code may not 
feel idiomatic Go, so you will need to use your judgment whether it's 
appropriate for you individually or for a larger team, where the least 
common denominator is more important than generated patterns.

Cheers,
Silviu


On Friday, 2 June 2017 08:55:12 UTC-4, brylant wrote:
>
>
> I've been trying hard (well.. as much as I can considering my lack of 
> in-depth go knowledge or - to be perfectly honest - lack of in-depth 
> knowledge of anything) to find suitable go+sql technique that would not 
> require a lot of code repetition, not use reflection and not use ORMs of 
> any sort... Could somebody please tell me if there's anything particularly 
> wrong with the following:
>
>
> type ScannerFunc func() []interface{}
>
> func (db *DB) ScanSome(stmt string, sf ScannerFunc, params ...interface{}) 
> error {
>  rows, err := db.Query(stmt, params...)
>  if err != nil {
>  return err
>  }
>  defer rows.Close()
>  for rows.Next() {
>  err = rows.Scan(sf()...)
>  if err != nil {
>  return err
>  }
>  }
>  if err = rows.Err(); err != nil {
>  return err
>  }
>  return nil
> }
>
> Having the above I could then implement the following for each of my 
> 'models' (User being an example below). This could easily be 'go 
> generate'-d for each model
>
>
> type User struct {
> UserID  int64
> Namestring
> Roleint
> // (...)
> }
>
> func ScanUsersFunc(users *[]*User) ScannerFunc {
> return ScannerFunc(func() []interface{}) {
> u := User{}
> *users = append(*users, )
> var r []interface{} = []interface{}{, , , 
> (more 
> properties)}
> return r
> }
> }
>
>
> and finally use it like this: 
>
>
> const (
> sqlUsersByRole = "SELECT user_id,name,role, (more if needed) FROM 
> user WHERE role=?"
> sqlAllUsers= "SELECT user_id,name,role FROM user"
> )
>
> func (db *DB) UsersByRole(role int) ([]*User, error) {
> users := make([]*User, 0)
> err := db.ScanSome(sqlUsersByRole, ScanUsersFunc(), role)
> if err != nil {
> return nil, err
> }
> return users, nil
> }
>
> func (db *DB) AllUsers() ([]*User, error) {
> users := make([]*User, 0)
> err := db.ScanSome(sqlAllUsers, ScanUsersFunc())
> if err != nil {
> return nil, err
> }
> return users, nil
> }
>
>
> Alternatively (to avoid scanning/returning all results) a callback could 
> be provided to ScanSome and called after each scan.
>
> Obviously I could also implement ScanOne for situations where I only 
> expect one row of results...
>
>
> So - any obvious issues with the above 'technique'...?
>
>
> Thanks,
>
> adam
>
>
>
>

-- 
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] [ERROR] invalid argument when executing bufio.NewWriter.Flush()

[Harry]

Thanks Jan!

You are great!

On Saturday, 3 June 2017 13:00:51 UTC+2, Jan Mercl wrote:
>
> On Sat, Jun 3, 2017 at 12:42 PM Harry  
> wrote:
>
> > How can I handle to write something out using bufio.NewWriter?
>
> Just fine. The problem is you haven't created any file to write to in the 
> first place, which checking the error could have told you.
>
> -- 
>
> -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.

Re: [go-nuts] [ERROR] invalid argument when executing bufio.NewWriter.Flush()

[Jan Mercl]

On Sat, Jun 3, 2017 at 12:42 PM Harry  wrote:

> How can I handle to write something out using bufio.NewWriter?

Just fine. The problem is you haven't created any file to write to in the
first place, which checking the error could have told you.

-- 

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

[go-nuts] [ERROR] invalid argument when executing bufio.NewWriter.Flush()

[Harry]

Hi guys,

How can I handle to write something out using bufio.NewWriter?

My code is like below,

var writer *bufio.Writer
var err error
file, _ := os.OpenFile(*fileName, os.O_WRONLY | os.O_APPEND, 0644)
defer file.Close()

writer = bufio.NewWriter(file)

writer.WriteString(strings.Join("something\n")

err = writer.Flush()
if err != nil {
//invalid argument
log.Fatal(err)
}


What is wrong?


Thanks guys!!

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

> Generics enable more than just replacing loops. For example, they can 
enable libraries of generic algorithms to be used with any type of array. 
Here's an example:

in my demonstration every type got this kind of method,
the problem become how do you jump from Type A to type B.
in []A to []B or A -> B

indeed it works on the item level, no more on the collections.

This question is solved in two ways,
- interface definitions (not interface value)
- static conversion, which always resumes to 
func(in-type) out-type

and some alternatives for convenience (producer/consumer)
func (func(in-type) out-type
func (in-type) func() out-type
func (func(in-type) func() out-type
// this is unfinished explanation it should include error management to be 
handled more completely. see please previous conv() fn introduced earlier 
to statically re decorate a func signature.

So far the sum/reduce things operation,
i left them as exercise to the stream declarer
and did not consider them as core.
Take become => filter (func(10 elements))
Map is map
Sort is All(fn sorter) []out
Reduce is a map operation, preceded by a conv if it reduces to a different 
type.


On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
wrote:
>
> Generics enable more than just replacing loops. For example, they can 
> enable libraries of generic algorithms to be used with any type of array. 
> Here's an example:
>
> foo := GetArray()
> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>
> That is simple to understand and in one line of code. Imagine the 
> acrobatics (and lines of code) needed to do this using Go's loops!
>
> You can read my full article on why Go needs generics here: 
> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>
> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:
>>
>> Since everyone thinks it but nobody bothers to reply to it: this whole 
>> thing you propose can be currently done with a for loop, which not only is 
>> explicit about what it doing, but it also lets you control if you want to 
>> exit early from it and so on. Complicating the whole language because 
>> something is cool (yet looks like a really complex thing that you need to 
>> think about while reading the code) is in no one's benefit. Stop trying to 
>> avoid a couple of extra rows of for {} (where the third row is literally 
>> just an "}")  and start embracing the fact that you can understand the code 
>> by looking at it and not apply any complex mental acrobatics to figure out 
>> what those three lines of code are doing. Your future self/person after you 
>> will thank you for that. 
>
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

yes true.

I m not sure i intend to change that asap, 
but this another topic,
i want not deep into right now.

That being said again agreed, understood, prone to happen, maybe.

On Friday, June 2, 2017 at 12:05:52 PM UTC+2, Egon wrote:
>
> On Friday, 2 June 2017 12:06:54 UTC+3, mhh...@gmail.com wrote:
>>
>> Sorry for this crime of thought, i was thinking it was a chance to talk 
>> about it and explore different paths.
>> That, this, is the only answer, well, life is hard.
>>
>
> Thinking and discussion is helpful, but I think the format here could be 
> improved.
>
> The problem in this thread is that these comments are "random thoughts" 
> instead of "organized thoughts" about different aspects, without 
> referencing any prior art.
>
> Organizing these thoughts and points works for these things much, much 
> better. Even better is a article / blog-post for something bigger.
>
> E.g. I would consider this form:
>
> 1. real-world problem (no "animal" or "bunny" examples)
> 1.1. where it exists
> 1.2. how frequent
> 2. Current solutions
> 2.1. current solution 1 (pros/cons)
> 2.2. current solution 2 (pros/cons)
> 2.3. current solution 3 (pros/cons)
> 3. Alternative approaches
> 3.1 alternative approach 1 (pros/cons/prior-art)
> 3.2 alternative approach 2 (pros/cons/prior-art)
> 3.3 alternative approach 3 (pros/cons/prior-art)
> 4. Comparison between solutions.
> 5. Cost / benefit discussion.
>
> *Each of these around 1-3 paragraphs.*
>
> This has a good basis for a good discussion, whereas random thoughts often 
> don't. Also there's always room for a middle-ground.
>
> Thinking aloud and random thoughts work somewhat in chats, but often 
> doesn't end-up in something tangible that can be used later on.
>
> + Egon
>
>
>> Just for the records, i did stop thinking like that when i started 
>> golang, its not like you are given the choice.
>>
>> Psst ... I must ask you about the address of the shop where you bought 
>> this wonderful magical crystal bowl you use to read in the future.
>> I kind of fail to find one for my current self.
>> thanks ;)
>>
>> On Friday, June 2, 2017 at 10:17:54 AM UTC+2, Florin Pățan wrote:
>>>
>>> Since everyone thinks it but nobody bothers to reply to it: this whole 
>>> thing you propose can be currently done with a for loop, which not only is 
>>> explicit about what it doing, but it also lets you control if you want to 
>>> exit early from it and so on. Complicating the whole language because 
>>> something is cool (yet looks like a really complex thing that you need to 
>>> think about while reading the code) is in no one's benefit. Stop trying to 
>>> avoid a couple of extra rows of for {} (where the third row is literally 
>>> just an "}")  and start embracing the fact that you can understand the code 
>>> by looking at it and not apply any complex mental acrobatics to figure out 
>>> what those three lines of code are doing. Your future self/person after you 
>>> will thank you for that. 
>>
>>

-- 
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] CGO & Plugins

[Cristian Măgherușan-Stanciu]

The best real world example I know of mixing cgo and plugins is 
https://github.com/eawsy/aws-lambda-go-shim and it works pretty well.

It compiles a go program as a native library using cgo, which is loading some 
more golang code compiled as a plugin.

The native library also happens to implement the Python module binary interface 
so eventually golang code can be called by the Python AWS Lambda runtime, but 
it should work with any other Python program.

-- 
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] filago: Monitor a Linux process' opening and closing of files, including Unix pipes and sockets

[Dave Cheney]

fuser(1) will tell you for a file

netstat(1) -anp will do for sockets 

-- 
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] filago: Monitor a Linux process' opening and closing of files, including Unix pipes and sockets

[ChrisLu]

Thanks! This should be very useful.

Sometimes I want to know the inverted answer that which process is using a port 
or a file. 

-- 
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] Copy map with empty interfaces

[Tamás Gulácsi]

How is cgo involved here? What kind of keys are you using?

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