Re: [go-nuts] Re: Float multiplication bug?

[Michael Jones]

This question is already answered, but i was on a plane and added a bit to
the printing and the comments. in case anyone ever refers to this thread in
the future, this is the better version of the program to run:
https://play.golang.org/p/EK0XMnMUKwv

On Fri, Feb 23, 2018 at 8:06 AM, Michael Jones 
wrote:

> One subtle thing is the difference between an ideal number, its
> floating-point representation, and its printed form.
>
> On Fri, Feb 23, 2018 at 5:46 AM,  wrote:
>
>> Thanks guys. That's very helpful.  I forgot that what I saw (and re-used)
>> as the "height" was not precise enough to make it comparable.
>>
>>
>> On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>>>
>>>
>>>  Hello Everyone,
>>>
>>>  This looks like a Golang bug to me. What do you all think?
>>>
  I have this function ...
>>>
>>> func getArea(base, side int64) float64 {
 var height, fSide, area float64
 fSide = float64(side)
 halfBase := float64(base) / 2.0
 height = math.Sqrt(fSide*fSide - halfBase*halfBase)
 area = halfBase * height
 fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
 area)

>>>
>>>
 hb2 := 151414.5
 h2 := 262256.452301
 fmt.Printf("Area 2: %f\n", hb2 * h2)

>>>
>>>
 return area
 }
>>>
>>>
>>> When I call it with `result := getArea(302829, 302828)`,   I get this
>>> output ...
>>>
>>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
 Area 2: 39709429596.929764
>>>
>>>
>>> I could see how some kind of rounding could produce the first Area
>>> value.  But in that case, why wouldn't Area2 be rounded as well?
>>>
>> --
>> 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.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>



-- 
Michael T. Jones
michael.jo...@gmail.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.

Re: [go-nuts] Appreciating Go

[Bakul Shah]

On Fri, 23 Feb 2018 17:39:16 -0800 Ian Lance Taylor  wrote:
Ian Lance Taylor writes:
> On Fri, Feb 23, 2018 at 5:23 PM, Bakul Shah  wrote:
> >
> > I once worked out some details of adding sum types to Go and I
> > think it is quite doable and easy to implement.
> 
> There is an extensive discussion of sum types in Go over at
> https://golang.org/issue/19412.

Thanks! Looks like Roger's ideas is similar. Not at all
surprising.  Will check it out further.

-- 
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] Appreciating Go

[Ian Lance Taylor]

On Fri, Feb 23, 2018 at 5:23 PM, Bakul Shah  wrote:
>
> I once worked out some details of adding sum types to Go and I
> think it is quite doable and easy to implement.

There is an extensive discussion of sum types in Go over at
https://golang.org/issue/19412.

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] Appreciating Go

[Bakul Shah]

On Thu, 22 Feb 2018 12:55:01 + Jesper Louis Andersen 
 wrote:
> 
> For sums, in Go, I have to return a pair,
> 
> x, err := someOperation(..)
> 
> but this is slightly inconsistent, insofar I can return "nil, nil", which
> might not be a valid value, or I can return "3, Error(..)" but in that case
> the 3 is not to be used. Only one "side" is valid at a given point in time.
> If you have sum-types in the usual sense, you can define something along
> the lines of (OCaml follows):
> 
> type ('a, 'b) result = Ok of 'a | Error of 'b

I once worked out some details of adding sum types to Go and I
think it is quite doable and easy to implement. For example,

func f(i int) float64|error {
if i == 0 { return errors.New("not zero") }
return 1./float64(i)
}

As in OCaml "|" is used for sum types and it binds less
tightly than existing type "expressions".

> And then you can discriminate on this value via pattern matching
> 
> match res with
> | Ok value -> ...
> | Error err -> ...

Not quite the same but something similar is doable with
type switch.

res := f(j)
switch res.(type) {
case error: ...
case string: ...
}

This use is identical with f returning interface{} (even the f
body remains exactly the same).  This makes sense since
interface{} is in a sense the sum of all other types.

But by allowing sum type, we can do better checking within f
(e.g. return "string" will fail to compile). And by using a
sum type instead of a product type to return a value or error
also makes the code clearer.

I once counted there were about 8000 uses of ,error as
return types for functions in $GOROOT/src which could benefit
from sum types. Now there seem to be about 4253 instances
(found using a crude regexp).

I think I worked out the semantics of T1|T2 where T1 and T2
are both interface types themselves. It all seem to fit
together, at least on paper! I need to find my notes

> The other matching construction is a switch-statement, but such a statement
> doesn't allow for matching deeply into an AST structure, which a
> traditional pattern matcher does.

Deeper matching also binds names to matched parts. e.g.

sumsqr [] = 0 
sumsqr (x:xs) = x*x + sumsqr xs

This sort of binding may be difficult to shoehorn into Go.
There may be no real benefit of binding head, tail of a slide
but consider an AST. If you are already cracking it open for
matching it with a pattern, you may as well bind variables to
interesting parts.

match stmt {
case If1stmt(test:, thenstmt:): ...
case If2stmt(test:, thenstmt:, elsestmt:): ...
...
}

Hard to come up with an intuitive syntax here.  Also probably
impossible  to add func level patterns.

> Coincidentally, given sum-types, you can write a regexp matching engine in
> very few lines of code. See Bob Harper's "Programming in Standard ML" [2]
> for example; it is the introductory example to get a feel for the language.
> The solution uses sum types to define the AST for regular expressions, and
> then uses pattern matching to build a matcher on regular expressions. I
> can't remember how far Bob takes the exposition however.

This should be doable given my sum-type proposal sketch above?!

> [0] They are really the same in the right setting. In a boolean algebra,
> for instance, + is OR and * is AND. If you look at them from the Category
> Theory branch of mathematics they are related: they are duals of each other
> which means that if you "invert" one you get the other and vice versa.
> 
> [1] Obviously, Go, being a descendant of Algol has two syntactic classes:
> statements and expressions, whereas OCaml is descendant from either Lisp or
> the Lambda Calculus depending on view. Those languages only have
> expressions as a syntactic class.

sum-types (which are easy to implement) and pattern matching
(may be not so easy) can be added to Go even if it has
non-expression syntatic classes.

> [2] http://www.cs.cmu.edu/~rwh/isml/book.pdf
> 
> [3]
> https://www.microsoft.com/en-us/research/wp-content/uploads/1987/01/slpj-book-1987-small.pdf

SLPJ's book was quite an eye opener for me back in the '80s! 

-- 
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 += Package Versioning

[David Collier-Brown]

>
> Some forms of attempted versioning don't do well with vgo (:-))
>

I tried a main named "consumer" that imported "gopkg.in/Shopify/sarama.v1", 
> and got
>
``` 

> [davecb@miles consumer]$ vgo build
> can't load package: import cycle not allowed
> package gopkg.in/Shopify/sarama.v1
> imports gopkg.in/Shopify/sarama.v1
> import cycle not allowed
> package gopkg.in/Shopify/sarama.v1
> imports gopkg.in/Shopify/sarama.v1
>
 

> [davecb@miles consumer]$ cat go.mod 
> module "gopkg.in/Shopify/sarama.v1"
>
```

The main.go started with 
```
package main 

import (
samara "gopkg.in/Shopify/sarama.v1"
"os"
"log"
"os/signal"
)

func main() {
consumer, err := samara.NewConsumer([]string{"10.5.70.111:9092"}, nil)
if err != nil {
panic(err)
}
```

I didn't expect it to work, but the nature of the error might be 
interesting 

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

[go-nuts] Re: yaml 1.1 release

[Dmitri Shuralyov]

Just as a heads up, this package (gopkg.in/yaml.v2) is now also affected by 
issue https://github.com/niemeyer/gopkg/issues/54. It wasn't one of the 
affected import paths a week ago.


On Friday, February 23, 2018 at 2:20:22 PM UTC-5, Roger Peppe wrote:
>
> Of course I mean 2.1. Version two. TWO is the version. 
>
>
> On 23 February 2018 at 19:17, roger peppe  > wrote: 
> > I'm happy to announce the release of goyaml 1.1. 
> > 
> > It includes the following improvements: 
> > 
> > - Add Encoder and Decoder types 
> > This allows encoding and decode multiple YAML documents in a stream. 
> > 
> > - Alternative timestamp support (e.g. 2015-01-01). Credit to 
> anthonybishopric. 
> > 
> > - If a value implements an IsZero method and omitempty is specified, 
> > the value will be omitted if IsZero returns true. This means 
> > that time.Time now works correctly with omitzero. 
> > 
> > - Strict mode now enforces key uniqueness (issue #284) 
> > 
> > - Plain scalars with colons in are now allowed in flow-style mappings 
> > and sequences. (issue #295) 
> > 
> > - Forward references to anchors are now disallowed. 
> > 
> > - Version is now tagged compatible with vgo (and there's even a go.mod 
> file!). 
> > 
> > Thanks to everyone for their issues and PRs, and for bearing with my 
> > very slow maintenance of this package... I hope to work on some more 
> > improvements soon! 
>

-- 
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: Go += Package Versioning

[Aram Hăvărneanu]

> Ah… yes, that would probably let me work on it. Didn’t occur to me
> — thanks for pointing it out. It seems unpleasant to deal with,
> though, especially since there is a non-zero chance that you then
> commit your go.mod file with that change inadvertently.

See my proposal here:
https://github.com/golang/go/issues/23972#issuecomment-368077927

-- 
Aram Hăvărneanu

-- 
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: Go += Package Versioning

[Richard Wilkes]

Ah… yes, that would probably let me work on it. Didn’t occur to me — thanks 
for pointing it out. It seems unpleasant to deal with, though, especially 
since there is a non-zero chance that you then commit your go.mod file with 
that change inadvertently.

I think a local replace will do that. Something like: replace "
> foo.com/my/pkg" v1.5.2 => ../local-clone-with-changes
>
 

Put that in the top-level module, and it should override that import 
> throughout the build with your local copy, pending changes and all. Or is 
> that not what you were trying to do here?


-- 
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: Go += Package Versioning

[David Anderson]

On Fri, Feb 23, 2018 at 3:34 PM, Richard Wilkes 
wrote:

> Overall, I really like the direction vgo is headed.
>
> One thing that seems to be difficult, if not impossible to do (I've yet to
> figure out how to do so, anyway) is to work with code that has yet to be
> committed and resides outside of your module. This is a frequent occurrence
> for me, as I often have to work on groups of changes that interact between
> multiple repos. Yes, I'll eventually check those changes in, but usually
> not while actively working on the problem.
>

I think a local replace will do that. Something like: replace "
foo.com/my/pkg" v1.5.2 => ../local-clone-with-changes

Put that in the top-level module, and it should override that import
throughout the build with your local copy, pending changes and all. Or is
that not what you were trying to do here?


> Related to this, it took a few minutes to realize that you really can't
> "downgrade" to a commit-level entry with the tool when a tag is present in
> the repo -- you have to manually edit it to get the desired behavior. I put
> downgrade in quotes because what I was actually trying to do was to get the
> actual latest (HEAD) code, but could not without manually futzing with the
> go.mod file. This is also something that I frequently need to do -- and I'm
> relatively sure I'm not alone -- so it seems like the tool should make this
> easy, not hard.
>
> Despite the two problems above, an inability to work with GitHub
> Enterprise (filed in a bug report), and concern over how IDEs will work
> with library source, I'm already enjoying working with vgo.
>
> - Rich
>
> --
> 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] Re: Go += Package Versioning

[Richard Wilkes]

Overall, I really like the direction vgo is headed.

One thing that seems to be difficult, if not impossible to do (I've yet to 
figure out how to do so, anyway) is to work with code that has yet to be 
committed and resides outside of your module. This is a frequent occurrence 
for me, as I often have to work on groups of changes that interact between 
multiple repos. Yes, I'll eventually check those changes in, but usually 
not while actively working on the problem.

Related to this, it took a few minutes to realize that you really can't 
"downgrade" to a commit-level entry with the tool when a tag is present in 
the repo -- you have to manually edit it to get the desired behavior. I put 
downgrade in quotes because what I was actually trying to do was to get the 
actual latest (HEAD) code, but could not without manually futzing with the 
go.mod file. This is also something that I frequently need to do -- and I'm 
relatively sure I'm not alone -- so it seems like the tool should make this 
easy, not hard.

Despite the two problems above, an inability to work with GitHub Enterprise 
(filed in a bug report), and concern over how IDEs will work with library 
source, I'm already enjoying working with vgo.

- Rich

-- 
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: New to Go; Saying Hello !

[bucarr]

Another newbie here.  Welcome and I feel the same way about Go!

-- 
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: New to Go; Saying Hello !

[Dmitri Shuralyov]

Hello!

I can really relate to what you're describing. When I started programming 
in Go 5 years ago, I felt the same way, and I still do to this day! There 
are so many moments of joy and bliss that happen when working with it 
daily. :) Hope you continue to enjoy it too!


On Friday, February 23, 2018 at 9:26:42 AM UTC-5, Chris FractalBach wrote:
>
> So, I started programming in Go about a month ago.  I can't stop.
> I can't even describe why I am enjoying the language so much, except by 
> saying...
>
> It's fun to program in Go!
>
> I have now embarked on a mission to create an online game, using Go for 
> the server.
> I thought I should stop by here and say hello, since I have a feeling that 
> I will be
> programming a lot in this language =)
>
> I am certainly Golang-Nuts about Go.
>

-- 
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: yaml 1.1 release

[roger peppe]

Of course I mean 2.1. Version two. TWO is the version.


On 23 February 2018 at 19:17, roger peppe  wrote:
> I'm happy to announce the release of goyaml 1.1.
>
> It includes the following improvements:
>
> - Add Encoder and Decoder types
> This allows encoding and decode multiple YAML documents in a stream.
>
> - Alternative timestamp support (e.g. 2015-01-01). Credit to anthonybishopric.
>
> - If a value implements an IsZero method and omitempty is specified,
> the value will be omitted if IsZero returns true. This means
> that time.Time now works correctly with omitzero.
>
> - Strict mode now enforces key uniqueness (issue #284)
>
> - Plain scalars with colons in are now allowed in flow-style mappings
> and sequences. (issue #295)
>
> - Forward references to anchors are now disallowed.
>
> - Version is now tagged compatible with vgo (and there's even a go.mod file!).
>
> Thanks to everyone for their issues and PRs, and for bearing with my
> very slow maintenance of this package... I hope to work on some more
> improvements soon!

-- 
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] yaml 1.1 release

[roger peppe]

I'm happy to announce the release of goyaml 1.1.

It includes the following improvements:

- Add Encoder and Decoder types
This allows encoding and decode multiple YAML documents in a stream.

- Alternative timestamp support (e.g. 2015-01-01). Credit to anthonybishopric.

- If a value implements an IsZero method and omitempty is specified,
the value will be omitted if IsZero returns true. This means
that time.Time now works correctly with omitzero.

- Strict mode now enforces key uniqueness (issue #284)

- Plain scalars with colons in are now allowed in flow-style mappings
and sequences. (issue #295)

- Forward references to anchors are now disallowed.

- Version is now tagged compatible with vgo (and there's even a go.mod file!).

Thanks to everyone for their issues and PRs, and for bearing with my
very slow maintenance of this package... I hope to work on some more
improvements soon!

-- 
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] New to Go; Saying Hello !

['Axel Wagner' via golang-nuts]

o/

We're happy to have you :)


On Fri, Feb 23, 2018 at 6:11 PM Daniel Skinner  wrote:

> hi :)
>
> On Fri, Feb 23, 2018, 8:26 AM  wrote:
>
>> So, I started programming in Go about a month ago.  I can't stop.
>> I can't even describe why I am enjoying the language so much, except by
>> saying...
>>
>> It's fun to program in Go!
>>
>> I have now embarked on a mission to create an online game, using Go for
>> the server.
>> I thought I should stop by here and say hello, since I have a feeling
>> that I will be
>> programming a lot in this language =)
>>
>> I am certainly Golang-Nuts about Go.
>>
>> --
>> 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] New to Go; Saying Hello !

[Daniel Skinner]

hi :)

On Fri, Feb 23, 2018, 8:26 AM  wrote:

> So, I started programming in Go about a month ago.  I can't stop.
> I can't even describe why I am enjoying the language so much, except by
> saying...
>
> It's fun to program in Go!
>
> I have now embarked on a mission to create an online game, using Go for
> the server.
> I thought I should stop by here and say hello, since I have a feeling that
> I will be
> programming a lot in this language =)
>
> I am certainly Golang-Nuts about Go.
>
> --
> 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] Re: Build started to fail with 1.10

[Vladislav Mitov]

Interesting fact is that if I remove "-std=c99" from CGO_CFLAGS it works 
locally, fails in Travis though.

On Friday, February 23, 2018 at 6:32:29 PM UTC+2, Vladislav Mitov wrote:
>
> Not sure, I'l building in golang:latest 
> https://github.com/miracl/gomiracl/blob/master/Dockerfile#L23.
>
> On Friday, February 23, 2018 at 12:26:27 PM UTC+2, Dave Cheney wrote:
>>
>> The failing line was added in december last year,
>>
>>
>> https://github.com/golang/go/commit/7cba779cea5#diff-56c7df71bce32f8e50115128ae30941eR13
>>
>> This also adds a dependency on time.h. Is time.h available in your build 
>> container?
>>
>> On Friday, 23 February 2018 20:09:02 UTC+11, Владислав Митов wrote:
>>>
>>> Nah, it's not that - 
>>> https://travis-ci.org/miracl/gomiracl/jobs/345158452. If fails also in 
>>> golang:latest where the yaml gotcha it's not a thing. Solid suggestion 
>>> though, thanks.
>>>
>>> On Friday, February 23, 2018 at 11:02:59 AM UTC+2, Владислав Митов wrote:

 Ah, I read about that but ti says `go version go1.10 linux/amd64`. 
 I'll try putting it in quotes now.

 On Friday, February 23, 2018 at 1:57:53 AM UTC+2, Nic Pottier wrote:
>
> This is almost certainly because your .travis file is specifying your 
> version as `1.10` vs `"1.10"`
>
> So your build is building with go 1.1 instead of 1.10.
>
> Ran into this myself this morning.
>
> -Nic
>
> On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов 
> wrote:
>>
>> Hey guys, 
>>
>> One of my build started failing with 1.10. Basically I'm building a 
>> wrapper around a C library and it fails with: 
>>
>> # runtime/cgo
>> gcc_libinit.c: In function '_cgo_try_pthread_create':
>> gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
>>   struct timespec ts;
>>   ^~
>> gcc_libinit.c:110:3: error: implicit declaration of function '
>> nanosleep' [-Werror=implicit-function-declaration]
>>nanosleep(, nil);
>>^
>> gcc_libinit.c:97:18: error: unused variable 'ts' 
>> [-Werror=unused-variable]
>>   struct timespec ts;
>>   ^~
>> cc1: all warnings being treated as errors
>> https://travis-ci.org/miracl/gomiracl/jobs/344782123
>>
>> Any hint's what's causing this? 
>>
>> Cheers, 
>> Vladi
>>
>

-- 
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: Build started to fail with 1.10

[Vladislav Mitov]

Not sure, I'l building in 
golang:latest https://github.com/miracl/gomiracl/blob/master/Dockerfile#L23.

On Friday, February 23, 2018 at 12:26:27 PM UTC+2, Dave Cheney wrote:
>
> The failing line was added in december last year,
>
>
> https://github.com/golang/go/commit/7cba779cea5#diff-56c7df71bce32f8e50115128ae30941eR13
>
> This also adds a dependency on time.h. Is time.h available in your build 
> container?
>
> On Friday, 23 February 2018 20:09:02 UTC+11, Владислав Митов wrote:
>>
>> Nah, it's not that - https://travis-ci.org/miracl/gomiracl/jobs/345158452. 
>> If fails also in golang:latest where the yaml gotcha it's not a thing. 
>> Solid suggestion though, thanks.
>>
>> On Friday, February 23, 2018 at 11:02:59 AM UTC+2, Владислав Митов wrote:
>>>
>>> Ah, I read about that but ti says `go version go1.10 linux/amd64`. I'll 
>>> try putting it in quotes now.
>>>
>>> On Friday, February 23, 2018 at 1:57:53 AM UTC+2, Nic Pottier wrote:

 This is almost certainly because your .travis file is specifying your 
 version as `1.10` vs `"1.10"`

 So your build is building with go 1.1 instead of 1.10.

 Ran into this myself this morning.

 -Nic

 On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов 
 wrote:
>
> Hey guys, 
>
> One of my build started failing with 1.10. Basically I'm building a 
> wrapper around a C library and it fails with: 
>
> # runtime/cgo
> gcc_libinit.c: In function '_cgo_try_pthread_create':
> gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
>   struct timespec ts;
>   ^~
> gcc_libinit.c:110:3: error: implicit declaration of function '
> nanosleep' [-Werror=implicit-function-declaration]
>nanosleep(, nil);
>^
> gcc_libinit.c:97:18: error: unused variable 'ts' 
> [-Werror=unused-variable]
>   struct timespec ts;
>   ^~
> cc1: all warnings being treated as errors
> https://travis-ci.org/miracl/gomiracl/jobs/344782123
>
> Any hint's what's causing this? 
>
> Cheers, 
> Vladi
>


-- 
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] vgo and enterprise GitHub servers

[Richard Wilkes]

Filed https://github.com/golang/go/issues/24076 for this.

On Thursday, February 22, 2018 at 5:28:58 PM UTC-8, andrey mirtchovski 
wrote:
>
> can you create an issue for this? we're also suffering from the same 
> internally. please make it about GitHub Enterprise, as that is what 
> they call it :) 
>
> On Thu, Feb 22, 2018 at 5:16 PM, Richard Wilkes  > wrote: 
> > Is it expected that vgo should work with enterprise GitHub servers at 
> this 
> > point in time? When trying it out, I find I'm getting messages like this 
> > during import resolution: 
> > 
> >> vgo: resolving import "jaxf-github.fanatics.corp/forge/furnace" 
> >> findRepo: XML syntax error on line 25: unescaped < inside quoted string 
> >> vgo: import "jaxf-github.fanatics.corp/forge/ratelimiter" -> 
> >> import "jaxf-github.fanatics.corp/forge/furnace": unknown VCS, Repo: 
> git, 
> >> https://jaxf-github.fanatics.corp/forge/furnace.git 
> > 
> > 
> > Imports from GitHub itself are resolving fine. Anyway, any insight as to 
> > what might be going wrong would be appreciated. The error message isn't 
> > terribly enlightening to me, I'm afraid. 
> > 
> > - Rich 
> > 
> > -- 
> > 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] Go += Package Versioning

[Jon Calhoun]

Not ideal, but you *could* release a new major version where the "breaking"
change is the import path change. Eg if you are on v3 now, make a v4 folder
and the upgrade to v4 process would involve updating import paths. I
wouldn't do this right away since vgo is just a prototype and could change
to handle this situation better, but it is an option.


On Fri, Feb 23, 2018 at 10:00 AM, Nic Pottier  wrote:

> On Fri, Feb 23, 2018 at 7:59 AM, roger peppe  wrote:
> > As Russ pointed out to me, you can work around that by using a
> > 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
> > section. If you've got that, it ignores the version tags.
>
> Right, that works for clients of the library (and I did manage to get
> my projects working with that and it now feels magical) but authors of
> modules above v1 are posed with a bit of a quandary as to how to give
> their users a nice vgo version without breaking current users on plain
> go.
>
> From Russ's latest post I think the answer is you put a v3 subdir in
> your repo with a copy of the code, add a mod.go and update both the
> root and v3 until vgo becomes adopted everywhere.
>
> -Nic
>
> --
> 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/jFPz5yZCPcQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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] All goroutines hung in futex / sleep

[Ian Lance Taylor]

On Fri, Feb 23, 2018 at 1:19 AM, Michael Andersen  wrote:
>
> Ok I found the problem. A tight loop was indeed preventing the garbage
> collector from proceeding, and then the GC was stopping everything else. The
> loop contained atomic.LoadUint64 and atomic.CompareAndSwapUint64, but
> neither of those seem to qualify as preemption points. Fixing that loop
> fixes everything.
>
> Thanks to Ian for pointing me on the right path and thanks to Florin Pățan
> on gophers.slack.com for pointing me at Delve which eventually let me find
> the problematic code.
>
> I know this is not at all the job of the race detector, but given that
> compiling with -race is the first thing we do when a program experiences
> "deadlock" type behavior, and I have seen several people being thrown off by
> the way go behaves when there are tight loops, can we not detect that the GC
> has stalled for way too long and print something out? Like "Goroutine #545
> is preventing GC" or something? Just a thought.

That seems like a good suggestion.  Want to open an issue for it at
https://golang.org/issue?  Thanks.

There is a pretty good chance that the general preemptible loop
problem will be fixed in 1.11.

Ian




> On Thu, Feb 22, 2018 at 11:09 PM, Michael Andersen 
> wrote:
>>
>> I have found that GODEBUG=schedtrace still prints when the program is
>> frozen but I cannot find much documentation on deciphering its output. The
>> full output is here:
>> https://gist.github.com/immesys/7f213c63c54ce60ba72d1cbc9ffcc4cb but here
>> are the first few lines. It looks like this is garbage collector related?
>>
>> SCHED 111364ms: gomaxprocs=40 idleprocs=0 threads=78 spinningthreads=0
>> idlethreads=65 runqueue=31 gcwaiting=1 nmidlelocked=1 stopwait=1
>> sysmonwait=0
>> P0: status=3 schedtick=36699 syscalltick=29158 m=-1 runqsize=0 gfreecnt=45
>> P1: status=3 schedtick=37370 syscalltick=30563 m=-1 runqsize=0 gfreecnt=31
>> P2: status=3 schedtick=36650 syscalltick=29478 m=-1 runqsize=0 gfreecnt=17
>> P3: status=3 schedtick=42395 syscalltick=34028 m=-1 runqsize=0 gfreecnt=38
>> P4: status=3 schedtick=40531 syscalltick=33546 m=-1 runqsize=0 gfreecnt=27
>> P5: status=3 schedtick=41369 syscalltick=31884 m=-1 runqsize=0 gfreecnt=19
>> P6: status=3 schedtick=39302 syscalltick=32162 m=-1 runqsize=0 gfreecnt=39
>> P7: status=3 schedtick=39739 syscalltick=32624 m=-1 runqsize=0 gfreecnt=34
>> P8: status=3 schedtick=32585 syscalltick=24358 m=-1 runqsize=0 gfreecnt=45
>> P9: status=3 schedtick=40376 syscalltick=30399 m=-1 runqsize=0 gfreecnt=27
>> P10: status=3 schedtick=31018 syscalltick=22164 m=-1 runqsize=0
>> gfreecnt=40
>> P11: status=3 schedtick=32043 syscalltick=24479 m=-1 runqsize=0
>> gfreecnt=53
>> P12: status=3 schedtick=36459 syscalltick=25222 m=-1 runqsize=0
>> gfreecnt=21
>> P13: status=3 schedtick=38445 syscalltick=28317 m=-1 runqsize=0
>> gfreecnt=38
>> P14: status=3 schedtick=39533 syscalltick=28189 m=-1 runqsize=0
>> gfreecnt=29
>> P15: status=3 schedtick=37009 syscalltick=27231 m=-1 runqsize=0
>> gfreecnt=29
>> P16: status=3 schedtick=36957 syscalltick=26211 m=44 runqsize=0
>> gfreecnt=45
>> P17: status=3 schedtick=35632 syscalltick=26481 m=-1 runqsize=0
>> gfreecnt=48
>> P18: status=3 schedtick=36228 syscalltick=24751 m=-1 runqsize=0
>> gfreecnt=59
>> P19: status=3 schedtick=32479 syscalltick=22970 m=-1 runqsize=0
>> gfreecnt=48
>> P20: status=3 schedtick=34090 syscalltick=25864 m=-1 runqsize=0
>> gfreecnt=12
>> P21: status=3 schedtick=35409 syscalltick=24369 m=-1 runqsize=0 gfreecnt=6
>> P22: status=3 schedtick=42235 syscalltick=28607 m=-1 runqsize=0
>> gfreecnt=16
>> P23: status=3 schedtick=29733 syscalltick=19429 m=-1 runqsize=0
>> gfreecnt=43
>> P24: status=3 schedtick=34757 syscalltick=22141 m=-1 runqsize=0
>> gfreecnt=26
>> P25: status=3 schedtick=31434 syscalltick=21767 m=-1 runqsize=0
>> gfreecnt=23
>> P26: status=3 schedtick=31597 syscalltick=21657 m=-1 runqsize=0
>> gfreecnt=53
>> P27: status=3 schedtick=32539 syscalltick=22653 m=-1 runqsize=0
>> gfreecnt=34
>> P28: status=3 schedtick=29503 syscalltick=20588 m=-1 runqsize=0
>> gfreecnt=28
>> P29: status=3 schedtick=30842 syscalltick=20199 m=-1 runqsize=0
>> gfreecnt=41
>> P30: status=3 schedtick=29787 syscalltick=19492 m=-1 runqsize=0
>> gfreecnt=15
>> P31: status=3 schedtick=28226 syscalltick=19101 m=-1 runqsize=0
>> gfreecnt=32
>> P32: status=3 schedtick=34254 syscalltick=24135 m=-1 runqsize=0
>> gfreecnt=27
>> P33: status=3 schedtick=34567 syscalltick=22554 m=-1 runqsize=0
>> gfreecnt=36
>> P34: status=3 schedtick=30416 syscalltick=19722 m=-1 runqsize=0
>> gfreecnt=33
>> P35: status=1 schedtick=19536 syscalltick=13084 m=0 runqsize=0 gfreecnt=50
>> P36: status=3 schedtick=29336 syscalltick=19015 m=-1 runqsize=0
>> gfreecnt=28
>> P37: status=3 schedtick=29794 syscalltick=19499 m=-1 runqsize=0
>> gfreecnt=40
>> P38: status=3 schedtick=31748 syscalltick=20359 m=-1 runqsize=0
>> gfreecnt=35
>> P39: status=3 schedtick=31851 

Re: [go-nuts] "golang.org/x/net/internal/iana" //use of internal package not allowed

[Ian Lance Taylor]

On Fri, Feb 23, 2018 at 2:10 AM,   wrote:
>
> "golang.org/x/net/internal/iana" //use of internal package not allowed
>
> how to import

You can't.  It's not allowed.

What are you really trying to do?

Ian

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

Re: [go-nuts] Go += Package Versioning

[Nic Pottier]

Right, any self import needs to change for the vgo case. (but not for
the go case unless you force everybody currently using your library to
start using semantic versioning paths)

-Nic

On Fri, Feb 23, 2018 at 10:06 AM, Zellyn Hunter  wrote:
> On Fri, Feb 23, 2018 at 10:01 AM Nic Pottier  wrote:
>>
>> Right, that works for clients of the library (and I did manage to get
>> my projects working with that and it now feels magical) but authors of
>> modules above v1 are posed with a bit of a quandary as to how to give
>> their users a nice vgo version without breaking current users on plain
>> go.
>
>
>  Why not just commit a mod.go with v3 in it at the root, and tag it
> 3.{y+1}?, assuming you're already on v3.y? Adding mod.go doesn't break
> existing users. vgo users will use different import paths. If you like, you
> can branch off of your 1.x tag, add a mod.go with v1 in it there, and tag it
> 1.{x+1}. Same for v2.
>
> Oh wait, is it a problem because your self-import paths need to change (or
> not) depending on whether the client is using vgo? I think I'm unclear on
> that detail :-)
>
> Zellyn

-- 
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 += Package Versioning

[Zellyn Hunter]

On Fri, Feb 23, 2018 at 10:01 AM Nic Pottier  wrote:

> Right, that works for clients of the library (and I did manage to get
> my projects working with that and it now feels magical) but authors of
> modules above v1 are posed with a bit of a quandary as to how to give
> their users a nice vgo version without breaking current users on plain
> go.
>

 Why not just commit a mod.go with v3 in it at the root, and tag it
3.{y+1}?, assuming you're already on v3.y? Adding mod.go doesn't break
existing users. vgo users will use different import paths. If you like, you
can branch off of your 1.x tag, add a mod.go with v1 in it there, and tag
it 1.{x+1}. Same for v2.

Oh wait, is it a problem because your self-import paths need to change (or
not) depending on whether the client is using vgo? I think I'm unclear on
that detail :-)

Zellyn

-- 
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 += Package Versioning

[roger peppe]

On 23 February 2018 at 15:00, Nic Pottier  wrote:
> On Fri, Feb 23, 2018 at 7:59 AM, roger peppe  wrote:
>> As Russ pointed out to me, you can work around that by using a
>> 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
>> section. If you've got that, it ignores the version tags.
>
> Right, that works for clients of the library (and I did manage to get
> my projects working with that and it now feels magical) but authors of
> modules above v1 are posed with a bit of a quandary as to how to give
> their users a nice vgo version without breaking current users on plain
> go.
>
> From Russ's latest post I think the answer is you put a v3 subdir in
> your repo with a copy of the code, add a mod.go and update both the
> root and v3 until vgo becomes adopted everywhere.

Good point. Ugh.

-- 
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 += Package Versioning

[Nic Pottier]

On Fri, Feb 23, 2018 at 7:59 AM, roger peppe  wrote:
> As Russ pointed out to me, you can work around that by using a
> 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
> section. If you've got that, it ignores the version tags.

Right, that works for clients of the library (and I did manage to get
my projects working with that and it now feels magical) but authors of
modules above v1 are posed with a bit of a quandary as to how to give
their users a nice vgo version without breaking current users on plain
go.

>From Russ's latest post I think the answer is you put a v3 subdir in
your repo with a copy of the code, add a mod.go and update both the
root and v3 until vgo becomes adopted everywhere.

-Nic

-- 
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 += Package Versioning

[Zellyn]

Fantastic post. One small answer below:

On Friday, February 23, 2018 at 2:22:32 AM UTC-5, David Anderson wrote:
>
> The version to use in that replacement was hard to come by. Since vgo was 
> unable to compute the right dependency list without this replacement, it 
> bailed without giving me any version I might use. The date+hash format is 
> irritating to construct by hand, but could be trivially lifted into a tool 
> (perhaps even vgo itself).
>

git log -1 ae16178c028329cb0b979cd63bbd3921ddaf0945 
--date='format:%Y%m%d%H%M%S' --format='v.0.0.0-%cd-%h'
v.0.0.0-2018011942-ae16178c02

Zellyn
 

-- 
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] New to Go; Saying Hello !

[fractalbach]

So, I started programming in Go about a month ago.  I can't stop.
I can't even describe why I am enjoying the language so much, except by 
saying...

It's fun to program in Go!

I have now embarked on a mission to create an online game, using Go for the 
server.
I thought I should stop by here and say hello, since I have a feeling that 
I will be
programming a lot in this language =)

I am certainly Golang-Nuts about Go.

-- 
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.org/x/net/internal/iana" //use of internal package not allowed

[sdlaovip]

"golang.org/x/net/internal/iana" //use of internal package not allowed

how to import 

-- 
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: Float multiplication bug?

[Michael Jones]

One subtle thing is the difference between an ideal number, its
floating-point representation, and its printed form.

On Fri, Feb 23, 2018 at 5:46 AM,  wrote:

> Thanks guys. That's very helpful.  I forgot that what I saw (and re-used)
> as the "height" was not precise enough to make it comparable.
>
>
> On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>>
>>
>>  Hello Everyone,
>>
>>  This looks like a Golang bug to me. What do you all think?
>>
>>>  I have this function ...
>>
>> func getArea(base, side int64) float64 {
>>> var height, fSide, area float64
>>> fSide = float64(side)
>>> halfBase := float64(base) / 2.0
>>> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>>> area = halfBase * height
>>> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
>>> area)
>>>
>>
>>
>>> hb2 := 151414.5
>>> h2 := 262256.452301
>>> fmt.Printf("Area 2: %f\n", hb2 * h2)
>>>
>>
>>
>>> return area
>>> }
>>
>>
>> When I call it with `result := getArea(302829, 302828)`,   I get this
>> output ...
>>
>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
>>> Area 2: 39709429596.929764
>>
>>
>> I could see how some kind of rounding could produce the first Area
>> value.  But in that case, why wouldn't Area2 be rounded as well?
>>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.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: Float multiplication bug?

[steve_bagwell]

Thanks guys. That's very helpful.  I forgot that what I saw (and re-used) 
as the "height" was not precise enough to make it comparable.

On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>
>
>  Hello Everyone,
>
>  This looks like a Golang bug to me. What do you all think?
>
>>  I have this function ...
>
> func getArea(base, side int64) float64 {
>> var height, fSide, area float64
>> fSide = float64(side)
>> halfBase := float64(base) / 2.0
>> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>> area = halfBase * height
>> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height, area)
>>
>  
>
>> hb2 := 151414.5
>> h2 := 262256.452301
>> fmt.Printf("Area 2: %f\n", hb2 * h2)
>>
>  
>
>> return area
>> }
>
>  
> When I call it with `result := getArea(302829, 302828)`,   I get this 
> output ...
>
> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
>> Area 2: 39709429596.929764
>
>
> I could see how some kind of rounding could produce the first Area value.  
> But in that case, why wouldn't Area2 be rounded as well?
>

-- 
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 += Package Versioning

[roger peppe]

On 23 February 2018 at 12:31, Nic Pottier  wrote:
> Thanks for the great write up Dave, you've inspired me to "try harder" to
> use it on a few of my projects after running into similar issues.
>
> As you noted, my remaining big question mark is how existing libraries that
> are above v1 transition to a vgo style while remaining backwards compatible
> during the transition.

As Russ pointed out to me, you can work around that by using a
0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
section. If you've got that, it ignores the version tags.

-- 
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 += Package Versioning

[Nic Pottier]

Thanks for the great write up Dave, you've inspired me to "try harder" to 
use it on a few of my projects after running into similar issues.

As you noted, my remaining big question mark is how existing libraries that 
are above v1 transition to a vgo style while remaining backwards compatible 
during the transition. That seems like the biggest wrench to adoption. (if 
we can convince everyone to start using v# in import paths) I was preparing 
to open some PRs with dependencies of mine to introduce go.mod files, but 
as I understand it that won't be enough for those above v1.

On Friday, February 23, 2018 at 2:22:32 AM UTC-5, David Anderson wrote:
>
> I'm curious how we could upstream the changes I had to make to client-go. 
> I had to rename module-internal imports, which will break existing non-vgo 
> uses of the library, but vgo offers no alternative to this renaming that 
> I'm aware of. It looks to me like there's no graceful upgrade path for this 
> module. The repo structure works either for pre-vgo clients, or for vgo, 
> but not both at once.
>

-- 
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 += Package Versioning

[Nicolas Grilly]

On Fri, Feb 23, 2018 at 8:20 AM, David Anderson  wrote:

> The date+hash format is irritating to construct by hand, but could be
> trivially lifted into a tool (perhaps even vgo itself).
>

Very true. I suffered from the same issue while trying vgo. This could be
improved to ease the adoption of vgo by projects with many dependencies
that are not already compatible with vgo semver.

-- 
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] http.shutdownPollInterval documentation

[Sridhar]

Thanks. I was fairly certain that's what it meant. 

Wasting more time, the pedant in me argues - but 

"Left as an exercise for the reader" generally implies it's a solved 
problem and the reader is to take time to re-solve to hone their skills.
  
 

On Friday, 23 February 2018 00:50:24 UTC, Ian Lance Taylor wrote:
>
> On Thu, Feb 22, 2018 at 1:50 PM, Sridhar  > wrote: 
> > 
> > In https://golang.org/src/net/http/server.go the documentation for 
> > shutdownPollInterval (admittedly unexported) reads: 
> > 
> > // Ideally we could find a solution that doesn't involve polling, 
> > 
> > // but which also doesn't have a high runtime cost (and doesn't 
> > 
> > // involve any contentious mutexes), but that is left as an 
> > 
> > // exercise for the reader. 
> > 
> > Is this a remnant from a book on Go ? If so which one ? 
>
> It's not from a book.  "Left as an exercise for the reader" is just a 
> saying.  It means, approximately, "we're not sure how to do it, but if 
> you can figure it out, please send a fix." 
>
> 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.

[go-nuts] Re: Appreciating Go

[Doğan Kurt]

Go is great because it's creators are great. Being smart alone doesn't mean 
anything. Bjarne Stroustrup is smart. It takes a good taste, a lot of first 
hand experience and many other things.

Simplicity is the main characteristic of Go. Let's see where it comes from; 

Ken Thompson is a walking simplicity. He practically created unix 
philosophy [1]. How the computing industry would look like without him? It 
would be quite different i believe.

I don't know how many times i've read or heard of the importance of 
simplicity from Rob Pike. His book with Kernighan, *The practice of 
programming*, which is my favorite book, has simplicity in it's cover.

Robert Griesemer is from Wirthian school, a student of Niklaus Wirth. I 
believe Niklaus Wirth is the one single person who emphasizes simplicity 
the most. There is even a book about it [2].

We are very fortunate to have Robert in Go team. One could only dream such 
a great merge of the pragmatism and practicality of Unix languages and 
elegance of Wirthian languages. Sure unix team was aware of Wirth's work 
but there is no doubt that the real influence came with Robert. 

If the both schools didn't see simplicity as the primary value, Go would be 
a union of both instead of an intersection.

I see people think Go is merely a language from Google, it's unfortunate. 
Let's recognize the creators.

Thank you:

Ken Thompson
Rob Pike
Robert Griesemer
Russ Cox
Ian Lance Taylor

and rest of the Go team.

[1] https://www.jwz.org/doc/worse-is-better.html
[2] https://www.amazon.com/dp/1558607234

-- 
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: Build started to fail with 1.10

[Dave Cheney]

The failing line was added in december last year,

https://github.com/golang/go/commit/7cba779cea5#diff-56c7df71bce32f8e50115128ae30941eR13

This also adds a dependency on time.h. Is time.h available in your build 
container?

On Friday, 23 February 2018 20:09:02 UTC+11, Владислав Митов wrote:
>
> Nah, it's not that - https://travis-ci.org/miracl/gomiracl/jobs/345158452. 
> If fails also in golang:latest where the yaml gotcha it's not a thing. 
> Solid suggestion though, thanks.
>
> On Friday, February 23, 2018 at 11:02:59 AM UTC+2, Владислав Митов wrote:
>>
>> Ah, I read about that but ti says `go version go1.10 linux/amd64`. I'll 
>> try putting it in quotes now.
>>
>> On Friday, February 23, 2018 at 1:57:53 AM UTC+2, Nic Pottier wrote:
>>>
>>> This is almost certainly because your .travis file is specifying your 
>>> version as `1.10` vs `"1.10"`
>>>
>>> So your build is building with go 1.1 instead of 1.10.
>>>
>>> Ran into this myself this morning.
>>>
>>> -Nic
>>>
>>> On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов 
>>> wrote:

 Hey guys, 

 One of my build started failing with 1.10. Basically I'm building a 
 wrapper around a C library and it fails with: 

 # runtime/cgo
 gcc_libinit.c: In function '_cgo_try_pthread_create':
 gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
   struct timespec ts;
   ^~
 gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
 [-Werror=implicit-function-declaration]
nanosleep(, nil);
^
 gcc_libinit.c:97:18: error: unused variable 'ts' 
 [-Werror=unused-variable]
   struct timespec ts;
   ^~
 cc1: all warnings being treated as errors
 https://travis-ci.org/miracl/gomiracl/jobs/344782123

 Any hint's what's causing this? 

 Cheers, 
 Vladi

>>>

-- 
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] vgo with package path without dot

[wilk]

Hi,

I work with GOPATH per project.

Then I use to give them a one word path directly under src:

$GOPATH/src/myapp

But I found that it doesn't work with vgo. It looks at 
/usr/local/go/src/ instead of my GOPATH.
The same when i use replace with a clone of a libs.

If there is a dot in the package name it works

$GOPATH/src/my.domain/myapp/

Should i submit an issue or shoud i forget quickly this bad practice ?

-- 
William

-- 
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] All goroutines hung in futex / sleep

[Michael Andersen]

Ok I found the problem. A tight loop was indeed preventing the garbage
collector from proceeding, and then the GC was stopping everything else.
The loop contained atomic.LoadUint64 and atomic.CompareAndSwapUint64, but
neither of those seem to qualify as preemption points. Fixing that loop
fixes everything.

Thanks to Ian for pointing me on the right path and thanks to Florin Pățan
on gophers.slack.com for pointing me at Delve which eventually let me find
the problematic code.

I know this is not at all the job of the race detector, but given that
compiling with -race is the first thing we do when a program experiences
"deadlock" type behavior, and I have seen several people being thrown off
by the way go behaves when there are tight loops, can we not detect that
the GC has stalled for way too long and print something out? Like
"Goroutine #545 is preventing GC" or something? Just a thought.

Thanks
Michael

On Thu, Feb 22, 2018 at 11:09 PM, Michael Andersen 
wrote:

> I have found that GODEBUG=schedtrace still prints when the program is
> frozen but I cannot find much documentation on deciphering its output. The
> full output is here: https://gist.github.com/immesys/
> 7f213c63c54ce60ba72d1cbc9ffcc4cb but here are the first few lines. It
> looks like this is garbage collector related?
>
> SCHED 111364ms: gomaxprocs=40 idleprocs=0 threads=78 spinningthreads=0
> idlethreads=65 runqueue=31 gcwaiting=1 nmidlelocked=1 stopwait=1
> sysmonwait=0
> P0: status=3 schedtick=36699 syscalltick=29158 m=-1 runqsize=0 gfreecnt=45
> P1: status=3 schedtick=37370 syscalltick=30563 m=-1 runqsize=0 gfreecnt=31
> P2: status=3 schedtick=36650 syscalltick=29478 m=-1 runqsize=0 gfreecnt=17
> P3: status=3 schedtick=42395 syscalltick=34028 m=-1 runqsize=0 gfreecnt=38
> P4: status=3 schedtick=40531 syscalltick=33546 m=-1 runqsize=0 gfreecnt=27
> P5: status=3 schedtick=41369 syscalltick=31884 m=-1 runqsize=0 gfreecnt=19
> P6: status=3 schedtick=39302 syscalltick=32162 m=-1 runqsize=0 gfreecnt=39
> P7: status=3 schedtick=39739 syscalltick=32624 m=-1 runqsize=0 gfreecnt=34
> P8: status=3 schedtick=32585 syscalltick=24358 m=-1 runqsize=0 gfreecnt=45
> P9: status=3 schedtick=40376 syscalltick=30399 m=-1 runqsize=0 gfreecnt=27
> P10: status=3 schedtick=31018 syscalltick=22164 m=-1 runqsize=0 gfreecnt=40
> P11: status=3 schedtick=32043 syscalltick=24479 m=-1 runqsize=0 gfreecnt=53
> P12: status=3 schedtick=36459 syscalltick=25222 m=-1 runqsize=0 gfreecnt=21
> P13: status=3 schedtick=38445 syscalltick=28317 m=-1 runqsize=0 gfreecnt=38
> P14: status=3 schedtick=39533 syscalltick=28189 m=-1 runqsize=0 gfreecnt=29
> P15: status=3 schedtick=37009 syscalltick=27231 m=-1 runqsize=0 gfreecnt=29
> P16: status=3 schedtick=36957 syscalltick=26211 m=44 runqsize=0 gfreecnt=45
> P17: status=3 schedtick=35632 syscalltick=26481 m=-1 runqsize=0 gfreecnt=48
> P18: status=3 schedtick=36228 syscalltick=24751 m=-1 runqsize=0 gfreecnt=59
> P19: status=3 schedtick=32479 syscalltick=22970 m=-1 runqsize=0 gfreecnt=48
> P20: status=3 schedtick=34090 syscalltick=25864 m=-1 runqsize=0 gfreecnt=12
> P21: status=3 schedtick=35409 syscalltick=24369 m=-1 runqsize=0 gfreecnt=6
> P22: status=3 schedtick=42235 syscalltick=28607 m=-1 runqsize=0 gfreecnt=16
> P23: status=3 schedtick=29733 syscalltick=19429 m=-1 runqsize=0 gfreecnt=43
> P24: status=3 schedtick=34757 syscalltick=22141 m=-1 runqsize=0 gfreecnt=26
> P25: status=3 schedtick=31434 syscalltick=21767 m=-1 runqsize=0 gfreecnt=23
> P26: status=3 schedtick=31597 syscalltick=21657 m=-1 runqsize=0 gfreecnt=53
> P27: status=3 schedtick=32539 syscalltick=22653 m=-1 runqsize=0 gfreecnt=34
> P28: status=3 schedtick=29503 syscalltick=20588 m=-1 runqsize=0 gfreecnt=28
> P29: status=3 schedtick=30842 syscalltick=20199 m=-1 runqsize=0 gfreecnt=41
> P30: status=3 schedtick=29787 syscalltick=19492 m=-1 runqsize=0 gfreecnt=15
> P31: status=3 schedtick=28226 syscalltick=19101 m=-1 runqsize=0 gfreecnt=32
> P32: status=3 schedtick=34254 syscalltick=24135 m=-1 runqsize=0 gfreecnt=27
> P33: status=3 schedtick=34567 syscalltick=22554 m=-1 runqsize=0 gfreecnt=36
> P34: status=3 schedtick=30416 syscalltick=19722 m=-1 runqsize=0 gfreecnt=33
> P35: status=1 schedtick=19536 syscalltick=13084 m=0 runqsize=0 gfreecnt=50
> P36: status=3 schedtick=29336 syscalltick=19015 m=-1 runqsize=0 gfreecnt=28
> P37: status=3 schedtick=29794 syscalltick=19499 m=-1 runqsize=0 gfreecnt=40
> P38: status=3 schedtick=31748 syscalltick=20359 m=-1 runqsize=0 gfreecnt=35
> P39: status=3 schedtick=31851 syscalltick=20260 m=-1 runqsize=0 gfreecnt=46
>
>
>
> On Thu, Feb 22, 2018 at 8:47 PM, Michael Andersen 
> wrote:
>
>> Hi
>>
>> Thanks for your suggestions. This freeze happens to coincide with a
>> larger number of cgo calls which in turn most likely do blocking read/write
>> from sockets. How are those treated by the scheduler?
>>
>> I am not doing anything FUSE related, nor do I have assembly code. The
>> only 

[go-nuts] Re: Build started to fail with 1.10

[Владислав Митов]

Nah, it's not that - https://travis-ci.org/miracl/gomiracl/jobs/345158452. 
If fails also in golang:latest where the yaml gotcha it's not a thing. 
Solid suggestion though, thanks.

On Friday, February 23, 2018 at 11:02:59 AM UTC+2, Владислав Митов wrote:
>
> Ah, I read about that but ti says `go version go1.10 linux/amd64`. I'll 
> try putting it in quotes now.
>
> On Friday, February 23, 2018 at 1:57:53 AM UTC+2, Nic Pottier wrote:
>>
>> This is almost certainly because your .travis file is specifying your 
>> version as `1.10` vs `"1.10"`
>>
>> So your build is building with go 1.1 instead of 1.10.
>>
>> Ran into this myself this morning.
>>
>> -Nic
>>
>> On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов 
>> wrote:
>>>
>>> Hey guys, 
>>>
>>> One of my build started failing with 1.10. Basically I'm building a 
>>> wrapper around a C library and it fails with: 
>>>
>>> # runtime/cgo
>>> gcc_libinit.c: In function '_cgo_try_pthread_create':
>>> gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
>>>   struct timespec ts;
>>>   ^~
>>> gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
>>> [-Werror=implicit-function-declaration]
>>>nanosleep(, nil);
>>>^
>>> gcc_libinit.c:97:18: error: unused variable 'ts' 
>>> [-Werror=unused-variable]
>>>   struct timespec ts;
>>>   ^~
>>> cc1: all warnings being treated as errors
>>> https://travis-ci.org/miracl/gomiracl/jobs/344782123
>>>
>>> Any hint's what's causing this? 
>>>
>>> Cheers, 
>>> Vladi
>>>
>>

-- 
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: Build started to fail with 1.10

[Владислав Митов]

Ah, I read about that but ti says `go version go1.10 linux/amd64`. I'll try 
putting it in quotes now.

On Friday, February 23, 2018 at 1:57:53 AM UTC+2, Nic Pottier wrote:
>
> This is almost certainly because your .travis file is specifying your 
> version as `1.10` vs `"1.10"`
>
> So your build is building with go 1.1 instead of 1.10.
>
> Ran into this myself this morning.
>
> -Nic
>
> On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов wrote:
>>
>> Hey guys, 
>>
>> One of my build started failing with 1.10. Basically I'm building a 
>> wrapper around a C library and it fails with: 
>>
>> # runtime/cgo
>> gcc_libinit.c: In function '_cgo_try_pthread_create':
>> gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
>>   struct timespec ts;
>>   ^~
>> gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
>> [-Werror=implicit-function-declaration]
>>nanosleep(, nil);
>>^
>> gcc_libinit.c:97:18: error: unused variable 'ts' 
>> [-Werror=unused-variable]
>>   struct timespec ts;
>>   ^~
>> cc1: all warnings being treated as errors
>> https://travis-ci.org/miracl/gomiracl/jobs/344782123
>>
>> Any hint's what's causing this? 
>>
>> Cheers, 
>> Vladi
>>
>

-- 
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 += Package Versioning

[Henrik Johansson]

A sidenote is that there seems to always be issues with using kubernetes
client.
Is it structured very un Go-ish?

Very nice writeup!

NB: I was also hit by the casing issue with the same viper dependency.

fre 23 feb. 2018 kl 08:28 skrev David Anderson :

> I should add: even though I spent several hours working through these
> issues, I feel very happy about the process and outcome. I have high
> confidence that I understand what vgo is doing with my module spec, and
> that I know how to tweak its thinking in future. I would contrast this with
> my experience with Glide. Last weekend, I tried to `glide up` this same
> project, and spent 4 hours trying to resolve the resulting mayhem of
> diamond dependencies and build errors. I failed, rolled back the change,
> and decided MetalLB could stay on old code for a while longer. I still have
> very low confidence that I understand what glide will do when I `glide up`,
> or that it will produce a working result.
>
> Additionally, some of the time spent is likely the learning curve. As
> https://github.com/golang/go/issues/24032 illustrates, I was initially
> confused and had to re-read some of rsc's writing to formulate my plan of
> action. Despite that, I still spent less time end to end than with glide,
> and I had a working build at the end of it.
>
> - Dave
>
> On Thu, Feb 22, 2018 at 11:20 PM, David Anderson  wrote:
>
>> This is an experience report onboarding vgo for a relatively complex
>> project (multiple binaries, vast import tree, tricky unidiomatic imports).
>> I leave it here in the hopes that it guides other people, and potentially
>> illustrates places where vgo falls short of great. TL;DR it went pretty
>> well, modulo a couple of UX speed bumps.
>>
>> The result is the `vgo-test` branch of https://github.com/google/metallb/
>> . Cloning that repository should allow you to `vgo test ./...`, `vgo build
>> ./controller`, `vgo build ./speaker`, and a few others. I don't make any
>> representation that the code does what it should, merely that it builds and
>> passes tests.
>>
>> The resultant go.mod,
>> https://github.com/google/metallb/blob/vgo-test/go.mod , is quite messy.
>> This is mostly due to the number of dependencies that have no semver at
>> all, forcing vgo to use commit hash "versions". The result is a lot of
>> visual noise in the file, but hopefully that will improve over time as both
>> vgo and dep nudge people towards semver releases.
>>
>> I encountered two major roadblocks on the road to `vgo test ./...`: the
>> Kubernetes client library, and mixed case packages. These are
>> https://github.com/golang/go/issues/24032 and
>> https://github.com/spf13/jWalterWeatherman/issues/22 respectively.
>>
>>
>> The Kubernetes client library is a worst case scenario for vgo. It
>> releases a new major version every 3 months under the same module name,
>> with real incompatibilities between versions; and it relies extensively on
>> a transitive version lock to force a specific package selection on its
>> dependents. Making this library usable from vgo required the following:
>>
>>- Fix up client-go in a fork
>>   - Fork github.com/kubernetes/client-go to
>>   github.com/danderson/client-go
>>   - Add a go.mod to the fork, containing only: module "
>>   k8s.io/client-go/v6"
>>   - Update all internal self-references within client-go: perl -pi
>>   -e 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
>>   - Commit the result,
>>   
>> https://github.com/danderson/client-go/commit/7d8481153a9edbf8eacc176ce29f8d58949c3a77
>>   . Tag as v0.0.0-vgo-prototype-compat and push.
>>- Make my repository use my fork of client-go:
>>   - Update all uses of client-go to the new versioned package name: perl
>>   -pi -e 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
>>   - Require the right version in mod.go: require "k8s.io/client-go/v6"
>>   v6.0.0
>>   - Replace upstream with my fork in mod.go: replace "
>>   k8s.io/client-go/v6" v6.0.0 => "github.com/danderson/client-go"
>>   v0.0.0-vgo-prototype-compat
>>
>> I'm curious how we could upstream the changes I had to make to client-go.
>> I had to rename module-internal imports, which will break existing non-vgo
>> uses of the library, but vgo offers no alternative to this renaming that
>> I'm aware of. It looks to me like there's no graceful upgrade path for this
>> module. The repo structure works either for pre-vgo clients, or for vgo,
>> but not both at once.
>>
>> The UX was lacking to explain the reason for failures, before I made any
>> of the changes. Given just my repository, vgo inferred that I wanted v1.5.2
>> of client-go (3+ years old), continued resolving dependencies, and
>> eventually barfed when it found an import for a client-go subpackage that
>> didn't exist in 1.5.2. The error was simply a bunch of "no such file or
>> directory", and required some head-scratching to