Re: [go-nuts] Gollvm failed to build hugo

[Yuan Ting]

Thanks for direction,

I think the root cause of this issue is exactly the same in #38728 but I 
afraid the patch in #38728 only fix the building of gollvm (i.e. add 
-fcd-branch=none to the build flags). In the above case, gollvm uses 
/usr/bin/cc to compile gccgo_c.o during the building of hugo without 
-fcd-branch=none and finally fails in linking time. So I guess we need also 
add this flag in somewhere gollvm calling /usr/bin/cc. This is only needed 
for newer linux distributions, I can't reproduce it in ubuntu 18.04.

Thanks, Ting

On Monday, August 10, 2020 at 9:30:45 PM UTC+8, Than McIntosh wrote:
>
> Hello,
>
> >># github.com/gohugoio/hugo
> >>/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
> split-stack sequence at section 1 offset 0
>
> This issue is https://github.com/golang/go/issues/38728, which should be 
> fixed at this point at tip. 
>
> Thanks, Than
>
>
> On Mon, Jul 20, 2020 at 2:33 PM Ian Lance Taylor  > wrote:
>
>> [ + thanm, cherryyz ]
>>
>> On Mon, Jul 20, 2020 at 4:24 AM Yuan Ting > > wrote:
>> >
>> > Hi, I try to build hugo with fresh gollvm but the linker complains that:
>> >
>> > # github.com/gohugoio/hugo
>> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
>> split-stack sequence at section 1 offset 0
>> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
>> split-stack sequence at section 1 offset a6
>> >
>> > To reproduce:
>> >
>> > git clone https://github.com/gohugoio/hugo.git
>> > cd hugo && go build
>> >
>> > Platform: x86_64 ubuntu:20.04
>> > Gollvm build flags:
>> > cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 
>> -DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G 
>> Ninja
>> >
>> > --
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to golan...@googlegroups.com .
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/d722a1e8-d205-4c9e-8ae4-623c19dd2946o%40googlegroups.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/263c45b3-597a-4cbb-878c-5d199defd6f7o%40googlegroups.com.

Re: [go-nuts] Generics: after type lists

[Patrick Smith]

On Mon, Aug 10, 2020 at 1:53 PM burak serdar  wrote:
> Would it be possible to make it explicit instead of trying to combine
> builtin types and others?
>
> type Number interface {
>type int, int8, int16, int32, int64, unit, int8, int16, int32,
> uint64, float32, float64
> }
>
> func Min(type T Number)(a, b, T) {
...
> }
>
> type Lessable interface {
>func LessThan(interface{}) bool
> }
>
> func Min(type T Lessable(T))(a, b T) {
...
> }
>
> This would be similar to c++ template specialization. Specializations
> could be limited to built-in types to limit ambiguity.
>
> }

There are two problems with this. First, it would require either a
concept of "this or that" in interfaces, or duplicating all code that
calls Min, however indirectly. This or that:

type NumberOrLessable interface {
// Satisfied by any type that satisfies either Number or Lessable
Number | Lessable
}

func [type T NumberOrLessable](a, b, c T) T {
return Min(a, Min(b, c))
}

Or code duplication based on the interface that T satisfies:

func [type T Number](a, b, c T) T {
return Min(a, Min(b, c))
}

func [type T Lessable](a, b, c T) T {
return Min(a, Min(b, c))
}

Second, Ian has long indicated strong opposition to specialization, as
I think have others.

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

Re: [go-nuts] Generics: after type lists

[Patrick Smith]

On Mon, Aug 10, 2020 at 9:46 AM 'Richard Oudkerk' via golang-nuts
 wrote:
> Another way to bridge the gap between builtin and custom types could be to 
> have a package op that has functions that delegate to either an operator or a 
> method.  Then you could write generic functions like
>
> func Min[type T op.Lessable](a, b T) T {
>   if op.Less(a, b) {
> return b
>   }
>   return a
> }
...

Indeed, and quite a while ago I sketched out a proposal along those
lines: https://gist.github.com/pat42smith/ed63aca983d4ba14fdfa320296211f40
. There was very little
reaction to that proposal.

> I don't think op.Lessable is expressible with the latest proposal though.

Also true, so this almost certainly won't fly.

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

Re: [go-nuts] Generics: after type lists

[burak serdar]

On Mon, Aug 10, 2020 at 10:46 AM 'Richard Oudkerk' via golang-nuts
 wrote:
>
> Another way to bridge the gap between builtin and custom types could be to 
> have a package op that has functions that delegate to either an operator or a 
> method.  Then you could write generic functions like
>
> func Min[type T op.Lessable](a, b T) T {
>   if op.Less(a, b) {
> return b
>   }
>   return a
> }


Would it be possible to make it explicit instead of trying to combine
builtin types and others?

type Number interface {
   type int, int8, int16, int32, int64, unit, int8, int16, int32,
uint64, float32, float64
}

func Min(type T Number)(a, b, T) {
  if a
> For each function Foo in op, op.Foo(a, ...) would delegate to either 
> a.Foo(...) or to a builtin operator, and there would be an associated 
> interface op.Fooable. For example
>
> op.Add(a, b) is equivalent to a.Add(b) or a + b
> op.Len(a) is equivalent to a.Len() or len(a)
> op.Get(a, i) is equivalent to a.Get(i) or a[i]
> op.Range(a, f) is equivalent to a.Range(f) or for k, v := range a { f(k, v) }
>
> I don't think op.Lessable is expressible with the latest proposal though.
> On Monday, 10 August 2020 at 02:29:53 UTC+1 Ian Lance Taylor wrote:
>>
>> On Fri, Aug 7, 2020 at 4:33 PM Patrick Smith  wrote:
>> >
>> > I like the second draft for generics. It seems to me a large
>> > simplification and improvement over the first draft. Considering just
>> > the state of Go today, I would be quite happy with this, even if it's
>> > not perfect. Thanks to Ian, Robert, and everyone else for their work
>> > on this.
>> >
>> > Also, I would vote for square brackets over parentheses.
>> >
>> > But I do have concerns related to the future development of Go. In
>> > particular, if we think it likely that a future version of Go will
>> > allow operator overloading, then perhaps type lists are not the best
>> > choice.
>> >
>> > To my mind, the biggest defect in the design draft is that we can't
>> > write generic functions and types that work transparently with both
>> > builtin and user-defined types (that do not inherit appropriate
>> > behavior from an underlying builtin type). For example, we can't write
>> > a
>> >
>> > func Min[type T ...](a, b T) T { ... }
>> >
>> > that works both when T is int and when T is
>> >
>> > type BigInt struct { i *big.Int }
>> >
>> > Instead, we would use workarounds such as writing two versions of Min,
>> > or passing in an adaptor function or object; in the case of Min, a
>> > comparison function. And that's OK, especially in an initial version
>> > of generics.
>> >
>> > But generics would be significantly easier to use if we could write
>> > functions that work on both builtin and user-defined types. The two
>> > most likely candidates for allowing this seem to be operator
>> > overloading (where BigInt might have a method named "<", "operator<",
>> > or some such, that allows it to be used with the < operator) and
>> > methods on builtin types (where int might be given a method named Less
>> > with the same behavior as the < operator). Of course, other solutions
>> > could be imagined, but I'll confine my speculations to those two.
>> >
>> > Now let's try to imagine how sorting slices might be implemented in
>> > the standard library in various futures. Of course, the current sort
>> > package would have to be kept and maintained for a long time.
>> >
>> > If Go2 implements the current draft with type lists, then we might add
>> > a sort2 package containing something to:
>> >
>> > func SliceBy[type T](s []T, less(T, T) bool) { ... }
>> >
>> > type Ordered interface { // Copied from the draft
>> > type int, int8, int16, int32, int64,
>> > uint, uint8, uint16, uint32, uint64, uintptr,
>> > float32, float64,
>> > string
>> > }
>> >
>> > func Slice(type T Ordered)(s []T) {
>> > SliceBy(s, func(a, b T) bool { return a < b })
>> > }
>> >
>> > type Lesser[type T] interface { Less(T) bool }
>> >
>> > func SliceByLess(type T Lesser[T])(s []T) {
>> > SliceBy(s, T.Less)
>> > }
>> >
>> > All well and good. Now say time goes by and Go3 adds operator methods.
>> > Nothing in the sort2 package expresses a unified sort using operator
>> > methods, so we need a new package sort3:
>> >
>> > func SliceBy[type T](s []T, less(T, T) bool) { ... }
>> >
>> > type Lesser[type T] interface { <(T) bool } // Or whatever the syntax is.
>> >
>> > func Slice(type T Lesser)(s []T) {
>> > SliceBy(s, func(a, b T) bool { return a < b })
>> > }
>> >
>> > (We might just add sort3.Lesser and sort3.Slice into the sort2 package
>> > under different names, but I suspect the aim would be to eventually
>> > deprecate sort2.)
>> >
>> > The effects will ripple through other code, both in and outside the
>> > standard library. Suppose some Go2 code has a chain of generic
>> > functions A calls B calls C calls D, where each exists in two
>> > versions, one for builtin types and one for user-defined types, and
>> > the two versions of D call sort2.Slice or sort2.SliceByLess. When

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

[Ivan Ivanyuk]

Ok, thanks for the clarification.

On Mon, Aug 10, 2020 at 9:38 PM Ian Lance Taylor  wrote:

> On Mon, Aug 10, 2020 at 1:30 AM Ivan Ivanyuk 
> wrote:
> >
> > Thank you for answering
> >
> > Why does it take so long to implement generics then? There is already an
> instrument in playground that works fine. Why not just roll it out and
> improve design, if needed, in next version?
> >
> > Having generics in 2021 means many projects will choose other languages
> in 2020, which will effectively mean 1 year of work in other language
>
> Besides what other people have said, we believe, rightly or wrongly,
> that language stability and backward compatibility are important
> features for Go programmers.  We don't want to roll out a version of
> generics that we then have to change in some incompatible way.  That
> would force people to rewrite programs over time, which is painful,
> and will decrease people's perception of Go as a stable and reliable
> language.
>
> Ian
>
>
>
> > On Mon, Aug 10, 2020, 04:13 Ian Lance Taylor  wrote:
> >>
> >> On Sat, Aug 8, 2020 at 7:51 PM  wrote:
> >> >
> >> > Add support of optional syntax_version to file beginning, allow
> compiler to tokenize/compile file by the compiler of syntax_version, using
> any number of syntax_version-s in same project
> >> >
> >> > Why? Because go takes ridiculously long to implement generics, and
> implementation is very likely to not be perfect or to become not perfect
> when world changes. Having support of several syntaxes/compilers in same
> project will allow to adapt syntax faster
> >>
> >> We already support something like this on a per-module basis via the
> >> "go" line in a go.mod file
> >> (https://golang.org/cmd/go/#hdr-The_go_mod_file).  See also
> >>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
> >> .
> >>
> >> Ian
>

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

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

[Ian Lance Taylor]

On Mon, Aug 10, 2020 at 1:30 AM Ivan Ivanyuk  wrote:
>
> Thank you for answering
>
> Why does it take so long to implement generics then? There is already an 
> instrument in playground that works fine. Why not just roll it out and 
> improve design, if needed, in next version?
>
> Having generics in 2021 means many projects will choose other languages in 
> 2020, which will effectively mean 1 year of work in other language

Besides what other people have said, we believe, rightly or wrongly,
that language stability and backward compatibility are important
features for Go programmers.  We don't want to roll out a version of
generics that we then have to change in some incompatible way.  That
would force people to rewrite programs over time, which is painful,
and will decrease people's perception of Go as a stable and reliable
language.

Ian



> On Mon, Aug 10, 2020, 04:13 Ian Lance Taylor  wrote:
>>
>> On Sat, Aug 8, 2020 at 7:51 PM  wrote:
>> >
>> > Add support of optional syntax_version to file beginning, allow compiler 
>> > to tokenize/compile file by the compiler of syntax_version, using any 
>> > number of syntax_version-s in same project
>> >
>> > Why? Because go takes ridiculously long to implement generics, and 
>> > implementation is very likely to not be perfect or to become not perfect 
>> > when world changes. Having support of several syntaxes/compilers in same 
>> > project will allow to adapt syntax faster
>>
>> We already support something like this on a per-module basis via the
>> "go" line in a go.mod file
>> (https://golang.org/cmd/go/#hdr-The_go_mod_file).  See also
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
>> .
>>
>> Ian

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

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Ian Lance Taylor]

On Mon, Aug 10, 2020 at 6:07 AM Markus Heukelom
 wrote:
>
> For what it is worth: for non-exported functions/types all operations could 
> be allowed, possibly leading to infamous C++-level error messages but as you 
> are the author of the package, those error messages would make sense to you 
> anyway.
>
> For example, I could really use to be able to write things like this:
>
> func sibling[type t](node *t) *t {
> if node.parent == nil {
> return nil
> }
> if node.parent.left == node {
> return node.parent.right
>   }
>   return node.parent.left
> }
>
> This is not really possible with the current design. Of course I could 
> specify an interface with getters/setters, but that feels a bit silly and 
> cumbersome as everything is local to the package anyway.
>
> I don't have better a solution, but all contracts/constraints do is prevent 
> long, unreadable error messages while inside a package there's no real 
> problem with those error messages to begin with.

Go is a strictly typed languages, and constraints are the meta-types
of type parameters.  You are suggesting that we should have an escape
hatch for that meta-type system when using unexported types.  I
suppose that is possible.  It seems like something we could add later
if it brings a big benefit.

I'm not sure when your example would really arise.  It looks like you
have a tree type; why not make that a parameterized type and make
sibling a method on the type?

Ian

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

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

[Ian Lance Taylor]

On Mon, Aug 10, 2020 at 7:08 AM Markus Heukelom
 wrote:
>
> Just a quick thought, instead of "comparable" (and type lists) maybe we could 
> use a single operator to specify the required "operators" interface:
>
> type BiMap[type V, K ==] struct {
> forward map[K]V
> reverse map[V]K
> }
>
> func Max[type T <](a, b T) T {
>
> }
>
> func ScanRowStruct[type T .](rows sql.Rows, dest *T) error {  // operator . 
> ensures T is a struct
>
> }

It could probably work, but we wind up with a bunch of special purpose
syntax with only a tenuous connection to the way constraints work in
general.  And you have to define connections between operators.  That
is, comparable supports both == and !=, but you only mentioned ==;
does == imply !=?

Ian

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

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

[Ian Lance Taylor]

On Mon, Aug 10, 2020 at 7:08 AM Alvadron  wrote:
>
> The type of map keys in Go should be comparable. As you haven't specified any 
> restriction to the type parameters, it doesn't compile because Go doesn't 
> know whether K and V are comparable.
>
> If you add the restriction  "comparable", then it compiles:
>
> type BiMap[type V, K comparable] struct {
> forward map[K]V
> reverse map[V]K
> }
>
> PD: It is true that the error could be more informative. Right now we get:
>
> type checking failed for main
> prog.go2:13:14: invalid map key type K
> prog.go2:14:14: invalid map key type V
>
> Not sure if it is possible but, ideally, the message should say something 
> like "Invalid mp key type K: it is not comparable"

Getting a better error message is https://golang.org/issue/40551.

Ian

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

Re: [go-nuts] Generics: after type lists

['Richard Oudkerk' via golang-nuts]

Another way to bridge the gap between builtin and custom types could be to 
have a package op that has functions that delegate to either an operator or 
a method.  Then you could write generic functions like

func Min[type T op.Lessable](a, b T) T {
  if op.Less(a, b) {
return b
  }
  return a
}

For each function Foo in op, op.Foo(a, ...) would delegate to either 
a.Foo(...) or to a builtin operator, and there would be an associated 
interface op.Fooable. For example

   - op.Add(a, b) is equivalent to a.Add(b) or a + b
   - op.Len(a) is equivalent to a.Len() or len(a)
   - op.Get(a, i) is equivalent to a.Get(i) or a[i]
   - op.Range(a, f) is equivalent to a.Range(f) or for k, v := range a { 
   f(k, v) }

I don't think op.Lessable is expressible with the latest proposal though.
On Monday, 10 August 2020 at 02:29:53 UTC+1 Ian Lance Taylor wrote:

> On Fri, Aug 7, 2020 at 4:33 PM Patrick Smith  wrote:
> >
> > I like the second draft for generics. It seems to me a large
> > simplification and improvement over the first draft. Considering just
> > the state of Go today, I would be quite happy with this, even if it's
> > not perfect. Thanks to Ian, Robert, and everyone else for their work
> > on this.
> >
> > Also, I would vote for square brackets over parentheses.
> >
> > But I do have concerns related to the future development of Go. In
> > particular, if we think it likely that a future version of Go will
> > allow operator overloading, then perhaps type lists are not the best
> > choice.
> >
> > To my mind, the biggest defect in the design draft is that we can't
> > write generic functions and types that work transparently with both
> > builtin and user-defined types (that do not inherit appropriate
> > behavior from an underlying builtin type). For example, we can't write
> > a
> >
> > func Min[type T ...](a, b T) T { ... }
> >
> > that works both when T is int and when T is
> >
> > type BigInt struct { i *big.Int }
> >
> > Instead, we would use workarounds such as writing two versions of Min,
> > or passing in an adaptor function or object; in the case of Min, a
> > comparison function. And that's OK, especially in an initial version
> > of generics.
> >
> > But generics would be significantly easier to use if we could write
> > functions that work on both builtin and user-defined types. The two
> > most likely candidates for allowing this seem to be operator
> > overloading (where BigInt might have a method named "<", "operator<",
> > or some such, that allows it to be used with the < operator) and
> > methods on builtin types (where int might be given a method named Less
> > with the same behavior as the < operator). Of course, other solutions
> > could be imagined, but I'll confine my speculations to those two.
> >
> > Now let's try to imagine how sorting slices might be implemented in
> > the standard library in various futures. Of course, the current sort
> > package would have to be kept and maintained for a long time.
> >
> > If Go2 implements the current draft with type lists, then we might add
> > a sort2 package containing something to:
> >
> > func SliceBy[type T](s []T, less(T, T) bool) { ... }
> >
> > type Ordered interface { // Copied from the draft
> > type int, int8, int16, int32, int64,
> > uint, uint8, uint16, uint32, uint64, uintptr,
> > float32, float64,
> > string
> > }
> >
> > func Slice(type T Ordered)(s []T) {
> > SliceBy(s, func(a, b T) bool { return a < b })
> > }
> >
> > type Lesser[type T] interface { Less(T) bool }
> >
> > func SliceByLess(type T Lesser[T])(s []T) {
> > SliceBy(s, T.Less)
> > }
> >
> > All well and good. Now say time goes by and Go3 adds operator methods.
> > Nothing in the sort2 package expresses a unified sort using operator
> > methods, so we need a new package sort3:
> >
> > func SliceBy[type T](s []T, less(T, T) bool) { ... }
> >
> > type Lesser[type T] interface { <(T) bool } // Or whatever the syntax is.
> >
> > func Slice(type T Lesser)(s []T) {
> > SliceBy(s, func(a, b T) bool { return a < b })
> > }
> >
> > (We might just add sort3.Lesser and sort3.Slice into the sort2 package
> > under different names, but I suspect the aim would be to eventually
> > deprecate sort2.)
> >
> > The effects will ripple through other code, both in and outside the
> > standard library. Suppose some Go2 code has a chain of generic
> > functions A calls B calls C calls D, where each exists in two
> > versions, one for builtin types and one for user-defined types, and
> > the two versions of D call sort2.Slice or sort2.SliceByLess. When Go3
> > with operator methods arrives, if we want to unify these, we have to
> > write a third version of each of A, B, C, and D, where D calls
> > sort3.Slice.
> >
> > On the other hand, suppose Go2 has type lists and Go3 gives builtin
> > types methods corresponding to operators. Assuming the name Less is
> > used for <, sort2.SliceByLess now handles both builtin and
> > user-defined types, so we don't need a sort3 package. And in th

Re: [go-nuts] Generics and parentheses

[Edwin S]

I am trying to add my 2 cents here.


I am sorry if my opinions have been mentioned.

I personally prefer Round Brackets (parentheses). It is not about 
readability on symbols, but the way how I understand the logic of Type 
Parameters.



I see Type Parameters as a way to describe how to "instantiated" a 
Declaration (Func/Struct) for being used.

Considering the case of https://go2goplay.golang.org/p/JjA67w8ZvFu , the 
func `min` is asking for a `type` argument to be specified so it can work 
properly. Which means it is valid to code line L19 `m := min(int)` to 
initialize the func `min` with type `int`. 

If we try to read a Type Parameterized func declared in this way, it means 
the func `min` will first take a `type` argument to initialize it. then the 
second Round Brackets `(...)` put the arguments to call the func. 

However with Square Bracket, L19 of the case will not work, cause `m := 
min[int]` would mean taking an element from `min` on index `int`. (sure, 
min here is a Type Parameterized Func, not a slice)



On the other hand, we can take an analogy of how Functional Programming 
(FP) works with funcs with multi parameters. (correct me if I am wrong). 

In FP, when a function take two arguments, say `f(a int, b string)`, it's 
actually interpreted as "A function called `f`, it will first take an 
argument `a` with type `int`, and return a function f2 which keep a copy of 
`a` and takes an argument `b` with type `string`". 

An example in Go is following:

```go
func concat(a int, b string) string {}
```

is equal to

```go
func concat(a int) (func( b string) string){
return func(b string) {
a := a
// DO THE ACTUAL WORK
return
}
}

and when calling `concat()` with `concat(1, "2")`, is actually 
`concat(1)(2)` or `tmp := concat(1); result := tmp(2)`


Taking this analogy back to the original Type Parameters proposal. We can 
think of a Type Parameterized func has to be called with a `type` being 
specified. The Type Parameterized func will return a typed version of it. 
Then we call it with the actual argument(s). 

With Square Brackets, it cannot be interpreted in this way IMO as the 
syntax is inconsistence. It only make it easier to read for declaring a 
Type Parameterized func, but not easier to make an instance of the func 
with type.


On Saturday, August 8, 2020 at 12:02:51 PM UTC+2 Denis Cheremisov wrote:

> > Have the authors considered the implications of requiring the `type` 
> keyword to use a generic type, not just at declaration time? Would this 
> open up more syntax possibilities, such as `var x T`? This might 
> be easier to read at the expense of five more characters of typing. It also 
> could unify declaration and usage syntax even more than the proposal.
>
> > This might be easier to read
>
> Square brackets are easier to read. They are larger and catchier to eyes 
> than lesser and greater signs used as brackets. And type-less syntax with 
> mandatory constraint is even easier and feels like a great match with the 
> rest of the language.
>
>
> четверг, 6 августа 2020 г. в 22:25:19 UTC+3, Red Daly: 
>
>> Have the authors considered the implications of requiring the `type` 
>> keyword to use a generic type, not just at declaration time? Would this 
>> open up more syntax possibilities, such as `var x T`? This might 
>> be easier to read at the expense of five more characters of typing. It also 
>> could unify declaration and usage syntax even more than the proposal.
>>
>> (Personally, I will accept any syntax. It's not realistic to expect this 
>> for go2, but I would prefer if go3 ditched the C-style syntax altogether in 
>> favor of a simpler, lisp-style syntax. Such a syntax would make it easier 
>> to introduce language features like this one. Macros and metaprogramming 
>> would also be much more straightforward for users to add useful 
>> abstractions to the language.)
>> On Thursday, August 6, 2020 at 7:15:08 AM UTC-7 Mike Schinkel wrote:
>>
>>> Hi Russ,
>>>
>>> In general, I think the proposal is a really good one.  I like that you 
>>> abandoned contracts as interfaces were just too similar, and personally I 
>>> like the choice of square brackets.
>>>
>>> There are a few aspects I do not like — 1.) no zero value and 2.) lack 
>>> of covariance and contravariance — but perhaps those can be addressed in 
>>> the future?
>>>
>>> All in all, I think the team has come up with a really good approach to 
>>> generics, much better than the prior proposals.
>>>
>>> -Mike
>>>
>>> P.S. If there is one thing that piqued my interest about this thread it 
>>> was Geoff Speicher's suggestion of a "generic" keyword, assuming type 
>>> inference could be addressed. That approach would be even easier to reason 
>>> about than the current proposal, I think.  That said, the current proposal 
>>> is very good if type inference can not be addressed in Geoff Speicher's 
>>> suggestion.
>>>
>>> On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox 

[go-nuts] Re: "eg tool" for modules

[Kaveh Shahbazian]

There is a related issue , on Go 
GitHub repository, tracking support for modules.

On Sunday, August 9, 2020 at 12:23:12 AM UTC+2 Kaveh Shahbazian wrote:

> The "eg" tool - from Go Tools  
> Repo/Module - does not support Go Modules.
>
> 1 - Is there an alternative example-based refactoring tool, that provides 
> the same functionality?
>
> 2 - Are there any plans to support Go Modules by "eg" tool?
>
> P.S. The *astutil* 
>  package used 
> by "eg" also does 
> not seem to support Go Modules.
>

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

[go-nuts] Re: [generics] How to use maps in generic structs?

[Alvadron]

The type of map keys in Go should be comparable. As you haven't specified 
any restriction to the type parameters, it doesn't compile because Go 
doesn't know whether K and V are comparable.

If you add the restriction  "comparable", then it compiles:

type BiMap[type V, K comparable] struct {
forward map[K]V
reverse map[V]K 
}

PD: It is true that the error could be more informative. Right now we get:

type checking failed for main 
prog.go2:13:14: invalid map key type K 
prog.go2:14:14: invalid map key type V

Not sure if it is possible but, ideally, the message should say something 
like "Invalid mp key type K: it is not comparable"

El lunes, 10 de agosto de 2020 a las 13:49:48 UTC+1, markus@gain.pro 
escribió:

> This is invalid: 
>
> type BiMap[type V, K] struct {
> forward map[K]V
> reverse map[V]K 
> }
>
> How do I specify an interface constraint for V,K such that this is valid? 
> Is that possible at all?
>
>
>

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

Re: [go-nuts] Re: [generics] How to use maps in generic structs?

[Markus Heukelom]

Just a quick thought, instead of "comparable" (and type lists) maybe we
could use a single operator to specify the required "operators" interface:

type BiMap[type V, K ==] struct {
forward map[K]V
reverse map[V]K
}

func Max[type T <](a, b T) T {

}

func ScanRowStruct[type T .](rows sql.Rows, dest *T) error {  // operator .
ensures T is a struct

}




On Mon, Aug 10, 2020 at 3:45 PM 'Carla Pfaff' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> K and V must be comparable, since you use them as map keys:
>
> type BiMap[type V, K comparable] struct {
> forward map[K]V
> reverse map[V]K
> }
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/dwZnPgTC7So/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/202f1ffa-ac89-42eb-b617-d82e14c537een%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Port to powerpc 440fpu

[David Riley]

On Aug 10, 2020, at 4:59 AM, Hugo Cornelis  wrote:
> 
> 
> Hi,
> 
> Bottom line: Docker works reliably on powerpc 440fpu 32 bit using gccgo as 
> the compiler.  We will likely soon start working on powerpc e6500 in 32bit 
> mode.
> 
> After a fix in the structures used by the epoll system calls, the problem 
> disappeared.  I assume the problem was a starvation similar to
> 
> https://github.com/moby/moby/issues/39461
> 
> We had to correct the used system call numbers for the fstat system call 
> family, for sendfile, fadvise, ftruncate, truncate and fcntl.
> 
> We also had to fix the alignment of some of the structures used by these 
> functions and for the EpollEvent structure (ie. the generator did not always 
> generate correct structures).  The fix for EpollEvent also fixed the I/O 
> starvation problem.
> 
> It remains unclear why the generator did not generate correct structures.  We 
> updated the post processor mkpost.go to fix the structures (alignment + 
> member names), but did not look further into the underlying problem.

Glad to see updates!  I hope there's a chance to mainline this, I would welcome 
running Go in 32-bit PPC on my Net/OpenBSD machines that run on that platform.


- Dave

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

[go-nuts] Re: [generics] How to use maps in generic structs?

['Carla Pfaff' via golang-nuts]

K and V must be comparable, since you use them as map keys:

type BiMap[type V, K comparable] struct {
forward map[K]V
reverse map[V]K 
}

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

Re: [go-nuts] Gollvm failed to build hugo

['Than McIntosh' via golang-nuts]

Hello,

>># github.com/gohugoio/hugo
>>/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
split-stack sequence at section 1 offset 0

This issue is https://github.com/golang/go/issues/38728, which should be
fixed at this point at tip.

Thanks, Than


On Mon, Jul 20, 2020 at 2:33 PM Ian Lance Taylor  wrote:

> [ + thanm, cherryyz ]
>
> On Mon, Jul 20, 2020 at 4:24 AM Yuan Ting  wrote:
> >
> > Hi, I try to build hugo with fresh gollvm but the linker complains that:
> >
> > # github.com/gohugoio/hugo
> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
> split-stack sequence at section 1 offset 0
> > /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
> split-stack sequence at section 1 offset a6
> >
> > To reproduce:
> >
> > git clone https://github.com/gohugoio/hugo.git
> > cd hugo && go build
> >
> > Platform: x86_64 ubuntu:20.04
> > Gollvm build flags:
> > cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86
> -DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G
> Ninja
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d722a1e8-d205-4c9e-8ae4-623c19dd2946o%40googlegroups.com
> .
>

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

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Markus Heukelom]

On Sun, Jul 19, 2020 at 3:16 AM Ian Lance Taylor  wrote:

> On Sat, Jul 18, 2020 at 4:55 AM Markus Heukelom
>  wrote:
> >
> > Concerning the current generics proposal, was it every considered to not
> allow type contracts at all?
> >
> > No type contracts would mean that generic functions can only use =, & on
> variables of parametric types, as these are always available for all types.
> Nothings else is allowed.
> >
> > This would remove the possibility to write generic mathematical
> functions, for example. But it is simple and it already enables a lot of
> usefulness. Was this considered too restrictive?
> >
> > Type contracts could optionally be added in a later stage, but at least
> at that point we will have a larger body of generic code to work and test
> with.
> >
> > A bonus, disallowing all operations except assignment and address-taking
> would maybe also stop abuse of templates in the name of "but it is more
> efficient than interfaces" and "fancy coding syndromes".
>
> I think that for a language like Go any generics implementation must
> permit people to write the functions Min and Max.  The functions are
> trivial, but they are among the first that programmers accustomed to
> generics complain about in Go.
>
>
For what it is worth: for non-exported functions/types all operations could
be allowed, possibly leading to infamous C++-level error messages but as
you are the author of the package, those error messages would make sense to
you anyway.

For example, I could really use to be able to write things like this:

func sibling[type t](node *t) *t {
if node.parent == nil {
return nil
}
if node.parent.left == node {
return node.parent.right
  }
  return node.parent.left
}

This is not really possible with the current design. Of course I could
specify an interface with getters/setters, but that feels a bit silly and
cumbersome as everything is local to the package anyway.

I don't have better a solution, but all contracts/constraints do is prevent
long, unreadable error messages while inside a package there's no real
problem with those error messages to begin with.



> Ian
>

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

[go-nuts] [generics] How to use maps in generic structs?

[Markus Heukelom]

This is invalid: 

type BiMap[type V, K] struct {
forward map[K]V
reverse map[V]K 
}

How do I specify an interface constraint for V,K such that this is valid? 
Is that possible at all?


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

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

[David Skinner]

A handyman can do many things. But domain-specific experts like plumbers, 
electricians, and carpenters are far more skilled and efficient.

Statistical analysis of psycholinguistics indicates that there exist 
specific modes of thinking, no one syntax will ever be the best syntax for 
all modes of thought.

One lesson I learned in my brief and ineffective stint with the IEEE 
Standards is that when you try to satisfy all stakeholders, you end up with 
a pudding that satisfies no one.

I do believe that letting the Go team be both deliberate and opinionated is 
for the best.

I also do not consider the go2go tool a toy, but rather a proof of concept. 
It is similar and superior to the translation tool that I am using 
internally.

I have never considered the Go language to be the best language for 
anything except for the implementation of solutions. It is not the best for 
defining a project or for defining a solution. Warren Swader never needed 
Go, He could conceive an entire game and code it in ASM. I started without 
a compiler by writing MachineCode directly in Octal. 

Ivan Ivanyuk has a most excellent idea, one that I fully support. It is 
also one that is fully supported by the Go programming language.

   - Begin your project with a doc.go file and define the API and package.
   - Create your domain-specific grammar file.
   - Create your Doit.ivan file with your domain-specific syntax.
   - //go:generate goyacc -o Doit.go -p parser ivan.y
   
This is perhaps an oversimplification but details are available at

   - https://blog.golang.org/generate
   
The Go team is incapable of maintaining multiple syntaxes and we need to 
respect their bandwidth, but in their wisdom, they have enabled us to 
achieve all of our domain-specific goals, not in 2021 with generics, but 
rather with Go 1.14 with generate. Please do not expect them to do all of 
our work, learn to use the tools they have been providing us.

On Monday, August 10, 2020 at 5:21:07 AM UTC-5 Carla Pfaff wrote:

> On Monday, 10 August 2020 at 10:30:55 UTC+2 Ivan Ivanyuk wrote:
>
>> There is already an instrument in playground that works fine. Why not 
>> just roll it out and improve design, if needed, in next version?
>>
>
> The go2go tool is just a toy, an experiment, a simple translation tool. It 
> will be thrown away once they begin with the real implementation.
>
> https://twitter.com/GoTimeFM/status/1292148677155463169
> (Transcript from the Go Time podcast): *"The experimental tool has no 
> similarity whatsoever to any real implementation. [...] If this does move 
> forward to become a proposal and it gets accepted, then most likely the 
> implementation will be to start with a branch of the main Go toolchain, and 
> we'll start adding generic support on that branch, which will involve 
> changing the compiler mainly and any other changes to other tools that are 
> required."*
>  
>
>> Having generics in 2021 means many projects will choose other languages 
>> in 2020, which will effectively mean 1 year of work in other language
>>
>
> Go aims at careful and cautious language design, not at catering to 
> impatient people. 
>

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

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

['Carla Pfaff' via golang-nuts]

On Monday, 10 August 2020 at 10:30:55 UTC+2 Ivan Ivanyuk wrote:

> There is already an instrument in playground that works fine. Why not just 
> roll it out and improve design, if needed, in next version?
>

The go2go tool is just a toy, an experiment, a simple translation tool. It 
will be thrown away once they begin with the real implementation.

https://twitter.com/GoTimeFM/status/1292148677155463169
(Transcript from the Go Time podcast): *"The experimental tool has no 
similarity whatsoever to any real implementation. [...] If this does move 
forward to become a proposal and it gets accepted, then most likely the 
implementation will be to start with a branch of the main Go toolchain, and 
we'll start adding generic support on that branch, which will involve 
changing the compiler mainly and any other changes to other tools that are 
required."*
 

> Having generics in 2021 means many projects will choose other languages in 
> 2020, which will effectively mean 1 year of work in other language
>

Go aims at careful and cautious language design, not at catering to 
impatient people. 

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

Re: [go-nuts] Port to powerpc 440fpu

[Hugo Cornelis]

Hi,

Bottom line: Docker works reliably on powerpc 440fpu 32 bit using gccgo as
the compiler.  We will likely soon start working on powerpc e6500 in 32bit
mode.

After a fix in the structures used by the epoll system calls, the problem
disappeared.  I assume the problem was a starvation similar to

https://github.com/moby/moby/issues/39461

We had to correct the used system call numbers for the fstat system call
family, for sendfile, fadvise, ftruncate, truncate and fcntl.

We also had to fix the alignment of some of the structures used by these
functions and for the EpollEvent structure (ie. the generator did not
always generate correct structures).  The fix for EpollEvent also fixed the
I/O starvation problem.

It remains unclear why the generator did not generate correct structures.
We updated the post processor mkpost.go to fix the structures (alignment +
member names), but did not look further into the underlying problem.

Hugo




On Thu, Jul 9, 2020 at 10:08 AM Hugo Cornelis 
wrote:

>
>
> On Fri, Jul 3, 2020 at 9:36 PM Ian Lance Taylor  wrote:
>
>> That looks like the process is writing to a pipe that nothing is reading
>> from.
>>
>
> Yes, that is correct.  The question is: why doesn't the reader read from
> the pipe?  And why does it suddenly start reading when the Docker daemon
> process is terminated?
>
> At first I would believe this to be a starvation problem, but our
> investigation is still inconclusive.
>
> Here is what we know about the reader process / goroutine:
>
> - It is a goroutine that becomes active when Docker terminates.
>
> - This same goroutine gets stuck at io.CopyBuffer(epollConsole, in, *bp)
> before Docker terminates.  During this time the writer writes 18778
> characters (and then gets stuck).
>
> - All the configurations we tested, gave this or similar behaviour.
> However the behaviour is slightly timing dependent, ie. inserting logging
> statements may result in small changes to this behaviour.
>
>
> During the last few days of investigation we found one race in containerd
> and several bugs in our system call bindings for ppc (Ftruncate, Truncate,
> Fstatfs, Statfs, Lstat).
>
> We have fixed these, but the problem with the reader not reading / blocked
> I/O persists.
>
> It may be a case of starvation, or a race, or something else.
>
> More investigation is required.  We are now looking further into the
> system call bindings, debugging the code of Docker and its tools, and the
> gccgo runtime.
>
> Thanks for your reply.
>
> Hugo
>
>
>

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

Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

[Ivan Ivanyuk]

Thank you for answering

Why does it take so long to implement generics then? There is already an
instrument in playground that works fine. Why not just roll it out and
improve design, if needed, in next version?

Having generics in 2021 means many projects will choose other languages in
2020, which will effectively mean 1 year of work in other language

On Mon, Aug 10, 2020, 04:13 Ian Lance Taylor  wrote:

> On Sat, Aug 8, 2020 at 7:51 PM  wrote:
> >
> > Add support of optional syntax_version to file beginning, allow compiler
> to tokenize/compile file by the compiler of syntax_version, using any
> number of syntax_version-s in same project
> >
> > Why? Because go takes ridiculously long to implement generics, and
> implementation is very likely to not be perfect or to become not perfect
> when world changes. Having support of several syntaxes/compilers in same
> project will allow to adapt syntax faster
>
> We already support something like this on a per-module basis via the
> "go" line in a go.mod file
> (https://golang.org/cmd/go/#hdr-The_go_mod_file).  See also
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
> .
>
> Ian
>

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